MASTER TEST PLAN

Version: 1.0

Prepared for

[Enter Company Name Here]

[Name] Improvement Project

Revision History

Date Version Description Author

TABLE OF CONTENTS

1 INTRODUCTION...............................................................................................5
1.1 PURPOSE............................................................................................................................5
1.2 SCOPE...............................................................................................................................6
1.2.1 Product Description...............................................................................................7
1.2.2 The Current Product Version..................................................................................7
1.2.3 Updating the Product.............................................................................................8
1.2.4 High-Level Product Development Objective...........................................................8
1.3 TEST PLAN OBJECTIVES...........................................................................................................9
2 TEST ITEMS (FUNCTIONS)..............................................................................10
2.1 CLIENT APPLICATION.............................................................................................................10
2.2 QUICK HELP TESTING...........................................................................................................10
2.3 LICENSE KEY......................................................................................................................11
2.4 SECURITY..........................................................................................................................11
3 SOFTWARE RISK ISSUES................................................................................11
3.1 SCHEDULE.........................................................................................................................11
3.2 TECHNICAL........................................................................................................................11
3.3 MANAGEMENT.....................................................................................................................11
3.4 PERSONNEL.......................................................................................................................12
3.5 REQUIREMENTS...................................................................................................................12
4 FUNCTIONS TO BE TESTED.............................................................................12
5 FUNCTIONS TO NOT BE TESTED......................................................................12
6 TEST APPROACH............................................................................................13
FUNCTIONAL TESTING WILL BE CONDUCTED DURING THE ENTIRE APPLICATION DEVELOPMENT LIFE CYCLE BY THE QUALITY
ASSURANCE ENGINEER AND THE SYSTEM BUSINESS ANALYST. AT THE CONCLUSION OF EACH ITERATION, FORMAL TESTING
WILL BE CONDUCTED BY THE BUSINESS UNIT SUBJECT MATTER EXPERTS IN TWO CYCLES; WHILE OVERALL TESTING OF THE

ENTIRE SYSTEM WILL BE CONDUCTED BY THE QUALITY ASSURANCE ENGINEER AND THE SYSTEM BUSINESS ANALYST IN ONE

FINAL CYCLE.............................................................................................................................13

6.1 SPECIAL TESTING TOOLS........................................................................................................13

6.2 SPECIAL TRAINING ON TESTING TOOLS........................................................................................14
SINCE MICROSOFT VISUAL STUDIO 2010 ULTIMATE IS A RELATIVELY NEW TOOL ON THE MARKET, SOME SPECIAL TRAINING
WILL BE REQUIRED. DUE TO THE CURRENT TIME CONSTRAINTS OF THE PROJECT, THIS TRAINING WILL BE SCHEDULED AND

COMPLETED AT A LATER DATE.........................................................................................................14

HOWEVER, THE DEVELOPMENT TEAM; INCLUDING THE SQA ENGINEER, HAS PROACTIVELY BEGUN “SELF-LEARNING” AND
UTILIZING THE TOOL AND HAS INTEGRATED THE USE OF THE MICROSOFT TOOLS INTO ITS OVERALL TESTING STRATEGY.......14

6.3 TEST METRICS....................................................................................................................14

TESTING INFORMATION WILL BE COLLECTED AND ORIENTED TOWARD THE LEVEL OF TESTING. FOR HIGHER LEVELS,
APPLICATION AND FUNCTIONAL DATA WILL BE COLLECTED AND DOCUMENTED. FOR LOWER LEVELS, PROGRAM, UNIT, MODULE

AND BUILD DATA WILL BE COLLECTED AND DOCUMENTED...........................................................................14

ALL TEST RESULTS WILL BE DOCUMENTED IN THE MASTER TEST CASE SPREADSHEET, REVIEWED BY THE BUSINESS UNIT TEAM
LEADER, AND FORWARDED TO THE QUALITY ASSURANCE ENGINEER AND THE SYSTEM BUSINESS ANALYST...................14
 THE TEST RESULTS WILL BE EVALUATED AND ENTERED INTO THE TEAM FOUNDATION SERVER THROUGH THE USE OF VISUAL
