Looking for Trouble

Mostly a placeholder

I don't like working, as a tester, for organisations that are a step away from asking me to hide uncomfortable truths.

Are you looking for trouble? Does your organisation look for trouble?

If you're not looking for trouble, you're asking for trouble.

---

What does looking for trouble look like?

It looks like learning. It looks like acceptance. It looks like curiosity. It looks like being able to say "not ready, yet". It looks like earned pride and justified confidence. It looks like an active bug log. It looks like being practiced in the face of disaster. It looks like a budget for looking for trouble. It looks like reducing the "cost of failure".

What does not looking for trouble look like?

It looks like fixed test sets. It looks like crossing your fingers and hitting the deadline. It looks like contracts that say "no negative testing", or "payment at 0 bugs". It looks like unshared bug lists, and private triage. It looks like firefighting. It looks like reducing the "cost of testing".

---

I hear people say things along the lines of "We invest in avoiding trouble", as if looking for trouble is perhaps an admission of failure, or as if there's one budget pot and the more you set aside to look for trouble later, the less you can spend on avoiding it in the first place. I write "as if", as if those situations are neither true not tenable – but both can be true, and both can seem unarguably natural.

Looking for trouble is indeed an admission of failure – and not looking for trouble reveals an assumption of infallibility. Evidence for infallibility comes from studying failure – not from making every effort not to fail. I'm wary pf people who tout infallibility because they fear failure.

Sometimes there is indeed a "quality" budget, which has to be balanced between finding trouble before it's committed to a product, and catching trouble when it's been made into some deliverable that needs fixing. But that's a category error: There's a budget to make something, and then there is negotiating about where it gets spent. If there's a "Quality Budget", then "Quality" is a proxy for someone's fiefdom. Are they responsible for "Quality"? Maybe – and that reveals that several other people see themselves as not responsible. I'm wary of teams who place the responsibility for quality on one person's shoulders.

A specific budget to look for trouble? Where spending the resource properly involves asking the question: "What's the best way to spend this on looking for trouble?". Where process improvement means looking for trouble more efficiently and effectively? You can budget for that – even if sometimes that budget gets slurped in to the all-hungering urge for simple confirmation. Do it if you can.

---

As a project's 'test strategist', I've sat with more than one Head of Quality «something», to hear that their bailiwick "doesn't really cover the software". Assurance has assured me that their requirements engineering process is sophisticated enough that only confirmatory verification and validation are needed. We can get caught up in questions around what, exactly, is an engineer in our always-novel world of invention. Or we can just stop.

---

Different sources specify verification and validation in different ways. One consistent pattern is the idea of correctness, rightness.

I'm wary of this combination of similar words, as I'm wary of the trite comparison: Build the Right Thing vs Build the Thing Right. The obvious reason is that I'm confused: so many people and teams use these terms as if they're both opposite, and interchangeable. It's like scones: jam on top, or butter on top? Frankly, if sometimes it's mustard, who cares?

Many organisations build things with bad bits, and build some bits badly. We should look for those. Just looking for "right" might tell us about wrong, if we're lucky. Want to be lucky enough to spot the trouble? Look for trouble.

---

Organisations that actively look for trouble stand a better chance of reacting productively to surprises.

Organisations that don't look for trouble are a comfortable step away from hiding trouble that they find – particularly uncomfortable trouble.

---

When you use a system, do you hope that its makers looked for trouble before you scrambled into the hot seat?