The Fast Without the Furious: A Lean, Agile Approach to Quality Engineering

If you’ve been anywhere near a movie theater in the past two decades, you’re probably familiar with (if not a fan of) the $5 billion franchise “The Fast and The Furious.” All the sudden-turning, hard-shifting, and adrenaline-pumping action is great for the big screen, but for those of us who don’t live our lives a quarter-mile at a time―you know, IT professionals and software application developers―the thought of our projects spinning out of control is a little less than desirable.

With a lean and agile mindset and practices, we can develop and iterate features fast. But when we sacrifice quality for the sake of speed, the business side of an organization gets furious.

While a car movie analogy may seem odd, software engineering has been borrowing concepts and practices from the automobile manufacturing industry for decades, including agile, lean, and quality assurance (QA).

Quality Assurance vs. Quality Engineering

QA was adopted during the 1980s, and the responsibilities of development and quality work were separated into two different and distinct resources in two separate organizational departments. For developers, this caused their focus to shift more toward development and away from quality, since quality was no longer their domain. QA became more focused on “testing for quality” rather than protecting the overall quality of an application. With quality engineering (QE), the focus shifts to defect prevention and “built-in quality,” versus the traditional QA focuses on defect discovery.

User Expectations and the Need for Speed

As customer demand for new and sophisticated features continues to accelerate, the race to get to market quicker puts additional pressure on QA to keep pace. Most organizations meet this increasing user demand by focusing heavily on switching to a lean, agile mindset and development practices, but many have failed to make significant changes in QA.

The fundamental agile principle that most organizations either struggle with or entirely miss is the transfer of ownership of quality from an external QA department to the scrum team. In order to truly achieve the seemingly elusive “shift left” model (i.e., one where software testing is moved earlier in the development lifecycle – literally shifted left in the project plan), quality has to be built into every phase of the software development life cycle (SDLC) and quality metrics should be transparent to the scrum team at all times. Ultimately, this means that QE is baked into the process from the beginning.

With an Agile Lean Mindset, QE is the Winning Crew

QE is not a role but rather a mindset that needs to be adopted by the entire scrum team. The best path to success is to embed a QE Coach in the scrum team who serves as the quality enabler. 

Extending the racing metaphor a bit, think of the QE Coach as a crew chief who provides a breadth of testing expertise and is responsible for teaching and enabling methodologies to support the team. For non-functional requirement activities such as performance testing, subject matter experts (SME) can be used as shared resources to the scrum team.

In the racing analogy, this SME is synonymous with a specialist, such as a racecar driver. Their focus is:

• Driving specialized standards
• Implementing continuous unattended baseline tests in all environments
• Adding quality gates on all code commits

Simplifying the Shift from QA to QE with a Lean and Agile Mindset

Shifting from traditional QA to this newer QE mindset is not always simple. Organizations should learn from others who have pivoted to this model and have proven accelerators to make the transition easier. In fact, organizations shifting to DevOps should consider this as well, as QE is that elusive “last mile” when it comes to achieving continuous and unattended testing throughout the SDLC.

Benefits of Adopting QE

In my experience, organizations with a lean, agile mindset that have adopted an approach to QE and DevOps have seen a significant reduction of person hours per sprint. Post transformation, scrum teams have 100% of their user stories fully automated during the sprint. I have also seen organizations achieve a 100% reduction in the QA (manual testing only) role from scrum teams.

Of course, this shift from QA to QE can’t happen in isolation. It must be part of a larger, enterprise-wide culture change to a lean and agile mindset. To learn more about how organizations can get on the fast track, read our whitepaper, Getting unstuck: Making the PIVOT to business agility.