You need to “Test It Better”

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.

Rapid Reporting

After meeting Shmuel Gershon, probably the most energetic and enthusiastic tester on the Planet, at EuroSTAR 2010, I was introduced to a man of many talents. Not only does he like to read, write and talk about testing but he’s also adding back to the community in other ways with probably the most useful tool I’ve ever used whilst testing.


I introduce to you…….Rapid Reporter.


In essence, it is a reporting tool that allows you to jot down your thoughts, bugs, tests, notes, configs and setups as you test. Things I would have normally used Notepad++ for or a simple writing pad. But the tool is more than that really because it not only allows you to write down your testing notes, but it frees you up from breaking your lines of enquiry/testing by being so simple and easy to use.


The interface is incredible lean and minimalist and everything is pretty much controlled from the keyboard. It allows screenshots and rich text and pushes it all out in CSV format afterwards meaning it’s fairly generic.


It’s got some neat little features like the transparancy setting which I find myself using a lot whilst running multiple desktops, each one cluttered with various heads-up feeds or information radiators or browsers. Another neat feature is the countdown of session time and warning when you exceed the session time set. Nice.


Rapid Reporter has become my favourite little tool of choice now and no testing session starts without it running in the background. It’s proven invaluable when troubleshooting, retrospectively analysing sessions and tracking what sequences/patterns show bugs. I find myself typing more notes than I would have traditional entered and I also list out a lot more data than before which means more data when logging defects or replicating bugs.


So why not give it a download and see how you get on with it. And don’t forget to check out Shmuel Gershon’s blog too.