6 Tips for Software Testers on Asking Questions


Asking questions plays an important role in software testing. 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. Here are six tips on asking questions to help you get answers that will guide your testing beyond the superficial.

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.

User Comments

Thanh Huynh's picture

@Laszlo, Thank you!

Feel free to add more techniques or ideas to ask good questions.

November 25, 2015 - 12:26am
Ondřej Růžička's picture

Nice summary, thanks for this article, this is fully true !

November 25, 2015 - 1:04am
Tim Thompson's picture

Adding context is something I think is very important, but it is also the one thing that I constantly get dinged for in reviews. Management wants a staccato style bullet pointed communication and that ideally in person and not via email or bug tracker. Quite frustrating when the core issue in resolving issues is not enough context in the end.

I ask dozens of questions each day and if they are what I consider to be significant decisions or changes I ask the BA to include this in his docs.

November 26, 2015 - 1:07pm
Thanh Huynh's picture

Hi Tim,

Yes, yes I hear you. Management always want more with less :D and I hope they know how to ask good questions too.

One important point when reporting the problem ( or any other kind of reporting) is to understand who the reader or audience is. When you know who is your reader, you will find what kind of context or information he/she wants. For example:

* When you report the bug in Bug Tracking System, more often your reader is your developers. So you need to make sure the following contexts ar added such as tested environment, exact steps, log files, screenshot, pre-condition, etc so that developers can understand, reproduce and fix the problem.

* On the other hands, when you reports problem to management, I suggested to focus on summary of the problems, what severity of the problems is and the risks if these problems do not get fixed.

Hope it helps


November 26, 2015 - 10:10pm
Gerd Wiggen's picture

I love this article and summary. 

November 27, 2015 - 7:03am
hgamerow's picture

Great article - what made you decide to write it?  :-) 

Seriously, though, the art of asking questions - of engaging with our partners and the context - transcends roles on a software team. As a BA, I found myself substituting "business analyst" for "tester," and the substitution worked perfectly. We all face the need to go deeper sometimes, and the Huyhn methodology is a great way to go.

Thanks for a fun, engaging, and helpful article.

December 31, 2015 - 12:04pm
Thanh Huynh's picture


Thank you for your compliments!

What made me decide to write this post? Actually, I've myself recently realized that how important asking questions to testers and how often we under-estimate the value of asking questions. Of course, I'm not the one who coins these asking question techniques. What I did in the post was just collecting them and reminding us again how important and valueable these techniques are.

Thanks again!

January 3, 2016 - 3:30am
Steven Knopf's picture

Perhaps one more technique; not only have the courage to ask "stupid" questions, but also perhaps supply some of your own stupid answers.

As Polonius says in Hamlet Act II scene i:

"Your bait of falsehood takes this carp of truth."

In other words, if you talk rubbish people usually cannot resist helping / correcting you - providing a treasure trove of information in the process.


March 19, 2016 - 8:58am

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.