6/24/2013 hct organisation new information system test ... · 6/24/2013 hct organisation new...

6/24/2013

HCT ORGANISATION NEW INFORMATION

SYSTEM TEST PLAN AND IPLEMENTATION –

Black Box and White Box Testing

LEUTELE LM GREY – AUTHOR/STUDET

WHITIREIAN NZ: FACULTY OF BUSINESS AND INFORNMATION TECHNOLOGY

POST GRADUATE DIPLOMA

2013

SEMESTER ONE

IT8418 SOFTWARE QUALITY ASSURANCE

AND SOFTWARE TESTING

CONTRIBUTED FOR THE EDUCATION OF CURRENT AND FUTURE

YOUNG PEOPLE OF SAMOA.

WITH LOVE

LEUTELE LUCIA MARIA GREY

Leutele Leutele L.M.Grey:2002607

1

1

Table of Contents Executive Summary ................................................................................................................. 4

Test Results: STRATEGY01BBTDeskCheck ....................................................................... 4

Test Results: STRATEGY01BBT ........................................................................................ 4

Test Results: STRATEGY02WBT ........................................................................................ 4

Conclusion ............................................................................................................................. 4

Recommendation ................................................................................................................... 5

PART I - TEST PLAN OVERVIES ....................................................................................... 5

1.2. Organisation Background ........................................................................................ 5

1.3. The Systems Functional Requirement ..................................................................... 6

1.4. The Functional Specification ................................................................................... 6

1.5. HCT Source Code (Script) ...................................................................................... 6

1.6. HCT Database Logical Model ................................................................................. 6

1.7. Test Strategy ............................................................................................................ 6

1.8. What is not tested? ................................................................................................... 7

PART 2: TEST PLAN AND IMPLEMENTATION – BBT & WBT ............................... 7

2.1. Introduction ............................................................................................................. 7

2.2. BBT and WBT Strategies and Techniques .............................................................. 8

2.3. SECTION 1 - STRATEGY01BBTDESKCHECK ................................................. 8

2.3.2. HCT System Changes Document ............................................................................ 8

2.3.3. Results Stategy01BBTDeskCheck ........................................................................ 10

2.3.4. Recommendations ................................................................................................. 11

2.4 SECTION 2 – STRATEGYBBT01 ....................................................................... 11

2.5 BBT ‘Employee’, ‘Trainer’ and Administrator’, ................................................... 12

2.5.2. Employees Results ................................................................................................. 13

2.6. BBT Entity Trainer ................................................................................................ 13

2.6.2. Trainers Results ..................................................................................................... 14

2.7. BBT Entity Administrator ..................................................................................... 14

2.7.2 Administrators Results ......................................................................................... 15

2.8 BBT Entity Client .................................................................................................. 15

2.8.2. Client Results ......................................................................................................... 16

2.9. BBT Entity HCTEvents ......................................................................................... 16

2.9.2 HCTEvents Results............................................................................................... 17

2.10. BBT Entity Registrations ...................................................................................... 17

2.10.2. Registration Results ............................................................................................... 18


2

2

2.11. BBT EventSessions ............................................................................................... 19

2.11.2. EventSession Results ........................................................................................... 20

3. SECTION 3 - STRATEGY02WBT ...................................................................... 20

3.2. Testing Security ..................................................................................................... 20

3.3 Test Observation .................................................................................................... 20

3.4. White Box Test Plan Template .............................................................................. 21

3.5. WBT Employees Entity ......................................................................................... 21

3.5.2. Employees Results ................................................................................................ 22

3.6. WBT - Trainers Entity ........................................................................................... 22

3.6.2. Trainer Results ....................................................................................................... 23

3.7. WBT - Administrators Entity ................................................................................ 23

3.7.2. Administrators Results ............................................................................................... 24

3.8. WBT – Client Entity .............................................................................................. 24

3.8.2. Client Results ......................................................................................................... 25

3.9. WBT - HCTEvents Entity ..................................................................................... 25

3.9.2. HCTEvents Results................................................................................................ 26

3.10. WBT - Registration Entity ..................................................................................... 26

3.10.2. Registrations Results .............................................................................................. 27

3.11. WBT –EventSession Entity ................................................................................... 27

3.11.2. EventSession Results .......................................................................................... 28

PART III: RESULTS, CONCLUSIONS & RECOMMENDATIONS ............................. 28

4. Test Plan Overview ............................................................................................... 28

4.2 What is not tested? ................................................................................................. 29

4.3. BBT and WBT Strategies and Techniques ............................................................ 29

4.4. PART 2 - SECTION 1. STRATEGY01BBTDESCKCHECK ............................ 29

4.5. Results ................................................................................................................... 29

4.6. PART 2 - SECTION 2 – STRATEGY01BBT ....................................................... 29

4.7. Entities ‘Employees’, ‘Trainers’ and Administrators’ .......................................... 30

4.8. Results ................................................................................................................... 30

4.9. Entity Trainer ......................................................................................................... 30

4.10. Results ................................................................................................................... 30

4.11. Entity Administrator .............................................................................................. 30

4.12. Results ................................................................................................................... 30

4.13. Entity Clients ......................................................................................................... 31

4.14. Results ................................................................................................................... 31

4.15. Entity HCTEvents.................................................................................................. 31

4.16. Results ................................................................................................................... 31


3

3

4.17. Entity Registrations ............................................................................................... 31

4.18. Results ................................................................................................................... 31

4.19. Entity EventSessions ............................................................................................. 32

4.20. Results ................................................................................................................... 32

4.7. PART 2 - SECTION 3 – STRATEGY02WBT ..................................................... 32

4.7.2. Test Observation .................................................................................................... 32

4.7.3 White Box Test Plan Template .............................................................................. 32

4.7.4 Entity Employees ................................................................................................... 32

4.7.5. Results ................................................................................................................... 33

4.7.6. Trainer Entity ......................................................................................................... 33

4.7.7. Results ................................................................................................................... 33

4.7.8. Administrators Entity ............................................................................................ 33

4.7.9. Results ................................................................................................................... 33

4.7.10. Client Entity ........................................................................................................... 33

4.7.11. Results ................................................................................................................... 33

4.7.12. HCTEvents Entity.................................................................................................. 33

4.7.13. Results ................................................................................................................... 34

4.7.14. Registration Entity ................................................................................................. 34

4.7.15. Results ................................................................................................................... 34

4.7.16. EventSession Entity ............................................................................................... 34

4.7.17. Results ................................................................................................................... 34

6. Conclusions .............................................................................................................. 34

7. Recommendations ................................................................................................... 34

8. References ................................................................................................................ 35

Appendix 1 –HCT Requirement /Specification Document ................................................ 35

Appendix 2 – Harbour City Trainer System Changes ....................................................... 36

Appendix 3 - The Harbour City Trainers Logical Model .................................................. 37

Appendix 4 – Harbour City Trainers SQL Script (Code).................................................. 39


4

4

Report: Information System Test Plan and Implementation – Black Box

and White Box Testing - for Harbour City Trainer (HCT) System’s

Database

Executive Summary

The purpose of this assignment is to develop a test plan and test the complete set up HCT

Microsoft SQL database. There are two parts to this HCT System: (1) Microsoft SQL Database

and (2) the HCT Website. The HCT Website has not been created yet which means that the

HCT system is being partially tested. The testing involves developing a test plan and executing

it on the given database system, reporting on the results of the tests, and recommending the

changes needed to correct the faults found in the system. The testing strategies adopts the basic

Black Box Testing (BBT) and White Box Testing (WBT) generic functional and behavioural,

administrator accessibility, error spotting and matching of the HCT documents against SQL

inputs and outputs.

Findings

It was found that because the Website is not part of this test plan, it is possible that the security

and navigational challenges will derived from the designing structure of the logical model due

to the fragmented states of tables: HCTEvents, EventSessions, Registration and Clients.

Further, the largest portion of the system which involves testing the site interface, the

navigational tree and linkages to the database are excluded from this test plan. Types of external

and internal functionality problems that could affect all users interactions included: ease of

access, ease of navigation, user friendly aspects, and security. The testing results are as follow:

Test Results: STRATEGY01BBTDeskCheck

There have been several changes made to the customer requirement document. The usage of

the term ‘event’ rather than ‘course’ may cause a bit of confusion if the Client Registration

details go live. There is no mention of alternative arrangements for course venues. Also

significant changes have occurred where the employees, trainers and administrators roles and

rewards are concern.

Test Results: STRATEGY01BBT

The SQL Script has been written and executed accurately on the Microsoft SQL Server.

Test Results: STRATEGY02WBT

The SQL script has been written and executed accurately on the Microsoft SQL server.

Conclusion


5

5

The test plan and strategies adopted basic generic functional and behavioural, administrator

