Catch a defect in the design stage and it will cost you £1. Don’t catch it until implementation and it goes up to £6.5. By the testing stage, it climbs to £15 and in maintenance, that same defect that would have cost you a pound if you’d caught it early is now going to cost you £100.
You can’t argue with the maths. So why are you still waiting until the very end of development to test your code?
What’s wrong with Waterfall?
Ironically, it’s because a lot of people see it as being expensive to switch to a more Agile methodology. Most people still work Waterfall, waiting until they’ve finished their code to test it. It’s not a good system. Waterfall was invented for manufacturing hardware, not developing software. The processes – and the outcomes – are very different. With Waterfall software development, failing to capture an issue early on could mean going all the way back to day one to fix it. You essentially end up redeveloping, and spending more time (and money) fixing issues.
But that’s not even the biggest risk. Fail to catch defects at all, and your customers become your testers. With so many competitors in the market, that’s a dangerous game. 80% of apps are deleted after one use, with apps crashing or freezing being the main reason for customers disengaging. QA might seem like an annoyance and a cost centre, but ignoring it could be catastrophic.
Why take a quality-first approach
DevOps does it better. They integrate software development with IT operations to strategise, build and test continuously and collaboratively. It means they’re able to deliver rapidly and to a consistently high standard. A quality-first approach combines that DevOps mindset with QA. QA is embedded from the very start of the development process and acts as the custodian of the end result. Rather than checking for quality at the end, they’re responsible for ensuring it from the very first conversation with the customer. This results in not only better quality code, but better software quality overall.
One of the reasons people overlook QA is because they see it as just being about finding defects. That’s not the case. It’s also about checking the performance, security, vulnerabilities and accessibility of the product. The biggest benefit of taking a quality-first approach is that, like DevOps, you get a consistently better outcome, faster. Finding defects is certainly part of it – but the point is that it finds them before they become a problem, meaning the whole software development lifecycle moves much faster. Done well, it means you spend less time in QA, not more. We’ve found that clients using Waterfall can spend up to 45% of a project in QA. When they switch to a quality-first approach, that time is reduced significantly.
A quality-first approach allows you to test in a more streamlined and effective way. It prevents the issues that arise from either not doing enough testing, or doing too much. When QA isn’t baked in it usually means that Developers have to test their own work. But developers often don’t have a true understanding of the product requirements and end-user goals, and therefore don’t know exactly what they’re looking for. That can mean hours are wasted on testing individual features – and there’s still no guarantee that they’ll function properly when merged with other streams of work. So more hours are wasted testing the whole thing all over again.
What a quality-first approach looks like
The other issue with testing is that most people don’t have a framework for doing it well. It goes beyond the basics of checking if, say, a login page works when you click on it. It starts by questioning whether your plan will actually achieve the desired outcomes. Making the QA lead the custodian of those end goals. Mapping out the relevant acceptance criteria’s from day one and customising your QA approach to fit. Every component needs to be tested across every geography, every device and for every user. There are a few critical bases to cover if you’re not sure where to begin:
- Functional testing: End-to-end testing of the software against specification
- Negative testing: Testing expected results when the incorrect data is supplied
- Compatibility testing: Testing how software performs across various browsers and devices
But there’s also regression testing, unit testing, integration testing, and so on, and so on. At Distributed, we have libraries of tests that we run on every component of the code. Some are automated and some are performed by our QA lead or elastic team of testers. In short, there are a lot of ways to test and optimise your product, and a lot of places it could go wrong if you don’t.
How we ensure quality at Distributed
As an on-demand engineering partner, Distributed’s goal is to deliver quality outcomes quickly and consistently. We do that by embedding QA operations into the CI/CD pipeline, so that we can build better from the very beginning. Taking a quality-first approach means our customers create better products and have more confidence in them. In our next post, we’ll dive into exactly how we do that, and what outcomes it drives.
In the meantime, check out our Code Quality Standards for more on how to write good quality code.