18. Learning about problems that will threaten value to customers certainly requires scrutiny from the builder/insiders' perspective. The code shouldn't be inconsistent with builders' intentions. And among themselves, the builders can be pretty good at spotting such problems. /19
19. But to be really good at spotting problems that threaten customer value requires builders' savvy PLUS a significant degree of estrangement from the builders' set and setting, and requires immersion in the consumer/outsiders' form of life. And there's a problem here. /20
20. The problem here is that, with a few exceptions, *deep* immersion in the user/consumter/outsider form of life isn't easy to come by for most testers. Some testers have come from the product's intended domain; that can help a ton. Others study the domain deeply; also good. /21
21. Trouble is, not a lot of testers can get management support for estranging themselves somewhat from the building (both the activity and the physical workspace!) to immerse themselves in the customers' world. That immersion is how really deep learning happens, though. /22
22. I often see and hear test strategies that focus on building and automated checking. I rarely observe test strategies that address the need for deep learning about the customer domain. It seems to me that managers and testers alike could require that of each other more. /23
23. Acquiring significant expertise in the customers' domain can be time-consuming or expensive with uncertain payoffs. When the payoff occurs, it's hard to notice, because problems discovered through testing, and then fixed don't turn into big production disasters. /24
• • •
Missing some Tweet in this thread? You can try to
force a refresh
