Slim Down Your Test Plan Documentation

Test planning and its documentation is different at every company. The level of information written down ranges from a photo of a whiteboard drawing to the detailed steps of every test case and scenario, with screenshots. Agile development teams tend to not have a rigorous documentation system, but some companies are required to use certain templates or follow specific standards.

During my years of test planning and assessing the results, my experience has been that the stakeholders don’t really have the time and bandwidth to read through long plans carefully. This causes a decrease in testing scope and can create confusion and demotivation among the software testers, which lessens the quality of testing and results in wasted money and time.

This is why creating a useful yet short and to-the-point test plan is crucial for a well-planned testing cycle.

Evaluate What You Can Eliminate

The IEEE 829 standard defines sixteen items that can be included in a master test plan, and testing practitioner Peter Morgan came up with a handy acronym to remember them—SPACEDIRT: scope, people, approach, criteria, environment, deliverables, incidentals, risks, and tasks. Although this list is useful and thorough, some of this information is pretty constant for months, if not years, so if you’re looking to streamline your documentation, you probably don’t need to include all of these items in every test plan for every testing cycle. 

For instance, in the case of continuous development in agile teams, the entry criteria are always the same: test the functions ready to be tested while regression testing the old functions. Furthermore, the exit criteria usually are determined by the Scrum team on the fly, taking into acacount the development effort, the effect of the changes, and the time and personnel resources available.

Deliverables are also under consideration when a team is formed. They usually use the same reporting, incidentals, and documentation forms and channels throughout testing cycles. It’s part of the tribal knowledge, so there’s no point in copying and pasting this information again and again.

Risks don’t really change from sprint to sprint, and neither do their mitigation or contingency plans.

Testing tasks like test cases and scripts are too low-level to process in a high-level test plan document, so they should be linked to this test plan and reviewed separately, with a different audience, if needed.

Get your team to evaluate whether it can ditch the complete test detail rundown every time. If the answer is yes, we’ve got a new mnemonic to help you remember what’s important when defining your test plan.

The 5W2H Method

The 5W2H method helps you create an action plan for a particular problem. The name refers to the seven questions you ask when developing your approach: why, what, where, when, who, how, and how much.

Answering these questions can help you tackle any project by defining your strategy, and it should clarify communication and provide sufficient intent for a test plan, too. Let’s look at each question as it applies to a test plan.

Why?
Start with this question to specify the goal of the project and the set of requirements. This answer will be the justification and reasoning for the testing, from the goal of the sprint to the scope of the whole project.
Example: The goal of this sprint is to stabilize the system. We need fixes for five critical issues ready by the end of this sprint.

What?
What will be tested? Specify the functions to be tested, listing where regression testing is needed. Make a precise description of the testing scope, including what will not be tested, if applicable.
Example: Requirements X01 through X09 will be tested with functional testing, going over the customer path.

Where?
Where will testing be done? Specify the test environment and other relevant data, such as URLs or accesses. For dispersed teams, you also can specify a room, chat link, or city address.
Example: For testing, please use the staging environment. Here’s the access information: …

When?
When will you conduct the testing? Specify the time, dates, and deadlines. Describe when overtime is needed so testers can plan accordingly.
Example: The testing cycle begins July 25 and will last until the end of the day August 13. Having a holiday (August 1) in the middle, this gives us thirteen workdays for testing.

Who?
Who will do the testing? Specify the list of people on the testing team, along with the scope of their testing. In case of special roles like test managers, describe who’s responsible for what. Also include any special schedule, if needed. This can be a good visibility tool for those who are partially involved in testing or otherwise need to be aware of rescheduling, test environment downtime, etc.
Example: Regression testing of data integrity will be tested by Steve Palmer, having the first priority through the testing cycle.

How?
How will you test? Specify the testing methods and process. Emphasize where automation is used. Link the separate test approach documents and test scripts and scenarios. Also specify the testing tasks, by dates and priority order, if possible. Estimate or calculate the test coverage.
Example: Requirement X01 will be tested using the existing automaton script. It is scheduled to be run July 29 by Marc Stevens.

How much?
Is there any special cost as a prerequisite? For example, if there is a new testing hardware like a tablet, a terminal, or an outsourcing task, it should be mentioned here. “How much?” can also be interpreted as the frequency of the given task, so plan carefully if you need more than one round of test execution.
Example: As the login function will be responsive, we’re going to use crowdsourced testing. Karl Smith will organize this effort with a $900 budget.

If your team is looking to streamline its test plan documentation, I suggest the 5W2H method. It doesn’t take long to answer the seven questions, but they still provide valuable feedback and help you develop a sufficient plan of action. Add a fancy header if a written document is required, and you’ll have a pretty solid and extendable plan for the next few testing cycles.