|
“The best tester is not the one who
finds the most bugs or who embarrasses the most developers. The best tester is
the one who gets the most bugs fixed.” |
 |
So how can they do that?
Be Cordial and Patient
As a tester you may find it more difficult to convince a developer about a
defect you’ve found. Often, if a tester exposes one bug, the programmer will be
ready with ten justifications. It’s sometimes difficult for developers to accept
the fact that their code is defective—and someone else has detected it.
Developers need support from the testing team, who can assure them that finding
new bugs is desirable, healthy, and important in making the product the best it
can be. A humanistic approach will always help the tester know the programmer
better. Believe me, in no time the same person could be sitting with you and
laughing at mistakes that introduced bugs. Cordiality typically helps in getting
the developer to say “yes” to your bug report. An important first step!
Be Diplomatic
Try presenting your findings tactfully, and explaining the bug without blame. “I
am sure this is a minor bug that you could handle in no time. This is an
excellent program so far.” Developers will jump and welcome it.
Take a psychological approach. Praise the developer’s job from time to time. The
reason why most developers dislike our bug reports is very simple: They see us
as tearing down their hard work. Some testers communicate with developers only
when there is a problem. For most developers, the software is their own baby,
and you are just an interfering outsider. I tell my developers that because of
them I exist in the company and because of me their jobs are saved. It’s a
symbiotic and profitable relationship between a tester and a developer.
Don’t Embarrass
Nobody likes mistakes to be pointed out. That’s human nature. Try explaining the
big-picture need for fixing that particular bug rather than just firing bulky
bug reports at developers. A deluge of defects not only irritates the developer,
it makes your hard work useless for them.
Just as one can’t test a program completely, developers can’t design programs
without mistakes, and they need to understand this before anything else. Errors
are expected; they’re a natural part of the process.
You Win Some, You Lose Some
I know of testers who make their bug reports as rigid as possible. They won’t
even listen to the developer’s explanations for not being able to fix a bug or
implement a feature. Try making relaxed rules for yourself. Sit with the
developer and analyze the priority and severity of a bug together. If the
developer has a valid and sensible explanation behind her reluctance to change
something, try to understand her. Just be sure to know where to draw the line in
protecting the ultimate quality of your product.
Be Cautious
Diplomacy and flexibility do not replace the need to be cautious. Developers
often find an excuse to say that they refused to fix a bug because they did not
realize (or you did not tell them) how serious the problem was. Design your bug
reports and test documents in a way that clearly lays out the risks and
seriousness of issues. What’s even better is to conduct a meeting and explain
the issues to them.
A smart tester is one who keeps a balance between listening and
implementing. If a developer can’t convince you a bug shouldn’t be fixed, it’s
your duty to convince him to fix it.
-KabInfo.Net
|
QTP Testing
