6 Tips for Software Testers on Asking Questions

Asking questions is an essential part of software testing. If we think of testing like James Bach does—that testing is the process of evaluating a product by learning about it through exploration and experimentation—then learning what others expect should be part of that exploration. Therefore, as a tester, it’s smart to learn how to ask questions well.

Here, I share six tips on asking questions to help you get answers that will guide your testing beyond the superficial.

1. Learn from Kids

Asking questions is important, but people are afraid of it. Why are we so reluctant to ask questions? Often, it’s due to one of two reasons:

• We are worried we’ll look stupid. When we ask questions, we are telling people we don’t know something. Asking a question can make you vulnerable.
• We believe we “should” know things. This is especially true of people who have more experience. We tend to assume things and say, “I’ve been a tester for twelve years. I should be able to figure this out by myself.”

Kids do the opposite. They don’t care what people think of them. They just ask questions without shame, and if your answer doesn’t satisfy their curiosities, they will keep asking until they get an answer they understand (or until you’re tired of answering them).

The result? Kids learn new things very quickly.

So, take a tip from children and don’t ignore problems when you are puzzled; ask until you understand. The first step in learning to ask questions is to be brave enough to ask at all.

2. Address the Root Problem

Once you are willing to ask, you need to ask the right question. Often the questions we think of are shallow and don’t explain the root cause—for example, “Do you know of a good test management tool?”

Ask this question and you might get an answer, but it will likely be an answer that the person you’re asking found solved their problems. You are trying to solve your problems.

Instead, figure out what you really want to get from an answer, and then ask questions.

3. Add More Context

Beyond the root cause, the context explains the classic journalism questions—who, what, when, where, why, and how.

So, instead of just asking about a good test management tool, add context by saying how long you have had the problem you’re trying to fix, what you’ve found in the background research you have already done, what you have tried so far and how it worked out, and what you will do with the answers.

A better-crafted inquiry would be:

My team of three is currently using Excel spreadsheets to manage test cases, and it works fine. However, my team will be growing to ten or more people and may be distributed, so I’m looking for a new test management tool.

I want a free, web-based tool that works with both Mac and Windows and can link test requirements and test cases.

I’ve tried Bugzilla, but I don’t have a server to install software on, and I need something easier and more user-friendly.

Can you give me some other suggestions?

This inquiry is much better because it gives the context around the questions. With this inquiry, you’ll be much more likely to get the kind of answer you want.

4. Ask Five Whys

Asking “Why?” five times is a popular root-cause analysis activity. It’s an iterative question-asking technique used to explore the cause-and-effect relationships underlying a problem.

Here’s an example:

The vehicle will not start. (The problem)

1. Why? The battery is dead.
2. Why? The alternator is not functioning.
3. Why? The alternator belt has broken.
4. Why? The alternator belt was well beyond its useful service life.
5. Why? The vehicle was not maintained according to the recommended service schedule.

Because you continued asking why, you finally got an answer that gives the root cause.

5. Ask a Rubber Duck

Hey, don’t laugh.

I’m talking about a debugging technique called rubber ducking, where a programmer who’s stuck on a problem will explain his code line by line to a rubber duck at his desk while he’s debugging the code.

Often, the programmer will find the answer to the problem himself when he takes the time to explain the issue aloud to an impartial, inanimate object.

Although it’s usually a programming technique, the idea is applicable in software testing as well. Of course, you can explain the problem to your peers to jumpstart your thinking instead, but asking the rubber duck keeps you from interrupting your coworkers—and it sounds more fun.

6. Stop and Think

Let’s say someone comes to you with a problem. Before jumping in to tackle it, make sure you understand fully what’s going on. Michael Bolton suggests four simple words to use in order to pause and engage your critical thinking: huh, really, and, and so?

Bolton defines what these “breather” words mean as:

• Wait … huh? Did I hear that properly? Does it mean what I think it means?
• Um … really? Does that match with my experience and understanding of the world as it is, or how it might be? What are some plausible alternative interpretations for what I’ve just heard or read? How might we be fooled by it?
• Just a sec … and? What additional information might be missing? What other meanings could I infer?
• OK … so? What are some consequences or ramifications of those interpretations? What might follow? What do we do—or say, or ask—next?

When you take a second to pause and say huh, really, and, or so, communication flows more easily and you can gather your thoughts before trying to arrive at a solution.

Final Thoughts

Former football player, coach, and analyst Lou Holtz said, “I never learn anything talking. I only learn things when I ask questions.”

Asking questions plays an important role in our daily work as software testers. It isn’t easy—actually, it may be one of the most difficult skills to master—but it’s worth the effort because the more you ask, the more you learn.

Spend time practicing asking good questions. It will help you become a better tester.