Test Plans: Basics to Best Practices
A test plan acts as a blueprint or instruction manual on how and what you will test for a product release or sprint. It defines the scope, schedule, approach, and resources for your test efforts.
Testing creates a logical connection between all the components of product development. The product team defines requirements, which the testing team uses to build and run test cases. Then development writes and commits code, prompting tests to fire again. Finally, the progress and results of the test are delivered to executive-level stakeholders to track and analyze for business decisions.
Test plans include the kind of information that everyone along this product journey needs to do his or her job as efficiently as possible.
What is the Purpose of a Test plan?
Ultimately, a good test plan will help you release on time without sacrificing quality. It provides a common framework that ensures no steps are missed, and everyone is on the same page.
Test Plans help us determine the effort needed to validate the quality of the application under test. The test plan serves as a blueprint to conduct software testing activities as a defined process, which is minutely monitored and controlled by the test manager.
What Should a Test Plan Include?
The specific elements of any test plan will depend on the product. But you should make sure that your test plan includes:
1. Test Strategy and Objectives
Identify the main purpose of testing (in light of the product requirements) and what a successful completion of a testing cycle looks like. The two important factors in terms of quality assurance are usually coverage and velocity. The test strategy will define which one comes first (usually based on the business objectives).
2. Schedule, Estimation, and Deliverables
This depends whether your test cycle occurs during or after the cycle, but it is important to be able to determine how long will it take to qualify the tested functionality. And no less important is to understand “what will I get” as a user by the end of the testing cycle — is there any traceability matrix report I can rely on in order to support the decision making process? Predictability is key in this area, as the business would always want to know when we should be ready to ship.
3. Resources Required to Perform Testing
Given different coverage needs, it is important to understand what will it take — for example — to complete a testing cycle within x amount of days/hours. Resources include people (testing team) and technology (testing platforms/product units, testing tools — frameworks and other orchestration/execution tools).
RESOURCE: Create a software test plan for free in Helix TCM >>
Best Practices for Test Plans
Since test plans are supposed to help keep everyone on track, you don’t want the test plan itself to stall any part of the process. Here are some tips to create great test plans.
1. Know the Definition of Done for Every Test
How do you know if you have successfully fulfilled a test scenario if you don’t know what that means? It seems obvious, but it is actually quite common for bottlenecks to occur because testers did not have a clear understanding of what success looks like.
A definition of done begins with the requirements document. Tests are built around requirements. Their entire purpose is to validate whether certain conditions happen during the flow. You really need to go through each requirement, and define exactly what is the expected result and how the test should know that a requirement is met/missed (e.g. a test has passed/failed.)
For example, a test case might read:
“The purpose of this test case is to verify the requirement of a login. A successful login shall result in the user seeing the notification “Welcome to your banking application, have a nice day” and [insert specific image].”
That description plainly states the purpose of the test and what a successful login looks like. It clearly translates a business requirement into a technical requirement for testing.
This translation is the most challenging and critical component of testing. If you can properly translate from issues and requirements management into test cases, testers can successfully fulfill all the testing scenarios. And then you can say the feature is ready to release.
Going one level down, this granularity level should be also detailed for every logical step of your test case. It should be pretty much parallel to the way the user story defines that step. For example: “As a user, I would like to log in to my banking app providing my user credentials (username & password) so that I would be able to verify my account balance”.
2. Keep Test Cases Short and Concise
A definition of done isn’t the only guideline that identifies the success of a test. If you test too many things at a time, you will not know what has actually failed. It’s important to triage quickly when testing, so you want to be granular with your tests.
This is literally aligned with the known testing state of mind of “fail fast and fix fast.”
Think of it as building blocks — a couple of blocks together can create a greater structure. But if one of those is broken or not set properly, it is relatively easy to identify (visually in this case) which one it is and fix it.
For example, if one complete step of the test is to transfer a monetary amount from one account to another, this actually involves several steps. You would create separate tests and expected results for: logging in, transferring money, and then checking the balance to determine that the right amount was transferred.
By focusing your tests one step at a time, you can quickly identify any failure that may occur. Furthermore, the test itself will be quick. A huge test lasts a long time, whereas fast feedback is key to success in this process.
3. Organize Tests by Using Tagging or Appropriate Naming Conventions
You may notice that coverage and speed are a running themes here. This remains the case when it comes to how you describe your test plans.
A well-chosen naming convention accomplishes two things. First, within a long list of tests, you can quickly find the one you want. This can save you time searching, but also help ensure you do not accidentally use the wrong one.
Second, it further defines what is to be tested. Again, this minimizes the chance of error, which will help you stay on schedule.
The key to a good naming convention is to use as many contextual aspects as possible. Include variances so you know how everything is related. Start from test plan, then include the test cases, and the name of the CI job. Bound them all together by the same contextual aspects, whether by tagging or naming them using the same convention. For example:
SmokeTest.PreProdBuildCandidate
SmokeTest.iOS
BLOG: 4 Reasons Why Software Testers Struggle and How to Fix them >>
Executing Test Plan Best Practices
A really good test plan will help speed development, but only if everyone follows the same practices. Make sure that everyone understands the defined procedures, and also why they are in use. If you are making changes, people will better adapt to change when they understand the benefits of doing so.
It is also easier to enforce a good process when you work out of a universally-accessible tool that aligns everyone along the product journey. For example, you can create test plans and test cases in Helix ALM, but it also integrates with tools you use to code and run automated tests — and then provides reporting and visibility of the entire process. This way, everyone sees progress and can make decisions without switching between interfaces.
Want to try it out free? Use any single module of Helix ALM or the full suite free for 30 days. See if it helps you improve your testing.
Create a FREE Test Plan in Helix ALM ▶️ Watch a Demo First
Related Content
- Learn about using tools to find code vulnerabilities, ensure standards compliance, and reduce time-to-market early in the development process with Perforce's Shift Left 101
