7 Ways to Prioritize More Successfully During Test Planning

Test planning is an essential part of software testing no matter the size of the project or the team. A test plan ensures product coverage, keeps testing in line with overall project goals, and keeps everything on schedule. A solid test plan is likely to include:

• Business requirements
• Features to be tested
• Features NOT to be tested
• Testing approach, criteria & deliverables
• Properties of the test environment
• Duties & tasks assigned to each tester

Creating a test plan in a single document is a straightforward way to keep testing accountable to a schedule, a budget, and client requirements.

Test planning should be strategic—never arbitrary. Luckily, there are some creative ways to break up this seemingly impossible task. Here’s how to prioritize more meaningfully during test planning, to get a next-level bird’s eye view.

Adopt a team-based approach during risk analysis

Testers naturally tend to conduct risk analysis, but often in an unstructured way. Ever run through a mental checklist of customer priorities, features prone to failure, and any changes since the last build? That’s a good way to start a test cycle.

But putting some structure around the process of risk analysis is even better. To review risks in a way that’s fully comprehensive, try bringing in people from other teams. Hold a risk analysis meeting with a business analyst, a customer support representative, and a developer. Pulling in other viewpoints in an organized way gives the maximum insight into the system to be tested.

Together, you can determine the likelihood of failure for each feature and its impact. Organize the results of the risk analysis around features most likely to break and the ones whose failure would be the most detrimental.

Ensure that test planning is prioritized around client concerns

The QA department can receive client concerns in a variety of mediums:

• Forwarded emails
• Recorded calls of the client and dedicated support
• Input from developers
• Direct communication

One of the most important things you can do during test planning is to consolidate and visualize all client concerns. Get yourself in the habit of tracking any input that comes your way (in any format). During the test planning phase, translate relevant client concerns into one master document, bulleted list, or virtual bulletin board—whatever works. Once consolidated and translated into the language of the project, it’ll be that much smoother to work into your plan.

Track the discovery process

Any QA manager designing a test plan must incorporate the existing documentation of a project with an initial discovery process of the application.

With agile projects, you may have little to no documented information, and instead learn about the project during various touch points along its lifecycle or end up exploring it nearly blind. It’s critical to track this discovery process of a new application, regardless of how much you know up-front.

Try recording your initial exploration in a way that will be easy to share with your testing team. You can create a mind map with different features and their functions, record video and/or audio, or simply take notes of your first impressions and then format them. This can be used to inform how you segment tasks, and can later help you introduce new testers to the project.

Create product mind maps

Mind maps can be used to keep track of client concerns, track the discovery process, and understand the product as a whole.

Plus they’re fun.

You probably learned how to make mind maps in grade school. Simply grab a large sheet of paper and start connecting various elements and forming relationships between features and functions. Mind maps, whether digital or analog, are a highly visual way to organize any sort of work, but they really come in hand in software testing, which can quickly become overwhelming.

Mind maps can help you outline a product so that it’s easier to assign individual testing tasks. More importantly, mind maps allow you to track coverage of an app.

Separate creative from repetitive tasks

Most apps, particularly mobile, benefit from a mixed approach to testing. Regression tests, scripted tests, and manual exploration come together to provide full coverage that ensures quality and meets business objectives.

Striking the right balance will depend on each project, but it’s always necessary to determine which functions require scripting and clear pass/fail criteria, and which should be hard cases—creative issues that are harder to find.

Dependent on skill level, you can assign exploratory and scripted cases to each tester. This allows testers a creative break from sometimes boring scripts and provides the maximum amount of viewpoints in terms of usability and reliability. In short, give testers room to really try and break things, while making sure that all the basic steps are covered.

Organize test planning around user personas

User personas deserve a whole mind map of their own. Instead of breaking the product up by features, break it up by users (and what those users are trying to accomplish).

A photo editing app, for example, could produce a variety of user stories: someone who simply needs to resize an image, someone who wants to crop, someone who needs to create and print out a birthday card, and someone making an infographic. And on and on.

Next, you take those stories and break them down into steps, layering those user-based steps on top of other approaches for complete product coverage.

User personas for the application or system offer more context for making a first attempt at sequencing what needs to be tested.

Claire Moss

Work backward: write the most complex test cases first

Quick timeline? Tight budget? Small team?

Maybe you don’t have time for scripted AND manual tests to overlap each other. Maybe you don’t have time for testing that’s organized around features AND user personas.

When you need to cover an entire product on a tight timeline, you need to work backward. Take the above photo editing example. Let’s say your user wants to crop, resize, and download an image as a different file type than what was originally uploaded.

When you start off with the most complicated use cases (and track each step), you’ll find that most of the app gets covered. You can then search for any gaps and cover those in shorter, more simple test cases.

Scripting out the longest test cases first and having them covered early on in the test schedule allows for the entire process to move that much quicker.

All of these prioritization tips can be combined during test planning to make the cycle a success. When you’re focused on the full use of the product, know client concerns and are aware of risks, then how to make the best use of your time and resources becomes that much clearer.