Steven Lacroix

Steven Lacroix

Vice President, Consulting Services, U.S. Operations

Primary tabs

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 lean agile 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). 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 agile 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 seeming 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.

A winning crew for quality in agile

QE is not a role but rather a mindset that needs to be adopted by the entire scrum team and 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 drivingspecialized standards, implementing continuous unattended baseline tests in all environments, and adding quality gates on all code commits.

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 illusive “last mile” when it comes to achieving continuous and unattended testing throughout the SDLC.

In my experience, organizations 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 can’t happen in isolation. It must be part of a larger, enterprise-wide culture change. To learn more about how organizations, large and small can get on the fast track to agile adoption, this whitepaper is a good starting point: Download “The Agile Culture Shift: Why Agile isn’t Always Agile”

Key Differences between Traditional QA and Quality Engineering

About this author

Steven Lacroix

Steven Lacroix

Vice President, Consulting Services, U.S. Operations

As an IT professional with more than 20 years of experience in leading and managing all aspects, groups and silos in the software delivery life cycle, Steve has seen the impact of digital transformation up close where success factors have less to do with technologies ...