When our Head of QA, Nastya, joined Red Collar, one of the first processes she wanted to change was onboarding. In her previous roles, newcomers were often left to study everything on their own. Answers to simple questions could take days, and sometimes it wasn't clear who could help. The new process needed to be structured and informative while introducing people not only to the workflow, but also to the team and everyone's areas of responsibility.
 

After researching onboarding formats used by other companies, Nastya developed a quest-style plan with introduction stages, skill checks for junior specialists, and adaptation tasks for people coming from different backgrounds. The onboarding takes one workweek. Each day has a list of tasks and expected outcomes, and every tester receives a document with the complete plan.

To see a project where QA was part of a wider team working across design, frontend, backend, and technical support, explore the Future Crew case.

How the five days work

Day 1 is dedicated to the project, documentation, and team. The newcomer reads the internal documents, receives the necessary access, registers in Space, joins the project's TestIT, and reviews the defect-reporting guidelines. They also create and assign themselves a task in Space, attach it to the board, and join the daily standup after contacting the team lead and project manager.
 

The main reference document is the Test Plan Master. It contains project details, the team structure, contacts, areas of expertise, and links to environments such as Swagger, Storybook, and the testing stand. The first day is intentionally light on tasks and focuses mainly on navigation and introductions. People who already have experience with similar projects can skip the basic steps and move forward.

Day 2 introduces the analyst and the team's approach to test cases. The newcomer starts exploring project information in Notion and reviewing meeting recordings. Since analysts hold much of the project knowledge, the next task is to contact one of them and ask a question about a use case, its format, or its fields. The purpose is to break the ice and begin communicating.

Using the selected use case, the newcomer writes three test cases in Space. This helps the team align expectations and work toward a consistent test-case style. The day ends with another review of the bug-reporting rules and a small quest: find and report a defect in the guidelines themselves - if there is one.
 

Day 3 moves the work into TestIT and adds communication with the design team. The newcomer studies the system's structure, tags, and test plan format. They then contact a designer to find out which interface block was completed most recently and which one is currently in progress. Based on the latest block, they write five test cases and move them, together with the cases from Day 2, from Space into TestIT. At the end of the day, they review the first version of the test plan and prepare questions for the team lead.
 

Day 4 focuses on backend development and Swagger. If the newcomer hasn't used Swagger before, the team provides a guide. They introduce themselves to a backend developer, ask about authorization, select a microservice, and make two or three test requests. After discussing the results with the developer, they turn the requests into test cases. This stage helps the team understand which tools the newcomer already knows and where additional support may be needed.
 

Day 5 covers Storybook, frontend development, and the first real task. If Storybook is used on the project, the newcomer explores it and contacts a frontend developer with questions about specific interface elements. They then write five test cases based on the developer's latest completed block.
 

The newcomer also introduces themselves to the CTO and shares their first impressions of the project and the onboarding process. The final step is to ask the team lead for a real task. After five days, the plan is for the newcomer to be ready to start working on the project.

For shorter notes on design, development, and the way we work, follow Red Collar on X.

What changed

The schedule is flexible: people who already know some of the tools or adapt more quickly can complete it in three days. According to feedback from one of our mobile QA engineers, the mini-tasks helped him start communicating with the wider team, understand the workflow, and enter the internal processes more quickly.
 

The Test Plan Master also proved useful outside the QA team. Developers began using it to find project information and contacts, turning an onboarding document into a shared reference for the project.