5 steps how a QA can go through onboarding on a new project when there’s no onboarding.

I have seen the onboarding process in different companies, very large and small, hiring freelancers and hiring employees, with or without established processes.

Now I want to share my experience of how a new team member can take care of himself so that onboarding is easy, calm and efficient. Especially if this process is not set by the company.

How to efficiently and calmly join a new project if there is no formal onboarding process in the company?

Step 1. Understand whom to ask.

You need to understand who you can contact with questions about:
- the product,
- the process,
- accounts and tools.

Often a new employee does not have a clear and ready list of people who answer new QA’s questions.

Therefore, you can openly ask the team on daily and HR who helps you that such information is needed.

As a rule, a direct question will be answered and the contacts of the necessary employees will be given.

Although in a good situation, sometimes a team member takes on the role of such a “first contact” for a newcomer, who can be questioned about everything. And he already helps to direct to the right people. This is especially useful in a large, complex company.

The most useful contacts from the early days:

• experienced QA of this particular project,
• DevOps, which is responsible for the environment, if you need to locally build a product or autotests,
• tim lead, test lead or someone who has the most similar role,
• a developer in order to find out the technical details of the project,
• scrum master.

Step 2. Understand who to work with.

Getting to know your team will be a separate step.

The best option of meeting a team that I saw happened with myself.

Scrum Master wrote me and said that he would like to introduce me to the team tomorrow on the daily. And it would be great if I could say a few words about myself.

That is, he prepared me.

At the same moment he wrote to the general chat of the team that the daily tomorrow will take 15–20 minutes more and they will meet a new member of the team. And it would be great if the guys from the team could say a few words about themselves.

That is, he prepared a team.

And during this acquaintance he warmly and sincerely introduced himself, introduced each of the team members and we briefly told about ourselves.
It was pleasant, understandable, and immediately it was a little easier to navigate who is the front-end developer, who is the back-end, and so on. Even if all the names are not remembered.

On the other hand I can describe to you also the worst experience of meeting a team that happened before my eyes, but fortunately not with me .

A new tester joined the daily, everyone said him “Hello!” , and Project Owner stopped the greeting and said, something like, “Yes, new one. Nothing special. Let’s not waste time on this daily! ”

Poorly. It shouldn’t have been like this!
Of course, one cannot insure against such situations and onboarding.

So what can you do yourself if the Scrum Master or PO doesn’t organize this?

You can always write a few words about yourself (something about your experience, maybe about a hobby) in the general chat and so introduce yourself to everyone.
At the time of this writing, almost all teams do not work in the office, so offering everyone to drink a tea or coffee in the office will not work.

Although you can offer to do it virtually, on Friday afternoon, for example. Whoever wants to join such a small coffee break and get to know each other.

Step 3. Learn tools and accesses.

Only once while onboarding I had the list of tools, resources and accesses that are needed.

It was incredibly convenient, and most importantly, it allowed me to easily download and configure the required tools from scratch (I was given an empty laptop) and be ready.

Most often, there will not be such a list, and you will have to find out along the way. This is where the people from Step 1 will help a lot.

For example, once the complete list of accesses and resources that I needed but had to collect it myself contained:

• about 25 resources with tools for work that you needed to have access to (for example, Jira, etc),
• 12 instances with different settings of the application under test and at different stages (from development to pre-production), which I should use,
• and more than 45 accounts.

I needed to install and configure this environment pretty quickly on a laptop, and besides that, no one canceled the study of the product, meetings and the first “combat missions”.

An approximate checklist of accesses and accounts may look like this. You may need access or login credentials :

• to company mailing address
• to the SSO (Single Sign On) system if necessary
• to the company’s messenger (for example Slack or Teams)
• to project management system (e.g. Jira, Azure DevOps)
• or to a bug tracking system (e.g. Bugzilla)
• to the project documentation (e.g. Confluence)
• to the API documentation if needed
• to the instances at various stages (development, test, staging)
• to office.com products if needed
• to the log-tracking system (for example, Kibana, Data dog)
• to the remote repositories
• to the application design
• to the analytics and testing metrics (for example, in Jira)
• to the database management tool.

Plus :

