Tester Untested! - Who will Test when you Rest?

During a not-so-long-ago discussion with a tester friend she pointed out with a self-satisfying grin on her face: “testers have the power to scrutinize other’s work and this power makes testing so much of fun”. Though she might have been true to some extent in her statement, it made me to revisit my year old decision to choose software testing as a life long career. I wondered if it was this power (to be able to find fault in other’s work), which indeed had guided my decision to join testing. Thankfully, in my case the answer was a big NO. To me, the satisfaction of helping the end users in getting a better software to use and helping the stakeholders in taking a better-judged decision about the product that I am testing, are much more satisfying and important than the feeling of finding fault with someone’s work.

For those testers who take pride in finding faults in other's works, I just came across something from Jon Bach’s STAR East 2007 Presentation Slide – Top Ten Tendencies That Trap Testers [PDF file]. In the presentation, under Tendency #3 Jon discusses how being untested can become one of those fatal traps that can paralyze the progress of a software tester.

So many times, as testers we devote so much of our time in scrutinizing the works of others but we forget to scrutinize our own work! We often fail to realize that a tester is also a human being and is prone to errors/failures. If there is no way to test the work of a tester it might result in letting the tester getting carried away and in becoming complacent with his work. As testers, we might be quite good at finding fault in other’s work (defect in a programmer’s code, fault in a requirement document, mistake caught in a peer review…), but is it not equally important to start finding fault in our own works? Ability to challenge one’s own ideas/views is a skill that is found in very few people. By trying to challenge/question our own beliefs we generate opportunity to verify the concreteness of our ideas. By doing so we create chance to come across conflicting ideas that might be used against our original beliefs by someone trying to prove us wrong. It is like bombing our own castle wall in order to test its robustness against enemy artillery units in an attempt to prepare us against future real attacks from attackers.

There can be so many areas where our testing might be not-up-to-the-mark and missing something and we might never know it until we start testing our own work! They can range from ill-designed tests, unclear and often misguiding bug titles, bugs that report failures (effects) not faults (cause), complacency with testing know-how, over-dependency on requirement documents as if they were words from the Bible, fear to break rules, willingness to follow the age-old concepts in testing without ever daring to question them, not ready to learn more on testing and so on. Testers tend not to inspect their own work and this is when they start to fall prey into the trap! Testers need to take a step back and test their testing just as they test the code written by the programmer. I don't see anything wrong in scrutinizing the work of others as long as the tester keeps testing his own work! Do you test your tests? Do you challenge your own views/ideas and look for counter-ideas that might prove you wrong? Do you practice self-criticism?

Happy Testing…

Share on Google Plus

About Debasis Pradhan

Debasis has over a decade worth of exclusive experience in the field of Software Quality Assurance, Software Development and Testing. He writes here to share some of his interesting experiences with fellow testers.