STUDIO TEST MANAGER; WHERE EACH “AUTOMATABLE” TEST CASE WILL BE RECORDED AND RUN USING THE “CODED UI
TEST” FEATURE IN VISUAL STUDIO 2010 ULTIMATE. ............................................................................14
REPORTS WILL BE GENERATED HIGHLIGHTING:......................................................................................14
THE NAME OF THE ASSIGNED TESTER................................................................................................14
THE NUMBER OF TEST CASES COMPLETED...........................................................................................14
THE NUMBER OF PASSED AND FAILED TEST CASES..................................................................................14
THE NUMBER OF OPEN ISSUED (BY PRIORITY).......................................................................................15
EVENTUALLY, PERFORMANCE TESTING WILL BE CONDUCTED TO MEASURE THE SYSTEM RESPONSE TIME, BASELINE LOAD, AND
SYSTEM STRESS CAPACITY..............................................................................................................15

6.4 CONFIGURATION MANAGEMENT.................................................................................................15

TEST CONFIGURATION MANAGEMENT WILL BE MANAGED BY THE LAB MANAGER TOOL; INCLUDED WITH THE MICROSOFT
VISUAL STUDIO 2010 ULTIMATE PACKAGE.........................................................................................15
LAB MANAGER CAN FULLY PROVISION AND READY MULTIPLE ENVIRONMENTS FOR TESTING SO THAT BUILD SCRIPTS CAN
EXPLICITLY TARGET A PARTICULAR LAB CONFIGURATION AT BUILD TIME. LAB MANAGEMENT STORES THE ENVIRONMENTS AS

VIRTUAL MACHINE IMAGES IN A LIBRARY OF PRE-BUILT IMAGES USING SYSTEM CENTER VIRTUAL MACHINE MANAGER

(SCVMM) TO ENSURE TEAMS ALWAYS BEGIN THEIR TESTING FROM A KNOWN CONFIGURATION. ..............................15
THE FOLLOWING OPERATING SYSTEMS AND BROWSER WILL BE USED IN MULTIPLE COMBINATIONS FOR TESTING THE [PROJECT
NAME] APPLICATION:...................................................................................................................15
OPERATING SYSTEMS.................................................................................................................15
WINDOWS XP.........................................................................................................................15
WINDOWS VISTA......................................................................................................................15
WINDOWS 7...........................................................................................................................15
BROWSERS.............................................................................................................................15
FIREFOX 3.0..........................................................................................................................15
INTERNET EXPLORER 7.0............................................................................................................15
INTERNET EXPLORER 8.0............................................................................................................15
6.5 REGRESSION TESTING............................................................................................................15
REGRESSION TESTING WILL BE CONDUCTED AT THE CONCLUSION OF EACH TESTING ITERATION BY THE SQA DEPARTMENT
AND ANY ASSIGNED BUSINESS UNIT SUBJECT MATTER EXPERTS. IN MOST CASES, THE TESTING WILL BE BASED ON SEVERITY OF

DEFECTS DETECTED.....................................................................................................................16

6.6 REQUIREMENTS MANAGEMENT..................................................................................................16

THE BUSINESS REQUIREMENTS WILL BE ELICITED AND MANAGED BY THE SYSTEMS BUSINESS ANALYST. ANY ELEMENTS IN
THE REQUIREMENTS AND DESIGN THAT DO NOT MAKE SENSE OR ARE NOT TESTABLE WILL BE IMMEDIATELY DOCUMENTED AND

REPORTED TO THE SBA; WHO WILL IN TURN ADDRESS THESE ISSUES WITH THE SHAREHOLDERS FOR FURTHER CLARIFICATION.
..........................................................................................................................................16
7 TEST STRATEGY.............................................................................................16
7.1 SYSTEM TEST.....................................................................................................................16
7.2 PERFORMANCE TEST.............................................................................................................16
7.3 SECURITY TEST...................................................................................................................16
7.4 AUTOMATED TEST................................................................................................................16
7.5 STRESS AND VOLUME TEST ...................................................................................................16
7.6 RECOVERY TEST ..............................................................................................................17
7.7 DOCUMENTATION TEST .......................................................................................................17
7.8 BETA TEST.......................................................................................................................17
7.9 USER ACCEPTANCE TEST........................................................................................................17
8 ENTRY AND EXIT CRITERIA.............................................................................17
 8.1 TEST PLAN........................................................................................................................17
