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 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 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 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 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.
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 remainder of the venture were investing their energy in TDD creation, we QA’s have recognized the Testing degree (Test Situations) and made the principal reliable Testing plan draft. The following period of SDLC is to check while the coding happens.
Engineers are the essential mark of concentration for the whole group in this stage. QA group likewise enjoys the most incredibly ever-significant assignment which is only “Experiment Creation”.
On the off chance that the Test Situations were “What to test”, the experiments manage “How to test”. Experiment creation is an overwhelming piece of the Test planning period of the STLC. The contribution for the experiment creation action is the Test Situations and the SRS report.
For Analyzers like us, Experiments are the genuine article – it is the stuff where we invest the majority of our energy. We make them, survey them, execute them, keep up with them, mechanize them-and indeed, you understand everything. Regardless of how experienced we are and which job we play in an undertaking – we would in any case work with the experiments.
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 improvement bunch is managing an item XYZ directly following getting two or three necessities from the clients. The testing bunch has almost started their preparation for the test portraying or orchestrating stage. Test organizing should be expected to address the basic essentials refered to by the clients. This has been done by the testing bunch.
Neither of various accomplices was involved during this stage and the orchestrating has been frozen.
The improvement bunch has now carried out specific enhancements in the business stream to determine two or three issues in their work with the client’s support. As of now the item has come to the testing bunch for a test. With the testing plan as per the old business stream, the testing bunch has started their round of testing. This impacted the testing assumptions with numerous deferrals as the changed business stream was not conferred to the testing bunch.
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 experiments is one of the means in the STLC stage. This should be acted as per the plans that were worked out before. Thus, arranging generally continues overwhelming the entire of the testing stage. The following is a model where the testing group gets affected by the progressions 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 area | Test Planning | Test Execution |
|---|---|---|
| Person responsible | The 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 focus | The 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 mode | This 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. |
| Inputs | The 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 started | It 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 period | The 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 positioning | Test 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 usage | There 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 deliverables | This will impact all of the testing phases in a larger manner | This will impact the subsequent cycle or release to be tested. |
The above delineations could have made sense of in better shape over the significance of test arranging exercises than that of test execution. By certain means, the execution stage is a sort of subset of the testing plan.
In light of the test system, approach and different things the testing plan has a higher likelihood of getting altered to give space to the changes. Something distinct Test execution relies upon the experiments. Experiments depend on the plans. Subsequently changes in plans will guarantee changes in the experiments.
Be that as it may, alternately, changes in experiments need not obligatorily search for changes. This is one of the fundamental explanations behind which arranging keeps up contrasted with the test execution stage.
Our forthcoming instructional exercise will make sense of for you more about how to make test cases? What are they? What’s more, how we can make them work for us alongside the different viewpoints connected with the experiments.
YOU MAY BE INTERESTED IN
The Art of Software Testing: Beyond the Basics
Automation testing course in Pune