TestStorming™: Build a Collaborative Approach to Software Test Design in 11 Easy Steps


There are many ways to approach test design. These approaches range from checklists to very precise algorithms in which test conditions are combined to achieve the most efficiency in testing.

There are situations, such as in testing mobile applications, complex systems and cyber security, where tests need to be creative, cover a lot of functionality, and go beyond what may be described in a requirements document, use case or user story.

Over the last thirty years or more, a variety of test design techniques have been described in books and training courses. These techniques include boundary-value analysis, decision tables, requirements-based testing and so on. Each of these approaches has upsides and downsides which require the test analyst to fully understand the limitations and requirements of the techniques used in a particular situation.

In some cases, test design techniques can be combined to achieve a higher level of test coverage, as well as gaining different angles or perspectives on the software to be tested.

One thing I have learned in my many years experience as a test designer is that test design is a very nuanced activity. Textbook techniques are fine and needed, but a small change in how the technique is applied can have a huge impact in the effectiveness of the tests. This is one reason why training in how to apply test design techniques is so important. However, training is just the starting point for good test design.

Another thing I have observed is that many times, test design is performed by one person, working from documents or other items. This means the test designer is often working in isolation.

When test design is conducted in isolation, it is easy to miss important perspectives and conditions that should be tested. A collaborative approach to test design has many benefits:

  • Shared problem solving ability
  • Increased knowledge of the application to be tested
  • Increased knowledge and experience in test design
  • Higher levels of ownership in the test design activity
  • Greater creativity in ways to create tests
  • More objectivity in prioritizing tests
  • Better communication about the project, the tests and the problems to be solved

In this article, I describe a technique I have found simple and effective in designing great tests quickly. This technique combines the world of test design with that of brainstorming, so I call this technique “TestStorming™”.

The process

TestStorming™ doesn’t have to be complicated or regimented; however, there are some key steps that help in getting off to a good start.

Step 1–Decide on How to Capture Input

This process is so easy it can be performed just using a whiteboard. However, there are some great tools, such as mind mapping (see article in this issue) tools that can add organization and the ability to distribute the information gathered in the session.

One such tool is FreeMind, an open source mind mapping tool that works well in both Mac and Windows environments.

Another free tool is XMind.

Step 2–Define the Scope of the Session

This includes both the time to be spent in the session and the number of features to be addressed.

Step 3–Define the Focus of the Session

Having a particular focus prevents the team from digressing into areas that may have limited value or importance in the test. For example, the focus of a TestStorming™ session might be the security aspects of a mobile device. In fact, the focus could be to design tests for the secure ordering process using a mobile device.

Step 4–Assign a Leader

Without a leader, the session can drift into non-productive discussions. Also, the leader may need to “prime the pump” of ideas by coming up with some initial suggestions. Sometimes, a session may stall. This requires a leader to inject some remarks or ideas to get more ideas.

The leader should be someone with knowledge of both the subject matter and testing. The leader should also know how to facilitate dynamic group discussions, mediate disputes and keep a session on track.


Step 5–Invite the Participants

Like many other activities, such as reviews and retrospectives, the success of a TestStorming™ session depends on the quality of the people in the room. You want people who are:

  • Creative thinkers
  • Critical thinkers
  • Knowledgeable about the context of how the application will be used
  • Knowledgeable about organizational goals for the application
  • Understanding of different types of users
  • Knowledgeable about test design (you want people who can think of strong tests)
  • Courteous to others in the session
  • Able to contribute ideas (otherwise, they are not really needed in the session)

Another way to identify participants is by role, such as:

  • Testers
  • Developers
  • Users

Step 6–Conduct the Session

In the session, several things are discussed at the outset, including:

  • The basis for test design, such as requirements, use cases, user stories, user experience, and the application itself
  • Known risks
  • Known issues
  • Past defect trends
  • The nature of the application and specific features to be tested
  • The context of how the application is used
  • The objective of the session

Once the background is understood, participants contribute their ideas for test design. This can be done in a variety of ways:

Answering context-free questions, such as:

  •  What are the most important things to be tested?
  •  What are the least important things to be tested?
  •  Where is the risk in the features to be tested?
  •  Which unusual events could occur?
  •  Which events would be most commonly performed by the average user?
  • Each person writing their “top 5” tests on index cards, from which the leader will use as input for the list of conditions to test.
  • Going around the room in a round-robin format, making suggestions about conditions to test. This allows people to build on other people’s ideas.

One of the most basic rules of brainstorming is to not restrict the ideas that are suggested. This rule is also adhered to in TestStorming™. The goal is to get as many ideas as possible on the table, board, or tool. Then, they can be refined.

Step 7 – Filter, Refine and Combine Tests

This is where the magic happens. After the team has contributed their ideas and it is apparent that the flow of input is slowing down, the leader asks the team to take a step back and look at the ideas put forth.

From the test ideas suggested, the team organizes them into categories such as:

  • Functions
  • Risks
  • User personas

During the categorization process, some tests may be eliminated, others may be combined and enhanced.

One of my favorite test design methods is what I call “toggling” conditions. For example, if someone suggests testing a new customer placing an order, create a test condition for an existing customer placing an order. Toggling allows for ideas to grow exponentially by expanding on existing test conditions.

