20) If you present testing as a complex, cognitive, *social*, *self-directed*, *engineering*, *problem-solving* task, I guarantee more programmers will happily throw themselves into it. And, if you have testers, MORE TESTERS WILL TOO. So what is the problem to be solved here?
21) One big problem is: we have a new, complex, technological product that we intend to help solve a problem; and that we may not understand the problem or our solution as well as we'd like; and whatever we don't know about the all that could bite our customers and could bite us.
22) Finding problems that matter in that product is greatly aided by access to rich models of the product itself; of customers, how they use it, and what they value; of who else might be affected (support, ops, sales...); of coverage; of recognizing possible trouble; and of risk.
23) If you want programmers to enagage with testing, connect them with the experiemental aspects of it; the investigative aspects; the productive discontent and complaining that triggers innovation. Ask them to build analytical tools that afford visibility and controllability.
24) Remind them that if testing is boring, that's a Severity 1 danger sign; excellent testing isn't boring. It's all about the thrill of the chase! We're looking for really cool bugs before they get away from us and cause us more oh-no-not-this-again work later on! Or...if not...
• • •
Missing some Tweet in this thread? You can try to
force a refresh
