One interesting question, and source of conflict, that I often see when managing testers and testing is that of ‘who classifies the defects’. A lot of the negativity one sometimes notices between testers and developers stems from this, a lot of misunderstandings start from this, and in some companies a whole cottage industry has sprung up around it. Who should classify a defect, who should make the decision on how important it is, and how quickly it should be fixed?


Before I start I should explain that I work in a large company, delivering mobile applications to multiple internal customers, based on a platform model. We have a lot of defects across the products and platforms. We have so many that we employ many dedicated defect managers whose job is to categorise, arrange, house-keep and close the mass of open defects across the multiple release streams. We use an Agile SDLC, with Scrum for new development, switching to Kanban once we are in dedicated productisation phases. So you could say I know a thing or two about defects. I even used to raise them, back in the day 


In the Red Corner
Now, back to the story. In the red corner we have the testers. These guys are at the coal face, they are finding the bugs and raising as many quality defects as they can. If they are good then they feel almost an emotional attachment to the defects; they represent time and effort put in. So they should tell us how important they are, right? Well maybe, but not so fast – maybe they are too close to the each defect. Maybe they have too close an attachment. Maybe emotion blinds good judgement. Whilst we rely on our testers having the best ‘customer’ view of the product, are they the right people to be categorising our defects?


In the Blue Corner
Over to the blue corner – here we have the developers and team leaders or managers. Aren’t they the best people to decide? They know in detail how long it takes to fix a bug, how much capacity they have, how complicated it is. And there could lie a problem – are they too focused? Can they see the big picture? Do they really understand what the customer needs, and which defects need to be fixed in order to deliver that?


A Third Option?
Then to a third option. Taking the boxing analogy, let’s call them the referee. Someone to make sure that things run smoothly. Here’s where we use a defect manager; someone with an independent view to manage the defects, consult both the testers and developers, representatives of the customers, and project managers. Someone who can try and see both views, not a database admin or defect pusher, more of a technical person who a good overall knowledge to ensure that categorisation happens with inputs from all and not just influence from one.


The defect manager can be a person but equally it could be a role. The key thing is that the person sits in a position of independence and is not seen to be pushing their own view. In a cross-functional Agile team we have used the Product Owner for this in the past. Sitting in neither corner, but somewhere in between, controlling the backlog and therefore also controlling the defect fixing. Categorisation falls naturally in this area, whether the defects come from internal testing or from external testing together with the internal or external product program. I have not found the test manager to be a good person to carry out this role – they are too close to the defects and lack the independence needed in order to effectively categorise and drive fixes to completion. Equally, a development team leader or manager is also not a good choice, often taking the technical view and not that of the customer. Sure, if there is no-one else then either of those roles ‘will do’ but getting true independence will result in better categorisation and a more effective close-down of defects and therefore better quality code.