In a perfect world, engineers and programmers wake up in the morning, write code, and go to sleep knowing they will never have to deal with unexpected bugs or those 2 am production outages that we’ve all had the pleasure of attending to. That’s the perfect world. We all know, perfect coding or perfect software design doesn’t exist. But we can get pretty damn close with solid testing practices and a test plan.
A test plan is a crucial document for any software development project. It outlines the strategy, objectives, scope, and procedures for testing the application. A thorough test plan helps to ensure that the testing process is well-organised, efficient, and effective in achieving the testing objectives. Outages are never fun, they are stressful and there is a risk of suffering monetary loss for the company. In 2015, Amazon was estimated to lose approximately $203,577 per minute of downtime! That’s a million dollars every five minutes. We avoid these dangerous outages with well-tested systems.
Whether you're a software developer, tester, or project manager, understanding test plans can help you ensure that your software is thoroughly tested before release or before it’s incorporated into the day-to-day business. It’ll also help you sleep at night!
RELATED: How to Create a Test Plan
Explanation of a test plan
The key purpose of a test plan is to ensure we cover as many potential paths an application can go down to ensure everything will work as expected. Most systems have a massive amount of pathways for users to experience, think about all the unique paths a user might take when they log into an application. Each feature introduces a plethora of new user pathways. Taking all these variables into account, we need to validate and ensure each pathway works as intended.
Your test plan document should describe who, what, when, where, and how a system is to be tested. I’ll explain this further in the key components section below, first, let’s discuss the importance of a test plan.
Importance of a test plan
At the end of the day, no matter how elegant and beautiful a website may be if it doesn’t work or cannot be relied on, it is a detriment to the user and business. Companies like Amazon, AWS, Microsoft, etc., are what they are today because they not only supply great solutions in their respective industries but also can be relied on by customers and businesses alike.
Whenever a customer needs to make a purchase, maybe an emergency set of birthday supplies for a party a parent forgot to order, they trust Amazon because they know they can order something at any time of the day and they won’t have any problems. A test plan helps ensure stability.
A test plan also provides a framework to deal with bugs and kinks in the software. Software development teams will have something like a “bug bash” before new features are shipped to the customer. This is a period of intense testing, where team members can collectively gather to test the system with these new features. Times like this are when it’s important to have a test plan in place. You want to know that every member is on the same page regarding what and how new features are tested. If everyone is checking the same boxes as they go through the system then we can know that testing has been followed to a set standard. It allows for a divide-and-conquer approach.
A bug bash alone is a great system to implement, however without a plan in place, everyone may be retesting the same things or just running wild within a system without any real purpose. Comprehensive test plans give teams a defined set of things to be tested, but also provide them with the proper steps to prepare for this test. The divide and conquer approach fits in great here because each team member can take different portions of a feature and test them individually, further increasing the test coverage and ensuring a product will be delivered with the best odds for success.
Finally, the test plan provides opportunities for everyone on the team to see the completed work. Unfortunately, in reality not every member of a team may put their hands on the new features being made and sometimes people can become out of touch with the product. It's unavoidable, but a bug bash is a great way to not only test the system but give everyone an opportunity to see it before it’s live. This fresh perspective can also provide opportunities for improvement because you’re effectively running a tiny private beta amongst the people who know the product the best; further improving the product for the end user.
Key components of a test plan
- Test objectives: These are specific goals and objectives that a software testing effort aims to achieve. They define what is expected to be accomplished through the testing process, such as validating workflow, ensuring requirements are met, and in some instances ensuring the user experience is good.
- Test strategy: It describes the scope of testing, the types of tests that will be performed, the tools and techniques that will be used, and the roles and responsibilities of the testing team. The strategy helps ensure that the testing is focused and directed for maximum effectiveness.
- Test scope: Test scope refers to the boundaries of the software testing effort. It defines the specific features, functions, and requirements that will be tested, as well as any constraints or limitations that may impact the testing process. Large applications may be incredibly complex and the test scope helps ensure only the necessary parts are handled.
- Test environment: The test environment is the collection of resources that are used to execute software tests. The tests will be done in a staging environment mimicking production or done in production but disabled for the average user.
- Test cases: Test cases are detailed descriptions of the specific steps that will be taken to execute a particular test. They define the expected results and any inputs or conditions that must be met to achieve those results. Test cases typically make up the bulk of a test plan and can correspond to acceptance criteria or specific product needs.
- Test scheduling: Test scheduling is the process of defining the timeline for the testing effort. It involves determining when each test will be executed, who will execute it, and how long it is expected to take. Test scheduling also includes any dependencies or constraints that may impact the testing timeline.
- Test deliverables: Test deliverables are the artifacts that are produced during the software testing process. Sometimes these can be videos, screenshots, or certain outputs in the system to validate it was tested and how it was tested. Additionally, it may be commentary from the testers involved to describe certain things they experienced when testing the system.
Preparing a test plan
A. Identify test requirements: Testing requirements are typically based on the project goals, stakeholder needs, business objectives, and software specifications but early identification and communication about these requirements are important to ensure everyone is kept in sync during the testing effort.
B. Determine test objectives: Test objectives are identified based on the identified requirements and they define what the testing should achieve. Typically they are closely tied to the expected outcomes a project is looking to achieve.
C. Develop test strategy: The test strategy should outline the overall approach to testing, including the testing methods, tools, resources, stakeholders, and timelines. The test strategy is typically communicated ahead of time to make sure any dependent services or teams are available to handle their respective portions of the testing effort.
D. Define test scope: The test scope outlines the boundaries of the testing effort. Large systems can be incredibly complex and typically can fall under multiple team responsibilities. Defining a test scope to focus the testing efforts helps keep efforts directed and effective. Discussing backend services, frontends, environments, etc., are all important for the test scope.
E. Prepare test environment: This involves creating the test environment and making sure it closely resembles the production environment. This may also include creating user accounts or data sets in a certain state so unique workflows can be tested. This also includes communicating with other teams when testing to remove potential disruptions and deployments that can change the use cases being tested.
F. Design test cases: Test cases describe the specific steps that will be taken to execute a particular test, including the expected results and any inputs or conditions required to achieve those results. These will typically define expected starting states and ending states for how the system will function, alongside steps to get from the starting state to the ending state. In some instances, step-by-step screenshots or directed workflows are part of good test cases.
G. Plan test schedule: Test scheduling defines the timeline for the testing effort, including when each test will be executed, who will execute it, and how long it is expected to take. It also includes any dependencies or constraints that may impact the testing timeline. Accurate test scheduling alongside good preparation of test environments ensures that any potential variables that can change and affect the testing outcomes are managed, like sudden deployments from uninformed teams.
H. Outline test deliverables: Test deliverables are the artifacts that are produced during the testing process, including test plans, test cases, test results, defect reports, and any other documentation related to the testing effort. These artifacts can vary but can also include videos, photos, or software output to validate that the test cases were completed. Additionally, providing opportunities for testers involved to state inputs.
StrongQA has a good example of a sample test plan, I recommend you check that out to see the outline and how it looks.
How to write a test plan
Test plans and a thorough testing process is not easy, but it's an important step to finalising the deployment of changes to production environments and ensuring minimal obstructions for customers. A good test plan will lead to thoroughly tested software and a team feeling more confident about the work they have completed. Ultimately, every stakeholder will feel happy and accomplished when they see all of their asks are met and their customers are providing positive feedback on the features they are being given.
If you’d like to create your own test plan for software testing, you can find more information in the article How to create a test plan. Thanks for reading ✌️
