The work of Quality Assurance professionals can often be intricate while being holistic at the same time. Hence it stands to reason that ensuring an effective start for a new employee is critical to their performance and the team's overall success. Although highly important, designing the onboarding process is not as intuitive.
What NOT To Do
For QAs/Testers
-
DO NOT ask them to explore the application for a few days to understand how it works. WHY?
- Exploring an application is a time-consuming process with no measurable end results.
- Often such an endless quest leads to differences in understanding of expectations from the applications.
Eg. For an e-commerce product you as QA Manager would expect the QA to focus on the product’s checkout flow however a Tester with a background in mobile application testing might end up focusing on the navigations. So at the end when you as Manager ask if the QA has understood the “application”, although the answer would be yes, it would still mean different things for both of you. - Sometimes limitations/known issues in the applications can confuse the QA/Tester thereby limiting their confidence in the application & further limit their ability to question things since they would not be sure if something is broken or an undocumented feature 😉
-
DO NOT share tons of documentation to understand details. WHY?
- As humans we can neither retain nor retrieve a lot of information in a short span of a few days. This will add enormous pressure on the new joiner while still resulting in inefficiencies at the end.
- Everyone hates it. So just dont do it.
-
DO NOT ask them to execute all the cases from the entire regression suite. WHY?
- In effect, it will take forever to finish for a person with no prior knowledge of the product or processes.
- Too much work pressure. Not needed right when someone joins. Have mercy!
- Any occurrences of bugs will complicate and prolong the test.
- Without prior experience with the application, the end result of the test will be less than satisfactory for both the manager and the individual.
-
DO NOT make them work in isolation from other teams.
- No matter how fast you need to get up and running with your work, they will always need to interact with people from other departments for gaining valuable knowledge. So make sure to introduce them to key people from other departments and enable them to collaborate.
- Also introduce each person effectively and not just names and designations. Pro tip: You need these people to remember each other.
- Sometimes companies assign a person from the team to handle introductions. However, in non-colocated teams, not many people know each other well and hence may not have the reach or the resources or rapport to make the introductions.
Additionally for Automation Engineers
-
DO NOT share a bunch of test cases to automate right away. WHY?
- Most often manual test cases are written from the perspective of a human, specifically a QA professional, and often need to be rewritten to make them work with automation.
- However without prior experience of the applications and their processes it is very challenging to adapt test cases for automation.
- Also driving test coverage without consulting the automation engineer with regards to scope & priority is like treating them as Automation Printing Machines, which they are not. You hired these smart individuals for a reason. Listen to them.
-
DO NOT make them work on manual testing tasks for too long. WHY?
- Test automation needs a certain set of skills, attitude & perspective which is different from manual testers(domain experts). Hence automation engineers could be less effective there.
- While focusing on manual testing for too long, their automation skills could get rusty, which they will realize sooner or later and resent their work. If that continues, you could even lose them, and you don’t want that!
Now, if you're not following any of the practices above and want
to learn how to improve?
READ ON.
However if you're not doing anything for onboarding and making the person
start working right away?
DEFINITELY READ ON!!!
Designing the right onboarding process
To design the right onboarding process you need to understand its underlying driving forces which are the needs of the new joiner, the team & you as a leader.
For effective performance of the new joiner, they need to:
- Understand the product(s).
- Understand the process(es).
- Understand the team(s) & colleague(s).
- Understand culture.
- Understand expectation(s).
For a cohesive functioning of the team, they need to:
- Understand how responsibilities will be shared within the team.
- Understand how to leverage the strengths & support the challenges of the new joiner.
- Most importantly the team needs to build trust amongst each other.
For clarity & confidence as a Manager, you need to:
- Understand if the newbie needs help in any areas at work.
- Make sure to iron out misalignments between job expectations (if any).
- Only spend optimum time or energy to manage the onboarding.
- Enable the newbie to perform at their best.
- Make sure the newbie does not quit in a few days. 😅
As you can see from the objectives above, most of them were missed by the processes mentioned in the DON’T section. I believe these objectives are self-explanatory however, should you have any challenges in understanding them, feel free to contact me.
Now we will see how to effectively set up the process.
What To Do
For QA Engineers
1. Introduce the applications & platforms
- If a test suite exists already, scope out a few smoke tests (if not done already) and ask the QA to execute these tests on a the most important platfoms.
- Then share a feature in the application for the QA to explore & write tests for it. If a test suite does not exist as per point#1, then priotise critical feature(s) for the QA to write tests for them.
2. Introduce the teams & processes
- Task the QA with validating bug fixes (no more than 7-8 in a week). This way they will need to interact with the developers and other team members to undestand the tasks and build rapport while discussing processes.
- Invite the newbies to observe a few meetings within & accross teams. This will also be a good experience for the new joiner to observe the culture in the teams and get comfortable.
Additionally For Automation Engineers
3. Assess capabilities & establish expectations
- Allow the engineer to create a sample framework for automation for a small use case (which is not automated till now), while following the coding standards (eg. code styling, formatting, conventions etc.) of the team.
- Guide the new joiner to create a test capability matrix for their framework. If other frameworks are in use already, allow the newbie to comparatively analyse all these frameworks to understand possibilities of improvement in the team’s processesing capabilities & possible pitfalls to watch out for in the future.
There you have it!
On finishing the above the new joiners will be acquainted with the products, processes & standards to follow and be enabled to perform at their best.