Thread by @michaelbolton

1) We should be noticing a problem with the "just get the developers to test" idea. Why not ask developers to do HR, too? Accounting?

Because developers want to build things, solve problems. They're not *so* much into finding problems, neither in their own stuff nor in others'.

2) Most people are like developers in this sense: they tend to envision happy outcomes—and social groups tend to reinforce this, discounting potential problems. "Positive asymmetry" described in Karen Cerulo's /Never Saw It Coming/. (Off to the bookstore!)

3) This is NOT to say that developers can't test; developers can be excellent testers. Like everyone else, though, there are a couple of vulnerabilities that need to be managed. The first is that we are ALL highly imperfect at seeing weaknesses in our own stuff.

4) A second vulnerability is that programmers, when testing, are really good at finding problems important to programmers, since that's their domain and their skill set. That is, with their expertise, they're in an excellent position to find programming problems.

5) Still, most of the time, most programmers don't have *contributory* expertise in the domain for which they're writing programs, even though they might have strong interactional expertise; and, like everyone else, strong ubiquitous expertise (see Collins, Rethinking Expertise).

6) Programming expertise greatly helps testing close to the code, focused on functional correctness, program architecture, etc. Deep, naturalistic, investigative, domain-centered, user-focused, testing benefits from being situated full-time outside of the programmer's mindset.

7) Yes, yes; everybody on the team should test. Yes, yes, it's everyone's responsibility. But expertise in testing benefits from focus on and deep study of testing; just as expertise in accounting and HR benefits from focus on and study of those.

8) Trouble is: testers who study testing deeply are almost (albeit not quite) as rare as programmers who study testing deeply. And positive asymmetry provides a powerful social obstacle towards focusing on risk, problems, and trouble, making testing a socially awkward craft.

9) The obstacle is not insurmountable, but it should be recognized as part of the social landscape of testing and development. Focusing on problems tends to harsh people's buzz. Yet that focus on problems and risk is essential if we want to discover problems before users do.

10) Do you disagree? That’s OK; we can talk about it. But first, you might want to pause and ask if you’re vulnerable to positive asymmetry.