Can I Buy a Vowel? Why the Move from QA to QE is Necessary for Agile Development

While QA merely provides a quality check before deployment, QE is the process that instills quality into software design

Eric Getchell, Head of Quality and Infrastructure Services

A recent inquiry on the question-and-answer site Quora asked, “What is agile?” A seemingly simple question, yet it drew 40 responses, ranging from basic analogies to complex explanations complete with diagrams and related threads on the various types of agile frameworks. While Eagle has certainly touched on the many benefits of an agile development model, (here and here, for example), the transition from QA (Quality Assurance) to QE (Quality Engineering) can help contextualize what an agile model looks like in action and, more importantly, underscores how DevOps translates into improved quality and a faster time to value for clients.

Traditionally, developers have relied on quality assurance analysts to measure the quality of software ahead of deployment. In a customary waterfall operational model—in which products are designed, implemented and verified in sequential order—the quality assurance team is typically the last stop to eliminate any bugs in the code prior to release. Within this model, the role of a QA analyst is primarily to detect defects, measure the impact, and—when they invariably discover an issue—send the code back to the developers to begin the cycle anew.

Quality engineering, in contrast, is about defect prevention versus defect measurement. QE is effectively an upstream event in which quality engineers work alongside cross-functional development teams to discover and solve issues in real time. Enabled by an agile, iterative development model, the move to QE ensures quality is baked into the software at the onset of development and remains in focus not only up to but also beyond deployment. This process utilizes quality measurements at build time allowing for continuous quality gates prior to code submittal. Gone is the protracted feedback loop in which QA and the development team play hot potato with the code base until a fix occurs. In an agile model, quality is simply engineered into the entire process.

But this is not the only factor that lends to improved quality. While most CIOs who champion a microservice-oriented architecture will emphasize the ease and speed of continuous deployment, the transition toward smaller, component-based releases also brings focus to specific desired outcomes. Breaking up a monolithic application may create more moving pieces, but it means development teams and quality engineers are running tests on smaller pieces of code, with discrete functions to analyze and assess—fewer variables simplifies root-cause analysis. In addition, test strategies that include performance, security and end-to-end integration are driven into the continuous integration and continuous deployment (CI/CD) pipelines for all applications. Moreover, the CI/CD pipelines are extensible and consistent, allowing for all applications to be delivered in a similar fashion while also removing the need for “manual” code delivery, which inherently degrades the customer experience.

The use of test automation is a core principle to quality engineering that creates predictable and measurable processes. Emphasis on automation through unit testing and end-to-end user experience testing allow for feedback loops within seconds of code merges. Test failures force design teams to think through challenges and be proactive in solving problems immediately, knowing that if they do not, the code cannot move forward.

With the adoption of CI/CD, automated measurements and notifications become innate to the agile process, so that if a build fails, development and QE teams are flagged immediately and deal with the issues on the spot. In an agile framework, everything from functionality and usability to API integration and deployment tests can be automated. Even code style verification tools, known as linting, can be preset, measured and systematized to avoid programmatic or stylistic errors at build time. This highlights the importance of consistency in transitioning to an agile model that can also facilitate the extensibility of the platform.

The delivery and support model also evolves as quality improves. For instance, software updates can go directly into production and bypass the weeks or even months that new software releases would traditionally spend in a test environment. Moreover, rapid deployment only becomes possible when users trust the QE process rigor that underpins the quality and resiliency of software.

In his book, Out of the Crisis, the late MIT professor Dr. Edwards Deming observed that “you cannot inspect quality into a product”—quality either already exists or does not upon inspection. The move from QA to QE may seem like mere semantics but quality engineering is the process that instills and maintains quality into software delivery. As such, QE is both the base for vendors adopting agile development models as well as the boon to end users who benefit from improved quality and a faster time to value. It is also why those who understand the difference seem to make such a fuss over a simple vowel.

Leave a Reply