Test Planning: A Process in which we create test plan

Test Plan : It is document which describes Strategy/Approach(How Testing should happen)

    It is blue print of Testing. By this EveryOne will get guidance about how to do     Testing.

When you should start Test planning:


1.Requirments(SRS/BRS) are Baseline

2.Development Plan is ready & reviewed(Baseline)

Advantantage of Making Test plan:


1.To have effecting Testing(Testing with good outcome)

2.To have proper utilization of resources

3.To avoid Random Testing

IEEE 829 Format of Test Plan


1.Test Plan ID

It is unique ID given to Test Plan by which will be able differentiate between multiple test plan



MTP: Master Test Plan is for Whole Project

STP: System Test Plan is for Particular Type of Testing or Level Testing

For Performance testing Seperate Test plan is needed which will contain

>Seperate Environment

>Seperate Specilized Performance Tester

>Seperate Entry & Exit Criteria


While giving introduction three things should be included 1.About project 2.Content of Test Plan


This project is for Vivekanand Colleage of Engineering. And here there will be three types of User

(1.Admin 2.Staff 3.Student)

This plan contains types of Testing, defination of done & defination of ready, scope of testing & risk involve in our Project

This test plan can be referred by Testing team, BA, Project Manager, Developer.



2.Development Plan

3.IEEE 829 Test plan format

4.Similar Project (optional)

5.Previous Version of Same Project (optional)

6.Design Documents (if available)

4.Test items: List Out Modules that you are interested in Testing




5.Feature to be Tested:(Function to be Tested) (Within Scope)


-Add Staff

-Edit Staff

-Delete Staff

-Add Book

-Delete Book

-Edit Book

-Add Student

-Edit Student

-Delete Student


-Add Book

-Delete Book

-Edit Book

-Add Student

-Edit Student

-Delete Student

-Collect Fine

-Approve Requested Book


-Request Book

-Suggest Book

6.Feature not to be tested(Out of the Scope)

1.Pay fine Online (This will be available in next version)

7.Approach:(How testing going to be happen)

1.Level of Testing:

Unit Testing /Integration Testing/ System Testing/ AT

2.Types of Testing:

Smoke Testing/Performance Testing/ Compatibility testing/ Usability Testing etc.

3.Test Execution

1.Manual Testing

2.Automatio  testing

4.Test Environment Approach:

1.Local Environment

8.Entry & Exit Criteria

Entry Criteria(Defination of Ready):

-Build/SoftWare should be ready

-Test Environment should be ready

-Test Cases, Test Suite Should be ready

Exit Criteria(Defination of Done):(When to Stop testing):


-Application should be 90% good in Qaulity

9.Suspend & Resume Criteria:

1.Show Stopper Defect

>OTP not generated or Wrong OTP generated

-Test Environment not ready on time

-Build Received Late

10.Test Deliverables:

-Execution log

-Defect Report

-Test Case

-Test Suite


-Test Scripts

11.Test Environment/Test Bed/Test Lab:

-Hardware & Software needs for Testing






Software: (Along with Version)






12.Schedule: (Deadlines For Every Activity)

Activity Name No. of Days required Date Range

1.Test analysis                 3 6th Sep to 8th Sep

2.Test Design(Writing Test Cases) 7

3.Test Implementation

-Writing Test Scripts                 3

-Test Enviroment Set Up 3

4.Execution of Test Cases         10

13.Staffing & Training 

-Hiring new Employee

-And Provide Training to Emplyees

-Training can be on Tool

-Domain Training

14.Roles & responsibilities(Who is incharge)

Activity Name Responsible Person's Name Designation

1.Test analysis John Sr. Tester

2.Test Design(Writing Test Cases) John Sr. Tester

3.Test Implementation

-Writing Test Scripts Smith Automation Engineer     

-Test Enviroment Set Up Smith, Santosh Automation Engineer & 

System Engineer

4.Execution of Test Cases Ram & Shyam Jr. Tester

5.Defect Reporting Ram & Shyam Jr. Tester

15.Risk & Contingencies : Project Risk / Process Risk

Technical Issues:

-SRS/BRS is having not clear requirements which will create more communication cycle with BA

-Build or Test Environment not ready on time.

Supplier Issue:

-POS Machine not delivered on time

Political/Personal Issue:

