Just finished reading the Lean Startup by Eric Rise. It’s a great book about how lean manufacturing principles can be used to help startups innovate and succeed.

One of the concept from the book that I really liked is called the Five Whys.

Its origins in the Toyota Production System, and proposes that every supposedly technical problem is actually a human problem.

Five Whys is a root cause analysis and preventive maintenance technique that we expect to see on a manufacturing floor. The Lean Startup suggest that this concept can be used in startups. I agree and want to take it a step further by showing how we can use the Five Whys for software testing.

The Five Whys In Your Startup

1. A new release broke a key feature for customers. Why? Because a particular server failed.
2. Why did the server fail? Because an obscure subsystem was used in the wrong way.
3. Why was it used in the wrong way? The engineer who used it didn’t know how to use it properly.
4. Why didn’t he know? Because he was never trained.
5. Why wasn’t he trained? Because his manager doesn’t believe in training new engineers, because they are “too busy.”

The Five Whys For Software Testing

1. A broken build made it to Stage environment. Why?All the automation passed.
2. Why did the automation pass? Not all of the test causes where ran.
3. Why weren’t all the cases ran? A down stream Jenkins job wasn’t triggered.
4. Why wasn’t the job triggered automatically? It wasn’t properly linked.
5. Why wasn’t it linked? Because the Tester forgot to do it, and the team doesn’t believe in process documentation.

Why Ask Why?

Bugs and other environmental issues are like big wafer cookies. They have layers. Asking why helps you break through each layer, and dig deeper. With both example above we can solve the problem right away. We only need one or two whys to do it. This is pretty tempting to do because it’s fast and you see immediate results.By doing so the problem is likely to come back though. The root cause is still lurking around.

10 Times To Use The Five Whys Technique As A Tester?

1. Before filling a new bug – The best case scenario here is that you find the root cause for the bug and can tell the developer. The worst case is that you’ll have more information that you can add to the ticket. Either way it’s a win-win.
2. When an automated test fails – There are a few reasons why an automated test can fail. The main goal here is to figure out what truly caused the failure. Was it because of a bug or is the failure a false positive?
3. When the testing environment is down – This can be on any environment: Development, Test, Stage, or Production, When an environment goes down it’s a big deal. You want to find the root cause so that you can fix the problem for good.
4. When a production issue is found by support team – You want to get as much information as possible. I’ve seen situations where someone has done database updates to unblock customers without spending the time to root cause the issue. We ended up doing this multiple times before someone took the time to fix the underlying problem. Fixing the symptoms might seem fast & easy but they’re deceptive. In the long run you end up spending more time. Ask why and attack the source.
5. When a build fails – This is similar to an environment breakdown. Failing builds can be a big headache. They block features from being tested. Slow down the feedback loop. Block features from being released. Stop automated test from being ran. They pretty much block everything. That’s why it’s so important to use the Five Whys on broken builds. It’s a very high leverage point.
6. When the gated deployment allows a major issues to come through – Did you just implement a gated deployment process? Well if not here are 7 Benefits of Gated Deployments. However if the gated deployment is still letting major issues through then you’re not going to be seeing any of those great benefits. So Five Whys the process whenever things go pair shaped to fix the real problem.
7. Before patching a bug – If you’re doing a patch than the issue is pretty serious (you’r breaking the normal deployment schedule so it better be serious). You’ll mainly using the Five Whys here to cover you butt.
8. Before testing a new feature – I like to use the Five Whys here to help me come up with test cases that I haven’t thought off or might have missed. Ask yourself why we’re adding this feature. Why the users would use it. Why it would help them. Things like that.
9. When a manual test fails – Code isn’t the only place where you can use the Five Whys. They can also helpful figure out why manual test have failed.
10. When you have no idea what happened – Sometimes things just blow up and you have no idea what could be the cause. Using the Five Whys can help you make sense of the madness.

Conclusion

The Five Whys technique is great for root cause analyzes. It can be used in a lot of different situations. The only word you need is why! Ask why now, your future self will love you for it. The question for use as Tester is really, Why not?

So now that you have the Five Whys for software testing technique try it out and let me know the results in the comments below.