5 Whys and Escalation

One of the things my QA department does is handle escalations from support. Basically, if support can't figure out a problem or if support believes that a problem is caused by a bug, it comes to QA. We figure out how to reproduce the issue and track it down to its source, then assign it out to the appropriate team for fixing.

Generally this works pretty well, but one of the things we would like to improve is how much support knows before things are kicked over to us. So we're starting to formalize around the 5 Whys.

The 5 Whys method is a cause analysis heuristic that can be used for all sorts of problems. The idea is to look at a problem and - much like your average 3 year old - start asking why. Asking why takes you from step to step and helps you avoid assumptions or leaps of faith.

For example:

1. I couldn't write to the network drive

Why?

2. The drive wasn't available

Why?

3. I can't get to the system that the drive is on

Why?

4. The system is down

Why?

5. The disk failed

This is an easy example, but it gets harder quickly. 

The "whys" are now part of the formal defect writeup.  I suspect this will reduce the number of bugs that end up in QA with a "huh?" attached.

We'll see what happens in a month or two...