Speed Up Quality Assurance With Early Visibility Into Requirements

“If we only had more time.”

How often have you heard that expression? Better yet, how often have you heard that excuse? If you’re reading this article, the chances are that you’re involved in either the development or testing of software. Perhaps you’re a product owner, maybe a dev lead, or a QA testing director overseeing a portfolio of customer-facing software applications. Any way you cut it, time always seems to run out when we need it the most.

It’s that one critical user story that didn’t make it in the last release that ultimately lost the renewal contract. Or, as a QA director, it’s that extra week that you were never allotted to have your team run through all those negative testing scenarios you created. If you just had that extra week for security regression testing, you would have caught that major security vulnerability that resulted in a massive data breach. If you’ve been working in the world of software delivery or quality assurance long enough, you’ve said it at least once: “If I was only given more time the outcome would have been different.”

Well, I won’t debate the fact that we are forced to move at the speed of light these days. Organizational leaders expect us to accomplish more with less, but they also provide us with very powerful tools that we didn’t have a short ten years ago. To me, a tool is only as powerful as its ability to extend across the enterprise. If you think about it, every tool we use for planning, building and delivering software can be viewed as a mini-conduit. As we know, a conduit is a person or organization that acts as a channel for the transmission of something. With software development, it’s the transmission of artifacts from tool-to-tool that ultimately instruct how a software product should be designed, built, tested and deployed. The tools that practitioners use are essentially conduits to the overall flow of value delivered to your end users, via software.

As a former QA testing manager, I pushed hard to get my teams an early glimpse into the outputs of solution scoping meetings. And why wouldn’t I? The last thing I wanted is for my team to be caught off-guard without enough time to create effective testing scenarios. If we knew what was being discussed, we could iteratively create high-level test scenarios and adjust them as necessary with each new pivot, change, iteration, etc.

Nowadays, teams live and breathe in their tools. In my days leading large-scale implementations, my teams would often use HP Quality Center, while the enterprise architects and business stakeholders gravitated towards other tools for solution scoping and requirement definition. In this article, I’d like to give you a few practical tips for integrating a development tool with a QA tool.

This is important, because if you’re working on an island without early visibility into requirements, you’re going to run out of time. And if you’re a development manager without visibility into the test design, execution or defect re-testing, you’ll also run out of time. More visibility enables you to manage your time better, which ultimately leads to higher levels of productivity.

High-Level Test Planning Allows QA to Move Faster

If your development team is using a development tool for solution scoping and sprint planning, it’s vital that all QA practitioners who are responsible for ensuring adequate test coverage have early visibility into the requirement definition process. This visibility is essential for a few reasons:

• As the solution is scoped (even at a high level), QA practitioners can glimpse into what existing test cases can be re-used to design adequate test coverage.

• High-level test planning is a method of broad-brush stroking both the happy and negative paths of validation that will need to occur for a new product release. Early insights to the QA team effectively provide a head start on this task. It reduces anxiety among the QA team and ultimately allows them to design the finalized testing scenarios more efficiently (faster!).

Many QA practitioners are using other tools such as quality assurance and other automated testing tools for test planning, design, execution and defect management. Many times in my career, especially on large enterprise-level software implementations, solution scoping has occurred across myriad business units without feeding into the early stages of the QA process.

Let’s take a specific example of integrating a development and QA tool in the earliest phase of the software delivery lifecycle. Research into the software delivery value streams of hundreds of leading organizations has uncovered this common integration pattern and created practical measures to close the gap between both tools to provide testers with early visibility into requirements. 

Here’s how it looks:

Through enterprise toolchain integration, a QA team’s tool-of-choice receives synchronized requirements artifacts from a development tool. The QA team can begin the process of high-level test planning within the functionality of their tool. In addition, the QA team can trace the test plans created back to the user stories within their tool, which is then reflected in the development tool. The net result is that:

• QA teams will no longer be rushed to create test cases when development is complete.

• Scrum masters, product owners and developers know what test cases have been designed for a specific user story within their tool-of-choice, while also having real-time insight into the execution status of the associated tests via the "Direct Cover Status" attribute.

• Traceability from the test, to the user story, to the feature and the epic is preserved between both tools via an enterprise toolchain integration solution.

Two-Way Defect Synchronization with Traceability Preserved

As your QA teams begin executing the tests previously created to cover the requirements, defects inevitably occur as part of the process. Your QA team logs the defect in their QA tool, but the development team is working in their own tool. Through integration, the defect synchronizes from the QA tool to the development tool. But it doesn’t just sync, it preserves the traceability, or linkage, back to the user story, back to the feature, and back to the epic.

Why is this important? As your app dev team analyzes the defects, they need to understand what test uncovered the bug – and why the defect appeared in the first place. The formal process of identifying "why" is often referred to as root cause analysis (or RCA). With traceability preserved from the defect initially created in the QA tool to the artifacts originally created in the development tool, the app dev team can more quickly analyze why the defect occurred by side-stepping to lines of code associated with each user story.

The end-to-end preservation of traceability between both tools ultimately reduces waste and shaves hours off the RCA process that most application development teams undergo. So not only have you accelerated the QA process, you may even have clawed back extra time to focus on continuously improving the process for the next release.