8.1.1 Test Plan Entry Criteria........................................................................................17
8.1.2 Test Plan Exit Criteria..........................................................................................17
8.1.3 Suspension and Resumption Criteria...................................................................17
8.2 TEST CYCLES.....................................................................................................................18
8.2.1 Test Cycle Entry Criteria......................................................................................18
8.2.2 Test Cycle Exit Criteria........................................................................................18
9 DELIVERABLES..............................................................................................18
9.1 TEST EVALUATION SUMMARIES..................................................................................................19
9.2 INCIDENT LOGS AND CHANGE REQUESTS......................................................................................19
10 ENVIRONMENT REQUIREMENTS....................................................................19
10.1 BASE SYSTEM HARDWARE....................................................................................................19
10.2 BASE SOFTWARE ELEMENTS IN THE TEST ENVIRONMENT..................................................................20
10.3 PRODUCTIVITY AND SUPPORT TOOLS.........................................................................................20
11 RESPONSIBILITIES, STAFFING AND TRAINING NEEDS.....................................20
11.1 PEOPLE AND ROLES............................................................................................................20
11.2 STAFFING AND TRAINING NEEDS..............................................................................................23
12 TEST SCHEDULE...........................................................................................23
13 POTENTIAL RISKS AND CONTINGENCIES........................................................24
14 CONTROL PROCEDURES...............................................................................24
14.1 REVIEWS........................................................................................................................24
14.2 BUG REVIEW MEETINGS........................................................................................................24
14.3 CHANGE REQUEST.............................................................................................................24
14.4 DEFECT REPORTING............................................................................................................25
15 DOCUMENTATION........................................................................................25
16 ITERATION MILESTONES...............................................................................26
17 MANAGEMENT PROCESS AND PROCEDURES..................................................27
17.1 PROBLEM REPORTING, ESCALATION, AND ISSUE RESOLUTION.............................................................27
17.2 APPROVAL AND SIGNOFF......................................................................................................27

1 Introduction

1.1 Purpose
The purpose of this Software Quality Assurance (SQA) Plan is to establish the goals,
processes, and responsibilities required to implement effective quality assurance
functions for the [Project Name] Improvement project.

This [Project Name] Improvement Software Quality Assurance Plan provides the
framework necessary to ensure a consistent approach to software quality assurance
throughout the project life cycle. It defines the approach that will be used by the
Software Quality (SQ) personnel to monitor and assess software development processes
and products to provide objective insight into the maturity and quality of the software.
The systematic monitoring of the [Project Name] products, processes, and services will
be evaluated to ensure they meet requirements and comply with [COMPANY NAME] and
[Project Name] policies, standards, and procedures, as well as applicable Institute of
Electrical and Electronic Engineers (IEEE) standards.

The overall purpose of this Master Test Plan is to gather all of the information necessary
to plan and control the test effort for testing the [Project Name] application. It
describes the approach to testing the software, and will be the top-level plan used by
testers to direct the test effort.

This plan is designed to create clear and precise documentation of the test methods and
processes that [COMPANY NAME] will use throughout the course of the [Project Name]
system verification testing.

This plan covers SQA activities throughout the formulation and implementation phases
of the [Project Name] mission. SQA activities will continue through operations and
maintenance of the system.

This Documenting of the test methods and processes will serve as the basis for ensuring
that all major milestones and activities required for effective verification testing can
efficiently and successfully be accomplished. This Master Test Plan will be modified and
enhanced as required throughout the verification testing engagement.

1.2 Scope
The scope of this quality assurance effort is to validate the full range of activities related
to the functionality of the flagship product of the [COMPANY NAME]: the [Project Name]
Course; as it undergoes re-designing and re-building.

This test plan describes the unit, subsystem integration, and system level tests that will
be performed on components of the [Name] application. It is assumed that prior to
testing each subsystem to be tested will have undergone an informal peer review and
only code that has successfully passed a peer review will be tested.

Unit tests will be done through test driver program that perform boundary checking and
basic black box testing.

The scope of this test effort outlines the quality assurance methodology, process and
procedures used to validate system functionality and the user’s ability to navigate
through the 4 major components of the [Project Name] Course solution:
  The Prep Course
 Practice Exams
 The [PRODUCT NAME]Exam
 A Progress Tracking

The functional testing will include a Prep Course creation and maintenance tool (Admin
Tool) for use by internal [COMPANY NAME] staff to facilitate creating new Prep Course,
Practice Exam, and [PRODUCT NAME]Exam question and answer databases, as well as
testing the ability to maintain those question and answer databases by adding new
questions, correcting errors in existing questions, modifying responses, etc. This
internal tool will support the maintenance of multiple versions of the software, and
should be capable of generating a database suitable for distribution with the software
itself. Finally, the test effort will include an internal tool which allows [COMPANY NAME]
staff to review results that are uploaded by users for the Prep Course, Practice Exams,
and [PRODUCT NAME]Exam.

