The Easiest Way to Ensure Quality
A common problem with quality
The easiest way to ensure quality of your product may also be... the least obvious.
Let’s talk about building quality products.
Very often organizations and teams approach quality assurance like this: they define something, they build it and then they test it. Sounds logical? Why not? The problem is that when building a complex solution, you—as a team—are inevitably making mistakes. And you naturally start making them from day one. By the time you test your system, you have layered lots and lots of functionality on top of something that contains an error. So, now that you discovered that error, you have a lot of rework to do. The amount of rework grows very fast over time. And we know what happens in reality: schedule expectations are set, and proper fixing will be a setback. Nobody wants to disappoint anybody, so the teams often have no choice but to cut corners and make things work somehow which is only going to hit them hard again later when production defects will begin to occur and when solution architecture will be so messed up that adding any new functionality will be extremely costly.
Testing early and often
There definitely is a better way, but that way requires of us to conceptually shift our approach to quality. See, to avoid the devastating effect of a defect on top of which a lot of things get subsequently built, we’re going to try to intercept that defect as early as possible.
How? By testing early and often.
A very good way to do this is by performing proper testing in every iteration. And if you, let’s say, operate in two-week iterations, you create new code and you test it in the same iteration. This doesn’t let those defects escape too far and you can’t build more than two weeks’ worth of code on top of a problem functionality.
Now, this often comes as a shock to organizations and teams that mostly test their software manually. Instead of making a single pass in the end, they now have to perform testing every two weeks!? And also need to retest the previous functionality to make sure that the new code didn’t break anything previously built. “That’s insane!”, they will likely think. “We better go back to our good-old test-it-in-the-end-and-suffer-dire-consequences approach!” And it is understandable. That’s just a lot of manual testing. And that is why test automation is so critical to building quality products and building them fast.
So, you want to test early and often and to support that, you need to automate your tests.
Here’s one important caution regarding the automation. Your automated tests need to be sustainable and that is one of the biggest challenges teams have when they start automating tests. They create a lot of tests. Later it turns out that they can’t effectively use them because they either didn’t take care of the data that the tests use or the interfaces by which the tests are hooked up to the code, and so on. So, simple advice: create a limited number of automated scenarios first and make sure that you can use them over a period of time and that they do catch defects. And you learn from that and create new tests, taking into account what you’ve learned.
Alright, now is the time for action. What is your situation with quality? What would be a simple, specific step that you would take to improve it?