QA engineers often must jump in to already running projects and start testing and adding value as soon as possible. When this occurs, we must gain knowledge of the system architecture, business logic, project process, QA process, legacy issues, future planned implementation, and many other aspects or the project. Learning all of this together at the same time can be very stressful and difficult to handle—that is to say, it is easy for us to became overwhelmed.

There are several things you should think about doing to smooth the transition, which I’ve listed below. Of course, there isn’t a magic solution to get up to speed quickly. This process can take weeks, months, or even years depending on the size of the project. It is important to understand this fact, both for the new QA and the rest of the team, including leaders and managers.

The Ideal Scenario

In this scenario, the client or company leadership knows about how hard this will be, and even if there are urgent deadlines to meet, it won’t add pressure to the new member. If this is the case the onboarding process should have the following:

• Documentation – This does not mean that the project has to have 100 pages in the wiki explaining everything in detail. What is really needed are some general guidelines and information that will be used throughout the project. For example, having URLs to all the different environments, user names and passwords, general flows of the main functionalities, and updated design mockups. Short videos can be useful too, but I don’t recommend recorded meetings with clients or stakeholders. There is too much that happens in those meetings that is often out-of-date by the time you rewatch them later.
• Test Suites – These are basic test cases collections for us to guide the testing. A well-made checklist is useful too.  
• Regular knowledge transfer sessions – Schedule these regular meetings with the project owners, other QA team members, or developers if necessary. These sessions should not take more than 30-45 minutes at a time. Too much information at one time is difficult to process and store correctly in our brains.
• Start with testing tasks of the same “type” – Don’t assign manual testing, API testing, automated testing, and regression testing tasks all at the beginning. Is better to start focused on one type of testing, like testing manually (exploratory tests if possible) to get familiar with the system. You can add more task types in a progressive manner when appropriate.
• Start focused on one area – It is good for both QA engineers and the team that we quickly gain good knowledge and confidence regarding one area/module/function. This way the team will feel more comfortable regarding the quality of the given area and we will start to add real value quickly. Once they are familiar with the process, it can be applied to other areas of the application as well.

The Non-Ideal Scenario

In this scenario, you may have been added to a project because there are deadlines (urgency), but the project did not include QAs in the past. The project may lack definition, documentation, processes, and may be of low quality. In this scenario, you will need do so some things in addition to the items listed in the section above:

• You will also have to manage the knowledge transfer meetings, negotiate the tasks you will be able to work on, and ask for the tools and information you need (once you have figured that out).
• You must always explain your status and blockers in the daily meetings or in one-to-one meetings with your leadership, and work togetherto solve all the issues.
• Finally, once you feel confident and things with the project are “stable”, you can start creating documentation, test cases, and checklists for future team members.

Summing Up

In both scenarios it is very important to always be very proactive. It is no excuse not to have some of the documents or processes described above. If you need something, ask for it. If you don’t know about the process or business rules, ask for those too. If you there is no process, create it. If there is no known solution for your blocker, try to come up with the solution.

To achieve all this your soft skills will be the key, not just you technical QA skills.  Remember, a high percentage of the success of the onboarding is up to you, so give it your best.