1.2.1 Product Description

The [Project Name] Course is a software product sold by the [COMPANY NAME] to
its members to help them study and prepare for the [PRODUCT NAME]Exam, which
is required for an individual to earn their Certified Fraud Examiner certification. The
[Project Name] Course software actually encompasses two different applications:
The [Project Name] Course itself, which offers over a thousand sample questions for
the member to study, and the actual [PRODUCT NAME]Exam, which administers
randomly-selected questions from a question database in a timed session.

The [Project Name] Course and [PRODUCT NAME]Exam are offered in US,
Canadian, UK, and International editions, and a new revision of each is released
annually.

1.2.2 The Current Product Version

Currently, this product exists in multiple buyable formats, including the stand-alone
Prep Course and Exam on CD, a downloadable version of the Prep + Exam, the
[PRODUCT NAME]Exam-only CD, a downloadable version of the [PRODUCT
NAME]Exam, and the [Project Name] Toolkit, which includes hard-copy study
material. In each case, both the [Project Name] Course and the [PRODUCT
NAME]Exam software programs are Microsoft Windows-based desktop applications
that utilize an encrypted Microsoft Access database for data storage. Users of the
software are initially provided with a license key to unlock the Prep Course.

Upon successful completion of the Prep Course, they are then provided a second
key to unlock the [PRODUCT NAME]Exam. The user may submit the results of the
Exam by exporting an encrypted text file from the software and then emailing that
file to the [COMPANY NAME] for grading.
1.2.3 Updating the Product
The software has proven to be a very stable and reliable product despite the fact
that it was developed in 1999; however, the product is showing its age and needs
to be re-written to bring it up to current standards. Since the product has proven to
be very successful and has received a great deal of positive feedback from users, it
is the intent of this project to keep most of the features of the existing version
intact. Additionally, several new features and enhancements will be added to
improve the customer experience with the product, help users work through the
Prep Course more efficiently, as well as to enhance the installation, maintenance,
and administration of the software. For this initial release, the product will continue
to be offered as an installable product on Windows-based PCs and will not require
Internet access, with the exception of a few specific tasks (such as license key
verification, transmitting exam results to the [COMPANY NAME], and receiving
updates and patches).

1.2.4 High-Level Product Development Objective

The high-level objectives of this project are as follows:

 Update the software to a current technology platform while

maintaining the core functionality of the original product

 Re-design the user interface to take advantage of current technology

standards, and to deliver a better user experience

 Improve the process for creating new versions of the [Name] by

providing tools that allow the addition, modification, and removal of questions
from the questions database, maintenance of sections and sub-sections, and
error-checking routines that ensure the question and answers database is
assembled correctly

 Provide a method for delivering updates to the product electronically

and seamlessly to the user

 Provide a feature set that helps the user proceed through the
certification process faster and more efficiently, from the time the product is
purchased to the time the exam results are submitted to the [COMPANY
NAME] for evaluation

 Allow internal non-technical personnel to manage the creation and

maintenance of new [Name] versions
1.3 Test Plan Objectives
This Test Plan for the new [Project Name] Course solutions supports the following
objectives:

This Test Plan supports the following objectives:

 Outlines and defines the overall test approach that will be used.

 Identifies hardware, software, and tools to be used to support the testing

efforts.

 Defines the types of tests to be performed.

 Defines the types of exam data required for effective testing.

 Defines the types of security threats and vulnerabilities against which each
exam system will be tested.

 Identifies and establishes traceability from the Requirements Matrix to test

cases and from test cases to the Requirements Matrix.

 Serves as a foundation for the development of Test Plans and Test Cases.

 Defines the process for recording and reporting test results.

 Defines the process for regression testing and closure of discrepancies.

 Identifies the items that should be targeted by the tests.

 Identifies the motivation for and ideas behind the test areas to be covered.

 Identifies the required resources and provides an estimate of the test efforts.

 List the deliverable elements of the test activities.

 Define the activities required to prepare for and conduct System, Beta and
User Acceptance testing

 Communicate to all responsible parties the System Test strategy

 Define deliverables and responsible parties

 Communicate to all responsible parties the various Dependencies and Risks

 Scope
