To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
The technical storage or access that is used exclusively for statistical purposes.
The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Hey Michael, while it’s certainly not the tester’s job to build confidence in the product, I’ve done quite well in many contexts by focusing on providing information that helps reasonable stakeholders to determine how confident they should be in the product,.
Put somewhat differently, I hope that the information my team and I deliver leads to stakeholders having greater confidence that they understand the state of the product, be it good or ill. (Helping them become confident that our schedule is a pipe dream and the product needs a ground-up redesign is way better than them wondering and hoping without good information.)
Michael replies: I’d like to encourage testers to notice the profound difference between confidence in the product and confidence in our understanding of the product. These are completely different things.
At the same time, I’d like to suggest that the tester’s job is not to build confidence, but to preserve skepticism. Remember, skepticism is not the rejection of belief; it’s the rejection of certainty. It’s our job to remain professionally uncertain so that we—and others— are not fooled by our confidence.
Well said as always, Michael. I agree with your call to preserve our own and others’ skepticism. I just find it’s that it’s complimented by understanding (especially in contexts like on-device software with very long lead times and where change is very expensive if not anticipated early) that some of our key stakeholders have a legitimate need to make early decisions based on their confidence in their understanding of the product. (e.g. Do we believe in the schedule enough to place our ad spend now? Do we know enough about this project’s limitations to cancel it and focus on other strategies?)
In The Logic of Failure, Dietrich Dorner says “An individual’s reality model can be right or wrong, complete or incomplete. As a rule it will be both incomplete and wrong, and one would do well to keep that probability in mind. But this is easier said than done. People are most inclined to insist that they are right when they are wrong and when they are beset by uncertainty. (It even happens that people prefer their incorrect hypotheses to correct ones and will fight tooth and nail rather than abandon an idea that is demonstrably false.) The ability to admit ignorance or mistaken assumptions is indeed a sign of wisdom, and most individuals in the thick of complex situations are not, or not yet, wise. (p. 42)”
I add value as a voice of skepticism, helping folks realize that their model is wrong and incomplete. At the same time, I add value as a provider of the sort of (falible, imprecise) information that helps thoughtful leaders (yes, I’ve worked with some) revise their mental model to make it more complete and more correct. That supports them to make the best decisions they’re able to in those moments of uncertainty.
[…] Michael Bolton: It is not the job of testing to build confidence in the product. Confidence is a relationship between the product and some stakeholder. It is much more the job of testing to identify problems in the product—and in people’s perceptions of the product—that are based on or that would lead to unwarranted confidence. […]
[…] me encanta la visión de Michael Bolton sobre el testing y la confianza, la cual expresa en este blogpost, indicando que “ganar confianza en el software” no es el objetivo del […]