How to Write a Test Plan Document from Scratch (Download a Real Plan) – Live Project QA Training Day 3

After introducing our readers to the live application for our free online software testing training, we came to know about how to review SRS and write test scenarios.

And now it’s the right time to dive deeper into the most important part of the software testing live cycle – i.e. Test Planning.

Most Important Phase of Testing – Creating a Test Plan:

In today’s article, we are going to see how to write a test plan document. 

At the end of this tutorial, we have shared a 19 pages comprehensive test plan document specifically created for the live project OrangeHRM, which we are using for this free QA training series.

We are now halfway into our live project series. Let us take a step back from the application and take a look at the Software Testing Lifecycle (STLC) process.

STLC can be roughly divided into 3 parts:

  1. Test planning
  2. Test Design
  3. Test Execution

In the previous article we came to know that in a practical QA project, we started with the SRS review and Test scenario writing – which is actually the step 2 in the STLC process – the test design, which involves details on what to test and how to test. Why haven’t we started with the Test planning?

Test planning indeed is the first and foremost activity that happens in any testing project.

What You Will Learn:

How Test Planning Takes Place at Each Phase of the SDLC

SDLC PhaseTest planning activity
InitiateIdeally QA team should get involved while the scope of the project is gathered from the customer/client in the form of business requirements. But in the real world, that is not the case. From a practical point of view, the involvement of the QA team is NIL. At the end of this phase, BRD is finalized and a basic Project Plan is created.
DefineSRS is created from the BRD. Test plan's initial draft is created. At this point, since the QA team is not done with the SRS review, the scope of testing is not clear. So the TP at this phase will only contain information on when testing is going to happen, project information and the team information (if we have it).
DesignThe SRS review is carried out and the scope of testing is identified. We have much more information on what to test and a good estimate of how many test cases we might get etc. A second version of the Test plan is created incorporating all this information.

From the above table, it is clear that the test plan is not a document that you can create all at once and use it from then on.

Test Plan is a dynamic document. The success of a testing project depends on a well-written test plan document that is current at all times. Test Plan is more or less like a blueprint of how the testing activity is going to take place in a project.

Clear Information on some Aspects of Test Plan Template

Items in a Test Plan TemplateWhat do they contain
Scope =>Test scenarios/Test objectives that will be validated.
Out of scope =>Enhanced clarity on what we are not going to cover
Assumptions =>All the conditions that need to hold true for us to be able to proceed successfully
Schedules =>Test scenario prep
Test documentation- test cases/test data/setting up environment
Test execution
Test cycle- how many cycle
Start and end date for cycles
Roles and Responsibilities => Team members are listed
Who is to do what
module owners are listed and their contact info
Deliverables => What documents(test artifacts) are going to produce at what time frames
What can be expected from each document
Environment => What kind of environment requirements exist
Who is going to be in charge
What to do in case of problems
Tools => For example: JIRA for bug tracking
How to use JIRA
Defect Management => Who are we going to report the defects to
How are we going to report
What is expected- do we provide screenshot?
Risks and Risk Management => Risks are listed
Risks are analyzed- likelihood and impact is documented
Risk mitigation plans are drawn
Exit criteria => When to stop testing

As all the above information are the most critical ones for the day-to-day working of a QA project, it is important to keep the Test Plan document updated at all times.

Few Important Pointers Regarding a Test Plan

  1. Test Plan is a document that acts as a point of reference based on which testing is carried out within the QA team.
  2. It is also a document which we share with the Business Analysts, Project Managers, Dev team and the other teams. This helps to enhance the level of transparency of the QA team’s working to the external teams.
  3. It is documented by the QA manager/QA lead based on the inputs from the QA team members.
  4. Test Planning is typically allocated with 1/3rd of the time that takes for the entire QA engagement.  The other 1/3rd is for Test Designing and rest is for Test Execution.
  5. The test plan is not static and is updated on an on-demand basis.
  6. The more detailed and comprehensive the Test plan is, the more successful will be the testing activity.

Sample Test Plan Document for OrangeHRM Project

A sample Test plan template document is created for our “ORANGEHRM VERSION 3.0 – MY INFO MODULE” Project and attached below. Please take a look at it. Additional comments have been added to the document in Red to explain the sections. This Test plan is for the Functional as well as the UAT phases. It also explains the Test Management process using the HP ALM tool.

Download Test Plan Sample:

Test Plan Doc Format => Click here to Download a test plan in Doc format which we created for the OragngeHRM live Project and we are using this for our software testing crash course.

Test Plan PDF Format => Click here to Download test plan in pdf file format.

Worksheet (xls) files referred in the above doc/pdf test plan versions => Click here to download the XLS files referred in the above test plan document.

The above Test plan template is a very comprehensive and detailed one. Please give it a thorough reading for best results.

Now, the Test plan is created and explained well. We will move on to the next phase in both SDLC and STLC.

SDLC’s Code:  While the rest of the project was spending their time on the TDD creation, we QA’s have identified the Testing scope (Test scenarios) and created the first dependable Test plan draft. The next phase of the SDLC is to check when coding occurs. Developers are the primary point of focus for the entire team in this phase. QA team also indulges in the most important task ever which is the “Test Case Creation”

If the Test scenarios were “What to test”, the test cases deal with “How to test”. Test case creation is a predominant part of the Test designing phase of the STLC. The input for the test case creation activity is the Test scenarios and the SRS document.

For Testers like us, Test cases are the real deal – it is the stuff in which we spend most of our times around. We create them, review them, execute them, maintain them, automate them- well, you get the picture. No matter how experienced we are and what role we play in a project – we would still work with the test cases.

In our next article, we will talk about how to create test cases? What are they? How we can make them work for us and the other aspects related to test cases.

QA Training Day 4: Writing Test Cases from SRS Document

=> See Also: One more Sample Test Plan Template and Test Plan Document

Please do keep us posted on how this series was helpful to you. 

Also, let us know your comments/suggestion about this article. For best results, work with us. :)