2 Test Items (Functions)
The testing effort will be concentrated on the following functions of the application:

2.1 Client Application

 Installation
 Uninstall
 Activation
 Prep Course Home Page
 Pre-Assessment
 Review Sessions
 Practice Exams
 Exam Application
 Admin Tool
 Editions
 Revisions
 Sections
 Subsections
 Topics
 Demo Questions (create, view, edit, and approve)
 Test Search Capability
 License Keys
 Exam Keys
 Review Exam Key Requests
 Review Exam Submissions
 Issue Reports

2.2 Quick Help Testing

The system will provide the [Name] users the ability to access a help menu; consisting
of links to various options. These following utility options will be tested:

 [COMPANY NAME] Reference Manual

 Launch [Project Name] Course
 Your Contact Information
 [COMPANY NAME].com
 FAQs
 Online Discussion Forums
 [PRODUCT NAME]Certification
 Qualification Checklist
 Request Exam Key
 Enter Exam Key
 Submit [PRODUCT NAME]Exam to [COMPANY NAME]
 Utilities
 Check for Updates
  Activate Product
 Report Issue

2.3 License Key

Current the License Key is requested by submitting an email to the [COMPANY NAME]
Certification Team. The [COMPANY NAME] Certification Team will electronically generate
and email the license key back to the requestor.

New functionality will be implemented to enhance this process. The users will be
required to complete and electronically submit a License Key request form to the
[COMPANY NAME] Certification Team. The [COMPANY NAME] Certification Team will
electronically generate and email the license key back to the requestor.

This new functionality will be included in the scope of the testing effort.

2.4 Security
Each user will need a UserId and password to login to the system. The UserId and
password will be created by the user during the registration process. The system should
validate that the UserId and password both meet the correct format standard. Once the
registration form has been electronically submitted, the system will notify the user that
the requested identification information has been accepted and the request has been
granted. The system will require the users to change the password every 30 days.

3 Software Risk Issues

3.1 Schedule
The schedule for each phase is very aggressive and could affect testing. A slip in the
schedule in one of the other phases could result in a subsequent slip in the test phase.
Close project management is crucial to meeting the forecasted completion date.

3.2 Technical
Since this is a new [Name] system, in the event of a failure the old system can be used.
We will run our test in parallel with the production system so that there is no downtime
of the current system.

3.3 Management
Management support is required so when the project falls behind, the test schedule does
not get squeezed to make up for the delay. Management can reduce the risk of delays
 by supporting the test team throughout the testing phase and assigning people to this
project with the required skills set.

3.4 Personnel
Due to the aggressive schedule, it is very important to have experienced testers on this
project. Unexpected turnovers can impact the schedule. If attrition does happen, all
efforts must be made to replace the experienced individual.

3.5 Requirements
The test plan and test schedule are based on the current Requirements Document. Any
changes to the requirements could affect the test schedule and will need to be approved
by the CCB.

4 Functions to Be Tested

The following is a list of functions that will be tested:

 Add/update user information

 Search / Lookup employee information
 Escape to return to Main Menu
 Security features
 Error messages
 Prep Course Functionality
 New License Key Request Functionality
 Practice Exam Functionality
 [PRODUCT NAME]Exam Functionality
 Progress Tracking Functionality
 Screen mappings (GUI flow). Includes default settings

A Requirements Validation Matrix will “map” the test cases back to the requirements. See
Deliverables.

5 Functions to Not Be Tested

This is to be determined.
6 Test Approach
Functional testing will be conducted during the entire Application Development Life Cycle by
the Quality Assurance Engineer and the System Business Analyst. At the conclusion of each
iteration, formal testing will be conducted by the business unit subject matter experts in two
cycles; while overall testing of the entire system will be conducted by the Quality Assurance
Engineer and the System Business Analyst in one final cycle.
The overall testing approach of the project will address and encompass the following rules
and processes:

6.1 Special Testing Tools

 Microsoft Visual Studio 2010 Ultimate - The comprehensive suite of application

lifecycle management tools used by the [COMPANY NAME] Software Development
Team to ensure quality results, from design to deployment. It includes: Integrated
Development Environment, Development Platform Support, Team Foundation Server,
MSDN Subscription, Testing Tools, Database Development, Debugging and
Diagnostics, Application Lifecycle Management, Architecture and Modeling, and Lab
Management.

 Visual Studio Test Professional 2010 - An integrated testing toolset that delivers
