I need to prepare a Test Plan. Any one can provide the a
Test Plan model which is sinple so that I can change use it
in my company...
- 2 Answers
- 9135 Views
- Global Edge, I also Faced
- E-Mail Answers
Answers were Sorted based on User's Feedback
Answer / madhavi
here is the sample test plan
TEST PLAN (Sample)
courtesy of sqatestester.com
Company Name
Test Plan Revision C
Revision History
DATE
REV
AUTHOR DESCRIPTION
5/14/98
A
First Draft
5/21/98
B
Second Draft
5/25/98
C
Added FTBT
Table of Contents 1. Introduction 4
1.1. Test Plan Objectives. 4
2. Scope…. 4
2.1. Data Entry 4
2.2. ReportsFile Transfer….. 4
2.3. File Transfer….. 4
2.4. Security 4
3. Test Strategy……. 5
3.1. System Test………. 5
3.2. Performance Test………. 5
3.3. Security Test………. 5
3.4. Automated Test………. 5
3.5. Stress and Volume Test………. 5
3.6. Recovery Test………. 5
3.7. Documentation Test……. 5
3.8. Beta Test 5
3.9. User Acceptance Test………. 5
4. Environment Requirements 6
4.1. Data Entry workstations 6
4.2 MainFrame 6
5. Test Schedule…… 6
6. Control Procedures… 6
6.1 Reviews 6
6.2 Bug Review meetings… 6
6.3 Change Request…. 6
6.4 Defect Reporting… 6
7. Functions To Be Tested 7
8. Resources and Responsibilities 7
8.1. Resources. 7
8.2. Responsibilities 7
9. Deliverables 8
10. Suspension / Exit Criteria… 9
11. Resumption Criteria……… 9
12. Dependencies 9
12.1 Personnel Dependencies 9
12.2 Software Dependencies 9
12.3 Hardware Dependancies 9
12.3 Test Data & Database… 9
13. Risks….. 9
13.1. Schedule… 9
13.2. Technical… 9
13.3. Management 9
13.4. Personnel 10
13.5 Requirements 10
14. Tools….. 10
15. Documentation 10
16. Approvals 11
1. Introduction
The company has outgrown its current payroll system & is
developing a new system that will allow for further growth
and provide additional features. The software test
department has been tasked with testing the new system. The
new system will do the following:
§ Provide the users with menus, directions & error
messages to direct him/her on the various options.
§ Handle the update/addition of employee
information.
§ Print various reports.
§ Create a payroll file and transfer the file to
the mainframe.
§ Run on the Banyan Vines Network using IBM
compatible PCs as data entry terminals
1.1. Test Plan Objectives
This Test Plan for the new Payroll System supports the
following objectives:
§ 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
2. Scope
2.1. Data Entry
The new payroll system should allow the payroll clerks to
enter employee information from IBM compatible PC
workstations running DOS 3.3 or higher. The system will be
menu driven and will provide error messages to help direct
the clerks through various options.
2.2. Reports
The system will allow the payroll clerks to print 3 types
of reports. These reports are:
§ A pay period transaction report
§ A pay period exception report
§ A three month history report
2.3. File Transfer
Once the employee information is entered into the LAN
database, the payroll system will allow the clerk to create
a payroll file. This file can then be transferred, over the
network, to the mainframe.
2.4. Security
Each payroll clerk will need a userid and password to login
to the system. The system will require the clerks to change
the password every 30 days.
3. Test Strategy
The test strategy consists of a series of different tests
that will fully exercise the payroll 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.
3.1. System Test
The System tests will focus on the behavior of the payroll
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.
3.2. Performance Test
Performance test will be conducted to ensure that the
payroll system’s response times meet the user expectations
and does not exceed the specified performance criteria.
During these tests, response times will be measured under
heavy stress and/or volume.
3.3. Security Test
Security tests will determine how secure the new payroll
system is. The tests will verify that unauthorized user
access to confidential data is prevented.
3.4. Automated Test
A suite of automated tests will be developed to test the
basic functionality of the payroll 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.
3.5. Stress and Volume Test
We will subject the payroll 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.
3.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 payroll data is recovered after
a system failure & no corruption of the data occurred.
3.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.
3.8. Beta Test
The Payroll department will beta tests the new payroll
system and will report any defects they find. This will
subject the system to tests that could not be performed in
our test environment.
3.9. User Acceptance Test
Once the payroll system is ready for implementation, the
Payroll 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.
4. Environment Requirements
4.1. Data Entry workstations
§ 20 IBM compatible PCs (10 will be used by the
automation tool to emulate payroll clerks).
§ 286 processor (minimum)
§ 4mb RAM
§ 100 mb Hard Drive
§ DOS 3.3 or higher
§ Attached to Banyan Vines network
§ A Network attached printer
§ 20 user ids and passwords (10 will be used by the
automation tool to emulate payroll clerks).
4.2 MainFrame
§ Attached to the Banyan Vines network
§ Access to a test database (to store payroll
information transferred from LAN payroll system)
5. Test Schedule
§ Ramp up / System
familiarization 6/01/98 -
6/15/98
§ System
Test
6/16/98 - 8/26/98
§ Beta
Test
7/28/98 - 8/18/98
§ User Acceptance
Test
8/29/98 - 9/03/98
6. Control Procedures
6.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.
6.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.
6.3 Change Request
Once testing begins, changes to the payroll 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.
6.4 Defect Reporting
When defects are found, the testers will complete a defect
report on the defect tracking system. The defect
tracking Systems is accessible by testers, developers
& all members of the project team. When a defect has been
fixed or more information is needed, the 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.
7. Functions To Be Tested
The following is a list of functions that will be tested:
§ Add/update employee information
§ Search / Lookup employee information
§ Escape to return to Main Menu
§ Security features
§ Scaling to 700 employee records
§ Error messages
§ Report Printing
§ Creation of payroll file
§ Transfer of payroll file to the mainframe
§ Screen mappings (GUI flow). Includes default
settings
§ FICA Calculation
§ State Tax Calculation
§ Federal Tax Calculation
§ Gross pay Calculation
§ Net pay Calculation
§ Sick Leave Balance Calculation
§ Annual Leave Balance Calculation A Requirements
Validation Matrix will “map” the test cases back to the
requirements. See Deliverables.
8. Resources and Responsibilities
The Test Lead and Project Manager will determine when
system test will start and end. The Test lead will also be
responsible for coordinating schedules, equipment, & tools
for the testers as well as writing/updating the Test Plan,
Weekly Test Status reports and Final Test Summary report.
The testers will be responsible for writing the test cases
and executing the tests. With the help of the Test Lead,
the Payroll Department Manager and Payroll clerks will be
responsible for the Beta and User Acceptance tests.
8.1. Resources
The test team will consist of:§ A Project Manager
§ A Test Lead
§ 5 Testers
§ The Payroll Department Manager
§ 5 Payroll Clerks
8.2. Responsibilities
Project Manager Responsible for Project schedules and
the overall success of the project. Participate on CCB.
Lead Developer Serve as a primary contact/liaison
between the development department and the project team.
Participate on CCB.
Test Lead Ensures the overall success of the test
cycles. He/she will coordinate weekly meetings and will
communicate the testing status to the project team.
Participate on CCB.
Testers Responsible for performing the actual system
testing.
Payroll Department Manager Serves as Liaison between
Payroll department and project team. He/she will help
coordinate the Beta and User Acceptance testing efforts.
Participate on CCB.
Payroll Clerks Will assist in performing the Beta and
User Acceptance testing.
9. Deliverables
Deliverable Responsibility Completion Date
Develop Test cases Testers 6/11/98
Test Case Review Test Lead, Dev. Lead, Testers 6/12/98
Develop Automated test suites Testers 7/01/98
Requirements Validation Matrix Test Lead 6/16/98
Obtain User ids and Passwords for payroll system/database
Test Lead 5/27/98
Execute manual and automated tests Testers & Test Lead
8/26/98
Complete Defect Reports Everyone testing the product On-
going
Document and communicate test status/coverage Test Lead
Weekly
Execute Beta tests Payroll Department Clerks 8/18/98
Document and communicate Beta test status/coverage Payroll
Department Manager 8/18/98
Execute User Acceptance tests Payroll Department Clerks
9/03/98
Document and communicate Acceptance test status/coverage
Payroll Department Manager 9/03/98
Final Test Summary Report Test Lead 9/05/98
10. Suspension / Exit Criteria
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.
11. Resumption Criteria
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.
12. Dependencies
12.1 Personnel Dependencies
The test team requires experience testers to develop,
perform and validate tests.
The test team will also need the following resources
available: Application developers and Payroll Clerks.
12.2 Software Dependencies
The source code must be unit tested and provided within the
scheduled time outlined in the Project Schedule.
12.3 Hardware Dependencies
The Mainframe, 10 PCs (with specified hardware/software) as
well as the LAN environment need to be available during
normal working hours. Any downtime will affect the test
schedule.
12.3 Test Data & Database
Test data (mock employee information) & database should
also be made available to the testers for use during
testing.
13. Risks
13.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.
13.2. Technical
Since this is a new payroll 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.
13.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.
13.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
13.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.
14. Tools
The Acme Automated test tool will be used to help test the
new payroll system. We have the licensed product onsite and
installed. All of the testers have been trained on the use
of this test tool.
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. Approvals
Name (Print) Signature Date
1.
2.
3.
4.
5.
Pages
LOADRUNNER TUTORIAL
MORE QUESTIONS
RATIONAL CLEARQUEST
RESUME (Sample)
TEST CASE (Sample)
TEST ENVIRONMENTS
TEST PLAN (Sample)
TESTDIRECTOR TUTORIAL
TRACEABILITY MATRIX (Sample)
USE CASE (Sample)
Archives
January 2007
Categories
Software Testing (1)
Meta
Register
Login
Valid XHTML
XFN
WordPress
------------------------------------------------------------
--------------------
| Is This Answer Correct ? | 6 Yes | 0 No |
Answer / vaibhav
1.INTRODUCTION..........................................................................6
1.1
Objectives..........................................................................6
1.2
Scope................................................................................6
1.3
Definitions/Acronyms/Abbreviation............................................7
1.4 Reference
documents.............................................................7
1.5 Assumption for test
execution...................................................7
2.TEST
STRATEGIES.......................................................................8
2.1 Test
Approach.....................................................................8
2.1.1 Test
Types...................................................................8
2.2 Model of
Execution................................................................9
2.3 Partitioning of Work Among
Team..............................................9
2.4 Test Competency Development & Training
Plans............................10
2.5 Entry and Exit Criteria for Transfer
Between Test Phases..................10
2.6 Completion of
Testing............................................................11
2.7 Test
Reuse..........................................................................11
2.8 Test
Environment..................................................................12
2.8.1 Test
Bed.....................................................................12
2.8.2 Test
Tools...................................................................12
2.9 Functional
Criticality.............................................................12
2.9.1 Test Case
Priority...........................................................12
2.9.2 Test Coverage
Goals........................................................13
2.10 Quality
Goals......................................................................13
2.11 Test Matrices to be
Collected..................................................14
2.12 Defect Logging and Tracking
Process..........................................14
2.12.1 Defect Tracking
Tool......................................................14
2.13 Defect
Source.....................................................................14
2.14 Defect
Severity...................................................................15
2.15 Defect
Priority....................................................................15
2.16 Defect Leakage and Defect
Mapping..........................................16
2.17 Defect
Status......................................................................16
2.18
Deliverables.......................................................................17
2.19 Assumptions / Constraints /
Dependencies...................................17
3.DESCRIPTION OF
TESTING.............................................................18
3.1 Testing
Types.....................................................................18
3.1.1 Function
Testing.............................................................18
3.1.1.1 Security and Access control
Testing................................19
3.1.1.2 User Interface
Testing................................................19
3.2 Requirements related
issues...................................................20
3.2.1 Requirement that cannot be
tested......................................20
3.2.2 Requirement that need clarity and
clarification.......................20
3.2.3 Testing Completeness
Criteria............................................20
| Is This Answer Correct ? | 1 Yes | 0 No |
How do we do testing if requirements are not documented properly?
how many levels of test execution will you follow and describe them?
if there are 10 step in test cases while executing if their is mismatch at step 5 what is status of test case ? pass or fail or anything else? if require tab is not available then what's the status of test case?
how many levels of regression testing is avilable in our testing process?
How do you document well a website (i.e an ONG website) pls help me with a sample. Need your help UR
can we test the product with out documents?
how will you decide defect severity & priority?
How To write Wimax field testing test cases,,,,? both negitive and Positive,,,,follows rule Tringulation (Logitude and latitude)
what is your company testcase format?
18 Answers Infosys, MasterMind, Sinsoft,
how will you know whether your reported defect rejected?
differentiate test scenario & test case?
17 Answers Talent Sprint, Triniti Advanced Software,
Why I think QA is the positon for me
Automation Testing 