Step 8 – Conclude the Session

At the end of the session, the leader should recap the tests suggested. For the sake of time, a summary may be best instead of reading each and every condition. If a whiteboard or flipchart is used to capture ideas, take pictures of it to e-mail to the team and others. If a tool is used, then the chart can be saved and distributed in either an editable format or an image format.

Step 9 – Refine the Tests

The purpose of the TestStorming™ session is to gather ideas for testing and to get those ideas to the point of use as strong, effective tests.

The next steps occur after the session when test analysts take the great ideas and use them for robust test design.

In some cases, the output from a TestStorming™ session might be a good set of test conditions. In other cases, the output may be good ideas of things to test: much like you would have in a checklist or defect taxonomy.

Regardless of the detail obtained from the session, the ideas and/or conditions will then need to be formed into executable test cases with expected results. In some situations, you may not know enough about the application to define expected results. In that case, you will need to treat the TestStorming™ output as a place to start exploring the application.

Step 10 – Perform the Tests

Since the main objective is to collaborate on tests, the way we know whether they are effective tests is to actually perform them. The main determinant is not whether the tests pass or fail, but rather, do they exercise the application in a way that provides coverage, measures risk, and goes beyond simple functional tests?

Step 11 – Update the Tests as Needed

After performing the tests, you will have a feel for whether or not to include the tests in future cycles. Perhaps you may decide to build upon certain tests. You may also see where some of the tests need to be modified to be more effective in finding failures.


There is power in collaboration, and test design is an activity that benefits greatly from group interaction. TestStorming™ is where test design meets brainstorming to define creative and effective tests.

To be successful, you need a good leader, good participants and a way to capture the input from multiple people.

Thankfully, there are some great free tools available. The rest is up to you to put your team’s creativity to work!
Randy’s original blog can be found, here, on his company’s website.

Randy Rice

Randall (Randy) W. Rice is a thought-leading author, speaker and consultant in the field of software testing and software quality. Randy has over 35 years experience building and testing mission-critical projects in a variety of environments. He has worked in the roles of software developer, system designer, project manager, QA manager, test manager, management consultant and trainer. Randy is the founder of Rice Consulting Services, where he is Vice-president of Research and Development and principal consultant.
You can follow Randy on Twitter @rricetester.

Randall Rice
Randy Rice is a thought leading author, speaker and practitioner consultant in the field of software testing and software quality. Rice has worked with organizations worldwide to improve the quality of their information systems and optimize their testing processes.

The Related Post

Are you looking for the best books on software testing methods? Here are 4 books that should be on your reading list! The Way of the Web Tester: A Beginner’s Guide to Automating Tests By Jonathan Rasmusson Whether you’re a traditional software tester, a developer, or a team lead, this is the book for you! It ...
Trying to understand why fails, errors, or warnings occur in your automated tests can be quite frustrating. TestArchitect relieves this pain.  Debugging blindly can be tedious work—especially when your test tool does most of its work through the user interface (UI). Moreover, bugs can sometimes be hard to replicate when single-stepping through a test procedure. ...
This article was adapted from a presentation titled “How to Turn Your Testing Team Into a High-Performance Organization” to be presented by Michael Hackett, LogiGear Vice President, Business Strategy and Operations, at the Software Test & Performance Conference 2006 at the Hyatt Regency Cambridge, Massachusetts (November 7 – 9, 2006). Introduction Testing is often looked ...
Please note: This article was adapted from a blog posting in Karen N. Johnson’s blog on July 24, 2007. Introduction The password field is one data entry field that needs special attention when testing an application. The password field can be important (since accessing someone’s account can start a security leak), testers should spend more ...
In today’s mobile-first world, a good app is important, meaning an effective Mobile Testing strategy is  essential.  
When You’re Out to Fix Bottlenecks, Be Sure You’re Able to Distinguish Them From System Failures and Slow Spots Bottlenecks are likely to be lurking in your application. Here’s how you as a performance tester can find them. This article first appeared in Software Test & Performance, May 2005. So you found an odd pattern ...
Creative Director at the Software Testing Club, Rob Lambert always has something to say about testing. Lambert regularly blogs at TheSocialTester where he engages his readers with test cases, perspectives and trends. “Because It’s Always Been Done This Way” Study the following (badly drawn) image and see if there is anything obvious popping in to ...
David S. Janzen – Associate Professor of Computer Science Department California Polytechnic State University, San Luis Obispo – homepage LogiGear: How did you get into software testing and what do you find interesting about it? Professor Janzen: The thing I enjoy most about computing is creating something that helps people. Since my first real job ...
LogiGear Magazine March Testing Essentials Issue 2017
LogiGear Magazine March Issue 2021: Metrics & Measurements: LogiGear’s Guide to QA Reporting and ROI
In software testing, we need to devise an approach that features a gradual progression from the simplest criteria of testing to more sophisticated criteria. We do this via many planned and structured steps, each of which brings incremental benefits to the project as a whole. By this means, as a tester masters each skill or area ...
I’ve been reviewing a lot of test plans recently. As I review them, I’ve compiled this list of things I look for in a well written test plan document. Here’s a brain dump of things I check for, in no particular order, of course, and it is by no means a complete list. That said, if you ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news