I didnt resolve all the bugs. Am I a bad tester?

Those who work in the industry would probably agree with what I type and those new to the field of testing might see this as an eye-opener. In my very first interview for a Software Test position, I was asked when would I say a product is good to ship? My quick answer was, "When there are no bugs in the product". My interviewer laughed and it struck me that I was wrong. So I went ahead to say, "Usually its not possible, but I would really like to ship a bug free product". All he said was "Good Luck". Needless to say, after a week the HR called me up to say they were sorry but I had missed out on the job.

When I think back on this, I laugh. Yes, who would'nt love to ship a bug free product. But I can almost gaurantee you that if someone tells you he has shipped bug free products all his life, either he is living under some weird delusion or he is taking you for a ride.

Products (and I mean almost all products I have known till now) are shipped with bugs. But these bugs are categorized into two types:

• Bugs which are not known
• Bugs which are known

For the amateur tester: Yes, products are shipped with known bugs too.

So if I know that my product has bugs, why the hell would I ship it?

Its something we all crib about and the word is "deadlines". Everyone has to meet a deadline and any good tester would know that testing never ends. So you have to put your foot down at one stage and say the product is ready to be shipped. And for me, this is where a good tester shines. Here is where you could prove your mettle. This is where you make the trade-off. You know there are bugs in the system, but how crucial are these bugs?

This is why I follow a mantra, which says "Prioritize". Every time you note a bug, give it a priority. Make sure the high priority ones are resolved. There is no way I would sign over the dotted line if these are not resolved. Try anything in the book to make sure high priority bugs are resolved before you ship the product. If the dev team does not agree to comply, camp outside your Test Managers office, sing a song in a lousy voice (I know one chap who tried this!!) and agree to stop only if the dev. team agrees to resolve your bugs.

Here is an example (I love examples). Lets take a product we use each day. Lets say, MS Word. Imagine you are a tester for some particular feature of MS Word. You realise that when you hit Ctrl+S your cursor moves back by 4 spaces, but your document is saved. So its surely a bug. Now each time you choose "Arial" font your application throws an exception and hangs. Again a very valid bug. But the second bug is definitely high priority. In a pressure situation I would ship the product with the cursor not staying where it should, but I would never ship the product as mentioned in the second scenario. My priority is to get the second issue resolved and I might ship the product with the first issue not resolved.

That took care of bugs which are known, but what about bugs which are not known? Usually its entered into your bug tracking system after user feedback. Like I said, its sometimes only the customer who identifies some amazing bugs we never thought of. Here again, you need to prioritize and hope to get it resolved in the next release. But if you have a major issue, get ready for some sleepless nights.

So if you didnt resolve all the bugs, you aint a bad tester, as long as you got the ones which really matter resolved. And this does not mean you take it easy. Always look for ways to convince dev. to resolve the low priority ones if possible. Keep slipping in the easy ones with the tough ones too! Keep that testing going and keep knocking your dev's. door till you make them cry (such an act tho', could be injurious to your health at a later stage)!