Test plan Page 1 of 9

Insurance Management System

Version No. 1 Date: 16/08/2010


Mahesh Kolhe
Addr-1: Vidyavihar
City - Mumbai

DOC STATUS : CURRENT

DOC TYPE :
CONTROLLED/UNCONTROLLED/
DRAFT

DOC Ref :

COPY NO. _____

VER. NO. _____

NO. OF PAGES :
(All pages except Title Page)


DATE :

TITLE : INSURANCE
MANAGEMENT SYSTEM


PREPARED BY :
SIGNATURE

NAME

CHECKED BY :
SIGNATURE

NAME

APPROVED BY :
SIGNATURE

NAME



SUMMARY : This project intends to
store basic information of
a insurance company
and its customers.
DISTRIBUTION :

Total Time spent in preparing
this document *
3hrs
00 mts
Total Time spent in reviewing this 1hrs
Test plan Page 2 of 9
Insurance Management System
Version No. 1 Date: 16/08/2010

document * 00 mts
Total Time spent on reworking
this document *
0 hrs
30 mts
* Time shall be tracked from the Draft Version to Final Version



Test plan Page 3 of 9
Insurance Management System
Version No. 1 Date: 16/08/2010

Revision History
This section describes the details of changes that have resulted in the current Test Plan document.

Serial
No.
Version
Number
Date
Sections Affected Remarks














































Test plan Page 4 of 9
Insurance Management System
Version No. 1 Date: 16/08/2010

Test Plan For Insurance Management System
1. Introduction
This projects stores policy details of a customer, personal details of customer,staff
details.
2. Purpose
This test plan will act as a future guidance for error detection and solving.
3. Scope and Goals
The goals of testing this project are:
To minimize redundancy of data.
To check the correctness of information.
To avoid duplicity of the data.
To organise the data in database under unified format.

4. Features that are not to be tested
Generation of receipt is not to be tested.
Testing is not required after updating the data.
5. Definitions, Acronyms and Abbreviations
T1=Tester 1
Ev=Evaluator
Su=Supervisor
6. References
No references.
7. Product Architecture


INPUT: Policy Holder Information
PROCESSING: Data converted in to standard format.
VALIDATION & TESTING: To test input data.
SORTING & ORGANIZING: Information is sorted according to input data.
OUTPUT: Receipt.
Test plan Page 5 of 9
Insurance Management System
Version No. 1 Date: 16/08/2010

8. Test Environment
8.1 Required Hardware

# Description Version Quantity Start Date End Date
1.
Hard disk : min 20Gb 1 20/8/10 13/9/10
2.
RAM 256Mb 1 20/8/10 13/9/10

8.2 Required Software:

# Description Version Quantity Start Date End Date
1. Windows XP 3 1 20/8/10 13/9/10
2. Visual Studio 6 1 20/8/10 13/9/10
3. Database SQL 7 1 20/8/10 13/9/10

9. Assumptions and Dependencies
No policy holder can have more than three policies record in the database.

10. Constraints
Hardware limitations:
Non availability of required resources.
Criticality of the application.
Safety and security considerations.

11. Test Coverage
11.1 Functionality testing
Sorting the student information using bubble sort.
Validation of input data for correctness.
11.2 User Interface testing
Tests the user interaction and perception of the system.
11.3 Storage testing (file access)
Tests to perform addition, updation, deletion and retrieval of information
from or to files.
11.4 Performance testing
Test plan Page 6 of 9
Insurance Management System
Version No. 1 Date: 16/08/2010