• preparation of a local environment for launching a project or autotests locally (depends on the project technologies)
• tools depending on the types of testing (Postman, JMeter, etc.)
• and so on depending on the types of testing and the project.

Knowing such a list in advance certainly helps a lot. But most often you will have to assemble it yourself, asking people whom we can freely ask for the details of the project.

Step 4, Set your onboarding goals.

Honestly, only once I had the experience of discussing clear goals for the onboarding period with my direct supervisor.

But how much it helped!

It was possible to follow a kind of checklist and understand what works and what does not.

Almost always at the beginning it seems that there is a lot of effort and actions, but very little result.

It is difficult for us to evaluate ourselves at the beginning.

It helps to determine the steps that need to be taken with the lead. When you cross out what has been done, it becomes clearer and support appears.
It may turn out that there will be two such lists if the test manager discusses one aspect, and the PO discusses another. Or you can combine them into one list.

It is very good if you manage to set goals for the first week, two, or three and agree to communicate, for example, once a week on this topic to understand how the process is going.

And yes, you don’t have to wait for such a step from the company. The employee himself can initiate such a plan for himself. Everyone will benefit from such initiatives.
It is extremely difficult to draw up a typical checklist here, since it all depends on the types of testing, the product, the process in the team. But you can rely on something like this :

Week 1

• get all the required accesses,
• read specific documentation (for example, infosek, policies, etc.) indicating links and sources, so as not to read all the company documentation,
• configure the local system and tools,

Week 2

• if necessary, obtain domain knowledge. I have worked in construction, banking, e-commerce, insurance and there is always domain knowledge that you need to have,
• study the product description (again with specific links, so as not to read too much),
• undergo planned trainings (if any, then specific names. For example, I underwent internal trainings before starting work on various topics from GDPR to labor protection of an office employee),
• participation in planned meetings,

Week 3

• product study with specific actions. For example, study how a certain module works, then the second,
• participation in a certain activity of the tester. For example, participation in regression (but only with detailed test cases to guarantee the required checks to be done),
• paired testing session with a more experienced tester if needed,
• etc.

If the company does not have a practice of discussing real and achievable goals for new employees, and you will be the initiator of such a process, then you should think about timing. You can negotiate with the lead the main goals and steps for the first weeks, at the end of the month, and then at the end of three months.

After the first month of work, it becomes much clearer how and what to do.

And after three months, when the trial period most often expires, the employee must be very clear about both the tasks and the work. With all the pros and cons.

That is, in three months the employee (we are not talking about the company at all) should be ready to answer the question of whether it is necessary to continue working on this project or not.

Step 5, last but not least. Understand how to work by process.

Processes do not stand in this place because they are less important. On the contrary, I am a supporter of very well-defined processes in testing and have always advocated aligned processes of test planning, test analytics, test design, execution and test closure if needed.

I put them in this place because it makes no sense to talk about the regression process or bug prioritization if you don’t know the product.

This is the icing on the cake that will put a lot of things in their place.

These questions can only be clarified by communicating with a test lead and / or an experienced tester. You should find out about the following questions (at least):

• How the testing process is organized in the company. Step by step.
• Which of the test team has what responsibilities
• Is there a regular, repetitive activity test? what are the rules for these activities? (for example, rules for conducting regression, requirements testing, test planning).
• How often the release occurs.
• What is the pre-release testing process?
• Who creates the test documentation and which one?
• What statistics and testing metrics are collected? By whom?
• Are there definitions for blockers, critical bugs, definition of done, and so on.
• What are the priorities for testing?
• What types of testing are performed?
• Sometimes the types of testing are split between testers or teams. Then you need to understand who is responsible for what.
• What activities are testers involved in? Design evaluation for example.
• How is the working time of testers kept?
• How is communication and feedback going on bugs, test design and test results?
• etc.

Of course, depending on the project and the situation, there will be additional steps and questions.

And most importantly, during onboarding, even for a dream job, we not only adapt to a new process and tasks. It is time also to see opportunities for some changes on the part of the company. And this is not fiction, my experience has shown it.
Sometimes the questions of a new specialist help to change something in the approach to testing or improve practices.

After onboarding, there always comes a time when it becomes easier and more interesting to work. And it’s better to go through this first time, taking good care of yourself and arranging for yourself an understandable onboarding. Albeit sometimes independently.