An easy approach to onboarding new testers

How do you onboard experienced and less experienced engineers as part of a QA team? Let’s look at the main steps in the process, using the example of the GS Labs team. We’ll share a plan outlining what to do first. 

It’s great when staff do their best to start contributing to the team’s work as quickly as possible, but a new job is always stressful, involving new people and new processes. Here, we won’t be focusing on the social and legal aspects of transitioning into a new role, and we’re going to move directly to the work itself. When a new team member arrives, they need some time to get familiar with the test stand and test object. The speed and success of this process depend on how up-to-date your team’s documentation and other processes are. 

Any new employee starts out with a probationary period. The purpose of this period is for the employee to successfully find their place within the team—that’s considered a good outcome.
The key objectives for the probationary period are: 

  • getting to know the team;
  • getting to know what the department does;
  • completing their own tasks.


The plan is roughly the same for all new hires, although the details depend on the specific responsibilities of the department and company concerned. 

Here’s a real-life example of a plan from GS Labs:

Onboarding tasks can typically be divided into several categories:

  • working with documentation;
  • working with test cases;
  • testing and working with defects.


Tools used

Different tools are used for each task. Let’s take a look at each one in more detail.

Test management systems

The advantage every novice has over a highly experienced colleague is the ability to ask unexpected questions about the product flow and written test cases. The novice is still able to look at the documentation and product with fresh eyes. 

For example, there is a test case to check that a broadcast message has been sent.

Fig. 1. Test case for sending a message.

An experienced team member may not pay any attention to any errors. In fact, they probably don’t even open the test case description every time. In this example, the server from which the message was sent is not specified, and there is no indication of where in the menu the user has to be to accept the message.
Another example involves obsolete test cases which need to be updated. Unfortunately, updating the test database is not always a priority task. Sometimes, test cases are not updated at all when requirements change. This is usually due to a lack of time or an oversight on the part of the tester.

Fig. 2. Obsolete test case.

Now let’s imagine that our experienced tester has decided to switch teams. In this case, a well-written and updated test case would help to solve the problem. This is where newcomers become invaluable to the project, as they can help to update the test cases.

By carefully going through the steps described in the test management system, new employees will certainly encounter weaknesses in test case descriptions.

Fig. 3. Updated test case.

As a rule, following a successful probationary period, the tester continues to familiarize themselves with new features and test cases. Depending on the complexity of the project, this may take a long time. 

Wiki systems

Confluence can successfully be used as an internal wiki. It can include descriptions of connection diagrams, test infrastructure development plans, etc. In addition, the plan for the probationary period (the onboarding plan) can also be stored in Confluence or similar systems.

The system has its own API, enabling you to automate how it works. Confluence makes it easy to plan tasks and is integrated with the manufacturer’s bug tracking system, JIRA.


Fig. 4. Using links to JIRA in Confluence.

Using tools like these, it is easy to write documentation, for example the specifications required by each tester.

Bug tracking system

GS Labs, which we are using as an example for our discussion of onboarding, has been using the Redmine system for a long time, but the company’s development and the team’s growth required something more. A decision was made to introduce the bug tracker JIRA.
Initially, JIRA was only intended to be used for error tracking, but it is now also used for planning Agile projects.

JIRA is an interactive dashboard which can be used to track the completion of tasks set. All tasks are categorized as various types of work item: functions, subtasks, defects, etc. They can easily be edited, assigned to various people, or simply have their status changed from “open” to “closed.” All changes made to a task are logged and recorded in worklogs. The system is a little more complicated than Redmine, but new staff still have few problems getting a grasp of it.

New employees can familiarize themselves with the bug life cycle and add to the description of the problem if necessary. This also contributes to the work on bugs.


In place of a conclusion

In the battle for talent, companies are increasingly striving to improve their onboarding processes. There are now many effective tools that help to ensure “painless” integration for new staff.
Thanks to some well-established processes, onboarding can be of benefit not just to new hires but to the entire team. Time spent mentoring and helping colleagues to settle in is an investment that supports the team as a whole.

Having an experienced mentor and making use of specialist “tools” will speed up the onboarding process for future staff.