-Health issue

-Confilts between team

16.Software Risk Issue:(Product Risk/ Quality Risk)

Quality : Degree to which Application meets Customer Expectation

1.Delivery of Incomplete Product

2.Delivery of Faulty Product

3.Software Hard to use or Slow to respond

4.Govt. Policy get Change

As soon as Govt. policy get Change you should implement in Product


Name: Designation SignWithDate


Test Design Tech


Test Design : Writing Test Cases

Technique : An Efficient/Proven Way

Since Complete/Exhaustive Testing is not possible hence we need to follow some technique(proven way) so that we get confidance about Quality of Application

-With the help technique number of Test Cases decreased without affecting coverage/Quality

Test Design Tech:

1.Specification Based Tech:

-Equivalance Class Partitioning

-Boundary Value Analysis

-Use Case  

2.Experience Based Tech

-Error Guessing

-Exploratory Testing 

-Checklist Based

3.Structure Based Tech: (White Box Testing)

-Statement Coverage

-Decision Coverage:



DL Checking App:


18 60

1.Group the i/p's or o/p's according to their behavior so that they are giving same output

0 17|18 60 |     61

invalid valid invalid

2.Select One value from Each partition

15, 25, 65

3.If testing with Selected value is passed then testing with all other values in same partition will be considered as Passed. 

if(age>18 && age<60)



Do not allow

if(age>=17 && age<=61)



Do not allow



It ignores Boundary Values where greater Chances of error/defect is there.

BVA(Boundary Value Analysis):


1.Group the i/p's or o/p's according to their behavior so that they are giving same output

0 17|18 60|61

invalid valid invalid

2.Take a Valid Partition & Do +1(value just above) & -1(value just below) to Edges/Boundary  of Valid Partition

18 60

   17        19    59        61


3 point BVA: 17, 18, 19, 59, 60, 61

2 point BVA:    17, 18, 60, 61

What is Use Case:

-It is Document that exercise the whole system on a transaction by transaction basis from start to finish

-Use cases describe the process flows through a system based on its most likely use

-They often use the language and terms of the business rather than technical terms

-Written only for Functional requirements

Advantage of Use Case:

-Since It is written in language of user,They serve as the foundation for developing test cases mostly at the system and acceptance testing levels

-Use cases particularly good for finding defects in the real-world use of the system (i.e. the defects that the users are most likely to come across when first using the system)

-Use case consists mainly of narrative text, it is easily understandable by all stakeholders, including customers, users and executives, not just developers and testers.


-Use cases are requirements but are not all of the requirements.

-Use Cases are Not Good for defining User interfaces, Data formats and Non-functional requirements

-Use cases are diagrammatically representations of flow of system.

Attributes of Use Case Documents:


1.Use Case ID: Any Company level Use Case ID so that we can differentiate between use Case

2.Goal : What you want from System

3.Pre-Condition :

Set condition that should be true before starting use case execution i.e Stable Internet & Laptop/System with Mic for Online System

4.Path/Flows: Total Ways of doing same thing

1.NOrmal/Basic : At least this should present System

2.Alternate Path: May or May not Present

3.Error/Exception Path: Path which occure whith help of Error


Entity Which are situated outside System & They intract with System

Primary Actor : Actor who Starts Transation

Supporting Actor:Actor Who helps primary Actor to achieve its goal


Condition that should be true after Successful execution of Use Case


1.USe Case ID: UC_Withdraw001

2.Goal: To withdrow money from ATM Machine


1.Valid ATM card with Valid PIN

2.Balance in Account & ATM Machine

3.ATM Machine should be in working Condition


1.Primay Actor: USer

2.Supporting Actor: ATM Card

5.Path/Flow : Basic/NOrmal Path


1.User: Swipe debit Card

  System:'Select Language' Message should display

2.User: Select required Language 

  System: Various Menu's should display

3.User: Select 'Withdrow' option

  System: 'Enter Amount' message should display

4.USer:Enter Amount & Continue

  System: 'Enter PIN' message should display

5.U:Enter PIN & Continue

  S:'Select Account Type' message should display

6.User: Select Account Type as Saving or Current

  S:'Do you want reciept' message should display 

7.U: Select 'Yes' or 'No' for reciept

  S:1.Cash should be dispensed after processing

    2.Reciept if Yes for reciept was Selected


