Five-Day Adaptation: How We Improved Onboarding for QA on Service Projects
Five days to dive in and meet the team — our new quest-style onboarding format. A quick guide for juniors and leads: what tasks to expect at the start and how to rethink the adaptation process for a QA team of 10+.
Hi! I’m Nastya, Head of QA at Red Collar. I’m going to walk you through how onboarding works on service projects for our QA team. The goal is simple: set up communication within the team and introduce all the essential tools. Our quest-based onboarding format is easy to scale, so it can be applied in other departments too.
I was thrown into the water and had to swim… or sink.
We’re moving away from that approach on day one.
In previous companies, I often felt like I was dropped into the deep end and left to figure everything out alone. I had to study a lot on my own, and answers to even simple questions could take days. Sometimes people didn’t even know who could help me.
When I joined Red Collar, the first thing I wanted to fix was the onboarding process — make it informative, structured, and painless. I wanted newcomers not only to understand the workflow but also to meet the team and understand who is responsible for what.
I started with research: different onboarding formats across companies. After structuring all the info, I was hooked by the idea of a quest-style onboarding and decided to try something similar. I added introduction stages, skill checks for juniors, and adaptation tasks for people who came from a different background.
The onboarding lasts one workweek. Each day has a list of tasks and expected outcomes. Every tester receives a document with the full plan.
Day 1: Getting to know the project, the documentation, and the team
On the first day, the newcomer reviews our internal documents, gets all the necessary access, and registers in our project space — Space. The plan continues with:
- Getting access to the project’s TestIT
- Reviewing the defect reporting guidelines
- Creating a task in Space, assigning it to yourself, and attaching it to the board
- Joining the daily standup and introducing yourself (before that, messaging the team lead and PM so they add you to all meetings)
For meeting teammates and tools, we use the Test Plan Master — a document with all project details, full team composition, contacts, and competence descriptions. It also includes the environment: links to Swagger, Storybook, and the testing stand.
We also have clear expectations for day one. The main goal is exploring Space, so besides completing tasks, I expect the newcomer to message me with something they feel is missing from the platform — a feature they’d like to see, for example. That way I know they actually navigated the system.
The first day looks like this: not too many tasks, mostly communication and introductions. People who have already worked on similar projects skip the basic steps and move on to the next stage.
Day 2: Meeting the analyst and practicing test case writing
The second day starts with exploring information about the project in Notion and reviewing meeting recordings. This takes time and can be done gradually.
Testers constantly work with analysts — they hold all the project knowledge. The main task of Day 2 is getting acquainted with the analyst and reviewing the documentation. Questions always appear, especially for newcomers, so the next quest task is to send any question about a use case — the format of documentation, field types, anything. The point is to break the ice and start communication.
Then comes the creativity part: using a use case, come up with three test cases and write them in Space as comments.
At this stage, we align expectations and adjust the approach so everyone is on the same page. It helps the newcomer integrate faster, understand the workflow, and go through reviews more smoothly. Test case writing is a personal skill, but in a large team a unified style naturally forms.
We finish Day 2 by reviewing the bug-reporting rules. Many people skip them, but the document is fundamental, especially for juniors.
Now comes a fun twist: I expect each newcomer to send me a defect they find… in the bug-reporting guidelines themselves. Most people inspect the document very carefully and look for errors. And whether a defect actually exists — that’s for them to figure out. ;)
Day 3: Hello, design team and TestIT
We start the day by exploring TestIT: its structure, tags, and test plan formatting.
Then we move on to design: the newcomer messages the designer, asks which block was completed last and which one is currently in progress. The task is to write five test cases based on the latest block. This again helps practice test case writing and communication — this time with the design team.
Next, we move the test cases from Space into TestIT along with the ones from Day 2 — learning how to work with a TMS.
At the end of the day, the newcomer reviews the first iteration of the test plan and prepares questions for the team lead.
Day 4: Development and developers
On Day 4 we meet the backend developers and explore Swagger. If someone hasn’t worked with it before — we have a guide.
Next tasks:
- Write to the backend developer, introduce yourself, ask about authorization in Swagger
- Choose a microservice and make 2–3 test requests
- Verify the results by discussing them with the developer again
Then all requests are turned into test cases. This helps understand what tools the newcomer is familiar with and where the gaps are. In the evening, I expect reports and review the test cases.
Day 5: Graduation and first real tasks
On the fifth day, we explore Storybook (if the project uses it) and meet the frontend developer. We ask questions about specific interface elements and write 5 test cases based on the latest block they completed.
After that — time to meet the CTO! The newcomer writes a short introduction and shares first impressions of the project and the onboarding. This helps remove psychological barriers — later communication becomes much easier.
Finally, it’s time to ask the team lead for the first real task. After five days, I expect the newcomer to be ready to dive in. What can I say, I’m an optimist. :)
How the team evaluates the onboarding and finishing it “externally”
Some people adapt faster or already know part of the tools — they finish the onboarding in just three days.
Onboarding helped me quickly build communication with the whole team, understand the workflow, and get into internal processes. I especially liked the mini-tasks that required talking to different teammates. — Anton, Mobile QA Engineer at Red Collar, 2 months on the team
During the process we discovered that this onboarding format turned out to be convenient not just for testers. Developers began using our Test Plan Master too — many now check it to find the information they need. And we’re always happy to help.
🛸 Get an estimate of your digital idea 👉 hello@redcollar.co