a complete plan-test-track workflow for in-context collaboration between testers and
developers.

 Microsoft Visual Studio Team Foundation Server 2010 (TFS) - The

collaboration platform at the core of our application lifecycle management (ALM)
process. Team Foundation Server 2010 automates the software delivery process and
enables everyone on our team to collaborate more effectively, be more agile, and
deliver better quality software while building and sharing institutional knowledge.
 Project artifacts like requirements, tasks, bugs, source code, and build and test
results are stored in a data warehouse. The tool also contains the reporting,
historical trending, full traceability, and real-time visibility into quality and progress.

6.2 Special Training on Testing Tools

Since Microsoft Visual Studio 2010 Ultimate is a relatively new tool on the market, some
special training will be required. Due to the current time constraints of the project, this
training will be scheduled and completed at a later date.

However, the Development Team; including the SQA Engineer, has proactively begun
“self-learning” and utilizing the tool and has integrated the use of the Microsoft tools
into its overall testing strategy.

6.3 Test Metrics

Testing Information will be collected and oriented toward the level of testing. For higher
levels, application and functional data will be collected and documented. For lower
levels, program, unit, module and build data will be collected and documented.

All test results will be documented in the Master Test Case spreadsheet, reviewed by
the business unit team leader, and forwarded to the Quality Assurance Engineer and the
System Business Analyst.

The test results will be evaluated and entered into the Team Foundation Server through
the use of Visual Studio Test Manager; where each “automatable” test case will be
recorded and run using the “Coded UI Test” feature in Visual Studio 2010 Ultimate.

Reports will be generated highlighting:

 The name of the assigned tester

 The number of test cases completed

 The number of passed and failed test cases

  The number of open issued (by priority)

Eventually, performance testing will be conducted to measure the system response

time, baseline load, and system stress capacity.

6.4 Configuration Management

Test configuration management will be managed by the Lab Manager tool; included with
the Microsoft Visual Studio 2010 Ultimate package.

Lab Manager can fully provision and ready multiple environments for testing so that
build scripts can explicitly target a particular lab configuration at build time. Lab
Management stores the environments as virtual machine images in a library of pre-built
images using System Center Virtual Machine Manager (SCVMM) to ensure teams always
begin their testing from a known configuration.

The following operating systems and browser will be used in multiple combinations for
testing the [Project Name] application:

Operating Systems

 Windows XP

 Windows Vista

 Windows 7

Browsers

 Firefox 3.0

 Internet Explorer 7.0

 Internet Explorer 8.0

6.5 Regression Testing

 Regression testing will be conducted at the conclusion of each testing iteration by the
SQA Department and any assigned business unit subject matter experts. In most cases,
the testing will be based on severity of defects detected.

6.6 Requirements Management

The business requirements will be elicited and managed by the Systems Business
Analyst. Any elements in the requirements and design that do not make sense or are
not testable will be immediately documented and reported to the SBA; who will in turn
address these issues with the shareholders for further clarification.

7 Test Strategy

The test strategy consists of a series of different tests that will fully exercise the [Name]
system. The primary purpose of these tests is to uncover the systems limitations and
measure its full capabilities. A list of the various planned tests and a brief explanation
follows below.

7.1 System Test

The System tests will focus on the behavior of the [Name] system. User scenarios will be
executed against the system as well as screen mapping and error message testing.
Overall, the system tests will test the integrated system and verify that it meets the
requirements defined in the requirements document.

7.2 Performance Test

Performance test will be conducted to ensure that the [Name] system’s response times
meet the user expectations and do not exceed the specified performance criteria. During
these tests, response times will be measured under heavy stress and/or volume.

7.3 Security Test

Security tests will determine how secure the new [Name] system is. The tests will verify
that unauthorized user access to confidential data is prevented.

7.4 Automated Test

A suite of automated tests will be developed to test the basic functionality of the [Name]
system and perform regression testing on areas of the systems that previously had
critical/major defects. The tool will also assist us by executing user scenarios thereby
emulating several users.

7.5 Stress and Volume Test

 We will subject the [Name] system to high input conditions and a high volume of data
during the peak times. The System will be stress tested using twice (20 users) the
number of expected users.

7.6 Recovery Test

Recovery tests will force the system to fail in a various ways and verify the recovery is
properly performed. It is vitally important that all [Name] data is recovered after a
system failure & no corruption of the data occurred.

