Sample Test Plan Lab1
Sample Test Plan Lab1
Test Plan
RECORD OF CHANGE
SIGNATURE PAGE
Test Leader
Quality Assurance
Project Manger
Project Manger
TABLE OF CONTENTS
1 INTRODUCTION..........................................................................................................6
1.1 Purpose.............................................................................................................................6
1.2 Definitions, Acronyms, and Abbreviations.............................................................................6
1.3 References........................................................................................................................7
1.4 Background information......................................................................................................7
1.5 Scope of testing.................................................................................................................8
A. Target of Test.........................................................................................................8
B. Test Stage..............................................................................................................8
C. Test Assumption.....................................................................................................9
1.6 Constraints........................................................................................................................9
1.7 Risk List...........................................................................................................................10
1.8 Training Needs.................................................................................................................10
3 TEST STRATEGY........................................................................................................12
4 RESOURCE................................................................................................................16
5 TEST MILESTONES....................................................................................................17
6 DELIVERABLES.................................................................................................................18
1 INTRODUCTION
1.1 Purpose
This is the comprehensive test plan of the Family Medical Officer project. The purpose of the
document is to describe scopes of test and activities which need to be taken during test process
of project. It addresses the following items:
Abbreviations Description
AT Acceptance Test
IT Integration Test
ST System Test
PM Project Manager
QA Quality Assurance
TP Test Plan
TC Test Case
TR Test Report
UT Unit Test
1.3 References
El Camino Hospital (ECH) is a not-for-profit organization with hospital campuses in Mountain View
and Los Gatos, California. The hospitals have served communities in the South San Francisco Bay
Area for nearly 50 years.
ECH has a website that is currently serving the desktop users. In order to better serve the mobile
consumers with a many different kinds of platforms such as iPhone and Android mobile devices,
ECH is in need of new version to serve the mobile users. This new version has the following main
functions:
The purpose of this project is to develop a HTML5 based web application so that it can function
well on both iPhone and Android mobile phones then develop the iPhone and Android applications
to link with the HTML5 web app.
The scope of the test will be limited to testing three applications: the HTML 5 applications and
two hybrid applications (on iPhone and Android).
A. Target of Test
Functional items and Non-functional items will be verified and passed by FPT development team,
then be validated, and approved by El Camino Hospital via test stages, including the
requirements of the following primary functions:
B. Test Stage
2 Integration Test The Integration Test will be performed by the FPT QA team.
After the Unit Test is finished, testers will execute the UT Gate based on
the UT Gate checklist for each function. The Integration Test will only
start if the result of UT Gate is Passed.
This test stage focuses on specific areas of use cases when all
requirements are completed, integration test should be performed to
ensure all components incorporate well.
C. Test Assumption
El Camino Hospital is to validate and approve for final software product, test
procedures and results.
Verification from FPT project team for test execution, documenting, and results
Requirements for the test are limited to functional and non-functional requirements
specified in Section 2 of this document.
Test will be executed on specific hardwares and softwares as defined in Section 4.2
1.6 Constraints
Test execution can be performed when system passes Unit Test Inspection
Complete testing needs support from El Camino Hospital for production environment
set-up
1 Unit Test Learn & study from internal: FPT's other teams
A. Functional Items
B. Nonfunctional Items
2. In normal conditions (could be 100 concurrent users or less), each page should load in 4
seconds or less.
3. In the stress condition (could be more than 100 concurrent users), each page should load in
12 seconds or less.
1 Unit Test To pass this stage, all unit test cases must be tested and passed 100%.
All defects should be fixed and re-tested. Average of 11 bugs/KLOC.
2 Integration Test To pass this stage, all test cases must be tested and passed 100%. All
defects should be fixed and re-tested. Average of 4 bugs/KLOC.
3 System Test To pass this stage, all test cases must be tested and passed 100%. All
defects should be fixed and re-tested. Average of 0.5 bugs/KLOC.
4 Acceptance Test Acceptance Test will be conducted and approved by El Camino Hospital.
3 TEST STRATEGY
A. Function Testing
Test Objective: Verify the application and its internal processes by interacting with the
application via the Graphical User Interface (GUI) and analyzing the
outputs or results
Technique: - Testers will create test scenarios against the requirements provided by customer.
Test scenarios will be created based on black box test technique.
- Testers execute test based on test scenarios and create report. Common defects
will be collected for improved checklist.
- Execute each case, using valid and invalid data, to verify the following:
Get the expected results when valid and invalid data is used
The appropriate errors or warning messages are displayed when invalid data is
used
- Execute each case, using boundary data, to verify the following:
Get the expected results when boundary data is used
The appropriate errors or warning messages are displayed when invalid data is
used
Completion All functional test cases have been executed to verify proper data
Criteria:
acceptance, processing, and retrieval, and the appropriate implementation
of the business rules, and passed
case
Special Functional testing will NOT be started in case of developers have not
Considerations: executed unit test before passing application to testers
- Testers execute test based on test scenarios and create report. Common
Technique:
defects will be collected for improved checklists.
- Execute each case, using valid, invalid and boundary data, to verify the
expected results display when valid, invalid and boundary data is used.
Special
N/A
Considerations:
C. Load Testing
In the normal condition could be 100 concurrent users or less, each page should
Test Objective: load in four seconds or less
In the stress condition could be more than 100 concurrent users, each page should
load in 12 seconds or less
Technique: - Testers will create test scenarios, test scripts against the requirements provided
by customer. Test scenarios will be created based on black box test technique, and
be supported by one of the following tools: IBM Rational Robot & Manager.
- Testers execute test based on test scenarios and create report. Common defects
will be collected for improved checklists.
- Execute each case, using valid and invalid data, to verify the following on a
random device:
In the normal condition could be 100 concurrent users or less, each page should
load in four seconds or less
In the stress condition could be more than 100 concurrent users, each page should
load in 12 seconds or less
In the normal condition could be 100 concurrent users or less, each page
should load in four seconds or less.
Completion
In the stress condition could be more than 100 concurrent users, each
Criteria:
page should load in 12 seconds or less
All performance requirements must be met
Special
Numbers of 100 virtual users should be available for Microsoft Visual Studio
Considerations:
D. Security Testing
Test Objective: Verify that the application is HIPAA & TRUSTe compliance
- Testers will create test scenarios against the requirements which are
Technique:
based on HIPAA & TRUSTe compliance. Test scenarios will be created
based on black box test technique. Refer to:
https://www.owasp.org;
http://www.wedi.org/snip/public/articles/testing_whitepaper08260
2.pdf;
http://www.macadamian.com/images/uploads/whitepapers/
HIPAA_TestStrategies.pdf for more detail.
- Testers execute test based on test scenarios and create report. Use WireShark
tool to validate transaction encrypted or not. Common defects will be collected for
improved checklists.
- Execute each case, using valid and invalid data, to verify the following: The
expected results occur when valid HIPAA & TRUSTe compliance.
Completion All test cases have been executed to verify proper data acceptance,
Criteria:
processing, and retrieval, and the appropriate implementation of the HIPAA
& TRUSTe compliance rules, and passed
E. Regression Testing
Verify the application on new build/ after bug fixing, and be sure that other
Test Objective:
functions is not affected by fixed parts each iterations
- Testers execute test based on test scenarios and create report. Common defects
will be collected for improved checklists.
- Execute each case, using valid and invalid data, to verify the following:
Get the expected results when valid and invalid data is used
The appropriate errors or warning messages are displayed when invalid data is
Technique: used
- Execute each case, using boundary data, to verify the following:
Get the expected results when boundary data is used
The appropriate errors or warning messages are displayed when invalid data is
used
Specified function test cases have been executed to verify proper data
acceptance, processing, and retrieval, and the appropriate implementation
of the business rules, and passed
Completion The appropriate activities will be performed when valid data is used.
Criteria:
The corresponding error/warning message mechanism is applied for each specific
case.
Special
N/A
Considerations:
Load test X X
Security test X X X
Regression test X X X
3.3 Tools
4 RESOURCE
Anh Pham Test Leader Manage test resources and assign test tasks
Create Test Plan, Test Cases (IT, ST), Test Scripts (IT, ST)
Linh Doan Quality Assurance Final Inspection Test Cases, Test Plan, Test Reports
Chien Nguyen Project Manager Approve Test Cases (UT, IT, ST), Test Plan, Test Results, Test
Reports
The FMO HTML5 web-based application and iPhone, Android Hybrid applications will require testing on
the following iPhone and Android devices:
Hardware OS Version
iPhone 4 iOS 4
Software Version
Microsoft Windows Server 2003 SP2
5 TEST MILESTONES
6 DELIVERABLES