After finalization of possible test for current project, Test Lead category people concentration on test plan document preparation to define work allocation in terms of What, Who, When & How to test. To prepare test plan document, test plan order follows below approach.

Test Planning - Step by Step

1] Team Formation:

In general, Test planning process starts with testing team formation. To define a testing team, test plan author depends on below factors;

1. Availability of testers
2. Test duration
3. Availability of test environment resource

2] Identify Tactical Risk:

After Testing team formation Plan author analysis possible & mitigation (ad hoc testing)

# Risk 1: Lack of knowledge of Test Engineer on that domain

# Soln 1: Extra training to Test Engineers

# Risk 2: Lack of Resource

# Risk 3: Lack of budget {less no of time}

# Soln 3: Increase Team size

# Risk 4: Lack of Test data

# Soln 4: Conduct test on past experience basis i.e., ad hoc testing or contact client for data

# Risk 5: Lack of developer process rigor

# Soln 5: Report to Test Lead for further communication between test & development PM

# Risk 6: Delay of modified build delivery

# Soln 6: Extra hours of work is needed

# Risk 7: Lack of communication in between Test Engineer - > Test team and Test team - > Development team


After completion of testing team formation & Risk analysis, Test plan author concentrate on Test Plan Document in IEEE format.

01) Test Plan ID: Unique No or Name e.g. STP-ATM

02) Introduction: About Project description

03) Test Items: Modules / Functions / Services / Features / etc.

04) Features to be tested: Responsible Modules for Test design (preparing test cases for added modules)

05) Features not to be tested: Which feature is not to be tested and Why? (Due to test cases available for the old modules, so for these modules no need to be tested / no test case)

Above (3), (4) & (5) decides which module to be tested – > What to test?

06) Approach: List of selected testing techniques to be applied on above specified

modules in reference to the TRM(Test Responsible Matrix).

07) Feature pass or fail criteria: When a feature is pass or fail description

(Environment is good) (After testing conclusion)

08) Suspension criteria: Possible abnormal situations rose during above features testing

(Environment is not good) (During testing conclusion)

09) Test Environment: Required software & Hardware to be tested on above features

10) Test Deliverables: Required testing document to be prepared (during testing, the type of documents are prepared by tester)

11) Testing Task: Necessary tasks to do before start every feature testing

Above (6) to (11) specifies -> How to test?

12) Staff & Training: Names of selected Test Engineers & training requirements to them

13) Responsibilities: Work allocation to every member in the team (dependable modules

are given to single Test Engineer)

14) Schedule: Dates & Times of testing modules

Above (4) specifies -> When to test?

15) List & Mitigation: Possible testing level risks & solution to overcome them

16) Approvals: Signatures of Test plan authors & Project Manager / Quality Analyst

4) Review Test Plan:

After completion of plan document preparation, Test plan author conducts a review of completion & correctness. In this review, Plan author follows below coverage analysis

* BRS based coverage (What to test? Review)
* Risks based coverage (When & Who to test? Review)
* TRM based coverage (How to test? Review)


After completion of Test Planning & required training to testing team, corresponding testing team members will start preparing the list of test cases for their responsible modules. There are three types of test cases design methods to cover core level testing (Usability & Functionality testing).

a) Business Logic based test case design (S/w RS)

b) Input Domain based test case design (E-R diagrams / Data Models)

c) User Interface based test case design (MS-Windows rules)