In the process of writing up the Deep Bruise Heuristic I realized there was another lesson in there as well.

Other testers (or players) are not you.

Just because you would have done something some way does not mean that they someone else would do so as well. I would have cleared the crowd to find a shot or pass had I been the one fighting for the ball, but that is because I cannot shoot backward or underhand. He could which, unfortunately for me.

When I talk about tricks and hard-won realizations to new testers, one of the things I stress is that you are not like the customers / end-users of the system so any ‘pretend to be the customer’ stuff is not much use. As testers, we know the existing system (usually). We know the goal of the product. We know what it is supposed to do. We know all the hacks and shortcuts we needed to use in order to work around problems or incomplete features. We know X. We know Y. We know Z. The customer does not. (Or usually does not to avoid and absolute statement)

When I talk about structuring a test team, a large part of what I advocate is for a diverse team to compensate for everyone’s biases and blind spots which is essentially this idea. Not diversity for diversity sake, but when it makes sense. This makes sure that testers are not all like you.

Both these things have a root in uniqueness and the danger of equating yourself as the same as someone else. Take a step back from a problem and double-check your surroundings if you find yourself thinking someone would have tested something because it is something you would have tested. For instance, I have thought a lot about how to test i18n in a web application and have presented at a conference before on that thinking so I like to think I know what I am doing. If someone says they have tested i18n to me I need to make sure I don’t automatically assign a level of testing that I would have done. I need to ask clarifying questions to come to the proper understanding of the situation.