Upload
hoangtu
View
212
Download
0
Embed Size (px)
Citation preview
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
Leutele Leutele L.M.Grey:2002607
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
Leutele Leutele L.M.Grey:2002607
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
Leutele Leutele L.M.Grey:2002607
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
Leutele Leutele L.M.Grey:2002607
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
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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:
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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
Leutele Leutele L.M.Grey:2002607
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;
Leutele Leutele L.M.Grey:2002607
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
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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
Leutele Leutele L.M.Grey:2002607
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
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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).
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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,
Leutele Leutele L.M.Grey:2002607
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
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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
Leutele Leutele L.M.Grey:2002607
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
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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).
Leutele Leutele L.M.Grey:2002607
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
Leutele Leutele L.M.Grey:2002607
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.
Leutele Leutele L.M.Grey:2002607
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’.
Leutele Leutele L.M.Grey:2002607
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
Leutele Leutele L.M.Grey:2002607
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(
EmployeeID smallint NOT NULL
CONSTRAINT PK_Trainers
PRIMARY KEY
CONSTRAINT FK1_Trainers_Employees
FOREIGN KEY REFERENCES dbo.Employees(EmployeeID),
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(
EmployeeID smallint NOT NULL
CONSTRAINT PK_Administrators
PRIMARY KEY
CONSTRAINT FK1_Administrators_Employees
FOREIGN KEY REFERENCES dbo.Employees(EmployeeID),
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
Leutele Leutele L.M.Grey:2002607
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,
EmployeeID smallint NOT NULL
CONSTRAINT FK5_Registrations_Administrators
FOREIGN KEY REFERENCES dbo.Administrators(EmployeeID),
EventID smallint NOT NULL
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,
EmployeeID smallint NOT NULL
CONSTRAINT FK3_EventSessions_Trainers
FOREIGN KEY REFERENCES dbo.Trainers(EmployeeID),
EventID smallint NOT NULL
CONSTRAINT FK1_EventSessions_HCTEvents
FOREIGN KEY REFERENCES dbo.HCTEvents(EventID),
CONSTRAINT UQ_EventSessions_SessionNumber_EmployeeID_EventID
Leutele Leutele L.M.Grey:2002607
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 '
Leutele Leutele L.M.Grey:2002607
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