R 1111-RIA-GUI-Test Plan 1.0

1. Test Plan Identifier:

(Program)(Release No)Test

Plan (Level of Test)

LIA-R1-Test Plan-GUI

1. A Revision History:

Revision History

Version Date Change Description Author

1.0 March 05 Initial Creation QT

1.1 Mar 06

Changes required for Risks

2.0 Introduction:

2.1 A high level

description of what this

level of Test is covering

must be provided

1. QA will validate field

Type, Field Caption,

Business Rules and field

properties associated with

Renters Projects

2.2 The description must

identify the system under

Test (Product, system, or

software being tested)

QA will validate Renters

Insurance Project Agent

Module from Customers

functionality to submit

functionality. This project

involves 3 sub modules.

1. Customer 2. Quotation

3.submit modules

2.3 The description must

identify high level

objectives, Goals and

purpose of the Testing

effort.

Renters Insurance Testing

Agent module objective is

validating the defects

associated with field level

i.e before going to test

system functionalities, in

GUI we will validate all the

Business rules associated

with Agent Module.

The purpose is to test

Functionality, Regression

smoke and adhoc testing

to send the error (Bug)

free code to the Next level

2.4 If a high level

document exist link to the

document must be

provided

Link to the Test Strategy:

2. Testing scope:

3.1 In scope (Features

to be tested)

3.1.1 A description of

the items to be tested

must be provided.

Depending on the level

of test this may include

specific components,

Modules, Interfaces,

Functional

Requirements, Non

functional

Requirements

3.2 Out of scope

(Features not to be

tested)

Renters Insurance:

Functional Requirements

associated with

1. Customers

2. Property Details

3. Loss history

4. Coverages

5. Quotation

6. Billing

7. Attachments

8. Submit

LIA:

1. Customers

2. Policy selection

3. Coverage selection

4. Beneficiaries

5. Underwriting

6. Agent Statement

7. Quotation

8. Billing

9. Documents

10. Submit

3.2.1 A description of

anything provided by the

project but that has been

specifically excluded from

testing effort must be

provided.

1. Navigation from Agent

Login to customer

screen

2. Validations associated

with third party

databases such as

(Dependencies)

1. Customer database

2. Loss history database

3. Billing database

4. After successful

submission of the

policy other products

(Marketing) screen

will be displayed

4. Test Approach:

4.1 For each type of

test create Type of

Testing and

objectives of Testing.

4.1 (Type of Test):

For each type of Test

a description of the

Test, subject of the

test, and the reason

for the test must be

provided

4.1.2 Foe each type

of test the

objectives for

the test must

be identified

4.1.3 For each

objective

identified ,the

approach that

will be used to

meet the

objectives

must be

defined. The

approach must

be how the

testing will be

performed to

validate the

objectives has

been met.

Functional Testing:

1. We will validate all

functional requirements

2. To find the defects

associated with

functional requirements

3. Objective of test is to

find the defects

associated with field

name, field type,

Business Rules

associated.

Smoke Testing:

Smoke Testing purpose is to

find the defects associated

with Environment stability

and build stability.

In this project daily morning

and evening we will perform

smoke testing to find the

stability.

Adhoc Testing:

To find the uncovered

defects during normal

testing we will do adhoc

testing

Regression Testing:

To find the new/injected

defects associated with build

changes/requirement changes

we will do Regression Testing.

5. Test plan

administration:

5.1 Defect Management

Plan:

Responsibilities:

1. All the defects should

be raised in defect

tracking tool called QC

2. All the defects which

come into pending

validation should be

Retested immediately

3. All the defect reports

should be sent to

management.

5.2 Test Management

plan

5.3 Environment

Management

5.4 Estimations

5.5 Status report

managemen

5.6 Configuration

Management

6. Entry criteria and Exit

criteria

Entry criteria for Test case

design:

When to start Test Case

design

1. All the requirements and

design documents are

analyzed by QA and all

the Queries resolved.

2. Required supporting

documents, Test data

should be available.

3. Test case design

(Excl/Tool) should be

available.

Exit criteria for Test case

design:(How many Test

Cases are enough)

1. Requirement – Test Case

Tractability.

2. Requirement Breakdown

3. Known Trouble spots

4. Risk Based analysis

Determining the highest

risk portions of the product

(Impact of failure) can

guide where more test

coverage needs to be

emphasized

When to stop Test case

design

Entry criteria for Test case

execution:

When to start Test Case

execution

1. Latest Code base should

be available in QA env

2. Smoke Testing should be

successfully completed

3. Reviewed Test cases

should be available.

4. Test executioner should

be available

5. Test Execution tool should

be ready

6. Automation scripts should

be available for

regression.

Exit criteria for Test Case

Execution:

1. No high and critical

defects

2. Medium and low defects

should be reviewed by TL.

3. Regression Testing should

be successfully completed

When to stop test case

execution

7. Test Resource Needs

1. Environment Needs

2. Training needs

3. Tool needs

8. Testing Mile stones:

1. Test plan

2. Test Approach

3. Requirement analysis

4. Test case design

5. Test Case Review

6. Test Case execution

7. Defects

8. Defect Reports

9. Project closure

documents

9.Risks, dependencies

Unexpected event

Risk Log:

Dependencies Log:

10. Authorizations:

TL:

OSC:

BA: