Today, the Sticky ToolLook newsletter from Stickyminds.com featured Jama Contour 3.1 and conducted a short Q&A with Contour product manager, Greg Unrein, who discusses traceability — managing the important connections between requirements and testing.

- – - – - – - – -

StickyToolLook: Please tell us about the value of clarity in requirements planning.
Greg Unrein: From my perspective, the whole idea behind “requirements” is to create a shared understanding of what you’re creating and why among all the people involved in the project, whether you call these details “requirements,” “stories,” “use cases,” or something else. With that in mind, the value of clarity in requirements becomes obvious. It’s the same as the value of clarity in any other form of expression, from code to prose, graphic design to mathematical proof: A shared understanding becomes much less likely without clarity. Lack of clarity leads to many problems, such as cost and time overruns, incorrect implementations, and low team morale.

More specifically, if a requirement isn’t clear, then there is a good chance that any test cases used to validate that requirement are going to be incorrect.

Clarity can come from strong writing, sketches and more formal diagrams, wireframes, storyboards, and any number of other communication techniques. It’s important to note that clarity does not imply verbosity; in fact, it is usually the reverse. As Pascal wrote, “I made this so long only because I didn’t have the time to make it shorter.”

STL: What other suggestions do you have for getting the most useful test coverage—both at the requirements planning stage and during testing?

GU: Being clear on what is being built and why is critical to success. Another important aspect of success is to understand how all of your requirements and test cases are related to each other so that the impact of changes in one area can be understood and decided upon in an informed way. This is the value of traceability.

My favorite technique, though, is to get people critically reviewing each other’s work. Like code reviews for developers, requirement and test case reviews are essential to achieving high quality. Whether you review in a meeting or online, have your test authors actively involved in reviewing requirements and your requirements authors actively involved in reviewing test cases. This fosters shared understanding and improves the quality of both the requirements and test cases.

STL: When you see issues with traceability between requirements and test cases, where does the disconnect most often occur? How do you repair it, and how do you avoid it next time?

GU: When you’re relating your test cases to requirements, it isn’t hard to identify and fill the gaps left by uncovered requirements, so this is rarely a problem. However, some requirements are more challenging to test than others, and a common disconnect is that while all requirements are covered by test cases, there are some requirements that don’t have adequate coverage. Repairing the immediate problem is simple: Focus more testing on the complex requirements. Avoiding the problem in the future usually comes down to having the test authors involved during requirement creation in order to characterize the testing complexity of each requirement, so that your test coverage analysis can include this dimension.

STL: How do you recommend tackling a change to the requirements after the rest of the process is in motion?

GU: Start with the basics: Figure out which artifacts are impacted by the change, and decide whether you can afford to update those artifacts, leave them out of date, or avoid the change. This is usually called impact analysis.

Beyond the basics, involve stakeholders and the people whose artifacts will be impacted in a review of the proposed change. The group will see the change more holistically and be able to assess the true difficulty involved in making the change. Often, changes that seem daunting in a classic impact analysis are less onerous upon inspection by the people most closely involved in the work. With modern collaboration tools, this doesn’t have to take long or involve a meeting; just get the proposed change in front of this group with a way to discuss the changes, and make any necessary decisions to keep the team bought in and motivated and the project moving forward.

Greg invites you to send him your comments and questions about traceability.