The bug stops here
Or something like that is what every tester would want to be able to put on his/her business card. This means, “I CAN TEST”, and “I will NOT get us (the feature team) into those “Oops!” moments.” Once you’ve mastered this skill, developers want you to test their code. Program managers want you on their team. Others have more confidence in your ability to test.
But there are still always those annoying little “damn I should have caught that one” bugs that get away. No matter how thoroughly you feel you’re testing the system. No matter how many angles you think you’ve covered. No matter how many different ways you’ve looked at the system. They do get away.
The question is for how long are they going to continue this escapade at our expense? It’s frustrating and making us age faster sooner and we hate it. No one wants to be in a position where they have to say, “this got away because…” How can you ensure that these don’t get away? That you don’t give anyone else a chance to find bugs that you should have found?
I’m no expert yet but am determined of getting there and one way is by making a mental/blog note of all I learn.
For starters, post-mortems are a MUST! Figure out what went wrong and why it went wrong.
Assuming in general is a dangerous way to function. One thing that I’ve learnt the hard way is to NOT make assumptions. Testers aren’t supposed to make assumptions. Repeat and memorise.
Behind every successful bug is an unintelligent (witless, dumb, half-witted, imbecilic, rash, short-sighted, puerile) assumption. Frequently stop to take a step back to figure out what assumptions you’re making. Ask yourself why you’re making those assumptions. If you aren’t absolutely convinced, write tests for them. Because, behind every successful test is an unintelligent assumption.
Secondly, know the expected results of your tests before you finally run your tests. Or, at the very least, know what the system should not be doing. Tests that go like “lets see what this does” are only successful if you know what should not happen. And check to be sure that hasn’t indeed happened.
Another thing you must do is to make sure you understand the system. Keep picking up parts of the system that you feel you know the least about, or parts that you haven’t completely understood and learn them better. A good test to check whether or not you’ve understood is to try and explain the part to someone else. If you feel yourself skipping a small bit of it cause you can’t explain it, it is because you haven’t understood it… This new understanding will help you come up with new tests.
I’m wiser today, even if by one step, is because I lived the step and rued it over and over again. When a blatant bug was found in something I’d tested, all the in-depth testing I’d done didn’t matter anymore. The one that got away for me was because of “inattentional blindness“. This is something I found out about when I was trying to figure out why this got away. But this was something I should have had tests for. I’d made assumptions about the existing system we were touching. I’d not understood exactly how stuff was supposed to happen. And therefore I didn’t have the tests for this. (I would give specifics but I’m sure I’d get fired. It’s all hidden under the word ‘confidential.’ Maybe after checking with legal :).)
These are just a couple of things I’ve figured out in the post-mortem I did. I’m not there yet :)! But I am working towards being able to put “the bug stops here” on my card and not worrying about bugs surfacing.
Dhruv Sood 