The health-care industry has a story they like to tell, it’s called the River Story and involves a group of rescuers working very diligently to help save all the people drowning in the river. Since the flow of drowning people is continuous, the rescuers have to work throughout days and nights to keep up.

The hero of the story starts out looking like a jerk. Instead of helping save the poor drowning souls, he steps away from the river and puts on his shoes.

The other rescuers confront our hero, asking why he doesn’t want to save these people. He says, “I am. I’m going upstream to find out why these people are falling into the river.”

Going upstream to prevent problems

The story is about going upstream to prevent problems. So instead of focusing solely on the people already drowning, going upstream means exploring the root cause to prevent them from falling in the river in the first place.

What are some of the ways that a QA/QE organization can help prevent problems?

The testers on the team usually have a ton of product and domain knowledge, which can be very helpful in preventing problems before they arise. When designing tests, they always try to think like a customer while simultaneously approaching the product with the attitude of  “how can I break this?” It’s in their nature.

I can’t count how many times a tester in a design review found issues well before any code was written. Testers are critical thinkers and often ask, “have you considered this?” or “what happens if that occurs?”. Wouldn’t it be wonderful if they ask the right questions before the code is created, so the subsequent code can be more fault-tolerant?

Testers usually develop a systematic view of the software. They see how the whole system works. Individual developers are usually deep experts in their field and can often benefit by talking with someone who has a wider perspective. Testers are therefore an excellent resource for developers to bounce ideas off of and see how the components all fit together.  

Finding a problem before the code is even written is much more effective than finding that problem after the developers have invested considerable time writing said code.

Customer research generally happens early in the life-cycle of a product or feature. Having testers participate in customer research has multiple benefits, better research and better testing. The testers bring their critical thinking and domain knowledge to the customer research team, which may result in additional insights. Also, when testers are involved upfront, they gain a deeper affinity for the customer’s point of view, which translates into better testing.  

Finding a problem as soon as it’s created, helps get it fixed efficiently. You are much more likely to know immediately the change that introduced the issue and the developer who caused it. Also, the problematic code is still fresh in the mind of the developer. These factors lead up to a more efficient way to find/fix problems. This early problem detection and shorter feedback cycle are one of the principle benefits of Agile development and testing.

Involving testers early sounds great, but where can we find the time?

Too often they are busy testing the current release and don’t have a lot of time to dedicate to design reviews or early testing. In the worst case, they are spending a lot of time testing hot-fixes in production (the equivalent of saving the people downstream).

One approach would be to start small. Spending just 1 hour in a design review may save several hours later, during the testing cycle. That way you’re able to use the hours saved to participate in more reviews and conduct early testing. After several of these virtuous cycles, you should start seeing the benefits.

Another approach would be to get additional help with the testing process, thus freeing up the time of your expert testers to prevent future problems. This approach might actually help you see benefits faster than the incremental approach.