lunes, febrero 18

You report too much defects! OR Defect triaging.

Ever heard “You report too much defects” from a developer or project manager? Before blaming them for being not committal for quality, try understanding that number of defects is not the only (and even not the right) quality measure. With this post I will try to share my experience on assuming responsibility for not-reporting certain defects – performing triage, thus helping to achieve better quality (due to both logical and psychological reasons).
Black tag in Triage: the most difficult to assign
According to wikipedia
Triage is a system used by medical or emergency personnel to ration limited medical resources when the number of injured needing care exceeds the resources available to perform care ...
Red - Emergent
Yellow - Urgent
Green - Nonurgent
Black - Dead or very severely injured and not expected to survive
... Patients who are severely injured and not expected to survive are the most difficult to assign because of the obvious ominous implications

The term triage is adopted for describing process of prioritizing defect fixes. And I want to stress that giving black tags are part (and the most significant in my opinion) of that process. If your development resources are limited (and they typically are) you want to give Black tag to defects that are too hard to fix, don’t you? Well defects are not people so it should be simpler to assign the black tag without morale complications, shouldn’t it? You may also include business priorities in tagging defects unlike battlefield patients triaged “with no regard to rank”. I still have seen a lot of testers unwilling to accept fact that correctly reported defect is cancelled with comment “legacy defect”, “accord to the specification” or simply “fixing is rejected”.
Documented and known defects
Do you know the joke: documented defect is no more defect – it is a feature. This is not a joke – it is reality the industry I work (probably it is not so in military or medical software industry /isn’t it strange however that those are areas where triage comes from :) / ). Cost and time-to-market are key factors (quality tend to have the secondary role) for products. For solutions key factors for success are unfortunately: I. show potential customer that you are the best to do this work (which not necessarily be truth) and II. Implement your contract obligations (e.g. pass all UAT tests or even worse – 95% of them, no matter how many bugs there are outside those tests).
So I believe you are used to see your management to add your reported defect to “list of known problems” as a problem resolution.
The problem here is that none is reading those known problems list until thy run into the problems. You are lucky if the known problem includes workaround acceptable for customer. If not – it may appear they will find alternative software and will hate your product forever because of effort put into trying to use it. I don’t believe that describing defect as know issue is THE ultimate solution. It may sometimes be better not to describe it, wait for customer to report and then implement a solution customer for each customer.
Less is more
In battlefield triage is associated with evacuation. Prioritization is aimed to understand whom to evacuate first. Those tagged black are left on battlefield and given painkillers to ease their passing. This will help you to evacuate those tagged red – otherwise they will die within few hours.
You don’t need to give painkillers for defects. If you left them on battleground (in the software) it will help your team to concentrate on fixing other defects.
“Secondary triage is typically implemented by paramedics, battlefield medical personnel or by skilled nurses”. Tester should learn to be “battlefield medical personnel”, which is not so simple however and requires understanding of the project and customer context.
What you will gain is more respect from developers and management, more respect to defects you report and more of them fixed as a result due to both technical and psychological reasons

http://testingreflections.com/node/4699

No hay comentarios.:

Publicar un comentario