Now it’s 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 halfway into our live project series. Let us now take a step back from the application and take a look at the Software Testing Life cycle (STLC) process.
STLC can be roughly divided into 3 parts:
- Test planning
- Test Design
- Test Execution
In the previous article we have seen 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 a testing project.
What You Will Learn:
How test planning takes place at each phase of the SDLC:
|SDLC Phase||Test planning activity|
|Initiate||Ideally 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.|
|Define||SRS 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).|
|Design||The 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 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 blue print of how the testing activity is going to take place in a project.
It has clear information on the following aspects:
|Items in a Test Plan Template||What 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 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|
Since, all the above information is the most critical for the day-to-day working of a QA project, it is important to keep the Test Plan document updated at all times.
Here are a few important pointers regarding a test plan:
- Test Plan is a document that is the point of reference based on which testing is carried out within the QA team.
- It is also a document we share with the Business Analysts, Project Managers, Dev team and the other teams. This is to enhance the level of transparency into the QA team’s working to the external teams.
- It is documented by the QA manager/QA lead based on the inputs from the QA team members.
- Test Planning is typically allocated 1/3rd of the time it takes for the entire QA engagement. The other 1/3rd is for Test Designing and rest is for Test Execution.
- Test plan is not static and is updated on an on demand basis.
- The more detailed and comprehensive the Test plan, the more successful 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 we created for the OragngeHRM live Project we are using for this software testing crash course.
Test Plan PDF Format => Click here to Download test plan in pdf file format.
Worksheet (xls) files referred in above doc/pdf test plan versions => Click here to download the XLS files referred in the test plan document above.
The above Test plan template is very comprehensive and detailed. Please give it a thorough reading for best results.
Now that Test plan is created and explained. 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 in the SDLC is when coding occurs. Developers are the primary point of focus for the entire team in this phase. QA team too indulges in the most important task ever- the test case creation.
If Test scenarios were “What to test”, the test cases deal with “How to test”. Test case creation is 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 us testers, test cases are the real deal – the stuff that 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 test cases.
In the next article we will talk about how to create test cases? What they are? 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
Like always, keep your questions and comments coming. Please do keep us posted on how this series is helpful to you. For best results, work with us. :)