July 22, 2015 // By Sam Flood
Requirements analysis and development is a crucial stage in any Software Development project. It is during this phase that the foundation for all future stages is laid. If requirements are poorly elucidated, not detailed enough (or too detailed), or don’t match with what the business and/or its users want, then all the effective system architecture, elegant coding, and effective testing in the world will not yield a successful result. On many traditional projects, this was a phase devoted solely to Business Analysts, who worked closely with their clients to build out a framework onto which development could be executed. It doesn’t have to be this way, though. With an effective agile project that follows the Magenic Foundation process, including other roles—particularly Quality Assurance staff—early in this phase can provide your project with significant value.
Let’s start by briefly reviewing what your Quality Assurance staff is. “Quality Assurance” has been thoroughly defined by a lot of people, and I won’t be able to cover the entirety of this discussion here, but briefly (in my own words): “Quality Assurance” is the practice of inspecting and testing both process and product in order to Provide Information about the system and the project’s process, in order to reduce risk. This helps Prevent faults by inspecting and testing process, and Detects faults when they occur by inspecting and testing the product. Magenic Quality Assurance is trained to do more than test. As Quality Assurance consultants, we are trained to provide feedback about all levels of a project: process, end-user utility, design friendliness, market expectations, technical risk, and testing. All too often, though, “Quality Assurance” staff are relegated to only the latter of these roles in a project, the “testing” subset (Defect detection). This cuts out a significant portion of the value that QA can provide.
It’s a fairly well established theory that the later in the software development lifecycle an issue is discovered, the more expensive it is to fix, and that most often, this cost growth curve is exponential rather than linear. By including QA early in your development process, you can effectively shift left more of the opportunity cost of finding and fixing defects by identifying those issues before they’re defects – even before technical design is complete! One way to accomplish this is to bring Quality Assurance in during the project planning phase. In a Magenic Foundation project, this would likely be during story-telling sessions during the Planning Sprint. By reviewing and commenting on requirements, they can bring all their experience in questioning and finding gaps in systems to bear on the requirements, identifying the issues before coding has even begun. Early in one project – building an e-commerce system for a large retail corporation – we saw this happen when we implemented QA requirements review during the planning sprint that preceded each development sprint. Our QA looked at each requirement and asked questions based on gaps or technical deficiencies we saw. In one case, during requirements review, QA was able to identify that our client had asked to use a specific tool for the requirement (Excel) that wouldn’t support the format desired (more than a million rows in a report). If we hadn’t identified this before we’d coded for it, we’d have discovered in testing that we were crashing the program, and would have had to go back to the drawing board (throwing away all the hours spent writing it in the first place).
That’s not to say this approach is without drawbacks. Bringing QA into requirements development and elucidation phases has to be carefully managed from a project and process standpoint. As a group, QA tends to be detail oriented and focused on making things right, and this can lead to feedback loops where QA gets caught in technical details and questions that get in the way of implementing a solution without bringing any additional value. We saw this too, when we implemented QA-based requirements review early: a requirement got badly derailed by questions about exactly which data fields would be saved to which tables in what database, when those questions weren’t central to the spirit of whether or not the requirement would serve its intended purpose. These loops can be avoided, if the process is managed effectively, and policed by good Business Analysts and Project Managers, who can recognize when a discussion is tangential and stop it early.
By utilizing QA staff earlier in your project process, and getting them involved in the early planning and requirements phases, we can shift left the cost to fix usability and technical issues that are identified. Because that growth curve is exponential, this saves time and money quickly, even if the relative rate of issue-detection is much lower than the rate during system testing.
If you’d like to contact us directly, email us or call us at 877-277-1044.