Bug are expensive. I think we can all agree on that. Having them in your product impacts the quality of the product and can hurt sales and customer satisfaction. We recognize that, and so we put a lot of effort (and by implication, money) into finding them. We hire testers and invest in test infrastructure. We do root cause analysis and have bug bashes. We explore and attack our software in many different ways, but how often do we stop and think about preventing bugs? Are they just inevitable or can we actually prevent bugs from appearing in the first place?
The answer is yes. Yes they are inevitable and yes we can prevent them from appearing. I don’t think anyone will ever be able to release ‘bug free’ software, but at the same time, there are many bugs that could be prevented in the first place.
Where do bugs come from? Well many different places of course. Miscommunication on the part of customers in what they want. Misinterpretation of what customers said they wanted by product managers or coders. Mistakes in coding. Misunderstanding of the platforms the product will be used on. There are many ways to miss the mark when it comes to software development, and some ambiguity will always be there. Nevertheless, we can still prevent some bugs. For example, by following some good practices in coding you will make it far less likely that you introduce certain classes of bugs. Or for another example, spending a few extra minutes getting clarification on what exactly a feature is needed for and what contexts it will be used in could prevent a whole raft of bugs.
There are many ways that bugs can be prevented, but what can a tester (working in the testing role) do to help with this? Testing usually happens after the bug has already been introduced and then it is too late to prevent it right? Or is it? One of the things that has been helpful to me is to recognize that the activity of testing and the results that we report out of it can be used to influence the way that a team thinks about some things. For example, something as ‘innocent’ as an email saying: ‘I’m planning some testing of feature X and I wanted to make sure I’m not duplicating work on this. What kind of unit tests have you done on this?’ can gently nudge coders to think about unit-testing their code (and the bug prevention benefits that come from writing code that is unit-testable in the first place). As Maaret pointed out in this post, there are many ways we can nudge things (or speed up movement) in the right direction.
So as a tester, don’t just focus on finding bugs. Think about how you could help prevent them as well.
offbeattesting 