accessibility, error spotting and matching of the documents against inputs and outputs. The

overall HCT database system testing strategies yielded free of error results.

Recommendation

Although the BBT and WBT test results are error free, it yielded important challenges in that

the customer software product has been partially tested. Therefore, it should be expected that

tremendous changes may be required once the full product is ready to be fully tested. It is

recommended that the software development team, reviewed the Customer Requirements

document to ensure that the customer has approved the following changes:

Courses Arrangements

Client Venues/Accommodations for International Clients

The roles and payment arranges for the Managers, Trainers, and Administrators

Contractors Roles and payment

Billing Tasks

Types of courses

Finally, to improve user online interactions the development team need to review the

designed structure of the following tables:

HCTEvent

EventSessions

Registrations

Clients

PART I - TEST PLAN OVERVIES

1.1 Introduction

1.1.1 There are two parts to this HCT System: (1) the Microsoft SQL Database and (2) the

HTC Website. The HCT Website has not been built yet which means the HCT system is

partially tested. The purpose of this assignment is to develop a test plan and strategies in order

to test the complete set up HCT Microsoft SQL database. The two basic software testing

techniques namely BBT and BWT are being utilized. The test plan results and

recommendations on the given database system are being provided in this report.

1.2. Organisation Background

1.2.1. The HCT is a Wellington small organisation that is experiencing expansion. The

business provides specialist Information Technology training on the construction of software

applications using the Oracle tools and is attracting interest from large companies both

nationally and in Australia. The HCT wishes to tap in to its niche markets and in order to

achieve business objectives the company need to build a web site that allows potential clients


6

6

to register for any course they wish. However, to enable building this new web site, the

company needs to automate the current system which requires constructing and creating of the

appropriate database .To fulfil the requirements for this assignment, a software database system

written in Microsoft SQL Server has been built and is provided. Along with the complete

Microsoft SQL Database and the Visual Basic Software, the core material resources consulted

in this course included: the HCT case study document, the HCT Systems Change document,

the systems logical model and the HCT Script (Code).

1.3. The Systems Functional Requirement

1.3.1. This document is the initial systems requirement which outlines the customer systems

functional requirement and business rules refer (Appendix 1: The Harbour City Case Study –

Customer Requirements).

1.4. The Functional Specification

1.4.1 The functional specification is the "How" of the product which identifies how the new

features will be implemented. This document includes items such as what database tables a

particular search will query. This document is critical to quality assurance because it is used to

build the Test Plan. The quality assurance is often involved in reviewing the functional

specification for clarity and helping to define the business rules (refer Appendix 2: HCT

Changes).

1.5. HCT Source Code (Script)

1.5.1. This document is the official source code for the new HCT database which will be

tested in this testing exercise. The source code was written and set up to build the HCT

new Database with using the Microsoft SQL Server Software 2012 and connect to the

