How to build a quality-first software development workflow

If you read our last post, you’ll know what’s wrong with current QA processes – and how detrimental to the delivery of your product roadmap they can be. (If you didn’t, we suggest you take a step back and start there). But knowing what’s wrong isn’t the same as knowing how to fix it.

Fear not. In this post, we’ll walk you through what a better development process would look like, and how to build in a way that ensures quality is baked in from the start.

Project scoping

While a lot of companies preach about quality development, very few of them have effective QA strategies in place. To work well, QA needs to be integrated from the very outset – not tacked on at the end.

Whatever you’re building needs not just to work, but to work well for the end-user. Understanding exactly what that means is the best place to start. Too often, development focuses only on functional requirements. By failing to take into account user context and expectations, you’re setting yourself and your developers up to fail. Developers can build you a mobile app – but if you haven’t told them it needs to support 1000 customers, and how those customers are expected to interact with and respond to it, the success of that app is another matter.

Good QA begins with understanding user needs fully, and turning those into a set of acceptance criteria. You can then give all that information to the development team, so they can build a product that meets both functionality and user expectations. It’s important to remember that this requires understanding user needs now and user needs later. Whatever you’re building, you probably want it to scale. Make sure developers know that, so that features that work now won’t break and need to be rebuilt later.

Creating testing criteria

Once you’ve briefed your developers on exact requirements, expected behaviour and deliverables, you can create an appropriate testing criteria framework. Testing frameworks shouldn’t be one-size-fits-all. Unfortunately, they often are. Typically, they’ll either be manual or automated, and focused purely on – you guessed it – functionality.

That’s a very limited way of testing. Ideally, you should customise your testing frameworks to match the real-world usage of your product. If you know how many users will interact with it, on which platforms and in which ways, test it accordingly. And most importantly, test for more than functionality.

Broaden your definition of what ‘defective’ means. Ultimately, software that works technically but isn’t intuitive to a user is still defective. So test for that – and be thorough, so you can have confidence your test coverage is as high as possible. Of course, you can only do this if you’ve thought about expected behaviours and know what your acceptance criteria are. That’s why project scoping is so important.

Development

Almost as soon as you start developing, you can start testing. You can do it feature by feature, or screen by screen. However you do it, make sure you’re breaking down and testing features while developers are still building. Waiting until after they’ve completed to find and fix defects will only cost you time and money.

Taking this approach can seem counter-intuitive. Some teams worry that the continuous loop of feedback will add time on to development. But it’s proven not to. Baking in QA processes from the start delivers quality and speed – not quality instead of speed. In fact, some Distributed clients have seen a reduction in development time of up to 25%. That’s because around 30% of major defects happen in the first week of development, thanks to misunderstanding around what requirements actually are. Catching those defects when they happen means they’re quick to fix. Waiting until weeks later, when your team will have to unpick all the subsequent work, means a 5-minute job turns into an 8-hour marathon.

Regression and UTA testing

Once development’s complete and merged, you need to test again. Even with clear acceptance criteria, merge conflicts are likely when you have different developers writing in different styles and formats. That’s why it’s important to test your software as a whole, and see if it’s still meeting expectations.

This is the stage at which most businesses start QA testing – if they do it at all. Frankly, it’s far too late. The opportunity to identify and fix defects in a quick and cost-effective way has long since passed, and that’s why the misperception that it’s inherently slow and expensive still lingers.

Delaying QA until this stage is actively damaging. Finding defects too late pushes out your target date and leaves you with a difficult decision: miss deadlines, or move ahead with risks. Most choose the latter and hope for the best. But there’s no need to make that choice at all. If you’ve started with proper project scoping, you should by this point have 98% confidence that you’re releasing with few (if any) defects. Those you do find will be from the last stage in the development process, meaning they’re comparatively quick and easy to fix.

Debrief

Testing’s complete, your software’s done – but you’re not quite finished with QA. The last step in a quality-first workflow should be to look at performance and learn from it.

There are a few key metrics to track. Defect leakage is one. Measuring how many defects you identify in QA vs how many your customers report back (and how significant they are) should give you an idea of how well your processes are working. Likewise, pass rates, failure rates and test case efficiency are important to track, as are support tickets. Reopened tickets are a good indication that there’s been miscommunication somewhere in the chain. Identify where, and you’ll be able to iterate and improve the next time around.

Remember that this process works as well for Waterfall teams as it does for Agile ones. In fact, it takes almost the exact same approach as Waterfall, with the addition of some extra QA checkpoints. Taking a quality-first approach might feel like a paradigm shift, but there’s no big secret to it. What it boils down to is better communication. Being explicit at the outset about what good looks like means your developers can build with intentionality. Continually checking in against clearly-defined goals avoids confusion, and gets you to the finish line faster. By asking “is this right?” at every stage, there’s a much better chance that by the end, it will be.

You can grab a sneak peek at our live process with the button below use password: qualityflow to access.