Starting or moving to different testing projects can be overwhelming. Usually, there is a lot of information to grasp as quickly as you can. Maybe the team is new, the stakeholders are different, and there might be a lot of specification files to read thoroughly.

Since I started my testing career, I have worked on various projects. I’ve joined some of them in their early stages, while others only later. Every new (at least new for me) project started the same way: a lot of meetings with different people from the project loading my brain with too much data. 

Were these meetings necessary and useful? Yes!

I find it essential to learn not only about the specifications but anything and everything other team members might know. If our purpose as testers is to “provide stakeholders [with] information about the quality of the product or service under test” (Cem Kaner, BBST® Foundations, Lecture 2) then I need to learn everything I possibly can about what might lower the quality of it.

How do I know what information to look for?

I learned this over the years. With each project, my list of questions has gotten longer and longer, and probably as I move from project to project, it will keep growing and possibly changing. This is why I will call the list I’ve gathered so far “version 1”.

Remember: This list has a guiding purpose. Not all of the questions will be suited for each context, and some contexts will need extra questions that are not on the list.

I grouped the questions into different topics. They are ordered from my subjective point of view. The actual order in which I would ask these will always depend on the availability of the people I will approach, and probably while learning more about the product under test I would change the priority of some of them.

Let’s dive into the pool of questions!

The product itself

• What is this product about?
• What is the purpose of it?
• What’s the history behind it? What is the company’s history or the team’s history?

In some cases, learning about the history of the product was indeed helpful. On one of my past projects, in an informal discussion with somebody from the design team, I found out that the current application I was testing was in fact a redesigned version of a very old, deprecated application. The new app was in development for some time already so no one was talking about the old one anymore. However, some legacy features were not matching quite well with the new app. They were creating a lot of confusion. But knowing where they were coming from, and where to go to understand their purpose was extremely helpful!

The team

• Who are my new teammates?
  • What roles do they have?
• What are the team’s needs and expectations?
• What is the workflow? How is the team organizing their tasks, deployments, and releases?
• What kind of meetings do they have?
• What challenges are they facing?
• Who has the domain knowledge?
• Who do I contact in case of what type of problem?
• Where do I report bugs?

Working processes are usually different from one project to another. Before shouting `This is not the way I’m doing things!` I give myself a few weeks/sprints in which I learn the team’s process or way of working. What I want to understand is the needs of my new team, what makes them efficient, and what information is helpful for them. Once I understand this, if some things are just not efficient for me, I will know how to raise this aspect and what solutions to search for that would fit everyone on the team.

Knowing who has the domain knowledge helped me on one of my projects where we were working on an accounting product. I’ve found it impossible to understand the entire product. Finding a person with domain knowledge willing to explain features and what to look for was essential.

The stakeholders

• Who are the stakeholders?
• What are the stakeholders’ needs?
• What are they expecting from you?
• To whom/where and when do I report my work? e.g.
  • Quick testing statuses;
  • Thorough testing documentation;
  • Overall testing statuses

At first, these might seem obvious questions. What can they expect? Testing, of course! 

I always managed to extract more than that. For me, the scope of these questions was to understand what kind of information they are expecting me to deliver, and what kind of bugs they are interested in. This will help me in defining the mission of testing, the information objective, and which are the most powerful testing techniques in this case. 

If the stakeholder/project manager/dev lead/whomever I’m discussing with seems to give too generic answers, I try to guide the discussion with some follow-up questions, like: 

• What are the main challenges of the project that we are facing right now?
• Do we have any feedback from users or other stakeholders?
• I understood from X that performance testing would be useful, what do you think?

The targeted users

• Who are the users?
• What kind of user is this product targeting?
• Do we have any demographics?
• What are the users’ needs that this product should fulfill?
• What are the technologies our users are using?
  • E.g. OSs, browsers, etc.

On my current project, we are working simultaneously on some applications that are targeting different communities.

Most of the users of one of our apps are coming with no technical background, so in this case, usability is quite important. 

Another app targets some specific communities where we learned that most of our users are using mobile devices most of the day. So for this application, compatibility testing is my primary focus.

The Budget

How many testing hours are included in the budget and where do I report these?

In case I’m allocated part-time to a project, then it’s helpful to understand how many hours per month I can spend on it. I track my hours during the month and if I notice I’m running out of their allocated budget I usually talk to the project manager or one of the stakeholders to prioritize my tasks for the remaining hours.

Claims and expectations

• What are the requirements and/or specifications?
  • Are these up to date?
• What is publicly claimed about this product?
• How is this product marketed?
• What are the claims made inside the company or team?
• What are the technologies used to build this app?
• Do we have or do we need a product terms dictionary?
• What are the future plans?
  • Do we have a roadmap?
  • Do we have a strategy or a plan?

Some projects already have this information documented, so usually, I start searching for them before going and asking someone. 

If there are undocumented things that I will later learn about, I will update or create new documents sharing the new info I have learned. There is no perfect project or perfect workflow. Maintaining documentation is time-consuming and often put aside. 

Having visibility and transparency in the projects I work on is a key aspect for me, and my heuristic is to give the same visibility and transparency I expect. Updating the documentation with the information I just learned is the first step for initiating a collaboration founded on these principles.

If you find these questions useful, you can download them for later here:

List of possible questions to ask on testing projects, v.1

What about testing?

My favorite technique to learn the new application I will work on is Testing Tours. I usually use the FCC CUTS VIDS mnemonic from M. Kelly and I organize my notes in a mindmap having a branch for each of the tours I take. In case I don’t have time to go through all the tours as other priorities come up, I will put my tour notes aside and continue whenever I will have time – even if it’s later in the project, there is always room to discover more about the product under test.

The purpose of testing tours is to go beyond the features and explore other aspects of the app. In my opinion, features are the easiest to learn, and starting with this tour helps than continuing with the other tours, like configuration data, or user tours. These tours will help generate more insightful questions, no doubt!

What do I do with all this information?

Organize & reflect!

Whenever I have some free time I work on sorting out the (so far) gathered information. If the project already has a place where documentation can be found, I will add files there. If not, I start my own testing folder where I add all my documents, spreadsheets, mind maps, and so on.

While working through my documents, I like to reflect on what I have learned during the discussions – Is everything clear? Is there something missing? How is this going to help me?

Strategize & plan!

Another benefit: my information objective and mission of the project becomes clearer. Therefore, I can outline a strategy, I can think of testing techniques to use, and I can lay out a plan.

Get inspired!

When I’m more ahead in the project and I feel stuck, I have so many things to come back to:

• for new test ideas
• to verify if I took into consideration all this stuff while I was testing or if there is anything that I missed out
• to check and analyze if the product stayed on its claimed path if the marketing we have is still valid and so on.

Starting new projects can be overwhelming. However, having the right (explorer’s) mindset and getting prepared for it will transform the experience into a much-appreciated challenge. What was your experience facing new projects? Do you have other questions to add to the list? What kind of exploring techniques do you use? Let me know in the comments below!