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.
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:
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.
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.