Everyone knows that the earlier you catch a bug the cheaper it is to fix. But how much time do you spend actively stopping bugs from breeding in the first place? Looking for bugs, finding and fixing them is really just treating the symptoms, not the underlying illness.
Think about how the doctors and scientists are trying to fight malaria. If someone has malaria, you can treat the fever-like symptoms by cooling their forehead with a damp cloth. You could try to treat the disease with homoeopathic or traditional remedies. Or better, you can give the patient some medicines that have been proven to actually work. Even better than that, you can try to stop the disease happening in the first place by giving people simple mosquito nets, or antimalarial drugs. Or you can treat the areas where mosquitoes breed with insecticides. It’s easy to see that it’s better to not get bitten by a mosquito in the first place than it is to have a damp cloth on your feverish malarial forehead. We can apply the same thinking to testing, where it’s better to stop a bug being written than it is to rush to fix a critical problem affecting real customers.
If the process of removing bugs from code is called de-bugging, then the process for entering bugs into code is called development
Whilst this is a nice quote to poke gentle fun at our friends and colleagues in the development teams, it’s not entirely true. Bugs don’t just appear out of thin air randomly. They happen for reasons. The more we understand those reasons, the more we can do to control them.
Sometimes the things we are told to do are the wrong things. We are asked to build X, but what is actually needed is Y. As a tester you can help prevent this by activley reviewing requirements before they are developed. This is called “static analysis” and isn’t very trendy these days, but it works. Get involved in backlog grooming sessions, and make friends with your BA and gain a deep understanding of the business you are working in, not just the technology department you’re working in.
Some requirements are badly written and contain errors or omissions, or are conveyed by someone who doesn’t really know what they’re asking for. Code written based on these requirements will never be good. So again, actively review requirements before dev starts, and make sure development doesn’t start until you are satisfied the requirements are of adequate quality.
However good the requirements are, sometimes they can be mis-interpretted. You can prevent this by repeating back to the analyst/business owner what you think the requirements are, and getting the dev to do the same. That way you can see what people actually know, which is often different to what they think they’ve read or heard.
The wrong skills
If people are made to do things they are not good at or don’t want to do, they are very likely to do it badly. You may have the best C++ developer in the world, but that doesn’t mean he’s going to be great at CSS3 and if you make him do your CSS3 work, expect lots of bugs. So, get people doing what they’re good at.
The wrong process and practices
Make sure your software development process is highly conducive to the avoidance of bugs. If your process doesn’t do Test Driven Development, doesn’t do code reviews and pair programming, doesn’t maximise automated unit and component test coverage and doesn’t use continuous integration, then you will find lots of bugs when the code is delivered to test. These things are not always easy, but they pay huge dividends and are worth the investment.
The wrong attitude
One of the highlights of my testing career was watching an egotistical developer proclaim loudly how all testers should be made redundant because he never had bugs in his code and it was a waste of time testing it. Within hours of this, one of my more junior testers took it on himself to dissuade this idiot of his opinion by systematically dismantling the developer’s latest code submission and highlighting several critical defects. The look on the developers face was priceless. He left the business shortly after that having learned a valuable lesson. A bad developer is one who thinks his code is so good it doesn’t need QA. A good developer is one who has done everything within his ability to make sure that QA won’t find anything wrong with his code. There’s a big difference here.
Another common attitude problem is that bugs are an inevitable fact of life and QA are there to find them. You don’t want to work with anyone who thinks like this because they don’t care about quality or they think it’s someone else’s problem.
The wrong focus
It’s really easy to mislead yourself into thinking you are doing the right thing when it’s going well. For example, if your dev team are doing lots of TDD and CI and the build monitor is always nice and green showing thousands of passing tests, it might be tempting to think everything’s just tickety-boo. But what if all those thousands of tests are all testing the same equivalence classes and haven’t covered any integration scenarios? Or you might have passed all your functional and user acceptance tests, but not done any performance/load/stress testing. As we’ve seen in my previous post, bugs like to lurk where you’re not looking.
Inadequate unit and component testing
A simple and obvious one. If your devs aren’t testing their own work they will pass bugs on to the testers. Everyone in the process must be aware they are responsible for passing the highest quality delivery they can to the next link in the chain.
Developers who are over worked or constantly “context switching” are likely to generate more bugs than a well rested and focussed developer. Working excessively long hours under excessive pressure for long periods of time is an incredibly obvious sign that your product ownership and planning is failing. Working like this in short bursts can be helpful and even fun but it’s not sustainable. The quality of work produced by teams in this situation will be poor and that means bugs.
We all have bad days. Try to spend them doing those boring, un-creative and easy tasks you’ve been putting off, and save the interesting and difficult stuff for when you’re feeling chipper. Look out for other people having bad days, and pay extra attention to their output on those days. Our standards slip when we’re feeling down.
Even if you’ve done everything you can to reduce the likelihood of bugs being written, they will still happen. People are human and humans make errors. But they key thing is there will be far fewer of them and they will be less severe. And that’s the point.
You may be thinking “Hey, lots of these things happen well up stream of me. I’m just a tester! How can I fix these problems?” Yes, it might be difficult, and yes there are some things you won’t be able to change depending on your seniority. But, it’s your job and your moral obligation to be aware of these things, point them out and make suggestions. Use your retrospectives and post implementation reviews and make a difference!