There is a group of testers, that adopt certain behaviours, when it comes to testing.
Sometimes, they are happy they found a bug, just so they can stick it to the person, who wrote that part of the program. Sometimes, they try to impose quality by meticulously entering bugs into a defect tracking system. Sometimes, they tend to keep metrics about the number of defects found in a release, just to stick them to the devs. Sometimes, they reprimand programmers for supposedly poor-quality work or for not following proper procedures or coding standards. Sometimes, they decline testing builds that don't have adequate documentation. Sometimes, they are convinced that programmers need drilling and are there to happily provide it.
Those people are the quality police.
Don't be a quality police officer.
Testing does not automatically increase the quality of the product. Software testers are people responsible for testing software (du-uh). They need to report what do they see and what is lacking.
If errors, defects or failures are communicated in a constructive way, bad feelings in the team can be avoided.
Top comments (4)
Really funny! I have learnt coding for a long time and frankly speaking, some of the bugs needs police :) Now, I am applying for police academy, so I would like to use this example when I will be working on the paper. I read a lot of interesting information at gradesfixer.com/free-essay-example... website where professionals writers gathered the top examples of papers to make the students' lives easier.
Personal retribution is certainly wrong. But what's wrong about metrics? Or reprimanding (of course, if done in a non-aggressive way) developers that don't follow coding standards?
Thank you for your comment! :)
If testers talk with developers about the coding standards in non-aggressive way, then YAY :) There is also nothing wrong about metrics, until they are used for punishing purposes, e.g. to judge individual performance - they can be twisted into any interpretation and used in harmful way.
I see, thanks for explanation.
It's strange to me that you tie terms "punishment" and "judging individual performance" together. I mean, imagine we're devs, and there's a tester testing our code. We work on the same parts of the same product. In a quarter, that tester shows us numbers: you've introduced 3 bugs into the codebase while I introduced 30. To me, that's a good indicator that, all things being equal, I'm way more careless than you. And that's some ground for actionable feedback, or for unit tests improvements, or whatever. But I see no harm in that.
Again, if you're talking about something like cutting a 1% off a yearly bonus for each bug, then sure, that's beyond the good and evil.