Tests related to performance characteristics like speed of queries,
processing speed, response time etc.
11.5 Security testing
Tests related to security parameters and aspects that have to be tested.
11.6 Recovery testing
Tests related to system failure and recovery like roll back, roll forward,
power fail/restart etc.
11.7 Compatibility/Conversion testing
Tests related to the running of the system on different hardware platforms,
different versions of hardware and software. Also tests to identify that data
is converted properly when hardware/software changes.
11.8 Stress testing
Tests related to boundaries on volume of data, loads due to multi-user,
multi-tasking features and continuous running of the system for the
specified duration.
In case of Regression test, the appropriate coverage must be decided
during each iteration.
12 Test Strategies/Approach
The Test strategy may be for the following types of tests: -
GUI testing
Functional testing
Stress and performance
Boundary testing
Error Handling.
Error Recovery
Regression testing

13 Test Deliverables
The output of the testing the project will be receipt.
14 Human Resource Requirements
14.1 Staff Requirement for Testing

Skill Level Specific Areas For Testing Effort ( Days) Trainings required
4 Navigation & GUI 14
-
3 Functionality 7

4 Database 5

Total Efforts : 14+7+5 = 26
Test plan Page 7 of 9
Insurance Management System
Version No. 1 Date: 16/08/2010

14.2 Roles and Responsibilities
This section shall identify roles and responsibilities of all parties involved in
testing

# Role Responsibility
1. Tester To perform test cases for project
2. Evaluator To validate input and expected output
3. Supervisor To supervise overall test plan

15 Test Schedule

Levels of
Testing
Person
Responsible
Documents and
Records
Approval
Authority
To be
Completed
on
Testing
Strategies
High Tester No 31
st
Aug
2010
Black and
white.
Medium Evaluator Yes 7
th
Sept
2010
Sandwich
testing.
High Supervisor Yes 13
th
Sept
2010
Acceptance
Testing.


16 Readiness Criteria
Code walkthrough must be completed and all subsequent changes to the code
completed before the unit is ready for unit testing
Unit/Module testing of all the units/module in the set must be completed
before integration testing of a set of units/modules
Integration testing of all the modules must be completed before system testing
System testing of all the modules must be completed before acceptance testing


Level of Testing Readiness criteria
Unit Perform acceptance testing
Integration All units must be tested
Systems Integration of all modules
Test plan Page 8 of 9
Insurance Management System
Version No. 1 Date: 16/08/2010


17 Acceptance Criteria
Output data should be based on the correctness input of input data.
17.1 Customer Defined
Each policy should have unique ID and the data should be secured properly
organized in the Database.
17.2 Internally Defined
Name, Date of birth, Registration No, Policy type are mandatory fields.

18 Defect Classification
Describe how the defects will be classified. Refer to section Measurement,
Analysis and Improvement for details on defect classification.

19 Defect Management
This section describes the methodology adopted for defect management. This
involves the defect identification, tracking to closure. Mention the name of a
defect management tool like PR Tracker, if identified for the project.

20 Testing Suspension Criteria
If 5 or more show stopping defects identified then the testing activity will be
suspended.

21 Testing Resumption Criteria
If 3 or more show stopping defects identified and corrected then the testing
activity will be res.

22 Tools And Techniques

# Description Version Quantity Start Date End Date
1. WinRunner
1
20
rh
Aug
2010
31
st
Aug
2010
2. Load Runner
1
1
th
Sept
2010
7
th
Sept
2010
3. QA Load
1
8
th
Sept
2010
13
th
Sept
2010
Test plan Page 9 of 9
Insurance Management System
Version No. 1 Date: 16/08/2010


23 Risk Identification and Contingency Planning

This section identifies the risks that are associated during the testing
Risk # Risk Nature of Impact Contingency Plan

26
Show stopper defects Wasted/idle testing
resources
Making the testing
team perform other
functions during
wait time

34
Insufficient time for
testing
Defects seeping out to
customers.
Distributing the
testing activities.

24 Test Data
The data should be attached along with the documents.

25 Traceability Matrix

SRS/HLD/LLD Reference Section No. and Name
Test Case
Number
No other policy holder can access details of other policy holder 47
Only character should be used in name field 48
Only numbers should be used in Policy No field 49