Thursday, July 16, 2009

Definitive Source

I got this question yesterday:

"Do you have a good resource defining standard defect severities?"

Let's parse that for a moment. There are three interesting points:
  • "good resource"
  • "defect severities"
  • "standard"
"Good resource"
Do I have a good resource for this question? Absolutely. I have my own experience. I have a community of testers who are more than happy to answer any question I have - all it takes is a communication to a couple of mailing lists and/or forums. In this case there has been a lot written about the topic in blogs, books, mailing lists, classes and training materials. I can also look at "reference implementations" - in this case the default severities available in a variety of defect tracking systems.

I have copious resources here, and many of them are trustworthy.

"Defect severities"
When I get asked about severity, the first thing I consider is whether the person means severity, priority, some mix of the concepts, or something else entirely. Context of course matters here - who's asking and why. Sometimes my first answer needs to be a follow-up question about what information they're seeking.

In this case the questioner was an engineer who I know can differentiate between severity and priority, and has the same basic understanding of the meaning of those terms that I do. So I can skip the "do you mean severity or priority" follow up.

Here's where it gets tricky. There isn't exactly a single governing authority for testing. There's not even a generally accepted association or membership group. Lawyers have the Bar Association, physicians have the American Medical Association (or equivalent in your country), testers have... well... I don't know of one.

So we have to proxy standards with experience, or with the concept that "a lot of people" think X. We find important sounding groups - I eventually dug up an IEEE spec to answer this question in a way that gave him the ammunition he needed - or we fall back on "general practice", or we quote someone we respect in the field who has talked about this. The same problem holds true for software workers of all stripes, I think. There's no "official standard" for Perl style, for example; people just make it up for themselves based on what they've seen, or they point to respected developers and groups. There's no standards body for DBAs, no near-universal association of UI designers.

I wonder sometimes if the lack of an "official standard" for so many of these concepts hurts us, even if many of us basically agree on the concept. Having a "standard" has problems, but so does not having a standard.


No comments:

Post a Comment