The Test Consultant’s Guide to Starting a New Project

7 min readApr 5, 2023

One of the best parts about consultancy work is that you get to experience many types of projects over a broad range of industries. You might be part of a single crack team working on a small urgent piece to solve a very specific problem, or part of an expansive, mature project which is essentially a company in its own right.

You might be acting in an advisory capacity to enable a team to perform at its best, or you may be sat right in the thick of it, purely delivering feature work. Additionally, there’s the challenge of getting up to speed rapidly so that you can start providing value to the client and project team as quickly as possible.

Easily learning new information, deducing what to filter out and what’s important, figuring out how to traverse a new social landscape and how to adjust your communication style to align with different working cultures is vital.

After riding this merry-go-round a few times, I devised a personal checklist of actions to take over the course of starting a new project. Whether you’re a consultant yourself, or perhaps you’re joining a new team or even a new company, having a framework to manage your own journey may end up being very useful.

Here’s mine!

So you know you’re moving, what can you do in the meantime?

Schedule a talk with the team lead or equivalent beforehand to find out information. You may not be able to talk about specifics due to confidentiality, but you can ask questions which can give you a good idea of what is to come. This will help you come in prepared, and more able to tailor your approach to their specific needs.

A suggested set of topics could be as follows.

Team structures: How many teams are there? What do they work on? How do teams communicate with each other?
Your role: What will be expected of you? Are you there to solve a specific problem? Do they see you as just a “resource” who will speed up their delivery with specific outputs or do they want you help them grow and improve?
Ways of working: What does their delivery journey look like? How do they go from “The business wants X” to it being in a customer’s hands?

Another way you can get ahead before the project starts is finding out what the tech stack is. You don’t have to become an expert in it, but from personal experience, it’s a lot easier to get to grips with a project’s particulars if you’re familiar with the basics of what it’s built upon. You’ll be able to focus on the project specific implementation details rather than trying to get your head around what a React component is. Another bonus is that it helps you speak the same language as the development team.

Let’s pretend my new project uses React to drive its frontend, and I’ve never heard of it before. The general approach I’d take here is quite simple.

Research: Hop onto my search engine of choice and find the React website. See if any of my favourite bloggers have written about it. Nothing too deep here, I just want to know what it is and how it does it.
Build: Most good tools have solid tutorials these days, so I’ll locate one of these and build it up on my personal laptop. This will give me a flavour of the adjacent tools needed to work in this space, such as using npm or choosing an IDE (if I don’t already have a strong opinion on that matter!)
Tinker: So now the tutorial app is complete and I have my own little Hello World React App. Can I make it do more? Maybe I want to extend it out to do more complex things. Maybe I need to brush up my JS skills before I can take it further. Any struggles I have going through this process will highlight where I need to focus my efforts.
Play: Remember not to get too stressed or fall prey to perfectionism. You’re a beginner, you’re learning, it’s fun! You don’t need to be an expert in a day. As I type this I am acutely aware that I am being a hypocrite!

What do you do first?

It’s your first day and you’re all kitted up with your new equipment. You may have a tonne of mandatory training to do and there’ll be lots of calendar invites flying around. Total chaos, usually. This chaos is good though, as it gives you space to do a little bit of extracurricular activity. Namely, finding out who to talk to so you can get an idea of how your new ecosystem works.

Some projects have a people directory which makes it quite clear who everyone is and what they do, some require a little more digging. Don’t be afraid of asking “Who’s the best person to talk to if I want to know about ____?” and approaching them. People are generally quite happy to talk about their work!

To kick things off, I’ll usually approach things in the following way.

Create an itinerary: Locate at least one person from each discipline present on the project who seems friendly and knowledgeable. Schedule a chat with them to find out more about who they are and what they do.
Prepare your questions: You want to understand the people you’re working with, how they perceive their role and yours. It’s important to understand the journey they’ve been on so far, if it’s an existing project. Maybe you’ll turn up and wonder why they’re not following best practices, only to find out they’ve been fighting to do so for a long time and they’re in the middle of turning things around. You don’t want to run the risk of accidentally belittling their efforts by making a load of suggestions early on.
Enjoy meeting new people: This one’s self-explanatory. Hopefully this part leads to lots of great conversations with your new colleagues!
Make notes: After each chat, I’ll usually write down anything interesting which I might want to explore further. Maybe somebody mentioned that they’re frustrated with how hard it is to write an automated end-to-end test in their current solution, or that they really wished there were more conversations between devs and testers. This can help provide talking points later on down the line, and really help zero-in on what the people and the project need from you.

And next?

As well as understanding the project’s processes and people, you’ll want to understand what the point of it all is. You may need to locate someone more detached from the implementation side of things, such as a delivery lead or a business analyst, to get the best results here. Here’s a list of what I’d seek at this point.

Overview of project goal: What are we hoping to achieve by building this, according to the business? A general answer which is far removed from specific functionality is best. “We want to make it easy for customers to open an account with us” is a good starting point.
Overview of functionality: This will provide an answer to the question “What does this thing actually do?” and could be achieved by a practical demo showing core flows and how a user might traverse the system.
User research: If applicable, see if you can get hold of any user research that’s been conducted, as that can provide the human context to sit alongside the business and technical context you’ve gained so far.

You’re clued up on the project, what happens now?

At this point, you feel pretty comfortable that you know why your project exists, and what it can do. You’ll hopefully have a surface level understanding of the application, and you’ll maybe even remember some peoples’ names.

At this point it’s important to take a step back and just observe. I like to take a back seat and do a bit of people watching before fully coming out of my shell. I might be keeping my eye out for the following:

Who are the dominant personalities on the team?
What relationships and dynamics can I see?
What’s important to each individual?
Who do people listen to?
Is there anyone who seems excluded/unhappy?

Answers to these questions will be important to know for the future if you want to start pushing for changes or improvements. It’s useful to know who’s going to be sympathetic to your cause, who might be a challenge to deal with and who can help influence others if needed. It’s also important to know if there’s anyone you can help bring the best out of. Maybe there’s someone whose quiet but competent voice needs amplifying. Maybe there’s someone who just needs a little encouragement as they get overlooked.

“Actual Work”

Of course, at some point you might need to do some “actual work”, something with a Jira task attached where you can log your time. It’s a bit unconventional as a tester, but if you feel up to the task, perhaps consider picking up a small bug task from the backlog. Through doing this, you’ll gain a whole load of benefits:

Insight into the system: You’ll be delving into the guts of the system to figure out why something isn’t working correctly, which is a great way of getting up to speed with how it works. Pairing with a developer can take the pressure off a bit, they can lead the process and you can ask questions about what you’re both seeing.
Insight into the team: You’ll hopefully have to do a code review. Code reviews are a great way of learning about your team. Maybe everyone feels under too much pressure with other tasks to do code reviews in a timely manner and you find you have to badger people, which causes tension. Maybe people silo themselves and don’t feel comfortable doing a code review outside their area of expertise. Maybe you’ll find everything works perfectly and you’ve shone a light on a strength of your team.
Insight into how delivery works: You’ll have had to pull down code, build it, write it, test it, push it and merge it. You’ll see the process from start to finish, and any weaknesses will be exposed through experiencing it all with fresh eyes. Maybe people take for granted certain pain points because they’ve been there for so long. You might have a perspective which can help improve things!
Empathy for the developers: Now you understand why everyone’s so grumpy, because you’ve gone through the whole journey of turning a business need into code.

Well done, you’re now settled in!

Now the real work begins! This journey will look a little different for everyone, and I’m interested to know how others approach the daunting but exciting prospect of starting afresh.