I’ve heard a lot of people recently talking about how they have been asked to “test better” or “test more” after bugs have been found in live. This is a question/statement often asked by people who assume (or expect) that testing guarantees no bugs in live. And here is the main problem. In a sense testing could continue forever on certain projects and you’d still potentially have bugs in the code. Most testers know that, but expectations and assumptions of others might not align.
There is also a misunderstanding of what testing is and how it is done. In my experience, the most experienced testers are those people who have never done testing, at least it appears that way when they talk about “testing better” or “testing more”. Testing is seen as the poor alternative to programming and an easy job to do. It’s often seen as someone running pre-defined test cases and ticking boxes.
Many people ignore the human element; skill, culture, outlook, motivation, experience, awarenes, understanding of features and requirements, competency levels of using certain technologies etc. And this ignorance of the human element is why many people assume one tester is the same as another and that testing can be done by anyone.
So statements like “test it better”, “test it more effectively” and the general expectation of completely bug free features are formed, in large, from a misunderstanding of what testing is, how skilled it can (and should) be and how relatively easy it is percieved.
But more worrying, in my experience, is the assumption in statements like “test it better” that testers are the only ones responsible for quality. That the buck stops with testing to ensure our products are good and our customers are kept happy.
I think we need to challenge statements like this and make people aware of other factors that can, and should, be considered when we find a bug in live. I’m not advocating pushing blame away or adopting sloping shoulders. Far from it. There are times when a tester needs to hold their hand up and say, “Yep. Missed that one which I really should have caught”, learn from it and move forward.
But there are times when in addition to saying “we should test it better” we should add in statements like:
- We should specify it better
- We should gather requirements better
- We should budget better
- We should resource it better
- We should focus better
- We should project manage better
- We should code it better
- We should unit test it better
- We should integration test it better
- We should UAT test it better
- We should dogfood it better
- We should support it better
- We should train our end users better
- We should communicate better
- We should prioritise our work better
What we absolutely should not be doing though, is settling for anything less than a fair statement about testing. If we messed up, fair enough. If we did our job with pride and resolution then it’s time to step up and say so.