7.7 Documentation Test

Tests will be conducted to check the accuracy of the user documentation. These tests
will ensure that no features are missing, and the contents can be easily understood.

7.8 Beta Test

The [Name] department will beta tests the new [Name] system and will report any
defects they find. This will subject the system to tests that could not be performed in our
test environment.

7.9 User Acceptance Test

Once the [Name] system is ready for implementation, the [Name] department will
perform User Acceptance Testing. The purpose of these tests is to confirm that the
system is developed according to the specified user requirements and is ready for
operational use.

8 Entry and Exit Criteria

8.1 Test Plan

8.1.1 Test Plan Entry Criteria
Package coding is complete and the code has been informally reviewed by the team.

8.1.2 Test Plan Exit Criteria

Either the second semester ends or all of the use case requirements have been
verified.

8.1.3 Suspension and Resumption Criteria

Testing will be suspended on critical design flaws that will require a package,
package interface redesigned. Testing will resume when the coding is complete and
code is reviewed successfully.
 If testing is suspended, resumption will only occur when the problem(s) that caused
the suspension has been resolved. When a critical defect is the cause of the
suspension, the “FIX” must be verified by the test department before testing is
resumed.

8.2 Test Cycles

8.2.1 Test Cycle Entry Criteria
TBD

8.2.2 Test Cycle Exit Criteria

All tests specified at the start of the iteration have completed successfully, or the end
of the second semester occurs.

If any defects are found which seriously impact the test progress, the QA manager
may choose to suspend testing. Criteria that will justify test suspension are:
Hardware/software is not available at the times indicated in the project schedule.

 Source code contains one or more critical defects, which seriously prevents or
limits testing progress.

 Assigned test resources are not available when needed by the test team.

9 Deliverables

Deliverable Responsibility Delivery Date

Develop Test cases Testers 10/13/2010

Test Case Review Test Lead, Dev. Lead, 10/15/2010
Testers
 Develop Automated test Testers TBD
suites
Requirements Validation Test Lead TBD
Matrix
Execute manual and Testers & Test Lead 9/20 – 10/15/2010
automated tests
Complete Defect Reports Everyone testing the product On-going
Document and Test Lead Weekly
communicate test
status/coverage
Execute Beta tests [Name] Department Users 10/18 – 10/29/2010
Document and [Name] Department Manager TBD
communicate Beta test
status/coverage
Execute User Acceptance [Name] Department Users 10/18 – 10/29/2010
tests
Document and [Name] Department Manager TBD
communicate Acceptance
test status/coverage
Final Test Summary Report Test Lead 11/1/2010

The following artifacts will be testing deliverables, available to the stakeholders:

9.1 Test Evaluation Summaries

These summaries will outline the tests conducted and their results.

9.2 Incident Logs and Change Requests

Incident log entries will be made for all bugs found during testing. The log will be used
to track the status of the bugs.
Any modifications to the requirements must be done through change requests, which
will ensure the proposed change is fully reviewed before being incorporated into the
[Name] application.

10 Environment Requirements

This section presents the non-human resources required for the Test Plan.

10.1 Base System Hardware

The following table sets forth the system resources for the test effort presented in this Test
Plan.

System Resources
Resource Quantity Name and Type
Application Server 1
 System Resources
Resource Quantity Name and Type
—CPUs
—Memory
—Hard Disk 1
—Hard Disk 2
—Server Name
—IP Address
Test Development PCs TBD

10.2 Base Software Elements in the Test Environment

The following base software elements are required in the test environment for this Test
Plan.

Software Element Name Version Type and Other Notes

Windows Server
SQL Server

10.3 Productivity and Support Tools

The following tools will be employed to support the test process for this Test Plan.
Tool Category or Type Tool Brand Name Vendor or In-house Version
Test Management Microsoft 2010
Defect Tracking

11 Responsibilities, Staffing and Training Needs

This section outlines the personnel necessary to successfully test the [Name] application.
Since staff size is fixed these number may change.

11.1 People and Roles

This table shows the staffing assumptions for the test effort.
Human Resources

Role Minimum Resources Specific Responsibilities or

Recommended Comments

(number of full-time
roles allocated)

Test Analyst 1 Identifies and defines the specific tests

to be conducted.

Responsibilities include:

• identify test ideas

• define test details

• determine test results

• document change requests

• evaluate product quality

Test Designer 1 Defines the technical approach to the

