To Avoid Trouble Successfully, We Must Look For It

Software testing can be socially difficult because of people’s natural desire to avoid trouble. This prompts them to avoid thinking about trouble, which means that they don’t look for it. But if you don’t try to find the trouble that’s in your product, that trouble will eventually find you.

Some might say we do think about trouble, and we try to avoid it by getting clear on our intentions in design work, and by checking our work as we go. Those are fine things to do, but they come with their own problems. In design and planning, we are often unaware of problems that may emerge as we combine elements in a system. Developers are rationally and justifiably resistant to slowing down the pace of their work. Even when we do our best, some problems will elude us.

So when value is at risk, when risk is significant, and when that risk can manifest as real problems that hurt people, deep testing done efficiently is a responsible thing to do—and not doing it means we did not do our best.

A correspondent on LinkedIn, Aaron Emery, asks:

How do you suggest dealing with management that want to ‘shoot the messenger’ in instances like these?

It depends on the management, the message, and the messenger.

Some social awkwardness can come from the message itself and the way it’s framed. “This feature sucks” is probably not as easily digestible as “this behaviour in the product is inconsistent with this requirement noted in the spec” or “…inconsistent with this other part of the product” or “…with what we’ve seen in previous versions of this product” or “…with reasonable desires of this until-now-forgotten user”. Point out the inconsistency dispassionately, and let the receiver of the message come to his or her own feelings about it. In other words: know your oracles.

Another approach is to point out that the message, although momentarily bad news, is offered in order to help make everyone look their best. “Yes; fixing this might take some work, but at least we won’t be inflicting it on customers” — or even “Yes, even though we’re not going to fix this, at least tech support will be prepared for it and can offer a workaround.”

It’s critical for testers to know that the product doesn’t have to look or behave the way we want it to. We don’t design the product, we don’t code it, we don’t sell it, and we don’t run the business. We’re trying to help our testing clients understand the product they’ve got, so that they can decide whether it’s the product they want. So if the client hears us and understands the nature of the product but doesn’t want to fix it, that’s fine—and that’s not shooting the messenger, either. That’s business.

If management says “why are you only telling us about this NOW?”, the reply is “because I only found out about it now. It’s a pity our planning and our coding discipline didn’t prevent this problem, but at least now we can fix it while there’s still time, or learn from this experience.”

If management is truly reckless and wants to suppress awareness of problems, driving the school bus blindfolded, then they probably don’t want your services as a tester. That’s okay too; testing is always optional — and so is your choice of testing clients. You might want to avoid that company’s products in the future, though.