Thread by @michaelbolton

1) Why have testers? Because in some contexts, in order to see certain problems, we need a perspective different from that of the builders—but we also need a perspective different from that of users. First, some people are neither builders nor users. Some are ops or support folk.

2) Others are trainers or documentors. Some people are affected by users, or manage users, but are not themselves users. Some are users, but forgotten users.

Another reason it might be important to have testers: everyone mentioned so far is focused mostly on *success*.

3) A key attribute of the skilled and dedicated tester is a focus on risk, problems, bugs, and the possibility of failure. Most builders can do that to a significant and valuable degree, but the mental gear shifting isn’t automatic; it requires skillful use of the mental clutch.

4) You *know* this. You know how easy it is for someone else to see things—good and bad—about your work that you haven’t noticed. And if you’ve worked with a group of creators, you know how easy it is for that certain one of you to think radically differently from the rest.

5) Being a dedicated tester inside a development group is sometimes hard. There’s a tension between near social distance (we ARE all on the same team) and farther social distance (we need diversity, which by definition requires some degree of distance and valuable differences).

6) To be a good tester requires critical proximity to the builders (technical skill can be super valuable) but also critical distance (our customers do not necessarily have the same kinds or degrees or domains of technical skill). Meanwhile...

7) To be an excellent tester in another sense requires proximity to the clients and customers—and not just the utterance or claim “I speak for the customer”. Developers often have more customer domain savvy than testers do. Testers must seriously strive to cultivate that too.

8) Sometimes that’s hard. Sometimes management isn’t supportive of testers immersing themselves in the world of the customer. Sometimes management, passively or actively, erects or maintains obstacles to testers connecting with the customers’ world. So we need determination.

9) The designers and developers and managers AND customers are mostly envisioning success. They enact the essential, fundamentally optimistic task of solving problems for people, which requires believing that those problems can be solved, and building those solutions.

10) Developers act as agents between the world of humans and the world of machines. This is wonderful.

Here’s the socially hard part for serious testers: we must focus on acting as agents between the world of technological solutions and the world of *skepticism* and *doubt*.

11) Skepticism is not the rejection of belief; it’s the rejection of certainty about belief. It is our job as testers to remain professionally and responsibly uncertain that there are no problems, even when everyone around us is sure there are no problems.

12) It is our job as testers to remember that when the magical AI can classify things at high degree of accuracy, there remains some degree of inaccuracy—and that inaccuracy can have real consequences for real people. People whom we haven’t met; who may not look or sound like us.

13) It is our job as testers to remember that “the user” or “the customer” is a *monumental* abstraction. There are users, and customers, and others affected by software who neither but nor use it. All of those are individuals, with needs and desires and obligations to others.

14) It is our job as testers to remember that intentions and desires of builders are significant and important. And that that’s not all there is to it. Misinterpretations and errors can elude even the smartest people, and the most diligent and disciplined development processes.

15) It’s our job as testers to note that it’s okay to be checking the build for errors, but on a disciplined team, checking the build must be a primary responsibility of builders. We can help with that, but doing so comes with opportunity cost: less time for testing deeply.

16) Of course, maybe our products are low risk. Maybe our product doesn’t have serious consequences; doesn’t affect money, human health and safety, the environment, or social relationships. Maybe our product can’t mislead or fool or rip off anyone, intentionally or accidentally.

17) But if there’s a risk that it can, maybe we need to develop the skills to do that well. Maybe, even though all can develop those skills to some degree, we need people who professionally inhabit a disciplined, critical mindset, like Ignaz Semmelweis, Ivan Illich, Socrates.

18) Maybe we need people who study, in depth and detail, how we can fool ourselves, as individuals and groups. Maybe we need people who examine, experience, explore, and experiment with the product from that perspective, on social, technical, and domain levels as a speciality.

19) Why as a speciality? Because when something is not someone’s focus, it will not be someone’s core competence. It will not be someone’s responsibility. It will not be someone’s focused commitment. It will not be someone’s aspiration. It will be a part-time job; a side hustle.

20) There’s an important message here for testers. Our role is suffering from benign neglect from some quarters; from active attack from others. We can’t rest on our laurels here. For one thing, in many places, we’re not necessarily earning many laurels to rest upon.

21) It’s good to be helpful to the team by checking for problems that are near the surface, near the coal face. It’s good to develop technical skills to help with that. But we must also alert our teams to the fact that deeper, subtler, worse problems won’t all yield to that.

22) To find those deeper problems means challenging the product with complex testing: investigating for problems, not just confirming that everything seems okay. It requires effort, determination, and negotiation; deepening our skills, our craft, and our testing.

—fin—