implementation of the test effort.

Responsibilities include:

• define test approach

• define test automation architecture

• verify test techniques

• define testability elements

• structure test implementation

Human Resources

Role Minimum Resources Specific Responsibilities or

Recommended Comments

(number of full-time
roles allocated)

Tester 2 Implements and executes the tests.

Responsibilities include:

• implement tests and test suites

• execute test suites

• log results

• analyze and recover from test

failures

• document incidents

Database 1 Ensures test data (database)

Administrator, environment and assets are managed
Database Manager and maintained.

Responsibilities include:

• Support the administration of test

data and test beds (database).

Designer 1 Identifies and defines the operations,

attributes, and associations of the test
classes.

Responsibilities include:

• defines the test classes required

to support testability
requirements as defined by the
test team
 Human Resources

Role Minimum Resources Specific Responsibilities or

Recommended Comments

(number of full-time
roles allocated)

Implementer 2 Implements and unit tests the test

classes and test packages.

Responsibilities include:

• creates the test components

required to support testability
requirements as defined by the
designer

11.2 Staffing and Training Needs

This section outlines how to approach staffing and training the test roles for the
project.

Staffing is fixed for the duration of this project. It is likely most of the staff will
assume some testing role.

12 Test Schedule

 Ramp up / System familiarization 10/01/10 - 10/15/10

 System Test 10/16/10 - 12/26/10
 Beta Test 12/28/10 - 01/18/11
 User Acceptance Test 01/19/11 - 02/01/11
13 Potential Risks and Contingencies

The overall risks to the project with an emphasis on the testing process are:

• Lack of personnel resources when testing is to begin.

• Lack of availability of required hardware, software, data or tools.

• Late delivery of the software, hardware or tools.

• Delays in training on the application and/or tools.

• Changes to the original requirements or designs.

Requirements definition will be complete by September 1, 2010, and, if the requirements

change after that date, the following actions will be taken:

• The test schedule and development schedule could move out an appropriate number
of days.

• The number of test performed could be reduced.

• The number of acceptable defects could be increased.

• Resources could be added to the test team.

• The test team could be asked to work overtime.

• The scope of the plan may be changed.

• There may be some optimization of resources.

14 Control Procedures

14.1 Reviews
The project team will perform reviews for each Phase. (i.e. Requirements Review,
Design Review, Code Review, Test Plan Review, Test Case Review and Final Test
Summary Review). A meeting notice, with related documents, will be emailed to each
participant.

14.2 Bug Review meetings

Regular weekly meeting will be held to discuss reported defects. The development
department will provide status/updates on all defects reported and the test department
will provide addition defect information if needed. All member of the project team will
participate.
14.3 Change Request
 Once testing begins, changes to the [Name] system are discouraged. If functional
changes are required, these proposed changes will be discussed with the Change Control
Board (CCB). The CCB will determine the impact of the change and if/when it should be
implemented.

14.4 Defect Reporting

When defects are found, the testers will complete a defect report on the defect tracking
system and submit the report to the Eureka software engineers for analysis. The defect
tracking system is accessible by testers, developers & all members of the project team.
When a defect has been fixed or more information is needed, the Eureka developer will
change the status of the defect to indicate the current state. Once a defect is verified as
“fixed” by the testers; the testers will close the defect report.

15 Documentation
The following documentation will be available at the end of the test phase:

 Test Plan

 Test Cases

 Test Case review

 Requirements Validation Matrix

 Defect reports

 Final Test Summary Report

16 Iteration Milestones

Milestone Planned Actual Planned Actual

Start Date Start Date End Date End Date
Iteration Plan agreed
Iteration starts
Requirements base lined
Architecture base lined
User Interface base lined
First Build delivered to
test
First Build accepted into
test
First Build test cycle
finishes
[Build Two will not be
tested]
Third Build delivered to
test
Third Build accepted into
test
Third Build test cycle
finishes
Fourth Build delivered to
test
Fourth Build accepted
into test
Iteration Assessment
review
Iteration ends
17 Management Process and Procedures

17.1 Problem Reporting, Escalation, and Issue Resolution

Problems will be reported to the team by e-mail. Bugs will be listed on the project page
with the developer responsible for fixing each bug. Each bug will be given a priority,
which will determine when it is addressed in the current iteration.

17.2 Approval and Signoff

The team manager must approve the initial test plan. As tests are successfully
completed the testers will sign off use case requirements.