Low-Tech Tools for the Thinking Tester

the first rules I tell them is “when in doubt, ask someone.” This involves getting up from your chair and physically walking over to the person who can help you solve the problem facing you. Using the sneakers on your feet to get answers in person can greatly reduce the amount of time required to understand something by avoiding the broken telephone game often played through email or some other electronic system.

When we test, we navigate a sea of doubt. Other team members are the beacons and buoys that help us find the correct path for the journey. Certainty is the fool’s path and there is much for us to be unsure of in any given project.

Some examples of opportunities to seek clarity from other team members include:

• You are uncertain as to how a feature or story should work from the customer’s perspective.
• You are uncertain as to what the expected system behavior should be while testing. Sometimes there may be competing ideas of what the “right” behavior should be, so ask someone before you jump to conclusions and report a bug.
• You need help with a blocking issue that is preventing testing. For example, you might need to access a new report in a system and when you do so, you might discover that the designated users don’t have the security permissions to view it. If you have a short amount of time to test a particular feature, find someone to help you get up and running as quickly as possible.

To be respectful of the other person’s time (i.e. the person you wish to speak with), I recommend the following before travelling through Sneakernet:

• When possible, repeat the observed problem before you ask someone for help. If you can’t reproduce a problem, is it still worth interrupting someone else about it?
• Check oracles: Check references (such as requirements and specifications), logs (e.g. additional information to support your observations), and comparable functionality (within the system or from competitive products). You may also want to ask a team member near you first. Sometimes the answer is nearer than you think.
• Consider alternatives: Use the Rule of Three to think of at least three possible causes or explanations for the unexpected system behavior or problem facing you.
• Bring data: Collect whatever information you need to help explain the problem to the person you are interrupting.

In distributed teams, where Sneakernet is impractical or inefficient, I choose tools that allow for the most human interaction first. My first runner-up choice is to use a telephone (or Skype or similar application) to contact someone for help. If that doesn’t work, I will then try an instant messaging program of some sort. Good communication involves more than just words and we pick up more of the underlying meaning and context when we see and hear someone speak. For this reason, email is almost never an option for me, unless it is to schedule a meeting to discuss the problem in person.

The amount of time saved by focusing on direct human interaction and verbal communication is tremendous; time saved is money saved. I have seen failed communications and misunderstandings between development team members that have gone on for days and weeks through tools like email and bug tracking systems. I can’t begin to estimate the impact to the project and costs when things like this happen.

I am OK with using email or creating bug reports after a conversation has taken place to summarize the key points we’ve already discussed. However, as with test plans, you should never bury important, timely