Visual Basic Software 2012 (refer Appendix 3 – The HCT Script (Code).

1.6. HCT Database Logical Model

1.6.1. This logical model was designed and implemented in conjunction with the HCT

Script/Source Code refer (Appendix 4: The HCT Database Logical Model).

1.7. Test Strategy

The main testing strategy is outlined in Figure 1.


7

7

Figure 1:HCT Testing Strategy

1.8. What is not tested?

1.8.1. This testing project focus on testing the newly created Microsoft SQL database only.

Because the Website has not been created, this means that the largest portion of the testing

which involves the site interface, navigational tree and linkages to the database will not be

tested. User ease of access and user friendly aspects, security and internal and external

interaction functionalities for both potential applicants and clients with the Administrators are

not available for testing. Testers are not able to access the internal source codes. This means

that the this testing exercise focused on basic generic functional and behavioural, administrator

accessibility, error spotting and matching of the documents against inputs and outputs. The rest

of this report is structured as follow: Part two of the report is divided in to three different testing

strategies including (1) Desk Check and implementation (2) BBT and implementation (3) WBT

and implementation. Part 3 provides the Summary/Conclusions and Recommendations.

PART 2: TEST PLAN AND IMPLEMENTATION – BBT & WBT

2.1. Introduction

2.1.1. There are two most important parts to the HCT Systems Project: (1) the newly built

database which is about to be tested and (2) is the HCT website which has not been built. This

provides testing limitations where the potential users and clients are concern. For example, the

potential applicants who may wish to apply for a trainer or the administrator position will have

to apply through the HCT new website to access the online employee application form.


8

8

Similarly the potential clients may have to register for a particular course using the online client

registration form. Hence the online interaction between the HCT administrator, the client

and/or the applicant. In this report we are only testing the database which is not accessible by

the external users accept for the administrator. For this reason, types of BBT and WBT testing

strategies that are being used involves matching up the scripts and other documents against the

Microsoft SQL server inputs and outputs and data that is accessible through Visual Basic 2012.

2.2. BBT and WBT Strategies and Techniques

2.2.0. The testing strategies for BBT and WBT being utilized throughout this entire testing

exercises are listed below. Each test strategy has been allocated a unique strategy number:

2.2.0.1. Strategy01BBTDeskCheck,

2.2.0.2. Strategy01BBTDatabaseSetUp

2.2.0.3. Strategy01BBTFunctionalTesting

2.2.0.4. Strategy01BBTBehaviouralTesting

2.2.0.5. Strategy02WBTUsability,

2.2.0.6. Strategy02WBTSecurity

2.2.0.7. Strategy02WBTErrorSpotting

The Testing begins with Stategy01BBTDeskCheck.

Table 1: BBT and WBT Strategies and Techniques

2.3. SECTION 1 - STRATEGY01BBTDESKCHECK

2.3.1. The Strategy01BBTDeskCheck involves matching up the HCT Systems Changes

(Specifications) against the HCT Case Study document (Customer Requirement Document).

Assuming that the testers have no knowledge of the customer needs and the programmers’

source code design and implementation, the key objective of this desk check is to find out if

the finished software matches the customer requirement?

2.3.2. HCT System Changes Document

2.3.2.1. The following design changes have been made to the current system which now

needs testing:


9

9

2.3.2.1.0. The design has been simplified. Details relating to Courses, Course

Offerings and Venues will no longer be recorded. All details relating to these tables

have been removed from the data models. Invoice details will be dealt with by another

system and have therefore been removed.

2.3.2.1.1. HCT now provide both Oracle Database and Microsoft SQL Server

training. A column called Specialisation has been added to the Events table to record

this detail. Specialisation is recorded as either ‘Oracle’ or ‘Microsoft’. The level of

training provided on an event is also to be recorded in the Events table. The level of an

event is described as ‘Beginner’, ‘Intermediate’ or ‘Advanced’.

2.3.2.1.2. It is no longer necessary to distinguish clients by type, as most of HCT’s

clients are now contractors. The name of the business and employee total is now to be

recorded in optional columns if the client is an organisation. All other client details have

been collapsed into a single table. The column called Specialisation records whether a

client seeks Microsoft SQL Server or Oracle Database training. As in the Events table,

‘Oracle’ or ‘Microsoft’ should be the only valid values for this column. Also like the

Events tables, a column called Level will be used to record whether the client seeks

‘Beginner’, ‘Intermediate’ or ‘Advanced’ level training.

2.3.2.1.3. It has now been deemed necessary to distinguish between different types

of employees. Employees are either ‘Trainers’ or ‘Administrators’. The column

EmpType is used to distinguish between each type of employee. This column appears

in Employees, Trainers and Administrators.

2.3.2.1.4. Managers can be either trainer or administrator type employees. Trainers

deliver event sessions and administrators register clients. Trainers are either Microsoft

Certified Professionals (MCP) or Oracle Certified Professionals (OCP). A column

called Certification will now be used to record this detail. The column called Position

is used to record whether a trainer is designated as either a ‘Trainer’ or ‘Consultant’

level trainer. Administrators do not have either certification or position details, but a

column recording whether or not they have been awarded a bonus (records either ‘Y’ -

yes or ‘N’ - No). Trainers are not awarded bonuses.

2.3.2.1.5. The Trainer table will record details specific to only Trainer type

employees and the Administrator table records details specific only to Administrators.

The Employee tables records details that are generic to both Administrators and

Trainers. Administrators cannot be both administrators and trainers and trainers cannot

be both trainers and administrators i.e. their roles are mutually exclusive. In addition,

the following business rules also apply:

2.3.2.1.5.0. Only administrator type employees can register clients for an

event.


10

10

2.3.2.1.5.1. Clients can only register for events that match their recorded

specialisation and level details.

2.3.2.1.5.2. Trainers can only deliver sessions for events whose

specialisation matches the trainer’s certification e.g. only OCP certified trainers

are allowed to deliver sessions for Oracle events.

2.3.2.1.5.3. Only Consultant level trainers can deliver sessions for advanced

level events.

2.3.3. Results Stategy01BBTDeskCheck

2.3.3.0. Business policies and rules are formulated to enable implementing the business

requirements. The HCT initial Requirements give rises to assumptions that this appears to be

seasonal courses and that staff members are only call-in during the scheduling time raised

concerns particularly where implementing business rules of the organisation is concern. For

example, if the staff members work part time, therefore the bonus rewarding system covers

both administrators and trainers of the company. The requirements seemed to say that the same

person can be a trainer or administrator and does the registration and training duties all in one

go. The same thing applies to the billing transactions, which is the reason the

Administrator/Trainer does all these jaws. The courses and venues have been removed and

have not been mentioned at all anywhere in the modified program. Are these expected to be

add in later in the Website?

2.3.3.1. Change 2.3.2.1.0 involves courses offerings, venues and invoice details which have

been removed from the data model and replaced by several tables including: HCTEvents,

Registrations and EventSessions. The modified SQL database does not show alternative

options for HCTEvents or EventSession venue. The term course goes together with training

which makes Events sounds bit confusing particularly when it is set on the actual online

Registration Form.

2.3.3.2. Change 2.3.2.1.1 involves an additional training programme which is Microsoft SQL

Server which is not mentioned in the Customer Requirements Case study document.

2.3.3.3. Changes 2.3.2.1.2; 2.3.2.1.3; 2.3.2. 1.4 & 2.3.2.1.5 all consists of modifications that

will affect initial arrangements and implementations of business rules of the business. The

requirement seemed to regard the Administrators to be the same as the trainer who may perform

client registration and can also train the clients. Which means that the trainer who is the same

as the administrator are advanced and qualified employees and there for both trainers and

administrator who are the same individuals may be entitled to the bonus anyway. If this is so,

then both the trainer and the administrator who is the same person who may be entitled to the

bonus is going to be unhappy for missing out on the bonus. There is no mentioned of any

consultant in the requirements, it can be a problem because the consultant may demand high

salary which the organisation may not be able to afford. It can also make the trainers and


11

11

administrators unhappy. It appears that the trainer or the administrator may be the one to set up

the registration and the course fees as well. I wonder if these roles should also be part of the

job description of the Administrator/Trainer who is the one and same person. The system is not

saying how to cater for the international clients who may wish to attend the courses. The course

offering is Oracle only, the requirement does not say anything about adding the Microsoft SQL

Server. Finally, the new system appears to be working fine, but the question remains, is the

finished product relevant to the requirements of the HCT? It is important for the systems

development team to review the specification functionalities and customer requirements with

the customers to ensure that the right software product is delivered to the customer in the end.

2.3.4. Recommendations

2.3.4.1. The probability of delivering the correct complete database system for the HCT

organisation relies heavily on whether or not the finished product is relevant to the

requirements of the HCT. Assuming that the company requires the website to be built as soon

as possible, this indicates that some of the data necessary to implement the HCT business rules

may have to be included in the new database. To ensure that the tested software system meets

the requirements of the HCT Company (Customer) it is recommended that Software

Development team review the Customer Requirements to ensure that the customer has

approved the following changes:

2.3.4.1.0. Courses Arrangements

2.3.4.1.1. Client Venues/Accommodations for International Clients

2.3.4.1.2. The roles and payment arranges for the Managers, Trainers, and

Administrators

2.3.4.1.3. Contractors Roles and payment

2.3.4.1.4. Billing Tasks

2.3.4.1.5. Types of courses

2.4 SECTION 2 – STRATEGYBBT01

2.4.1. The BBT technique (also called functional testing) is a type of testing that ignores the

internal mechanism of a system or component and focuses solely on the outputs generated in

response to selected inputs and execution conditions. A BBT Test plan designed template

illustrated in Table 2 provides the anatomy of each black box test case, however it cannot be

used in this testing exercise. The first column requires a unique identifier or test number.

Further it is extremely important that a specific clear description of the test case is provided.

The tester is required to describe the exact expected and the actual results. From these results

the tester should be able to determine whether or not the test case activity failed or passed. All

in all, testing should be considered as an iterative and essential part of the entire development

process focusing on early spotting of:

2.4.1.0. Incorrect or missing functionality;

2.4.1.1. Interface errors;


12

12

2.4.1.2. Errors in data structures used by interfaces;

2.4.1.3. Behaviour or performance errors; and

2.4.1.4. Initialization and termination errors

Table 2: BBT Test Plan Template

2.5 BBT ‘Employee’, ‘Trainer’ and Administrator’,

2.5.1. Since there is a direct correlation between the super type entity Employee and its

subtype entities Trainers and Administrators, this testing exercise focused on the Employees,

Trainers and Administrators entities. The entity SuperType ‘Employee’ represents the form for

which a potential client who may wish to register for a particular course/s may have to

complete. The super type employee consist of six attributes including: EmployeeID (PK1, U1),

EmpType(UI), Manager(FKI), Surname, Forename and StartDate. It’s two subtype entities are

Subtypes: Trainer whose attributes are EmployeeID (PK, FK1,Fk2,UI), Position (UI),

Certification(UI) and EmpType (FK2) and ‘Administrators’ whose attributes are: EmployeeID

(PK1,Fk1,Fk2); EmpType (FK2) and Bonus. These entities are depicted in Figures 3, 4 & 5.

Figure 3: Employees Entity Table


13

13

Figure 4: dbo.Employees SQL Input

Figure 5: dbo Employees SQL Output

2.5.2. Employees Results

2.5.2. The dbo.Employees SQL input data has been accurately set up. The EmployeeID

numbers are generated automatically by the software. The ‘Null’ function is used to block users

from seeing the field value as shown in the Manager entity. The check constraints ‘T’ or ‘A’

identifies and distinguish the difference between the Trainers and an Administrators. The

dbo.Employees input shows that the query has a 100% successful results which is shown by

the Message that 5 rows are affected in the transactions. The logical model also show this same

setting which was translated into the HTC Systems Source Code. When matching the SQL

Inputs/Outputs against the Visual Basic Forms, the results are identical.

2.6. BBT Entity Trainer

2.6.1. Both the Trainer and Administrator are subtype entities of the super type employee and

are organized in a specialization hierarchy. This means that both subtype entities many inherit

the attributes of the super type employee entity. This is reflected by the total completeness,

disjoint and overlapping constrains as depicted in Logical Model and symbolized by the letter

‘d’ in a circle over the ‘double line’. The manager attributes of the employee entity has a unary

or recursive relationship which means that the ‘employee’ has a relationship with itself. The

Trainer table records details specific only to the Trainer type as illustrated in Figure 6.7 & 8.


14

14

Figure 6: Entity 'Trainers' Table

Figure 7: dbo.Trainers SQL Input

Figure 8: dbo.Trainer SQL Output

2.6.2. Trainers Results

2.6.1. Registered Employees can access other employee information through the EmployeeID

Primary Key (PK) or Foreign Key (FK). Again, the check constraints ‘T’ or ‘A’ are set up to

identify each appropriate manager. The Position attribute fields are set up to accept either the

‘consultant’ or the ‘trainer’ constraints while the certification attributes constraints include

‘OCP’ or ‘MCP’. In this test case, only the sub type Trainer can access its Table. Finally the

UI Function Key appearing next to the ‘position’ and ‘certification’ attributes acts as another

security key to prevent users from accessing the Trainer information as shown in the in the

logical model. The SQL inputs and outputs shows identical accurate results.

2.7. BBT Entity Administrator

2.7.1. The entity Administrator table records details specific only to Administrators. The

Employee tables record details that are generic to both Administrators and Trainers.

Administrators cannot be both administrators and trainers, and trainers cannot be both trainers

and administrators i.e. their roles are mutually exclusive as illustrated in Figures 9,10 &11.


15

15

Figure 9: Administrators Table

Figure10: dbo.Administrators SQL Inputs

Figure 11: dbo.Administrator SQL Outputs

2.7.2 Administrators Results

2.7.2.1. The dbo.Administrator SQL inputs is aligned with the source code and correctly

set up. The employeeID is generated automatically by the SQL Software. Administrators do

not have either certification or position details, but a column recording whether or not they

have been awarded a bonus (records either ‘Y’ - yes or ‘N’ – No check constraints).The

EmpType functions is the unique identifier for the administrator employee.

2.8 BBT Entity Client

2.8.1 It is no longer necessary to distinguish clients by type, as most of HCT’s clients

are now contractors. The name of the business and employee total is now recorded in optional

columns if the client is an organisation. All other client details have been collapsed into a single

table. The column called Specialisation records whether a client seeks Microsoft SQL Server

or Oracle Database training. As in the Events table, ‘Oracle’ or ‘Microsoft’ are the only valid

values for this column. Also like the Events tables, a column called Level is being used to

record whether the client seeks ‘Beginner’, ‘Intermediate’ or ‘Advanced’ level training as

demonstrated in Figures 12, 13 & 14.


16

16

Figure 22: Client entity logical model

Figure 13: dbo.Clients SQL Inputs

Figure 14: dbo.HCTEvent SQL Output

2.8.2. Client Results

2.8.2.1. The Clients attributes included: ClientID, Specification which consists of two

check constraints namely ‘ORACLE’ or ‘ MICROSOFT’; CleintLevel attributes which

identifies the level of the client which enable registering of the client in the correct line of

training, Surname and Forename, Street, Postcode, Phone, BusinessName and employee totals.

The functionalities such as ClientID (PK or FK) allow for easy system navigation for the

Systems Administrator as well as connectivity to other relational entities, for example,

Registration and Administrator entities. The dbo.Clients SQL Output s show a 100% clearance

which means Message = 4 rows affected, query is executed successful.

2.9. BBT Entity HCTEvents

2.9.1 The design has been simplified. Details relating to Courses, Course Offerings and

Venues will are not recorded anymore. A column called Specialisation has been added to the

Events table to record this detail. Specialisation is recorded as either ‘Oracle’ or ‘Microsoft’.

The level of training provided on an event is also to be recorded in the Events table. The level

of an event is described as ‘Beginner’, ‘Intermediate’ or ‘Advanced’. Figures 15,16 & 17

showed seven attributes including: specialisation, clientLevel, EventName, EventDate,

EventCost and SeatsAvailable. The logical table was checked against the code which showed

satisfactory free error results.


17

17

Figure 15. dbo.HctEvents Table

Figure 36. dbo.HCTEvent SQL Input

Figure 47: dbo.HCTEvent SQL Output

2.9.2 HCTEvents Results

2.9.2.1. The SQL dbo.HCTEvent shows an important relationship with the Client entity which

can be access through the Registration entity PK or the ClientID FK1 or FK2. The HCTEvent

Form produces event training courses and their descriptions. The dbo.HCTEvents showed a

100% clearance indicated by the message = 4 Rows affected, Results – query executed

successfully. The forms Clients, Registration and HCT Events and Events Sessions are too

fragmented but all these tables are closely related. By redesigning these entities attributes these

should improve friendly user perspective and ease of navigation for the systems administrators

and maintain accuracy.

2.10. BBT Entity Registrations

2.10. 1. The key focus is to spot errors but most important is to concentrate on checking the

validation and security using the functionalities keys including PKs, FKs and UI constraints as

illustrated in Figure 18, 19 & 20. The seven attributes for Registration entity included:

RegistrationID, ClientID, Specifications, ClientLevel, EventID, EmployeeID,

RegistrationDate and Attendees.


18

18

Figure 58. Entity Registration Table

Figure 19. dbo. Registration for SQL Inputs

Figure 60. dbo. Registration SQL Outputs

2.10.2. Registration Results

2.10.2.1. The SQL dbo.Registration inputs and outputs shows identical results. The

setting of the codes is error free. The key focus for this test case is underpin by the security and

ease of navigation aspects. The entity table attributes included the RegistrationID (FK) and

user accessibility can be achieved by using the FKs of the EmployeeID, EventID and ClientID,

Specialization and ClientLevel entities. When testing the registration table in Visual basic, the

security is tight because they have been set up to be automatically generated by the SQL

software so that if typing in a password unfamiliar to the SQL settings for any of the entities in

question, and error message immediately pop up denying access. The dbo.Registration is 100%

outputs: Messages = 3 rows affected; Results = query executed successfully.


19

19

2.11. BBT EventSessions

2.11.1. The event session form allows the systems administrator to make enquiries

about the client registration, HCT Events Course, Event Sessions and Trainer details. The

EventSession entity is a bridging entity connecting the Trainer entity to the HCTEvents and

from the HCTEvents to the Registration and Client entities. Because of the long line of

connectivity, this give rise to security issues, whether or not the security mechanisms in play

are strong enough to prevent hackers from hacking the system remains to be seen. The

EventSessions unique attributes include: SessionID, SessionNumber,EmployeeID, Positions,

Certification, EventID, Specialization and ClientLevels as depicted in Figures 21,22 &23.

Figure 21.dbo.Eventsessions SQL Inputs

Figure 72. dbo.EventSession SQL Inputs

Figure 83. dbo.EventSession SQL Outputs


20

20

2.11.2. EventSession Results

2.11.2.1. The tests material used included the Code, Logical Model, and Microsoft SQL

Input/Output as well and the HCT systems change documents. Only one entry was set up in

SQL. All were input correctly, again the settings of the attributes can provide difficulties for

the Systems Administrator to navigate with ease amongst the system to collect required

information for different entities in order to complete the Client Registration processes. A

combination of many PK and FKs for navigations may jeopardize security settings. The System

setting is free of error.

3. SECTION 3 - STRATEGY02WBT

3.1. Given that the internal coding of the system is not available for testing, The WBT

testing strategy focus on matching the HCT Script (Code) against SQL Inputs and Outputs.

The key objectives of the testing strategy is to ensure that the systems codes have been entered

correctly into the Microsoft SQL by the systems programmer. White-box testing is testing that

takes into account the internal mechanism of a system or Component (IEEE, 1990). White-box

testing is also known as structural testing, clear box Testing, and glass box testing.

3.2. Testing Security

3.2.1. Clients and staff of the HCT are not able to access the database of the system. Only the

appointed System Administrator whose job is to manage and access the database to perform

the following functionality commands:

3.2.1.0. Create

3.2.1.1. Update

3.2.1.2. Add

3.2.1.3. Delete

3.3 Test Observation

3.3.1. When observing other testers’ testing strategies, the outcome was that because the

creator of the database for security reasons had lock the systems so that the system denied

access to any other user even the testers, this indicated excellent demonstration of security

because users are not allowed to access the database accept for the appointed ‘Systems

Administrator’. Using visual basic the creation of tested plans strategies resulted to duplication

of the code and error messages because the database on visual basic and SQL only recognised

the legitimate inputs initially done on Microsoft SQL. In the case of the EmployeeID numbers

which are also PKs and FKs, these are automatically generated by Microsoft SQL and hence

the error messages. The administrator names for example and contact details are repetitions of

combinations of the capital characters and so the system don’t seemed to recognize that as an

error, however when typing in a different pass word that is not existing the system rejects it.

Table 2 is an example of a design template that can be used for White Box Testing


21

21

3.4. White Box Test Plan Template

3.4.1. If for example this is a fully testing system project the design template as illustrated in

Table 3 provides the anatomy of each white box test case, however it cannot be used in this

testing exercise because the code is not available online. The first column requires a unique

identifier or test number. Further it is extremely important that a specific clear description of

the test case is provided. The tester is required to describe the exact expected and the actual

results. From these results the tester should be able to determine whether or not the test case

activity failed or passed.

Table 3: Design Template for White Box Testing

TEST TEST EXPECTED ACTUAL PASS/FAIL

NO DESCRIPTION RESULTS RESULTS

3.5. WBT Employees Entity

3.5.1 The employees entity represents the employee application form that external users may

retrieved from the company website. It has 7 attributes including EmployeeID, ManagerID,

Surname, Forename, StartDate, EmpType. The EmployeeID is the table’s PK and is NOT

NULL which means that users are able to see it. The Primary Key is a navigational function

which the administrator can use to navigate amongst the super type employees and subtypes

Trainers and Administrators. The EmpType function check constraint ‘T’ and ‘A’ distinguishes

the differences between the trainers and Administrators. The Microsoft SQL inputs has been

set up correctly as illustrated in Figures 24 & 25.


22

22

Figure 94. HCT Script for Employees Entity

.

Figure 105. SQL dbo.Employees Inputs

3.5.2. Employees Results

3.5.2.1. The Employees Code was set up correctly and the Microsoft Inputs and Outputs

show identical settings.

3.6. WBT - Trainers Entity

3.6.1. This strategy involves reading through the code to try and detect errors, then match the

code against the Microsoft SQL input data as illustrated in both Figures 26 and 27. The Trainer

entity is the subtype of super type employee and only those employees who are manager

trainers are registered in the trainer table. Trainers can access the super type employee’s entity

but no other entity may access the trainers subtype entity table. Trainers has four attributes:

EmployeeID (PK), Position (with check constraints distinguishing the Consultant from the

Trainer), Certification (check constraints OCP and MCP), and EmpType (with check

constraints ‘T’ or ‘A’ distinguishing the Trainer from an Administrator).


23

23

Figure 116. Trainer Entity Code

Figure 2712. dbo.Trainer SQL Inputs

3.6.2. Trainer Results

The test results showed that the code was input correctly in the Microsoft SQL Server and this

is reflected by the input data.

3.7. WBT - Administrators Entity

3.7.1. The Administrator entity is the subtype of super type Employee, only those employees

who are manager administrators are registered in the administrator table. Administrators can

access the super type employees’ attributes but no other entities may access the Administrator

subtype entity table. The Administrator entity consists of three attributes: including

EnmployeeID (PK and FK constraints); Bonus (with two constraints ‘Y’ or ‘N’) and the

EmpType (with check constraints ‘A’ or ‘T’ distinguishing the Administrator from the Trainer)

as illustrated in Figures 28 & 29.


24

24

Figure 28. Administrator HCT Code

Figure29. dbo.Administrator SQL Inputs

3.7.2. Administrators Results

The testing results shows that both the source code was input correctly and the Microsoft SQL

Server shows correct input and output outcome

3.8. WBT – Client Entity

3.8.1. The Client Entity acts as the Registration Form for those individuals who may wish to

enrol in any of the courses offer by HCT. The client entity consists of 13 unique attributes:

ClientID (PK and FK constraints); Specialization (check constraints ‘Oracle’, ‘Microsoft),

ClientLevel (check constraints ‘Beginner’, ‘Intermediate’, or ‘Advanced’), Surnames,

Forenames. Street, Suburb, City, Postcode, Phone, BusinessName and EmployeeTotal as

demonstrated in Figures 30 & 31.


25

25

Figure 130. Client SQL Code

Figure 141. dbo.Client SQL Inputs

3.8.2. Client Results

3.8.2.1. The code was set up correctly on the Microsoft SQL server, and the Microsoft

Server inputs show the same results.

3.9. WBT - HCTEvents Entity

3.9.1. The HCTEvents entity consists of 7 unique attributes: EventID (PK constraints),

Specialization (check constraints ‘Oracles’ or ‘Microsoft’), ClientLevel (with check constraints

‘’Beginner’, Intermediate’, or ‘Advanced’ and UI EventID, Specialization, ClientLevel) ;

EventName, EventDate, EventCost and SeatsAvailable as illustrated in Figures 32 & 33.


26

26

Figure 152.HCTEvent HCT Code

Figure 163. HCTEvents SQL Inputs

3.9.2. HCTEvents Results

3.9.2.1. The HCT code was set up correct on the Microsoft SQL. The Server shows

identical input result.

3.10. WBT - Registration Entity

3.10.1. Registration table connects the Administrator and the Client and HCTEvents to

the EventSessions and the Trainers. The table acts as the bridge for the Administrators to access

the Client registration details and related data online. The Registration entity consists of seven

unique attributes: RegistrationID (PK), EmployeeID(FK); EventID(FK); ClientID(FK);

ClientLevelID(FK) Specialization; ClientLevel; RegistrationDate, and Attendees as illustrated

in Figures 34 & 35.


27

27

Figure 174. Registration HCT Code

Figure 185.dbo.Registration SQL Inputs

3.10.2. Registrations Results

The Code was written and executed correctly in the Microsoft SQL Server as depicted in the

SQL inputs results.

3.11. WBT –EventSession Entity

3.11.1 The EventsSessions entity has eight unique attributes including: SessionID

(PK); SessionNumber; EmployeeID(FK3 constraints connecting the EventSessions to the

Trainer employeedID); EventID(with constraint FK Connecting EventSessions to HCTEvents

PK); EventID (with constraint FK1 connecting to HCTEvents table, Constraint UQ are

EventSessions _ EventNumber, EmployID and EventID); Specialization, ClientLevel,Position,


28

28

Certification consists of PK, FK, UQ constraints and are set up at the end of the code. As

demonstrated by Figures 36 & 37.

Figure 36. EventSession HCT SQL Code

Figure 197. dbo.EventSession SQL Inputs

3.11.2. EventSession Results

3.11.2.1. The code was written and executed correctly on the Microsoft SQL Server as

shown in the Inputs results in Figure 37.

PART III: RESULTS, CONCLUSIONS & RECOMMENDATIONS

4. Test Plan Overview

4.1. There are two parts to this HCT System: (1) Microsoft SQL Database and (2) HTC

Website. The HCT Website has not been built yet which means the HCT system is partially

tested. The purpose of this assignment is to test the complete set up HCT Microsoft SQL

database using the two basic software testing techniques namely black box and white box. This


29

29

involves developing and executing test plans on the HCT database system, reporting on the

results of the tests and provide recommendations.

4.2 What is not tested?

4.2.1. This testing project focus on testing the newly created Microsoft SQL database. A large

portion of the test plan being omitted include: site interface, navigational tree and linkages to

the database. User ease of access and user friendly aspects, security and internal and external

interaction functionalities for both potential employees and clients with the Systems

Administrators are not available for testing. Testers are not able to access the internal source

codes.

4.3. BBT and WBT Strategies and Techniques

4.3.1 The testing strategies for BBT and WBT being used throughout this entire software

testing exercise are listed below:

4.3.1.0. Strategy01BBTDeskCheck

4.3.1.1. Strategy01BBTDatabaseSetUp

4.3.1.2. Strategy01BBTFunctionalTesting

4.3.1.3. Strategy01BBTBehaviouralTesting

4.3.1.4. Strategy02WBTUsability

4.3.1.5. Strategy02WBTSecurity

4.3.1.6. Strategy02WBTErrorSpotting

4.4. PART 2 - SECTION 1. STRATEGY01BBTDESCKCHECK

4.4.1. The Strategy01BBTDesckCheck involves matching up the HCT Systems Changes

(Specification) against the HCT Case Study document (Customer Requirement Document).

The key objective of this desk check is to find out if the tested database system matches the

customer requirements.

4.5. Results

4.5.1. The probability of delivering the correct complete database system for the HTC

organisations relies heavily on whether or not finished product is relevant to the requirements

of the HCT. Assuming that the Company require the website to be built as soon as possible,

this indicates that some of the data necessary to implement the HCT business rules may have

to be included in the new database.

4.6. PART 2 - SECTION 2 – STRATEGY01BBT

4.6.1. A designed Template for the BBT plan provides the format for the test case design as

illustrated in Table 2.


30

30

4.6.2. An UML use case technique was used to model the relations between the systems

website and the SQL database and how one interacts with the other. The unavailability of the

site provides limitations to the testing strategies.

4.7. Entities ‘Employees’, ‘Trainers’ and Administrators’

4.7.1. The super type employee consist of six attributes including: EmployeeID (PK1, U1),

EmpType(UI), Manager(FKI), Surname, forename and StartDate. It’s two subtype entities are

Subtype Trainer whose attributes are EmployeeID (PK, FK1,Fk2,UI), Position (UI),

Certification(UI) and EmpType (FK2) and SubType entity ‘Administrator’ whose attributes

are: EmployeeID (PK1,Fk1,Fk2); EmpType (FK2) and Bonus.

4.8. Results

4.8.1. The dbo.Employee query has a 100% successful results which is shown by the Message

function that 5 rows are affected in the transactions. The logical model also show this same

setting which was translated into the HCT Systems Source Code. When matching the SQL

Inputs/Outputs against the Visual Basic Forms, the results are identical.

4.9. Entity Trainer

4.9.1. The entity Trainers has four attributes: EmployeeID (PK), Position (with check

constraints distinguishing the Consultant from the Trainer), Certification (check constraints

OCP and MCP), and EmpType (with check constraints ‘T’ or ‘A’ distinguishing the Trainer

from an Administrator).

4.10. Results

4.10.1. The important events to look out for in this section is how effective and secure the

settings of specific links and unique keys as well as the EmpType constraints are, on the

database so that to prevent applicants and users from accessing information that are specific

only to each subtype and therefore no one else should have access to them.

4.11. Entity Administrator

4.11.1. The entity Administrator table records details specific only to Administrators. The

Employee tables record details that are generic to both Administrators and Trainers.

Administrators cannot be both administrators and trainers and trainers cannot be both trainers

and administrators i.e. their roles are mutually exclusive.

4.12. Results

4.12.1. The dbo.Administrator SQL inputs is aligned with the source code and have been

correctly set up. The employeeID is generated automatically by the SQL Software.

Administrators do not have either certification or position details, but a column recording

whether or not they have been awarded a bonus (records either ‘Y’ – yes or ‘N’ – No check


31

31

constraints) is included. The EmpType function is the unique identifier distinguishing the

Trainer from the administrator employee.

4.13. Entity Clients

4.13.1. The client entity consists of 13 unique attributes: ClientID (PK and FK constraints);

Specialization (check constraints ‘Oracle’, ‘Microsoft), ClientLevel (check constraints

‘Beginner’, ‘Intermediate’, or ‘Advanced’), Surnames, Forenames. Street, Suburb, City,

Postcode, Phone, BusinessName and EmployeeTotal.

4.14. Results

4.14.1. The dbo.Clients SQL code were correctly input in to the Microsoft SQL

software. The dbo.Clients SQL Output show a 100% clearance which means (Message = 4

rows affected, Query is successful).

4.15. Entity HCTEvents

4.15.1. The design has been simplified. Details relating to Courses has been translated in to the

HCTEvents table. The logical model showed seven attributes including: specialisation,

clientLevel, EventName, EventDate, EventCost and SeatsAvailable. The logical table was

checked against the code which showed satisfactory free error results.

4.16. Results

4.16.1. The SQL dbo.HCTEvent shows an important relationship with the Client entity which

can be access through the Registration entity PK or the ClientID FK1 or FK2. The HCTEvent

Form produces event training courses online details .The dbo.HCTEvents showed a 100%

clearance indicated by the message = 4 Rows affected and the: Results – query executed

successfully.

4.17. Entity Registrations

4.17.1. The Key focus is spotting errors. However special concentration on checking validation

and security using the functionalities including PKs, FKs, constraints and UI Functions and

behaviour .The seven attributes for Registration entity included: RegistrationID, ClientID,

Specifications, ClientLevel, EventID, EmployeeID, RegistrationDate and Attendees.

4.18. Results

4.18.1. The SQL dbo.Registration input and output shows identical results. The setting of the

codes is error free. When testing the registration table in Visual Basic, the security holds

because the functionalities have been set up appropriately (ID numbers are automatically

generated by the SQL Server so that if typing in for enquiry an unknown password an error


32

32

message immediately pop up denying access. The dbo.Registration is 100% accurate:

Messages = 3 rows affected; Results – query executed successfully.

4.19. Entity EventSessions

4.19.1. The EventSession entity is the bridging entity connecting the Trainer entity to the

HCTEvents and from the HCTEvents to the Registration and clients entities. Because of the

long line of connectivity requirements this may give rise to security issues long-term, providing

that the security mechanisms in play are strong enough to prevent hackers from hacking the

system.

4.20. Results

4.20.1. Only one entry was set up in SQL. All were input correctly. Again the settings of the

attributes can provide challenges for the Systems Administrator to navigate with ease amongst

the system to collect required information from different entities to complete Client

Registration processes. A combination of many PK and FKs for navigations may jeopardize

security settings. The System setting is free of error.

4.7. PART 2 - SECTION 3 – STRATEGY02WBT

4.7.1.1 White-box testing takes into account the internal mechanism of a system .The key WBT

strategy involves matching the HCT Script (Code) against Inputs and Outputs. The key

objectives of the testing strategy is to ensure that the system’s codes have been entered correctly

into the Microsoft SQL by the systems programmer.

4.7.2. Test Observation

4.7.2.1. Testers attempted to test the codes in visual basic 2012 by creating test case

scenarios using the click activity to test the user functionalities. Although it was easy to

implement this technique the results prompted an error message because Visual basic only

recognized the original data setup by the programmer on Microsoft SQL server. This means

the security functionalities and the executable general codes safeguard security protocols of

both Visual basic and Microsoft server.

4.7.3 White Box Test Plan Template

4.7.3.1. The design template as illustrated in Table 3 provides the anatomy of each white

box test case.

4.7.4 Entity Employees

4.7.4.1. The employee application form is designed for the external user. It has 7

attributes including the EmployeeID, ManagerID, Surname, Forename, StartDate and

EmpType.


33

33

4.7.5. Results

4.7.5.1. The Employees Code was set up correctly and the Microsoft Inputs and

Outputs shows identical settings.

4.7.6. Trainer Entity

4.7.6.1. Entity Trainers has four attributes: EmployeeID (PK), Position (with check

constraints distinguishing the Consultant from the Trainer), Certification (check constraints

OCP and MCP), and EmpType (with check constraints ‘T’ or ‘A’ distinguishing the Trainer

from an Administrator).

4.7.7. Results

4.7.7.1. The test results showed that the code was input correctly in the Microsoft SQL

Server and this is reflected by the input data.

4.7.8. Administrators Entity

4.7.8.1. The Administrator entity consists of three attributes: including EmployeeID

(PK and FK constraints); Bonus (with two constraints ‘Y’ or ‘N’) and the EmpType (with

check constraints ‘A’ or ‘T’ distinguishing the Administrator from the Trainer).

4.7.9. Results

4.7.9.1. The testing results shows that the source code was input correctly and the

Microsoft SQL Server shows correct input and output outcomes.

4.7.10. Client Entity

4.7.10.1. The Client Entity acts as the Registration Form for those individuals who may

wish to enrol in any of the courses offer by HCT. The client entity consists of 13 unique

attributes: ClientID (PK and FK constraints); Specialization (check constraints ‘Oracle’,

‘Microsoft), ClientLevel (check constraints ‘Beginner’, ‘Intermediate’, or ‘Advanced’),

Surnames, Forenames. Street, Suburb, City, Postcode, Phone, BusinessName and

EmployeeTotal.

4.7.11. Results

4.7.11.1. The code input correctly in the Microsoft SQL server, The Microsoft Server

inputs show the same results.

4.7.12. HCTEvents Entity

4.7.12.1. The HCTEvents entity consists of seven unique attributes: EventID (PK

constraints), Specialization (check constraints ‘Oracles’ or ‘Microsoft’), ClientLevel (with

check constraints ‘’Beginner’, Intermediate’, or ‘Advanced’ and UI EventID, Specialization,

ClientLevel; (EventName, EventDate, EventCost and SeatsAvailable).


34

34

4.7.13. Results

4.7.13.1. The HCT code was set up correct on the Microsoft SQL. The Server shows

identical input result.

4.7.14. Registration Entity

4.7.14.1. The Registration entity consists of seven unique attributes: RegistrationID (PK),

EmployeeID(FK); EventID(FK); ClientID(FK); ClientLevelID(FK) Specialization;

ClientLevel; RegistrationDate, and Attendees.

4.7.15. Results

4.7.15.1. The Code was written and executed correctly in the Microsoft SQL Server as

depicted in the SQL inputs Results.

4.7.16. EventSession Entity

4.7.16.1 The EventsSessions entity has eight unique attributes including: SessionID

(PK); SessionNumber; EmployeeID(FK3 constraints connecting the EventSessions to the

Trainer employeedID); EventID(with constraint FK Connecting EventSessions to HCTEvents

PK); EventID (with constraint FK1 connecting to HCTEvents table, Constraint UQ are

EventSessions _ EventNumber, EmployID and EventID); Specialization, ClientLevel,Position,

Certification consists of PK, FK, UQ constraints and are set up at the end of the code.

4.7.17. Results

4.7.17.1. The code was written and executed correctly on the Microsoft SQL Server as

shown in the inputs results.

6. Conclusions

6.1. The purpose of this report is to test the HCT newly created SQL Database. This involves

designing of test plans for BBT and WBT testings and implementing the test plan strategies.

Each of the seven HCT events as accordance to the HCT Logical Model was tested to ensure

accurate execution of the SQL source code. Part one of the report provides an overview of the

test plan. Part two is structured in to three different testing strategies including (1)

STRATEGY01BBTDESKCHECK (2) STRATEGY01BBT and (3) STRATEGY02WBT.

7. Recommendations

7.1 Although simple BBT and WBT testing strategies are used in the testing exercises, it

yielded important challenges of the partially tested software product. While the database setting

is free of error, it should be expected that tremendous changes may be required once the website

is built. To ensure that the tested software systems meets the requirements of the HCT


35

35

Company (Customer), it is recommended that the Software Development team review the

Customer Requirements document to ensure that the customer is aware of the following

changes:

7.1.0. Courses Arrangements

7.1.1. Client Venues/Accommodations for International Clients

7.1.2. The roles and payment arranges for the Managers, Trainers, and Administrators

7.1.3 Contractors Roles and payment

7.1.4. Billing Tasks

7.1.5 Types of courses

7.2. The BBT and WBT Testing results also revealed that the users and the systems

administrator may experience difficulties navigating through the system due to the fragmented

nature of entities: HCTEvents, HCT Registration, Clients and EventSessions particularly when

the online site interaction between users starts. Long term this could provide security issues

and difficulties in user navigation interactions. It is recommended that the System developer

review the following tables for a better solution:

7.2.1. HCTEvents Table

7.2.2. EventSessions Table

7.2.3. Registration Table

7.2.4. Clients Table

8. References

System Evolutif Limited. (2009).IEEE Test Plan Template. Foundation Course in Software

Testing.

Rover, R. (2009). White box testing technique.

Williams, L. (2006). Testing overview and black-box testing techniques.

Appendix 1 –HCT Requirement /Specification Document

Harbour City Trainers – Case Study Client Requirement Document/specification

Introduction

Harbour City Trainers (HCT) is a small but rapidly expanding organisation based in Wellington. They provide specialist IT training on the

construction of applications using Oracle development tools and their growing reputation has attracted interest from large companies both

nationally and in Australia. Because of the highly specialised nature of the training, these companies are prepared to transport and

accommodate their employees so that they can attend the 3 to 5 day long courses held at HCT’s premises in Wellington. HCT wishes to tap

this new market and intends to construct a web site that allows potential clients to register for a particular course. However, the first stage

will be to automate the current system.


36

36

Although the running of courses is an important source of revenue, HCT also hold 1-day seminars at a variety of venues throughout New

Zealand. These seminars aim to provide information about trends and developments in the database field in general and are not associated

with any particular course. Because of their duration, seminars are targeted specifically at a New Zealand audience.

Currently, clients most often register for either a course or seminar by contacting HCT directly by telephone. Administration staff are

responsible for each client they register. Bonuses are paid to these employees based on the number of clients they register each month. An

administrative employee registers the client, who could be a freelance contractor or an organisation, for either a particular event or course. An

event is considered as any one-day block of training, be it a 1-day seminar or a 1-day component of a course. Clients cannot register for just a

single day of course; they must register for the whole course. Each course or seminar that a client wishes to attend is recorded as a separate

registration. HCT wishes to record both current and historical details of courses and events on which clients register. These details will be

used as a source of primary data in a future marketing system. Address details of the venues used for seminars are also recorded for future

reference.

HCT employees perform either administrative duties, such as the registration of clients, or they deliver seminars and courses.

Often, 2 or 3 trainers deliver an event, each being responsible for a particular session during the course of the day. Each trainer records details

of each session they deliver at events. Bonuses are paid to trainers based on the number of sessions they deliver over the course of a month.

Each manager at HCT manages about 15 employees. Every employee in the organisation has a manager except the CEO.

Registration

When a potential client contacts HCT, an administrative staff member determines whether or not the client is known to the organisation. New

clients provide contact details and other relevant information. These details are currently recorded on paper and stored in a filing cabinet, as

is all the other information maintained by the organisation. Existing clients who have previously registered for courses and/or seminars may

need their details updated at this stage (e.g. change of address etc).

The next stage of the registration process involves identifying the course or seminar for which the client wishes to register. Each of HCT’s 50

courses is run about 3 times each year. Because of topical content of the seminars run by HCT, each seminar is only ever offered once at a

particular venue. When the course or seminar has been identified, the next step is to determine whether or not there are enough places available

to allow the client’s registration. Large organisations most often register between 5 and 10 of their employees for a particular course or seminar.

However, rather than registering each of these employees separately, administration staff block register the whole group. Individual contractors

are recorded as a separate registration for each contractor. If enough places exist the client is registered. Between 15 and 20 people register on

a course each time it is run, but around 50 people attend each seminar. After completing the registration, the number of places left on the

course or seminar is recalculated. If there are not enough places the client is advised accordingly and left to consider alternative options.

Confirmation details are forwarded to clients by return of post. These details include summary information about the content of the seminar

or course. For seminar registrations, the date, time and venue details are also provided. For course registrations, summary details of each day’s

training are provided together with the date that the course commences. The venue for all courses is the premises of HCT in central Wellington.

Invoicing – there is no account the administrator/trainer does the billing

At the end of each week, administration staff extract the registration details of those clients they have dealt with that week. For each

registration, an invoice is raised and forwarded to the client. The invoice number, date and amount are recorded within the client’s registration

details. HCT do not accept payment by instalments. The total due for each registration must be paid in full, with a single payment, two weeks

before the commencement of a course or 3 days before the commencement of a seminar. When a payment is received, the payment date is

recorded against the client’s registration. Finally, a receipt for the payment is forwarded to client.

Cancellations

Occasionally, clients contact HCT to cancel their registration. Under these circumstances, administration staff extracts the client’s registration

details and prepare a cancellation confirmation. Once this has been forwarded to the client, the client registration is destroyed. The return of

the client payment is dealt with by the Accounts department and is beyond the scope of this project.

Appendix 2 – Harbour City Trainer System Changes

HCT System Changes

The following design changes have been made to the current system which now needs testing:

a. The design has been simplified. Details relating to Courses, Course Offerings and Venues will no longer be recorded.

All details relating to these tables have been removed from the data models. Invoice details will be dealt with by another

system and have therefore been removed.

b. HCT now provide both Oracle Database and Microsoft SQL Server training. A column called Specialisation has been

added to the Events table to record this detail. Specialisation is recorded as either ‘Oracle’ or ‘Microsoft’. The level of

training provided on an event is also to be recorded in the Events table. The level of an event is described as ‘Beginner’,

‘Intermediate’ or ‘Advanced’.


37

37

c. It is no longer necessary to distinguish clients by type, as most of HCT’s clients are now contractors. The name of the

business and employee total is now to be recorded in optional columns if the client is an organisation. All other client

details have been collapsed into a single table. The column called Specialisation records whether a client seeks

Microsoft SQL Server or Oracle Database training. As in the Events table, ‘Oracle’ or ‘Microsoft’ should be the only

valid values for this a column. Also like the Events tables, a column called Level will be used to record whether the

client seeks ‘Beginner’, ‘Intermediate’ or ‘Advanced’ level training.

d. It has now been deemed necessary to distinguish between different types of employees. Employees are either ‘Trainers’

or ‘Administrators’. The column EmpType is used to distinguish between each type of employee. This column appears

in Employees, Trainers and Administrators.

Managers can be either trainer or administrator type employees. Trainers deliver event sessions and administrators register clients.

Trainers are either Microsoft Certified Professionals (MCP) or Oracle Certified Professionals (OCP). A column called Certification

will now be used to record this detail. The column called Position is used to record whether a trainer is designated as either a

‘Trainer’ or ‘Consultant’ level trainer.

Administrators do not have either certification or position details, but a column recording whether or not they have been awarded

a bonus (records either ‘Y’ - yes or ‘N’ - No). Trainers are not awarded bonuses.

The Trainer table will record details specific to only Trainer type employees and the Administrator table records details specific

only to Administrators. The Employee tables record details that are generic to both Administrators and Trainers. Administrators

cannot be both administrators and trainers and trainers cannot be both trainers and administrators i.e. their roles are mutually

exclusive.

In addition, the following business rules also apply:

Only administrator type employees can register clients for an event.

Clients can only register for events that match their recorded specialisation and level details.

Trainers can only deliver sessions for events whose specialisation matches the trainer’s certification e.g. only OCP

certified trainers are allowed to deliver sessions for Oracle events.

Only Consultant level trainers can deliver sessions for advanced level events.

Appendix 3 - The Harbour City Trainers Logical Model


38

38


39

39

Appendix 4 – Harbour City Trainers SQL Script (Code)

CREATE DATABASE [HarbourCityTrainers]

GO

USE [HarbourCityTrainers]

GO

CREATE TABLE dbo.Employees(

EmployeeID smallint NOT NULL

CONSTRAINT PK_Employees

PRIMARY KEY,

Manager smallint

CONSTRAINT FK1_Employees_Employees

FOREIGN KEY REFERENCES dbo.Employees(EmployeeID),

Surname varchar(30) NOT NULL,

Forename varchar(30) NOT NULL,

StartDate datetime NOT NULL,

EmpType char(1) NOT NULL

CONSTRAINT chk_Employees_EmpType

CHECK (EmpType IN ('T', 'A')),

CONSTRAINT uq_Employees_EmpID_EmpType

UNIQUE (EmployeeID, EmpType)

)

GO

CREATE TABLE dbo.Trainers(


CONSTRAINT PK_Trainers

PRIMARY KEY

CONSTRAINT FK1_Trainers_Employees


Position varchar(15) NOT NULL

CONSTRAINT chk_Trainers_Position

CHECK (Position IN ('Trainer','Consultant')),

Certification char(3) NOT NULL

CONSTRAINT chk_Trainers_Certification

CHECK (Certification IN ('OCP','MCP')),

EmpType char(1) NOT NULL

CONSTRAINT chk_Trainers_EmpType

CHECK (EmpType IN ('T', 'A')),

CONSTRAINT FK2_Trainers_Employees

FOREIGN KEY (EmployeeID, EmpType)

REFERENCES dbo.Employees(EmployeeID, EmpType),

CONSTRAINT uq_Trainers_EmpID_Position_Certification

UNIQUE (EmployeeID, Position, Certification)

)

GO

CREATE TABLE dbo.Administrators(


CONSTRAINT PK_Administrators

PRIMARY KEY

CONSTRAINT FK1_Administrators_Employees


Bonus char(1) NOT NULL

CONSTRAINT chk_Administrators_Bonus

CHECK (Bonus IN ('Y','N')),

EmpType char(1) NOT NULL,

CONSTRAINT FK2_Administrators_Employees

FOREIGN KEY (EmployeeID, EmpType)

REFERENCES dbo.Employees(EmployeeID, EmpType)

)

GO

CREATE TABLE dbo.Clients(

ClientID smallint NOT NULL

CONSTRAINT PK_Clients

PRIMARY KEY,

Specialisation varchar(10) NOT NULL

CONSTRAINT chk_Clients_Specialisation

CHECK (Specialisation IN ('Oracle','Microsoft')),

ClientLevel char(15) NOT NULL

CONSTRAINT chk_Clients_ClientLevel


40

40

CHECK (ClientLevel IN ('Beginner','Intermediate','Advanced')),

CONSTRAINT uq_Clients_Specialisation_ClientLevel

UNIQUE (ClientID, Specialisation, ClientLevel),

Surname varchar(30) NOT NULL,

Forename varchar(30) NOT NULL,

Street varchar(30) NOT NULL,

Suburb varchar(30) NOT NULL,

City varchar(30) NOT NULL,

Country varchar(30),

Postcode varchar(30),

Phone varchar(15),

BusinessName varchar(30),

EmployeeTotal smallint

)

GO

CREATE TABLE dbo.HCTEvents(

EventID smallint NOT NULL

CONSTRAINT PK_HCTEvents

PRIMARY KEY,

Specialisation varchar(10) NOT NULL

CONSTRAINT chk_HCTEvents_Specialisation

CHECK (Specialisation IN ('Oracle','Microsoft')),

ClientLevel char(15) NOT NULL

CONSTRAINT chk_HCTEvents_ClientLevel

CHECK (ClientLevel IN ('Beginner','Intermediate','Advanced')),

CONSTRAINT uq_HCTEvents_EventID_Specialisation_Level

UNIQUE (EventID, Specialisation, ClientLevel),

EventName varchar(30) NOT NULL,

EventDate datetime NOT NULL,

EventCost smallmoney,

SeatsAvailable smallint

)

GO

CREATE TABLE dbo.Registrations(

RegistrationID smallint NOT NULL

CONSTRAINT PK_Registrations

PRIMARY KEY,


CONSTRAINT FK5_Registrations_Administrators

FOREIGN KEY REFERENCES dbo.Administrators(EmployeeID),


CONSTRAINT FK4_Registrations_HCTEvents

FOREIGN KEY REFERENCES dbo.HCTEvents(EventID),

ClientID smallint NOT NULL

CONSTRAINT FK1_Registrations_Clients

FOREIGN KEY REFERENCES dbo.Clients(ClientID),

CONSTRAINT uq_Registrations_ClientID_EventID

UNIQUE (ClientID, EventID),

Specialisation varchar(10) NOT NULL,

ClientLevel char(15) NOT NULL,

RegistrationDate datetime NOT NULL,

Attendees smallint,

CONSTRAINT FK2_Registrations_Clients

FOREIGN KEY (ClientID, Specialisation, ClientLevel)

REFERENCES dbo.Clients(ClientID, Specialisation, ClientLevel),

CONSTRAINT FK3_Registrations_HCTEvents

FOREIGN KEY (EventID, Specialisation, ClientLevel)

REFERENCES dbo.HCTEvents(EventID, Specialisation, ClientLevel),

)

GO

CREATE TABLE dbo.EventSessions(

SessionID smallint NOT NULL

CONSTRAINT PK_EventSessions

PRIMARY KEY,

SessionNumber smallint NOT NULL,


CONSTRAINT FK3_EventSessions_Trainers

FOREIGN KEY REFERENCES dbo.Trainers(EmployeeID),


CONSTRAINT FK1_EventSessions_HCTEvents

FOREIGN KEY REFERENCES dbo.HCTEvents(EventID),

CONSTRAINT UQ_EventSessions_SessionNumber_EmployeeID_EventID


41

41

UNIQUE (SessionNumber, EmployeeID, EventID),

Specialisation varchar(10) NOT NULL,

ClientLevel char(15) NOT NULL,

Position varchar(15) NOT NULL,

Certification char(3) NOT NULL,

CONSTRAINT FK4_EventSessions_HCTEvents

FOREIGN KEY (EventID, Specialisation, ClientLevel)

REFERENCES dbo.HCTEvents(EventID, Specialisation, ClientLevel),

CONSTRAINT FK2_EventSessions_Trainers

FOREIGN KEY (EmployeeID, Position, Certification)

REFERENCES dbo.Trainers(EmployeeID, Position, Certification),

CONSTRAINT chk_Event_Sessions_Level_Position

CHECK (NOT(ClientLevel = 'Advanced' AND Position <> 'Consultant')),

CONSTRAINT chk_Event_Sessions_Specialisation_Certification

CHECK ((Specialisation = 'Oracle' AND Certification = 'OCP'))

)

GO

USE [HarbourCityTrainers]

GO

Print '

********* Employees **************'

Print '

Valid: Employees'

INSERT INTO dbo.Employees (EmployeeID, Manager, Surname, Forename, StartDate, EmpType)

SELECT 1, NULL, 'AAAA', 'AAAAA', '2000-1-1', 'T' UNION ALL

SELECT 2, 1, 'BBBB', 'BBBB', '2000-1-1', 'T' UNION ALL

SELECT 3, 1, 'CCCCC', 'CCCC', '2000-1-1', 'A' UNION ALL

SELECT 4, 1, 'DDDD', 'DDDD', '2000-1-1', 'T' UNION ALL

SELECT 5, 1, 'EEEE', 'EEEE', '2000-1-1', 'A'

GO

Print '

********* Trainers **************'

Print '

Valid: Trainers'

INSERT INTO dbo.Trainers (EmployeeID, Position, Certification, EmpType)

SELECT 1, 'Consultant', 'OCP', 'T' UNION ALL

SELECT 2, 'Trainer', 'MCP', 'T'

GO

Print '

********* Administrators **************'

Print '

Valid: Administrators'

INSERT INTO dbo.Administrators (EmployeeID, Bonus, EmpType)

SELECT 3, 'Y', 'A'

GO

Print '

********* Clients **************'

Print '

Valid: Clients'

INSERT INTO dbo.Clients (ClientID, Specialisation, ClientLevel, Surname, Forename, Street, Suburb, City)

SELECT 100, 'ORACLE', 'Beginner', 'AAAAA', 'AAAAA', 'AAAAAA', 'AAAAAAA', 'AAAAAAA' UNION ALL

SELECT 200, 'ORACLE', 'Advanced', 'BBBBBB', 'BBBBB', 'BBBBB', 'BBBBB', 'BBBBB' UNION ALL

SELECT 300, 'MICROSOFT', 'Intermediate', 'CCCCCC', 'CCCCC', 'CCCCC', 'CCCCC', 'CCCCC' UNION ALL

SELECT 400, 'MICROSOFT', 'Advanced', 'DDDD', 'DDDDD', 'DDDDD', 'DDDDD', 'DDDDD'

GO

Print '

********* Events **************'

Print '


42

42

Valid: HCT Events'

INSERT INTO dbo.HCTEvents (EventID, Specialisation, ClientLevel, EventName, EventDate)

SELECT 1000, 'Oracle', 'Beginner', 'AAAAAAA', '2000-1-1' UNION ALL

SELECT 2000, 'Oracle', 'Advanced', 'BBBBBB', '2000-1-1' UNION ALL

SELECT 3000, 'Microsoft', 'Advanced', 'CCCCCC', '2000-1-1' UNION ALL

SELECT 4000, 'Microsoft', 'Intermediate', 'DDDDDD', '2000-1-1'

GO

Print '

********* Registrations **************'

Print '

Valid: Registrations'

INSERT INTO dbo.Registrations (RegistrationID, EmployeeID, EventID, ClientID, Specialisation, ClientLevel, RegistrationDate)

SELECT 5001, 3, 1000, 100, 'ORACLE', 'BEGINNER', '2000-1-1' UNION ALL

SELECT 5002, 3, 2000, 200, 'ORACLE', 'ADVANCED', '2000-1-1' UNION ALL

SELECT 5003, 3, 3000, 400, 'MICROSOFT', 'ADVANCED', '2000-1-1'

GO

Print '

********* Event Sessions **************'

Print '

Valid Event Sessions'

INSERT INTO dbo.EventSessions (SessionID, SessionNumber, EmployeeID, EventID, Specialisation, ClientLevel, Position, Certification)

SELECT 1, 1, 1, 2000, 'ORACLE', 'ADVANCED', 'Consultant', 'OCP'

GO

6/24/2013 hct organisation new information system test ... · 6/24/2013 hct organisation new...

Documents