Getting on the same page: How testers can help clarify requirements

Gathering accurate requirements is one of the biggest challenges of software development. There can be a big disconnect between what the users want and the software that gets developed. In this tip, Agile expert Lisa Crispin gives some helpful advice on the best way to make sure the stakeholders, the developers and the testers are all on the same page.

Many Agile teams struggle with how to understand customer requirements. A user story doesn’t provide much detail. It’s all too easy for Agile teams to miss or misunderstand requirements. In this article, I’ll share some tried-and-true ways testers on Agile teams can help business stakeholders clarify requirements to ensure that the development team delivers the right software.

Story checklist

In Agile development, we work in tiny increments, which will help us stay on track. However, when you work with small user stories, it’s easy to lose sight of the big picture, and cause a problem in some seemingly unrelated part of the system. Our product owner came up with the idea of a story checklist to help alleviate this problem.

The product owner devised a template which he fills in for each new story, and which testers (and the rest of the development team) can use as a starting point for requirements and test cases. This checklist includes sections such as satisfaction conditions; impact on various documents, reports, and legal contracts; UI and report mock-ups, issues such as data migration, impact on pending transactions, auditing requirements; and the question, “What can go wrong with the completed functionality?” Checklists like this will give you a head start on a shared understanding of a user story.

Asking the right questions

One of the most important contributions testers make is asking good questions. When you meet with stakeholders to discuss a new theme or estimate user stories, look at the proposed feature from three different viewpoints. First, ask about the business value. What’s the purpose of the new functionality? What business problem are we trying to solve? Next, assume the perspective of the end user. How will real people use this new feature? What will a user do before and after? What’s the worst thing that could possibly happen? The best? Finally, consider the programmer’s point of view. What’s the simplest technical implementation? Could we implement this but still not solve the problem?

This is a quick process, but it can trigger important discussions that can identify the need for additional stories, narrower requirements, or a pared-down feature that can be implemented more simply. Everyone leaves with a better shared understanding of business needs.

Concrete examples

If we discuss a user story in abstract terms, we often get off in the weeds. It’s much more effective to ask the business experts for specific examples of desired and undesired system behavior. This often takes the form of drawing flow diagrams on the whiteboard, or talking through a scenario of what a real user might do.

Learning about new techniques and approaches is an essential part of the QA professional’s job. One example is the use of mind mapping which can be effective in brainstorming complex new themes as well as test cases. Take time to find learning opportunities, whether online, at a local user group, a conference, a magazine or book, and experiment with new ideas.

Getting the right people together

Testers are often the first to recognize a disconnect in understanding of requirements. One rule to follow is what Janet Gregory calls the “Power of Three.” Other practitioners have come up with the same rule independently, which affirms to me that it is really powerful. Anytime there is a discussion about a requirement, there must be a programmer, a tester and a business expert present in the discussion. You need all three viewpoints, and you need to make sure nobody is left out of the loop.

If I detect confusion about a requirement, I immediately try to assemble the right people to discuss it. Here’s a recent example. After 11 years, the business people decided to correct a misnamed user role in our system. The product owner gave us mock-ups with the new terminology, and the ScrumMaster started showing these around to the different stakeholders. It became clear that everyone had a different opinion. I scheduled a meeting for the same afternoon with all the stakeholders. In 15 minutes, we had all settled on terminology that worked for everyone, potentially saving days of re-work.

It’s essential to review requirements and test cases with the right stakeholders. In Scrum, we have a product owner who theoretically speaks for all the customers, but in reality, no one person can really represent every user. Take the time to understand each business expert’s needs, and if you have a product owner, work with her to ensure the feature will meet the minimum needs of all concerned.

Learning the domain

The testing skill I value most in myself is the ability to quickly learn a domain. Understanding each business expert’s job is essential to being able to help them make their jobs easier. Budget time to sit with business experts to understand what they do. They don’t always know that a simple software solution could save them time and prevent mistakes. Understanding the business lets us help customers prioritize and maximize the return on their software investment.

Documenting requirements and test cases

If your team finds it hard to get a shared understanding of the new user stories for an iteration, try writing high-level test cases together, as a team. This is one form of what Gojko Adzic calls “specifying collaboratively.” We do this a day or two before the start of each new iteration, in an hour-long “pre-planning” meeting. As the product owner explains each story, a team member writes down the agreed-upon specifications as bullet points on a whiteboard. There are usually just a few bullet points for each story. Unanswered questions are written in a different color marker, so we can be sure to get answers before the start of the sprint. We go over all the stories again and address questions during our sprint planning. Though we will expand on these, we have clear requirements for each story.

Consider photographing your whiteboard of requirements, any whiteboard drawings and diagrams, and mind maps to preserve on your team wiki. Wikis are a good place to keep documentation, because each team member is free to update it. Flesh these visuals out with more detailed narrative requirements. More importantly, you can take the concrete examples from your customers and turn them into executable specifications.

Automated tests are some of the most important documentation for the team. It’s what Gojko Adzic calls “living documentation,” which we must update with every change to the system. It’s important to choose test tools that encourage collaboration between testers and programmers to write and automate the test cases. This is a sure-fire way to get everyone on the same page. Once the code is finished and the tests pass, they can be run as part of an automated regression suite in a continuous integration process. Since they must always pass, these tests must be up to date. When someone comes over from the business side to ask something specific about how the system works, you can prove exactly what the production code does by running the inputs through an automated test.


Delivering a high-quality product is a team effort, but each of us brings our own unique skills to the team. Use your Agile testing mindset to get the right people together, attain a shared understanding of the features to be developed, and keep the customer and development teams on the same page.

Dig Deeper on Topics Archive