1.Cash equals to entered amount should be dispensed

2.Reciept(if yes for reciept was selected)

Experience Based:

>Testing is done based on  Experience of Tester

>Effectiveness varies depending on Experience of Tester

More Experience Tester will find more number of Defect & Less experience person will find less number of Defect.

Error Guessing:

-Guessing Error Based on My Previous Experience.

-Random Testing Based on My Experience(Systematic Testing will not be done).

-There is no planned Test Cases in Advance

-It is not replacement of Systematic Testing /Actual Testing

-It should be done in addition to systematic Testing

Exploratory Testing:


-As name suggest tester need to explore application & understand application since there no srs/brs.

-It is mostly followed in Agile where more focus toword working software is there rather than Documentation.

-When there is time crunch & no Documentation available

-Activities are timeBoxed of 120 min

30-min for Understanding

30 min for Preparing Test Charter contains Objective & Steps for Testing

30 min for Execution

30 Logging/Defect Reporting

-It is CunCurrent Test Designing, Test Executing & logging Activity

-It can be done in addition or in replacement of Systematic Testing

3.Checklist Based Testing:

-Here List Checks are defined in Advance to increase number of Defect

-Checklist is made by Tester or group of Tester or Manager

-It is also used in addition of Systematic Testing not in replacement

Defect Management:


A process which need to be followed as soon as defect is found.

Process like 1.Structure/template of My defect report

     2.Defect Categorization/type

     3.Defect Flow i.e Defect will forworded to directly to dev or to manager first.

     4.Severity or Priority levels 

Severity Priority

-------- --------

1.It deals with impact of defect 1.It deals with impact defect from

from functionality p.o.v Business/client/developer/BA

2.It is to see impact of Function 2.It is for deciding Which Should get fixed first

3.Levels 3.Levels

High High -- Immediate fixing required


Defects in Basic/Critical Feature,

Show Stopper/Blocker Defect

Application is getting freez,

Automatic Termination of Appln.

Medium Medium -- Before release 

------ ------

Defect in less important Feature

/Function, Performance Defects

Low Low   -- Can be fixed in next version

--- ---

Defects in Non-Functional requirement

i.e. Color, Font, Size, allingment

H.S & H.P:


1.Outgoing Call feature is not working

2.ATM Machine is not able to dispense Cash

H.S & M.P

1.Login is working in Cleartrip but User is able to do booking of Flight as a guest

H.S & L.P


1.Sometime there is Disconnection in Outgoing Call(5/100 times).

2.Self of Bike is Working & Kick Start is not working

L.S & H.P


1.There is mistake in Contact US(Email ID or Mobile Number) of any training organization.

2.Swap in name of H.O.D & Pricipal

3.On Welcome Page Mistake in Heading (Mistake on Frequently visited Page)

L.S & L.P:


1.Spelling & Grammatical Mistake on Page where less user visit is there

2.Mr or Mrs not written as title before name of Customer


Defect Life Cycle:


Defect Flow:

1.Tester > TTL > DTL >Dev >Tester  :: MNC like Structure

2.Tester > TL > Dev > Tester : Mid Scale Company

3.Tester > Dev > Tester

Tester A - Doing Systematic Testing 5 pm (Duplicate Defect)

Tester B - Doing Experience Based Testing 4 pm 

Deferred Defects are low priority Defect:


Defect Reporting Template:


1.Defect ID: Some unique ID


3.Module Name/Sub Module Name:

4.Type: Functional/ Non-Function Defects

5.Status: New/Open/Assign/fixed/close

6.Phase : Requirement/ Design/ Coding/Testing

7.Summary : 1 line information  about Defect


Steps for reproducing Defect

Expected Result:

Actual Result:



11.Reported By:

12.Reported To:

Defect Reporting Tools:


Mantis, Bugzilla, RedMine, QC(ALM)-HP, JIRA

Test Scenario  : What you want to Test

Test Case : How you will test the Selected item/Scenario

Test Scenario will have Multiple Test Cases.

Test Scenario Test Cases

Browse >1. With Valid Size & valid Format

2.WIth Valid Size & Invalid Format

3.With invalid Size & Valid Format

Upload 1.With Valid File Selection

2.Without File Selection