One of the earliest phrases I learnt in testing, and one of my favourites is that nobody likes being told that their baby is ugly. To put it another way, you’re going to spend a lot of your time as a tester criticising others’ work and you’re going to have to find a way to do that, that doesn’t just end up ticking them off.
There are two main areas where you’re going to come across this. The first is when you’re raising defects. I’ve blogged earlier about picking on every minute detail and raising defects for every ‘i’ not dotted, but it’s worth considering here that raising a hundred defects for typos and spelling mistakes isn’t going to win you any friends. These defects are going to show up on reports and are going to look bad, when the impact of them is probably minimal, and the time taken to fix them is likely to be minimal too.
I usually try and solve the problem by grouping these into one defect, or several defects grouped by page/section/functional area. This way you still get everything reported but you’re not repeatedly distracting the developer and project manager with what they see as minor issues.
Another technique (that can be combined with the above) is to do more than just raise the defect, by offering a suggestion on how to fix it. For spellings and typos it’s usually easy to supply the correct version as well. Be very careful here though not to be seen to be dictating a particular solution. Be clear that the solution is a potential one, or quote from the original specification to back up your claim.
Finally, ensure that you have a ‘Rejected’ option on your defect status list. We’re just as fallible as those that write the specifications and the code, and it’s to be expected that a proportion of the defects we raise will be invalid due to misunderstandings or not having access to all the information. As a counter to that, don’t be afraid to challenge a rejected defect, but accept that there will always be some.
Secondly is when reporting. You’re going to have graphs and charts that show failed tests and defects raised, and you’re going to have to comment on them. Choose your words carefully; assign blame to systems and applications rather than individuals and stick to the facts. Equally, emphasise the positives, and the efforts made to correct issues; this time ignore the systems and applications and focus on the individuals who got the defects fixed.
Have a separate section in your report for issues and recommendations. Identify the issues you came across, again avoiding assigning blame, and then provide suggestions on how those issues could be avoided in future. Crucially, always end on a positive note.
The aim is to be seen as someone trying to contribute to the overall solution, not just someone who finds bugs.