The numbers are right, the defects are grouped according to severity, system area, functional area or whatever makes sense in the project. If you are in a well-managed project you'll also be presented to an overview showing changes over time. The report is filed with graphs for easy presentation of the numbers. Nobody is awake now. Why?
Well, the "why" word is exactly the reason nobody cares about standard reports because they do hardly say a thing about why the defects are there.
Its' comparable to a train wreck. It has happened. The dust has settled. What remains now is twisted metal and a lot of questions with few obvious answers.
In well-driven projects there's room for the most fabulous defect activity - root cause analysis. The kind of work that really pays off both in the short run and in the long run.
The most fantastic book I've read for a while is actually this one.
It's an old book. It's from the time when the PC was a future concept, the Internet was research and tablets were science fiction. Yet it captures many of the conceptual problems we face when working in present day projects.
The reason I mention this book is because the authors have the most wonderful and simple problem break-down which goes as follow:
- What is the problem?
- What is really the problem?
- What is the problem, really?
Most projects only pay attention to the first bullet. Raise a defect, describe the initial problem. Done. Fix. Re-test. Done-done.
Instead of the "let's see how many defects we can close or down grade"-approach, try to apply the problem break-down method to your defects. Maybe not all of them. Maybe just the trivial ones. You know the most severe ones will get the attention anyway, so start from the bottom instead.
Then you'll have the chance of understanding why so many defects are being reported. And just then you might also have some actions to do to prevent defects. That is when you understand your defects.
Thanks for sharing..
ReplyDeleteFeedback: Can u please increase font size.
Question: I think this statements can be clear?
What is really the problem? (What is the real problem)
What is the problem, really? (Was it a problem, really)
Regards,
Srinivas Kadiyala
@srinivasskc
Hi Srinvas - Thanks for your comment!
DeleteRoot cause analysis is often neglected in projects – Either because there is no time, or because the truth hurts.
Asking the question “What is really the problem?” requires analysis and time. On top of this, it requires a controlled environment where you can actually trace the problem back to its origin. Going back to the origin of the problem is not necessary the root of the problem and that is where you have to ask the question “What is the problem, really?”
I have an example from a project I was involved in many years ago. Using the questions listed by Mikkel the rootcause analysis would have looked like this:
What is the problem? Too many defects are rejected by developers as not reproducible!
What is really the problem? Developers have a hard time understanding the scenarios described in the bug reports, and it shows that the problems can be reproduced by the person who raised the defect.
What is the problem, really? Business personnel involved in the test don’t have a clue on how to write a good and accurate defect report.
Problem was fixed by a Defects for Dummies manual, and me reviewing the defects for a period while the Business reps got the hang of writing repro steps without getting lost in business lingo or one-liners.
However the answer to What is the problem, really? Could easily have been something else – What if there was a significant difference in the DEV and TEST environment? What if the developers needed to have a crash course in reading requirements? What if the test was running on poor data?
Answering that last question accurately is in my opinion what makes money and optimizes productivity – Stopping the same error to happen over and over again.
And one last thing: Be careful how you bring your points about root causes across, there are a lot of sore feet and toes to step on in the process.
Happy testing!
/Nicolai