I had an interesting conversation with some friends last night and it got me thinking more about the roles that testers play in the software development process.  Thankfully I’ve worked with a number of testers through my career (although I could do with a few more now) and they’ve all approached the task differently.  Regardless of their methods and effectiveness, all have had to create and monitor defects.  Once that defect had been created and logged (you are using a defect/bug tracking system aren’t you?) testers, developers and managers all begin to position and promote defects based on their position’s perceived importance of each one.  This is where I’ve seen things get really interesting.

Some defects are obviously critical to fix and all involved will quickly agree to their importance.  Others are no so cut and dry and it will be these that cause the most heated and passionate debate.  Looking back on the many meetings and conversations that I’ve had that have degraded into pissing matches over the importance of a defect, I’m starting to realize that they often waste more time and energy than just making the damn change. 

There are bigger issues that the time and energy used in arguing vs. fixing.  In my mind, part of the role of a tester is to be an advocate for the user.  With that responsibility comes the requirement that they do step up and passionately argue defects.  What I’ve seen in a number of testers that I’ve worked with, is the feeling that they need to tirelessly argue for the user on all defects.  By pursuing all the defects with the same vigour, the testers that I’ve worked with have, over time, worked themselves into positions where they’re seen as calling wolf. 

When this happens the people triaging and fixing the defects will begin to immunize themselves from the testers arguments.  They will begin to reject defects out of spite, apathy and disillusionment with the tester.  Having this type of situation can make meetings heated and they often seem to degrade into personal shoving matches.  Testers hate the development team for appearing not to care about fixing the applications.  Developers hate dealing with the testers because they know that this one defect is not nearly as highly prioritized as the other things that they are working on.  Triaging defects becomes a nightmare where you can’t win.  People begin to loose confidence in the team and the system.  Morale plummets, and a death knell rings for your team.

My advice to testers is to be passionate about the defects that they are finding.  Pursue ‘defect free’ like a dog after a bone.  Be careful though.  Don’t demand that all defect receive the same resourcing and attention.  Instead know that the attention they are receiving during triage is the same, but after that some defects are going to be ignored until time, resource and/or money become available.  If you feel that a specific defect has not received the attention that it deserves then pursue it.  Pick your battles though.  Fight for the defects that you believe have been mis-prioritized and that the User will receive the most benefit from.  When you’re doing this make sure that you can present a clear argument outlining how this is going to affect the User in ways that demand the priority be re-evaluated.  Developers, managers, other testers and, most importantly, the Users will appreciate you doing this.  If you’re not arguing every defect and you’re presenting good reasons for changing the defect’s priority, most people won’t have any animosity to your efforts.  This will allow you to be more effective when you present concerns to the team.  It will also greatly increase the overall quality of your team.

To all the testers out there that I’ve worked with.  Thanks.  After spending the last three to four weeks managing a small group who’s focus has been to test a huge portion of an application, I have a much better appreciation of what you do and how you’re perceived within the team.