Test Plan

A-Test Plan Template:

1) Test Plan ID:

Some type of unique company generated number to identify this test plan.

2) Introduction:
Describe the purpose of the Plan, possibly identifying the level of the plan
(System Test Plan etc.). This is essentially the executive summary part of
the plan.

3) Test Items:
These are things you intend to test within the scope of this test plan.

4) References:
List all documents that support this test plan. Refer to the actual
version/release number of the document as stored in the configuration
management system.

5) Features to be Tested:
This is a listing of what is to be tested from the Users viewpoint of what the
system does. This is not a technical description of the software, but a Users
view of the functions.

6) Features not to be Tested:

This is a listing of what is NOT to be tested from both the Users viewpoint
of what the system does and a configuration management/version control
view. This is not a technical description of the software, but a Users view of
the functions.

7) Test Approach:
This is your overall test strategy for this test plan; it should be appropriate
to the level of the plan (master, acceptance, etc.) and should be in
agreement with all higher and lower levels of plans. Overall rules and
processes should be identified.

8) Entry Criteria:
It describes when to start Testing
9) Exit Criteria:
It describes when to stop testing

10) Suspension Criteria:

It describes when to stop testing temporarily.

11) Roles & Responsibilities

-Team Lead or Test Lead and Team members Roles and Responsibilities.

12) Schedule:
-Schedule for all Test activities in this Software Test Process.

13) Training:
Training on the application/system (Domain Training)
Training for any test tools to be used.

14) Test Environment / Lab:

It describes Require Hardware and software for setting-up Test
Environment or Test Lab.

15) Test Deliverables:

Lists out that what is to be delivered as part of this plan?

16) Approvals
Who can approve the process as complete and allow the project to proceed
to the next level.

17) Glossary:
Define terms and acronyms used in the document, it can be used to
understood the terms used in this plan.

B- A Sample Test Plan Document for Internet Banking Application

1) Test Plan ID: IBS_ST_TP_001

2) Introduction:

It is System Test Plan for Interment Banking System, internet web

application, provides access to Account holders and guest users from any
ware in the world. It has two interfaces one is Admin interface another is
User interface. Admin can be accesses by Bank authorized users, user
interface can be accessed by Bank account holders and guest users.

The propose of the system (Application) is to provide bank information and

services online (through Internet), Bank account holders can get Banking
services from any ware, without visiting the Bank branches.

3) Test Items:

Admin Interface:

Master Data

User Management

Reports
etc…

User Interface

Information

Personal Banking

Corporate Banking

Business

Etc…

4) References:

Requirements

Project Plan

Test Strategy

Use cases (If available)

High Level Design doc

Low Level design docs

Process guide line doc

Prototypes

5) Features to be Tested:

1. a) Admin Interface:
i) Master Data
1) Add new branch, Edit Branch /Delete Branch
2) Add new ATM
3) Add new loan type
4) Add new account type
5) Add new deposit type
….
ii) User Management
1) Create new user
2) Edit user
3) Delete user
etc…..
iii) Reports
1) Branch wise report
2) User wise report
3) Day, month, yearly reports
4) Service wise report (only loans, only new account. fixed deposits)

b) User Interface:
i) Information
1) Branch locators
2) ATM locators
3) Loans information
4) Bank history
5) Bank financial details
6) Fixed deposits information
7) Calculators
etc…
 ii) Personal Banking
1) Login
2) Balance enquiry
3) Bill payment (utilities, subscriptions)
4) Fund transfer (transfer to same bank, others banks)
5) Statement generation (mini stmt, detailed report)
etc…

iii) Corporate Banking

1) Add user, Edit user, Delete user
2) Balance enquiry
3) Money transfer
4) Payroll
5) Reports
etc..

6) Features not to be tested:

NA

7) Entry Criteria:

1. a) Test Design
Team formation, Responsibilities, Schedule,
Requirements, Test Case Template etc…

Training on Domain, on Automation tools

1. b) Test Execution:
Readiness of Test Lab
Readiness of AUT
Requirements
Test Case docs
Test Data
Defect Report Template
Etc…

8) Exit Criteria:
All possible test cases executed
Maximum defects fixed, Final Regression performed successfully

Confidence on Test process

Time Limitations

Budget Limitations

9) Suspension Criteria:

Show-Stopper bug found

Supplier issues

Vast changes in requirements

If resolving defects are more

10) Roles & Responsibilities

