Multidisciplinary, cross-organizational, analytic, and creative—testing, it could be said, is far from child’s play. Yet there’s something every toddler does that could help solve some of the biggest challenges testing programs face. When children reach the ages of two and three, they adopt a technique that helps them learn about the world and make connections between events—toddlers vigorously and persistently ask “why?”
This behavior can be frustrating for parents driven to find an answer to an endless string of increasingly specific questions, but the process is actually really important—and not just for child development. In fact, a similar method was developed by the “father of the Japanese industrial revolution,” founder of Toyota Industries, Sakichi Toyoda. Called the “5 Whys,” the method is an iterative question-asking technique used to determine the source of complex problems.
That the method is so simple a two year old could explain it is actually part of the appeal. When faced with a challenge, the investigator simply acknowledges the problem and then asks “why” five times. The result is a more nuanced understanding of the ultimate source of major problems.
In the context of testing, you can use the 5 Whys in two obvious ways. First, the method can help understand inefficiencies in testing and optimization processes. An example might look something like this:
The latest test busted after QA and launch.
- Why? Page selectors used by the code were changed.
- Why? A recent code push altered the page architecture.
- Why? IT wasn’t aware a test was running on the page.
- Why? The testing queue and development queue are not integrated.
- Why? Owners of testing (marketing) don’t communicate regularly with IT.
In this example, a frustrating bust reveals much more than improperly targeted test code—it shows that a lack of organizational communication and alignment has created a significant hurdle to executing tests.
The 5 Whys can also be useful for test ideation—especially when trying to understand confusing user behavior. An example of the method in this context looks like this:
New users bounce at a much higher rate than returning users.
- Why? New users aren’t motivated to take action.
- Why? They don’t have a clear understanding of the value proposition.
- Why? Little space above the fold is available.
- Why? Most of the section is devoted to a signup form.
- Why? Encouraging signups is a company priority.
In this case, the 5 Whys don’t deliver a clear answer. However, the process does uncover a potential reason for the user behavior and hints at a solution—moving the signup form down the page and using the space above the fold to increase motivation. It also reveals a potential organizational problem: The emphasis of company goals may be hurting page performance by diminishing the user experience. Test variations could easily be created at this point, or you could ask additional “why” questions to explore the issue more deeply.
Such a simple method, of course, can’t be perfect. If you’re using the 5 Whys as a problem-solving tool, it’s important to be aware of a few key criticisms. When using the 5 Whys, there’s a tendency to focus on superficial symptoms and not root causes. Take time to think carefully about each “why” in your list. There’s also a tendency for the investigator to be limited by current knowledge or biases. This can be avoided by comparing multiple lists from different people or working through the 5 Whys as a group.
When it comes to address big challenges, it helps to have a tool that can guide the process and offer direction. Though simple, the 5 Whys is a quick way to breakdown a confounding problem. It’s similar to the trick toddlers use to learn about the world around them—and it can help you gain a better understanding of the world of testing, too.