During a recent This Week in Testing, @alg shared that he’d been “doing the rounds” as part of his new job. to help formulate a test approach. He’d meet with various stakeholders to get a sense of the existing business processes.
I enjoyed reflecting that through this process, Al could give a sense of hope and belief in the role of testing by asking questions and oozing passion for testing.
I’m curious to know what questions you typically ask when you join a company and aim to get up to speed with existing business processes and the product.
@leigh.rathbone made a good point: Every company is unique so it’s not possible to rinse and repeat the same set of questions when moving from one company to another.
I think this is a good opportunity to help each other by sharing some of the typical questions you ask to help formulate a test approach.
I believe that as you start working in the company, you will have tasks and goals to accomplish. You may have questions that arise naturally while you work, possibly as a result of some mistakes. And yeah that’s true:
Every company is unique so it’s not possible to rinse and repeat the same set of questions when moving from one company to another.
Frankly speaking, I can’t recommend any general approach or set of questions because it heavily depends on many things As I mentioned, you will acquire general knowledge during onboarding and gradually absorb more specific information as you delve deeper into your tasks and everyday activities. In the beginning, I usually ask general questions, like “Tell me about the existing business processes”, etc
Each workplace is different. I usually ask for documents, and if the company does not have any documents related to it and if they don’t have it, they typically assign someone who knows the system; I go around, collect the information, and compile it into a document.
For me the approach I took was conversational and talking about scenarios, ways of working etc that the various departments have encountered and undertake.
Yes starting with, what are your processes comes into it. I use that as a jump off to understand what’s come up that’s caused a problem or interesting scenarios that crop up from time to time.
Absolutely there is no one size fits all, without becoming super generic and for me loosing that connection. I moved from one highly specialised sector (Workforce Management) to another (Banking) and yeah it’s not the same and the drivers are different.
“Walk me through the way of a requirement!” would be my first question, assuming that there wouldn’t be much of a written documentation (as usual).
I like how answers lend themselves to a strategy document with the same headings. There might be duplicates in some replies yet it allows folks to come at the information from various angles if perhaps it didn’t land the first time round.
Example questions — in no particular order:
(at the end of a convo) What’s a question you think I should’ve asked but didn’t?
When does that typically happen?
When does this need to happen?
Who should I speak to next?
Where could I get more information about that?
Who is responsible for this process?
Who has the most influence to change/support this process?
What happens if …?
Where does the information flow into this process and where does it flow out?
Why does that happen?
How does this process typically get blocked?
What’s the best way for me to learn more about this process?
A note on “why”. For some folks/situations, asking “why” may seem too direct and critical so I’ve found it helpful to tread carefully. In some cases, I reframe my “why” question and use “How come this …?” or “So I can understand this correctly, what are the reasons for …?”
I like those first two in particular. My current employer does digital transformation for clients, so when I work on a project I’m not going to be supporting the product through its whole life-cycle, but I can still get very good and relevant insights at the beginning of a project from those questions.