Evolving From Quality Control to Quality Engineering
Effective quality control is essential to creating products that customers love and trust. As the last line of defense before a product arrives in a customer’s home or business, quality control teams have the responsibility to ensure that products and services deliver as advertised. But the traditional testing paradigm limits the effectiveness of testing, by involving quality control only after key decisions have been made.
“The difference between quality engineering and traditional quality control is fundamental and structural”
At their best, quality control teams should be acting as customer advocacy organizations within companies, but to reach that point, we must evolve past a static paradigm and into an approach where we are conducting true end-to-end quality engineering.
The difference between quality engineering and traditional quality control is fundamental and structural. At its most basic, this approach requires quality control organizations to get involved in product development cycles far earlier than they have in the past, and to stay involved long after products are tested and shipped.
It’s still important to ensure that products meet specifications, but if we can have quality engineers in the room when those specifications are being set, and learn from our customers’ experiences with previous products, our input to the development process can be significantly more informed and meaningful.
At Comcast, we began implementing the Total Quality Management (TQM) approach throughout our testing operation in 2012, and have been adding core quality engineering components each year since. The ultimate goal behind these updates is to shift our focus to building quality in, rather than testing quality out.
That process is still underway, but from what we’ve already done we’ve already seen improvements that we can measure in quality outcomes, workflow improvements and cost savings. The other immediate advantage of this approach is that it integrates smoothly with our broader, company-wide shift toward Agile software development and a DevOps model of collaboration and operation. In this manner, we can ensure that we aren’t bolting old, slow testing methods onto new, fast development processes.
Beyond simply embedding quality control earlier in the development process, one of the guiding principles behind quality engineering is the concept of “shifting left.” This has become a popular term in quality management circles, and means different things to different people. For my organization within Comcast, “shifting left” is about asking a simple question: ‘How do we learn from mistakes and build our next product so that it doesn’t make the same mistakes?’
As it turns out, that simple question has a fairly complex and involved set of answers. The first thing you learn when you start asking that question is that you need to have visibility not just into how a product works in an advanced testing environment, but also how millions of customers are experiencing that product on a day-to-day basis.
One of the ways we’re trying to tackle that challenge is by doing more time and motion studies within our customers’ homes. We engage professional testers that are also Comcast Customers to use our self-install kits and meticulously document their experiences, timing execution of various steps and identifying issues that may impact customers.
This research generates extremely valuable, qualitative data that is simply not replicable even in the most sophisticated of testing environments. Capturing that data and directing it back into the development process is helping to make our products better and more intuitive.
If shifting left is about learning from your mistakes and committing to a culture of active learning and improvement, shifting right is about making sure that we’re putting what we’ve learned into the hands of everyone in our organization involved with providing a great customer experience.
This is about viewing a product not as a piece of code or a bundle of services, but as a tool that serves an important purpose in our customers’ lives.
As a practical matter, that means that when our researchers learn about a challenge our customers are encountering when they’re using one of our products, we don’t just want to fold that learning back into the development process, we also need to inform our care agents and field technicians so that they are equipped to help our customers.
One of the steps we took very early on as we began evolving our quality organization was to embed a senior team of quality engineers with our customer care agents. This team helps us shift left, by collecting quality information directly from the source and shift right, by supporting care agents with research-backed solutions and support.
Putting the Customer at the Center
What we want to build with all of these approaches, is a model where we place the customer directly at the center of the quality engineering equation, and leverage all available information and learning to make the customer experience better. We call this “spherical shifting”.
That means collecting quality information from every potential source within your organization, analyzing that information, and putting all that data to work in building, delivering and servicing product throughout their life cycle.
As just one example of how this works in practice, I’ll mention our Wi-Fi test house, where we are able to test how hundreds of consumer products interact with our wireless gateways, and how those gateways function in various building environments. This doesn’t just let us flag issues, it also helps us design better products, all by stepping into customers’ shoes and experiencing Wi-Fi the way they experience it.
At that point, “testing” becomes just one of many tools we use to engineer quality into every aspect of the customer experience.