Testers naturally love the challenge of breaking down a system to uncover the secrets it may hide. We do so by learning to use a great variety of tools that enable us to build models, to exploit behaviours, and to describe whatever intended and unintended behaviours we might discover. All of this is performed in order to help others make timely and informed decisions about the product. We are partners with all members of software development teams. We work together, solving great riddles and building evolving solutions to some of life's newest and greatest challenges.

So why do we so often find ourselves at testing conferences complaining about not being understood? We gather together and describe our struggles:

• How do we report accurately on exploratory testing efforts?
• Why does it seem so hard at times to get clear direction on where we should focus our time?
• Why must we spend so much time proving that we are performing valuable work?
• How do I answer that magic question: “When will testing be done?”

It certainly would be helpful to just have a “tester translator” available on every team to help us with these communication problems, but this seems unlikely. Perhaps it is time for us to look at this from the perspective of a tester exploring a system. How do we begin using our skills and tools to discover dependable heuristics on how to better communicate with our teammates?

Paul and Martin offer some interesting (and contrasting) approaches that might provide some clues on how to use some of your existing testing skills and talents to help solve this riddle within your own teams.