Confirmation Test Engineering: The Next Stage of Software QA?
Not long ago quality was still an afterthought in a software development lifecycle. It followed the earlier software requirements phases—gathering, design, and coding—in a sequential flow to take on official rounds of testing. It was more of a control phase, a gating phase where quality control was exercised through a series of predefined tests based on requirements that were handed off to testers.
While execution was largely undertaken in a waterfall cycle with product releases running into months if not years, testers tasked with quality control were under pressure to quickly finish their quality checks and control practices and hand off builds for final release.
Then came the phase where the software industry as a whole had an elevated understanding of quality and recognized a need to move from quality control to quality assurance. The move to agile development practices gave the quality discipline a much-needed facelift, forcing the team to think about how to engage the testing group up front to push quality upstream.
At a high level, this helped the entire product team. Testers were able to evaluate requirements from an end user standpoint and from a testability standpoint even before they were shaped as a product.
Quality assurance, a widely recognized discipline in the software quality world, is now preparing to head into the next phase—what some call the world of test engineering. Continuous and ongoing improvements in product quality are becoming necessary.
With short release agile cycles, quality cannot be compromised by allowing the release of a substandard product just to get it out in the marketplace at the earliest possible time. Creating a better quality version in the subsequent iterations should not be the goal. Quality is not a box that you close in one release and reopen in the next one with a new set of requirements and mandates.
It is becoming increasingly important for the testing group to provide the product team a confirmation up front of the product’s quality, in the form of SLAs or not. Then, in an ongoing basis, the testing group continues to engineer their test efforts to align with the predefined standards or confirmed SLAs.
However, it is important to not confuse the phrases software confirmation and confirmation bias. There is a huge difference between working toward a predetermined product quality (software quality confirmation) and working toward a hypothesis that you strongly believe in (confirmation bias).
Software quality confirmation provides better objectivity in your test effort and helps the tester move into a confirmation mindset—a mindset the tester needs to propagate in his own team and among other disciplines in the product team to help move the quality to the next level.
