Quality Assurance is More Than Just Testing—It’s a Formula for Success

Have you ever taken a moment to appreciate the fact that you can use an iPhone or an Android device without it falling apart? Or that you can order from your favorite restaurant year after year and consistently receive good fare without health issues? Do you show up at your workplace each day and play a part in moving tasks forward and receive a paycheck for doing so? 

Whether you realize it or not, each of these scenarios are directly impacted by quality assurance. An organization that can consistently and repeatedly produce desirable outcomes is, by definition, providing a quality product or service.  

So how does an organization ensure quality? Through quality assurance processes. Quality assurance often gets overlooked by the public—it’s human nature to pay more attention to negative experiences than flawless ones—but from a business perspective it’s invaluable. 

Read on to learn more about how quality assurance plays into each stage of agile product development and how to troubleshoot quality issues when they arise.  

Inserting Quality Assurance Processes into Each Project Stage

Ensuring quality is all in the process. But not just any process will do—after all, people are involved! A good process must leave room for dynamic and creative work to occur, and an overly laborious process runs the risk of dragging people’s work down. 

In order to make sure the process works for the people who follow it, it should maintain a balance between structure and freedom. There must be an irreducible minimum of structure that helps everyone maintain standards at each stage of the product or service creation process. And yet, there must be enough freedom to make changes as necessary.  

From an ISO or CMMI auditing perspective, quality assurance processes must have these three qualities:  

  1. Traceable (from beginning to end, the change has a formal connection to every stage) 
  2. Reproducible (for every change, the same standards are used to move it through) 
  3. It must ensure desirable outcomes 

Let’s explore the software development example below to see where quality assurance fits into each stage of product development. Since we use agile methodology at U.Group, we’ll be following an agile process in the example as well. 

Stage One: Product Ideation and Discovery 

Nearly all product creation processes begin with a set of requirements or needs. Think of this as the initial idea, change, or issue that a user is faced with and wants added or corrected. Let’s say you were tasked with creating a product with the following open-ended requirements:  

“As a generic end user, I want to have a device that’s small enough to carry around with me all day so that I can accomplish almost any task at any time.” 

The statement sounds simple, doesn’t it? Yet through the eyes of a quality engineer, this “simple” requirement immediately elicits dozens of questions, including:  

  • Is the “end user” literally anyone?  
  • How is “small enough” defined?  
  • How rugged does the device have to be when carried around?  
  • What are the typical tasks the device must accomplish?  
  • Where is the device likely to be used? 

No matter the design methodology, everyone needs a template to help keep pertinent questions at the forefront. Outlining a set of generic questions that garner the right answers serves as a repeatable process that helps add quality to the project. It also provides a structural approach—the scaffolding, as it were—where the contents of the idea go. 

What’s more, this list frees up the engineer’s creativity to delve into more specific questions that would only apply to the unique characteristics of the change at hand. The more assumptions can be fleshed out at this stage, the more likely it is that your team members understand the change, and the greater likelihood that the final outcome matches what the customer intended to receive. 

Stage Two: Idea Grooming 

Once your team has a good idea of what the user wants, the scrum master can get to work, from an IT perspective. During the idea grooming phase, other members of the team may begin to play “20 questions” to determine definitive characteristics, or specifications, that will eventually turn the item into something actionable.  

It’s helpful to note that when you have a framework for asking great questions ahead of time during stage one, those answers can further create a positive feedback loop with design specifications that help jumpstart the technical process.  

It is also typically at this point that technical leaders on a scrum team begin looking at items from a different perspective: how will the architecture of the product or service be impacted? What about security? How and where will it be tested? What deployment considerations need to be tracked?  

All these questions should be a part of the “scaffolding” of a repeatable process. In doing so, it becomes second-nature for subject matter experts to consider the impact of change without forgetting something. 

Clearly, there should be a certain amount of structure that helps guide the creative process forward. And per the agile methodology, grooming is a repeatable process where most or all members of the scrum collaborate to make sure that whatever the item in question espouses is understood and therefore executable. 

Stage Three: Task Execution 

In most IT shops, the idea grooming stage evolves into the task execution stage, where tasks become more recognizable. Developers begin coding (perhaps after a lead has approved plans) and databases are initialized. UI/UX teams build out more robust wireframes, and testers work with developers and other stakeholders to more fully understand how the item will work so that technical quality can be executed. 

After what could be several cycles of development code changes based on tester, user, business analyst, or other feedback (all of which are built into the process!), your team then ultimately has something to deliver. 

Stage Four: Deployment 

At deployment time, an aspect of IT known as Development Operations (DevOps) or, more recently, Development and Security Operations (DevSecOps) will play a pivotal role in making sure that these changes get presented successfully to the user for their use and benefit.  

Arguably, there are as many processes and procedures incorporated into DevSecOps as there are within any other aspect of the scrum team. The quality hallmark of such a deployment strategy is being able to deploy deliverables consistently and repeatedly without failure. 

How to Troubleshoot Quality Issues 

The four stages outlined above build the foundation for a quality process. How do you know that quality outcomes are assured? When any given product request can be introduced at the beginning of the process, and the deliverable deployed for that product meets user expectations. 

But what happens if there are failures? They can be addressed during reviews and retrospectives. Retrospectives are a part of the process that help keep the project accountable so that when issues arise, they can be dealt with. Their purpose is to ask the right questions to get to the right answers.  

Some of the main issues behind project failure include: 

  • A specification was missed 
  • Too many items were included in the Sprint 
  • The right code was put in the wrong place 
  • Testing was incorrectly applied 
  • The deployment pipeline pulled from the wrong branch 

These and many other issues can form the root-cause analysis for why an outcome wasn’t delivered as expected and had a negative impact on the user. If the issue can be pinpointed and corrected, then the team is one step closer to having a quality process. 

You can enforce true quality once you’re able to consistently review the entire lifecycle and eradicate issues as soon as they materialize. And yet, this is typically where many teams will falter. Often, it’s because the process becomes personality-focused instead of issue-driven.  

This flaw causes quality issues to plague the team, which will eventually break down the project. Once this happens, you’ll need to undertake more drastic changes to course correct. For this reason, quality assurance is everyone’s responsibility. If the team focuses on surmounting obstacles and correcting issues as they come up (or get noted for the next retro) and successfully executes their tasks, there will always be a better likelihood of desirable outcomes. 

Quality assurance processes like these are the reason you receive the latest iPhone or Android device without issue and can use them without crashing. The reason the latest menu item at your favorite restaurant is made to order and delicious. The reason you go to work the next day and help figure out the best way to get the latest product into your customer’s hands. Quality is more than testing—it’s proof-positive that you’ve received what you expected! 

Looking to add more tech best practices like these to your toolkit? Sign up for our newsletter to get insights on everything from Drupal website migration to managing your databases each month.

Get alerted to new job postings, events, and insights by registering for our monthly newsletter.