My bug report template includes a Severity attribute but my teams don’t bother populating it. The severity choices on my template are:
We leave it on the default.
Try as you may, to objectively define Severity, and it is still arguably subjective. “Loss of Functionality w/Work Around”…well, if we are creative enough, we can always come up with a work around; let’s use the legacy process. “Data Corruption”…well, if we run a DB script to fix the corruption is this bug still severe?
From my experiences, it has been better for humans to read the bug report description, understand the bug, then make any decisions that would have otherwise been made based on a tester’s severity assessment.
As an example, if the bug report description does not indicate the system crashes, and it does, it is likely a poorly written bug description. One shouldn’t need a Severity to pigeon hole it into.
My advice? Save the tester some time. Don’t ask them to populate Severity. Benefit from the discussion it may force later.
RSS
Thanks for the post.
I liked the last line: Its not necessary to keep the Severity as a column.
I would like to that is it: Severity levels u mentioned is constant for every time?
Wait, shouldn't "With No workaround" be more severe than "With workaround"?
bgoad, you nailed that one, dude. I think you just found a bug in Microsoft's TFS Severity list. Awesome!
I'll talk it up with my team and see if anyone else noticed.
See, I told you we didn't bother assigning severity. Ha!
srinivas, can you ask your question a different way? I think I am missing something. I realize English is not your primary language so thanks.
This advice does not scale well to large projects where reading through and understanding each bug is not feasible - severity, priority, and type/class (text, graphical, crash etc.) are the easiest way to triage defects efficiently. The test team should have enough product knowledge to be able to fill in these fields fairly accurately.
I've seen priority owned by different groups on different projects by on every project the test team has needed a way to indicate test blocking bugs somehow.
btw - TFS severity field is customizable and I'm pretty sure those aren't the defaults.
Byron W,
Thanks for the comment and suggestion on my TFS field. You are correct about Severity being customizable in TFS. So the problem bgoad mentioned was not Microsoft's but mine!
You may be right about large projects too. Maybe testers assigning more meta to bug reports does help. I can only share my own experiences, which are mostly on teams of between 2 and 10 people.
My thoughts - information on defects should be "just enough" for what the project team needs. If this includes having meta data that is needed for reporting or analysis systems, then the testers should assign the appropriate values for things like severity or priority and not just leave the defaults.
I tend to agree with Byron that in large projects where I've had to stay on top of 1000s of defects, having these values filled in helped me to filter and triage what needed to be looked at and what should be passed on to future dev efforts.
Over the last few years I've seen projects moving more and more towards follow the sun testing, and a big consideration that needs to be made when setting up any process is "Does it scale?"
If someone in Thailand is testing and part of the system goes down - do they have the knowledge and permissions to restart it? New team member is starting in India, is their manager empowered enough to set them up with everything they need to start testing?
A large part of my role in testing has been implementing and refining processes which can scale to work with a core team of a few testers to the same team a year down the line when there are 100 or more people involved.
Maybe I should start a blog ;)