Asking the right questions

Recently, I was informed by my manager to ask the right questions when in a meeting. I know this may sound weird to ask but what does it mean to ask the right questions when in a meeting? Are there any templates or questions to ask during a weekly meeting when working on a project?


Some of the ways I’ve arrived at the ‘right questions’:

  • When I join a project, comparing the existing product screen by screen to the new designs. This usually leads to a lot of questions about requirements, parity, and testability (is that a word?)
  • Have a note or doc set up for the project, and whenever I am confused about anything, I write it down in there so I have it ready to bring up in the next meeting. Not everything ends up being a question, or I might develop a question over the days leading up to a meeting.
  • “What do we need in place to test this?” is a question I ask a lot, so we can think through necessary resources and factor preparing for testing into our timeline.

I hope this was helpful! Curious to see other answers.


Hi Tammy,

This is a really important question already. :slight_smile: One that too little testers ask themselves enough, in my experience.

I saw a post on linkedin earlier about why testers weren’t invited to meetings and this is a big reason why. I’ve been in product owner roles or engineering manager roles where the wrong questions were derailing at worst and annoying at best.

So how do you ask the right questions?
Content: consider the goals of the people in that meeting, what they find important, value and fear. A product owner typically wants to get good-enough features to their customers as fast as possible. A developer wants that too, but doesn’t want to cut too many corners, doesn’t want to look bad and overwork for something that eventually doesn’t add value. Learn about their ways, their concerns and their hopes & fears.
→ Figure out what people’s agenda’s are and help facilitate discussions around the continuum of fast vs. stable or experiments vs. more analysis,…
Your voice: With good arguments, you can sway perceptions one way or another. You have the best knowledge about “What can de application actually do right now”. That’s your contribution. Don’t meddle too much in what it should do or has done, but inform on what it does now and what risks could manifest if a change would be brought.
Delivery: Think about who is listening to you and communicate to their level and vantage point. I’ve been so frustrated talking with developers or subject matter experts who parrot some exotic terms or acronyms. Learn how to tailor your message to the people in front of you. Being ununderstandable doesn’t make one look smarter.
Shift your focus: If you’re like most testers, you’re taught to speak about bugs and tests. Nobody really cares about those. Talk about goals, fears and by extension: value and risks. Do Risk Analysis together with the team (plugging RiskStorming here) to figure out what’s actually important. It’ll help, believe me.

Hope this helps!


Great answer. There isn’t much to add there.

I also would recommend sometimes keeping quiet and listening, learning, and studying.
Show your value, and deep understanding of things, outside those meetings in casual one-to-one conversations with people.


Ideally there should be no questions for you to ask if the project is running as it should, be I appreciate that this will not normally be the case.

Make sure, if you have time of course, that you familiarize yourself with the background to the meeting, so that you can arrive with any questions that you need an answer to, to help you achieve your objective.

Think about the context of the meeting too, i.e. the questions that you will ask at a Sprint kick-off will be different to the ones thart you will be asking at a Sprint retro.

In terms of asking the right questions never ask a question that you are able to find the answer to yourself, else you will lose the respect of your team.

The flip side is that there is no harm in phrasing a question that you know the answer to, but want the whole team to be exposed to scenario, so it is on their radars too and not just floating around within the test team.

In my old workplace, I was told by the tech lead that I could ask 3 silly questions before I would be refused an answer going forward!


If you haven’t already, it could be worth asking your manager what they mean by the right questions.

Beren’s answer is fantastic though


I use questioning banks (set of possible questions) as per my context to ask questions.

The important part is to know that it’s not important to ask every question in the bank. Some questions might be obvious to you and there is no point in asking them.

So, without much talking, here are my question banks:

software-testing-mindmaps/First day in a new project.png at main · dimensi0nless/software-testing-mindmaps · GitHub

Context-Free Questions for Testing – DevelopSense

Context-Free Questions for Automation - Rahul’s Testing Titbits

This topic matches well with the scenarios I saw this weekend in the True Detective TV series lastest season.
There’s a lead detective there who’s trying to teach the others to think, think better, critically, and think as if you’re leading into something interesting, new.

So there are many: You’re asking the wrong question, Ask again, That’s not the question, Ask the question, …

I found it fascinating and it’s a way I see testing as well.

1 Like

I don’t have a bank of questions as such, but I like to at least prepare 20 minutes before a meeting and do as much reading as required and take notes on areas to validate. Then whilst listening to the meeting, if those notes are not “answered” during the general discourse, I would then ask them and be content if the answer is provided at a later date.

1 Like