S.no Name Role Responsibilities Remarks
Test Planning, guidance,
1 Kareem Ulla SK Test Lead
Monitoring and Test control
Test Data Collection,
2 Venkat Rao P Sr. Tester
Generating Test Scenarios.
Test Case Documentation,
Test execution, defect
3 Swapna DK Tester
reporting and tracking for
Admin module.
Test Case Documentation,
Test execution, defect
4 Srinivas V Tester
reporting and tracking for
Personal Banking module.
Test Case Documentation,
Test execution, defect
5 Suneetha B Tester
reporting and tracking for
Corporate Banking module.
11) Schedule:
Task Days Duration Remarks
S.no
Understanding &
1) Analyzing 5 2nd July to 6th July
Requirements.
2) Review Meeting 01 9th July
Generating Test
3) 10 11th July to 22nd July
Scenarios.
4) Reviews 02 25th July to 26th July
Test Case
5) 40 29th July to 12thAugust
Documentation
6) Reviews 04 14th August to 18thAugust
20th August to 26th
7) Test Data collection 06
August
8) Reviews 01 28th August
Verifying Test
9) 01 29th August
Environment setup
10) Create Test batches 02 30th, 31st August
11) Sanity Testing 01 3rd September
Comprehensive 4th September to
12) 25
Testing 2ndOctober
13) Sanity Testing 01 3rd October
14) Selecting Test cases 02 4th and 5th October
8th October to12th
15) Regression Testing 05
October
16) Sanity Testing 01 15th October
17) Selecting Test cases 01 16th October
Regression Testing 17th October to
18) 04
Cycle 2 22ndOctober
 . . . .
. . . .
. . . .
19th November to
28) Final Regression 08
28th November
Evaluating exit
29) 01 or 02 29th, 30th of November
criteria
Collecting all
30) 02 3rd, 4th December
artifacts
Test Summary
31) 01 5th December
Report
Note: Regression Testing depends on Application and strength of
Development team.

12) Training

Training Program on Banking Domain

Test Automation Training using QTP Tool

13) Risks & Mitigations

Team members issues

Vendor issues

Time

Budget

14) Test Environment / Lab

Application Type: Web Application, Internet and Public

Server side:

Windows 2003 Server

UNIX server

Ms Exchange server

a) Web server, b) EDP, 3) Data storage

Bugzilla Tool

VSS

MS Office

QTP Tool etc….

Browser IE 7.0

————————————

Client side:

Windows XP + SP2

VSS

MS Office

QTP

Etc…
———————————————
AUT Environment

.NET (C#, VC++, ADO)

IIS -web server

COM+ -App server

SQL Server 2005 for Database server

—————————————————
15) Test Deliverables

Test Plan,

Review Reports,

RTM

Test Scenario docs

Test Case docs

Test data

Opened, Closed Defect Reports

Test Summary Report

16) Approvals
Task/s Author /Role Date & Signature
S.NO
1) Test Plan Documentation Kareem Ulla SK (Test Lead)
2) Review Hari Prasad (QA Analist)
Vinod Rao (Project
3) Approval
Manager)

17) Glossary

AUT –Application Under Test

.
.
.
PIN -Project Initiation Note
.
.
.SRS-Software Requirements Specification
 Test Procedure:
A test procedure is a formal specification of test cases to be applied to one
or more target program modules.

Detailed instructions document for the set-up, execution, and evaluation of

results for a given test case. This document contains a set of associated
instructions. This documentation may have steps specifying a sequence of
actions for the execution of a test

1. Effort Estimation
2.Project Initiation
3.System Study
4.Test plan
5.Design Test Case
6.Test Automation
7.Execute Test Cases
8.Report Defects
9.Regression Testing
10.Analysis and Summary Report.
 Confirmation / Debugging
Debugging is considered to be a complex and time-consuming process
since it attempts to remove errors at all the levels of testing. To perform
debugging, debugger (debugging tool) is used to reproduce the conditions
in which failure occurred, examine the program state, and locate the
cause.

Some guidelines that are followed while performing debugging are

discussed here.

1-Debugging is the process of solving a problem. Hence, individuals

involved in debugging should understand all the causes of an error before
starting with debugging.

2-No experimentation should be done while performing debugging. The

experimental changes instead of removing errors often increase the
problem by adding new errors in it.

3-When there is an error in one segment of a program, there is a high

possibility that some other errors also exist in the program. Hence, if an
error is found in one segment of a program, rest of the program should be
properly examined for errors.

4-It should be ensured that the new code added in a program to fix errors is
correct and is not introducing any new error in it. Thus, to verify the
correctness of a new code and to ensure that no new errors are introduced,
regression testing should be performed.

Confirmation Testing:
-Confirmation testing is also known as re-testing.

-Confirmation Testing is done to make sure that the tests cases which
failed in last execution are passing after the defects against those failures
are fixed.
-A problem is identified in a system and a defect report is created. A
software engineer maintains and analyzes this error report and finds
solutions to the following questions.

1-Does a .defect exist in the system?

2-Can the defect be reproduced?

3-What is the expected/desired behavior of the system?

4-What is the actual behavior?