Test Plan Tutorial: A Guide To Write A Software Test Plan Document From Scratch
An Ultimate Guide to Software Test Plan Document:
This tutorial will explain to you all about Software Test Plan Document and guide you with the ways on how to write/create a detailed Software Testing plan from scratch along with the differences between Test Planning and Test Execution.
Live Project QA Training Day 3 – After introducing our readers to the live application of our free online Software Testing Training, we came to know 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 lifecycle – i.e. Test Planning.
List Of ALL The Tutorials In This Series:
Test Planning Document:
Tutorial #1: How to Write a Test Plan Document (This Tutorial)
Tutorial #2: Simple Test Plan template contents
Tutorial #3: Software Test Plan example
Tutorial #4: Difference between Test Plan and Test Strategy
Tutorial #5: How to Write Test Strategy Document
Test Planning Tips:
Tutorial #6: Risk Management During Test Planning
Tutorial #7: What To Do When There Isn’t Enough Time To Test
Tutorial #8: How to Plan and Manage Testing Projects Effectively
Test Planning at Different Stages of STLC:
Tutorial #9: Regression Test Planning
Tutorial #10: UAT Test Plan
Tutorial #11: Acceptance Test Plan
Test Automation Planning:
Tutorial #12: Automation Test Plan
Tutorial #13: ERP Application Test Planning
Tutorial #14: HP ALM Test Planning
Tutorial #15: Mindmap Test Planning
Tutorial #16: JMeter Test Plan and WorkBench
Test Plan Creation – The Most Important Phase of Testing
This informative tutorial will explain to you the ways and procedures involved in writing a Test Plan document.
At the end of this tutorial, we have shared a 19-page comprehensive Test Plan document which was specifically created for the live project OrangeHRM, that we are using for this free QA training series
What Is A Test Plan?
Test Plan is a dynamic document. The success of a testing project depends upon 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.
Given below are a few pointers on a Test Plan:
#1) Test Plan is a document that acts as a point of reference and only based on that testing is carried out within the QA team.
#2) It is also a document that 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 work 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 the rest is for Test Execution.
#5) This plan is not static and is updated on an on-demand basis.
#6) The more detailed and comprehensive the plan is, the more successful will be the testing activity.
STLC Process
We are now halfway into our live project series. Hence, let us 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 our earlier tutorial, we came to know that in a practical QA project, we started with the SRS review and Test Scenario writing – which is actually the 2nd Step in the STLC process. The Test Design involves the details on what to test and how to test.
Why haven’t we started with Test Planning?
Planning indeed is the first and foremost activity that happens in any testing project.
Test Planning At SDLC Phases
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 very clear that a testing plan is not just a document that you can create all at once and use it from then on.
Components Of A Plan Document
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
Login
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-mentioned information are the most critical ones for the day-to-day working of a QA project, it is important to keep the plan document updated every now and then.
Sample Test Plan Document For A Live 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 testing plan is for both Functional as well as the UAT phases. It also explains the Test Management process using the HP ALM tool.
Download Test Plan Sample:
Doc Format => Click here to Download the Test Plan in Doc format this is the one that we created for the OragngeHRM live Project and we are using this for our Software Testing crash course as well.
PDF Format => Click here to Download the Test Plan in pdf file format.
Worksheet (.xls) files referred in the above doc/pdf versions => Download the XLS files referred in the above Test Plan
The above template is very comprehensive and a detailed one too. Hence please give it a thorough reading for the best results.
As the plan is created and explained well too, let us move on to the next phase in both SDLC and STLC.
SDLC’s Code:
While the rest of the project were spending their time on TDD creation, we QA’s have identified the Testing scope (Test Scenarios) and created the first dependable Testing plan draft. The next phase of SDLC is to check when the coding occurs.
Developers are the primary point of focus for the entire team in this phase. QA team also indulges in the most ever-important task which is nothing but “Test Case Creation”.
If the Test Scenarios were “What to test”, then 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 time. We create them, review them, execute them, maintain them, automate them- and 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.
Test Planning Vs Test Execution
Software test planning reserves a far better scope comparatively in the STLC phase. The delivery of quality software is ensured by the testing team. And what has to be done in testing is actually decided in the test planning phase.
This section will provide a complete overview and include illustrations on the importance of test planning and the execution phase. After reading this you will understand the significant importance of the planning phase when compared to the execution phase with more live examples and case studies for illustrations.
Test Planning
Given below are certain essential things to be noted while Planning:
Planning a test is the core important section in the testing cycle. The outcome of the testing phase will be determined by the quality and scope of the planning that has been done for the testing.
Planning the test usually occurs during the development phase in order to save the lead time for test execution upon mutual agreement from all the parties involved.
Some Important Facts to be noted include:
- Planning must be started in parallel to development, provided the requirements have been frozen.
- All the stakeholders like designers, developers, clients, and testers need to be involved while finalizing the plan.
- Planning cannot be worked out for an unconfirmed or any unapproved business needs.
- Similar test plans will be applied to the new requirements that the business will require.
Example #1
The development team is working on a software XYZ after getting a few requirements from the clients. The testing team has almost started their preparation for the test defining or planning phase. Test planning has to be designed to address the initial requirements quoted by the clients. This has been done by the testing team.
Neither of the other stakeholders was involved during this phase and the planning has been frozen.
The development team has now made some changes in the business flow in order to address a few issues in their work with the client’s approval. Now the software has come to the testing team for a test. With the testing plan as per the old business flow, the testing team has started their round of testing. This impacted the testing deliverables with many delays as the modified business flow was not shared with the testing team.
Observation from Example 1:
There are certain observations from the above example.
They are:
- Understanding the new business flow consumed a lot of time.
- Delays in project deliverables.
- Reworking on planning and the other tasks in the phase.
All these observations have to be converted into essential needs for an effective testing deliverable.
Major Components in the Planning Phase
Given below are the major components that are involved in the planning phase.
- Test Strategy: This is one of the most important sections that can explain the strategy that will be used while testing.
- Test Coverage: This is essentially required and it will do conformance mapping of the business needs and the test cases so that one can ensure if the entire software has been tested or not.
- Test Cycles and Durations: This can become very critical depending upon the rounds of development and their time for completing each round.
- Pass/Fail Criteria: It is very much required one in which the pass and fail criteria are defined. A few times this will also be defined by the clients.
- Business and Technical Requirements: Need to have the software and the purposes they serve will be clearly defined along with the low-level explanations.
Limitations
There are few things that can actually control the software testing phase especially the planning phase.
Following are such few areas:
- Features to be and not to be tested: This will clearly point out what has to be tested and what should not be.
- Suspension Criteria and Resumption Requirements: This is the decision-maker on the software developed and the criteria defined in order to suspend the testing or resume the testing.
- Responsibilities: A tester will have multiple responsibilities in ensuring the issues, bugs, and defects in the software under test. Additionally, the bugs have to be validated with the developers for them to fix.
- Risks and Contingencies: Risks associated during the testing should be clearly mentioned and proper contingencies during the time have to be defined very clearly.
Case Study #1
The development team from Example #1 is planning to release the software XYZ in 2 phases. Phase 1 has got many features to be tested and few not to be tested. Again the software has been released to test without keeping the testing team informed about the features that are yet to be developed.
Now the testing team starts its execution based on the testing plans they have worked out already. They come up with a large number of bugs. And after validation from the development team, most of them go invalid.
Observations from the above Case Study:
- Development team to release the software to the testing team with release notes and requirements coverage notes (release notes).
- Features to be tested and not to be tested have to be factored based on the released software before testing.
- Suspension and resumption criteria for the testing have to be defined properly.
- Risk and the contingency plans for the unavailability of the software have to be pictured perfectly.
Also read => How to Manage Risks During Test Planning Phase
Test Execution Plan
The execution of test cases is one of the steps in the STLC phase. This will have to be performed in accordance with the plans that were worked out earlier. Hence, planning always keeps dominating the whole of the testing phase. Below is an example where the testing team gets impacted by the changes in the testing plans.
Example #2
Testing the software A was started based on plan 1 worked out by the team. Later, owing to the business needs and the changes the testing plan had to undergo some changes. This, in turn, has forced the test cases or the execution to be changed.
Observations:
- The testing plan will determine the test case execution.
- The execution part varies as per the plan.
- As long as the plan and the requirements are valid the test cases are valid too.
Ways to Overcome Problems while Execution
Testers will more often come across various scenarios while they perform the test execution. This is when the testers will have to understand and know the ways to resolve the problem or at least find a workaround for the issue.
Example #3
During the test case execution of software B, the testing team comes across multiple issues. Few of them are show stoppers. They require developers in helping them to overcome the issue. This has happened several times and the outcome of it is a delay in testing the deliverables.
Observations:
- There is a dependency for overcoming environmental problems and issues.
- A Proper understanding of the environment is required for testers.
- Frequently occurring and known issues have to be documented for overcoming them in the future.
Version Controlling and Management
Version Controlling and management of testing plans and the test cases are really important in order to showcase the timely deliverables. This is being more significant and is often done with the help of a version control tool.
A version control tool not only helps them to control the testing plans but also assists in defects management. When there are testing projects with multiple cycles and releases, these tools can really help a lot in bringing down the metrics for supporting the testing deliverables.
Also, read => Risk Management at Test Execution Phase
Difference Between Test Planning & Test Execution
The following are a few important areas that will point out how planning will differ from the Test Execution phase.
Comparison areaTest PlanningTest Execution
Person responsibleThe test manager will be preparing the Test plan and will be sharing to all the stake holders for their review.This will be normally done by tester keeping in mind that the test cases prepared has been approved and signed off.
Main focusThe Test plan focus areas are how the testing should be carried out, what should be considered and what not to, environment that can be used, Test schedules etc.The Test execution focuses mainly on the execution of the test cases provided to be tested on the software.
Recurring or iterative modeThis is a single time activity. Having said that it may or may not require modifications for the future releases of the software.There are 3 parts in this area when we talk about iteration.
1. Functional testing.
2. Regression testing.
3. Re-testing.
InputsThe inputs for creation of a test plan is really required and to be provided by business analysts, Architect, clients etc.,The test case document is the major input.
Period when it can be startedIt has to be started along with the development cycle for effective outcome and to save time. But there are few models like water fall model where in the testing phase will start only after the development phase has been completed.Execution has to be started strictly after the development of the software has been done.
Closure periodThe test plan will have no such closure period. Generally a sign off from all interested parties for the software will be provided.Execution for a specific release or cycle will be considered to be closed when all of the test cases have been executed against the software.
Deliverable positioningTest plan will be considered as a major deliverable for the testing activity. This will be done as the first step in testing process.This will be coming as a last bench member in the testing phase. Post execution the defects/bugs status along with the test case execution status will be shared as one of the testing deliverables
Tools usageThere will not be many tools used as the planning activity will be more of discussion and documentation. To keep track of any changes to the plan, the test managers will normally use any version control tool like VSS or something else.It will depend on the mode of execution. In case of manual no tool will be used for execution. But for logging the defects and managing, some tools will be used.
In case of automation testing, the execution will be done with the help of tools like QTP, SELENIUM etc.
Impacts on the deliverablesThis will impact all of the testing phases in a larger mannerThis will impact the subsequent cycle or release to be tested.
The above illustrations might have explained in better shape over the importance of test planning activities than that of test execution. By some means, the execution phase is a kind of subset of the testing plan.
Based on the test strategy, approach and the other things the testing plan has a higher probability of getting modified to give room to the changes. It is a definite thing that Test execution depends on the test cases. Test cases are based upon the plans. Hence changes in plans will ensure changes in the test cases.
But conversely, changes in test cases need not mandatorily look for changes. This is one of the main reasons for which planning keeps up compared to the test execution phase.
Our upcoming tutorial will explain to you more about how to create test cases? What are they? And how we can make them work for us along with the various other aspects related to the test cases.
NEXT Tutorial => QA Training Day-4: Writing Test Cases from SRS Document
Are you an expert in writing a Test Plan Document? Then this is the right place to share your valuable tips for improvement for the upcoming testers. Feel free to express your thoughts with us in the comments section below !!
