Smarter Test Engineering

One of my friends was talking about the term/metric ‘Defect Detection Capability’. He was saying that calculating this metric and taking necessary steps to increase it, will improve test productivity. Well he was telling me that ‘Defect Detection Capability’ is how many defects a tester can find in a given amount of time, I will not agree this. How can we calculate testers efficiency by number of defects found. Is it a good practice? Is there any principle which states that each tester can find these many defects in a given time. No one can say how many defects can be found before testing. A tester cannot find same number of defects everyday he tests. The application may be stable after some time, at this time will you expect a tester to find the same number of defects that he/she have found earlier? Testing is always context dependent.

Bug is like a Land Mine: You can never estimate or say in advance that there will be a bug in particular feature of software; even with your experience or your exploratory thinking you may guess that there may be a bug but you cant say in advance that there is a bug without testing.
What do you do when you find a bug?
We find bugs of course I always believe that we are made to find bugs. After we find a bug the following are the actions we should perform:
Analyze the root cause for the failure whether it is a software fault or our fault.
Ask some of the peers to review it.
Draft the Problem report immediately because we may miss some things when we draft it after some time.

Writing Bug Reports effectively is also an art

To write fully effective bug report we should:
Explain how to reproduce the problem: If the programmer fails to reproduce the problem they simply reject the bug.
Analyze the bug so you can describe it in a minimum number of steps, a developer is more likely to postpone the bugs reports that look long and involved.
Write a bug report that is complete and easy to understand.

What does a Bug Report contain?
Abstract: A line about the bug which should give the developer an idea about the bug.
Platform Details: on which platform you got the problem.
Notes: any suggestions (optional).
Attachments like screenshots, log files etc
Steps to reproduce: write the steps by following which developer should reproduce the problem. Write the steps in a spoon feeding way so that the developer can reproduce the problem.
Expected result: The outcome which we expect or what the specification says
Actual result: The actual result which we get.
Test Case ID:
Test Case Name:
Tester Name:
Developer Name:
Severity: It talks about the seriousness of the bug. It is rated from 1 to 5, like 1 for critical failures, 2-3 for major and 4-5 for minor ones.
Priority: It talks about the urgency of fixing the bug. It is also rated as 1-5.
Version Number: The Version number of the software, this helps in future reference.