Reimagining Quality Assurance in Software Development

Without validation and testing, the software development process would be a mess. Engineers would deliver a lot more sloppy, broken code, and users would run into all sorts of bugs and issues. There’s no doubt — quality assurance is a critical part of software development. 

But what if we told you there’s a way to do QA differently?

At Lean TECHniques, our development team is made of more than 90 engineers and zero quality assurance specialists, and our product quality has never been better. We’ll let you know exactly how we do it — and why it works. But first, let’s take a look at the traditional approach to QA and the ways it falls short.

What Does Quality Assurance Typically Look Like?

Most companies have a quality assurance team whose job involves manually testing software features and functions to make sure they perform as they’re supposed to. It usually works like this:

1. A software engineer writes a new piece of code
2. The software engineer sends this new code over to the quality team
3. QAs validate that the code works as intended
4. QAs make sure nothing else is broken by retesting other features that may have been affected by the new code
5. Repeat as needed throughout the development process

This standard QA process works for a lot of companies, but it’s not without its shortcomings. For one, this type of QA requires a lot of manual effort and labor hours from your team, and it can be tedious. Second, it becomes easy to blame the QA team for any and all mistakes, even though someone else could have caught the defect earlier — or prevented it in the first place. Finally, this approach to QA often ends up wasting time and money because you’re not getting feedback until later in the development process, often when you’re supposed to have shipped.

So how can companies address these issues and improve the QA process? Here’s how we do QA.

An Alternative Way to Do QA

At Lean TECHniques, we see QA as an essential task, not a role. For this reason, we don’t have any dedicated QA specialists on our team. Instead, we have cross-functional, autonomous delivery teams that are responsible for building and delivering quality software. This means QA is everyone’s responsibility. Some features of our QA approach:

• Automated Regression Testing: We’ll work with you to build a robust CI/CD pipeline, giving your team the confidence that every release is thoroughly tested and safe for deployment. 
• Incremental Delivery: Work is delivered frequently, yet safely, encouraging timely feedback from customers as well as rapid response when problems emerge.
• Regular Stakeholder Reviews: We work closely with stakeholders to ensure quality through regular progress checks, providing the opportunity to give feedback and steer direction. 
• Pair Programming: This technique means we have an extra set of eyes on everything delivered, and it helps prevent single points of failure that often occur through knowledge silos.
• Release Management Techniques: Tools like feature toggles allow us to decouple deployments and releases and provide the ability to turn features on and off.
• ATDD/BDD: When working with a customer with QAs, we promote the use of ATDD/BDD, a technique that simplifies understanding of requirements and facilitates efficient testing, resulting in higher-quality software and faster delivery.

Why Change How You Do QA?

When people hear that we don’t have dedicated QAs, they are often confused and even skeptical. But while our QA methods are surprising to some, they’re also effective. We’ve seen positive results using this approach, and so have our clients.

One major benefit of our QA approach is that it leverages automated testing whenever possible. When you have computers doing the tedious work of testing and validating features, your team members have more time to focus on high value, creative work.

Another benefit we see when QA is a task rather than a role — there’s no finger-pointing when something goes wrong. With QA tasks distributed within cross-functional teams, everyone is responsible for building quality into the product from the beginning. This results in a higher quality solution every time.

Lastly, this way of doing QA encourages feedback early in the development process, so your engineers can find and fix issues sooner, which saves time and money in the long run.

Changing Your QA Approach: Next Steps to Take 

So, are we saying you need to get rid of your entire QA department?

Not necessarily, and certainly not right away. But we do recommend taking a look at your current quality assurance framework and finding opportunities for improvement and automation. Far from making QAs redundant, automation frees them from mundane testing and engages them in more valuable, exploratory work. Most QAs are excited to leverage their problem solving prowess and deliver on your organization’s desired outcomes.

If you continue to see the value in the QA role and you don’t want to eliminate it, try to get QAs involved earlier in the development process. This “shift left” approach will help you deliver higher-quality software with reduced time and cost implications.

For support as you review your QA efforts, reach out to our team. Our experts have unique insights into strengthening and streamlining your development processes.