13

We've been going through onboarding procedures with multiple people that were becoming a part of our QA team throughout the history of our company. During these times we usually try to meet with a new person more often, do a couple overviews of our products and workflows, ask to research the tools we use for test automation and point to the tutorials to go over.

What are the general recommendations and strategies to make a new QA specialist onboard in the most efficient, productive and motivating manner?

10
  • 1
    a fully remote team as in the whole team who are remotely together in one location or everyone within this team is in a different location?
    – Yu Zhang
    Dec 18, 2017 at 3:51
  • 1
    @YuZhang every single member of the QA team is working remotely, all working from different locations. Thanks.
    – alecxe
    Dec 18, 2017 at 3:52
  • Fully remote team makes onboarding completely different. The key part (pairing for few weeks) is not possible. It should be two different questions, you might get better answers. Dec 19, 2017 at 16:05
  • @PeterMasiar okay, good point, removed that part from the answer. Thanks!
    – alecxe
    Dec 19, 2017 at 16:54
  • 1
    Atlassian just posted interesting article about building distributed/remote teams. They recommend "Secondments" - temporary assignments in a new job role or location. Interesting read. It is not recommendation of any Atlassian products, even if we do use few :-) Dec 19, 2017 at 20:52

8 Answers 8

5

If you can (given the constraints of technology and time zone), pair them with your existing QA specialists to do real work.

1
  • 1
    pair up with devs and business analysts would help too. But I guess it is difficult enough already to pair up with QAs when they work remotely.
    – Yu Zhang
    Dec 18, 2017 at 3:53
4
+50

I've run my quality engineering on-boarding for a few months and find going through the Agile Testing book by Janet Gregory and Lisa Crispin a great approach. It can act as a great guide to:

  • The agile testing quadrants
  • Good approaches to Unit testing such as mocking and stubbing
  • Embedding quality engineers within development teams
  • Adopting a quality mindset and much more

Learn from this Agile Testing Book. enter image description here

3

A few years ago I helped to onboard a team member who worked remotely. Two suggestions:

  1. build trust (rookie should feel safe to ask for a help)
  2. for first few weeks give small assignments (4-12h long) and check on a daily basis (phone or video call) how it is going
2

To On-board New QA Employees I'd Recommend:

  • Give Documentation on functionality of software applications used
  • Let Employee Review Existing Test Cases
  • Let Employee Review view past issues/bugs with the software
  • Let Employee Review Automated Test Cases written
  • Provide links to tutorials on Test Case Logging Software
  • Provide links to tutorials on Automation Software
  • For a remote team, make sure to foster environment with lots of open communication via skype, email, and chat
  • If no documentation exists, let the developer tell the QA how the software works
1

If you have some sort of description of your SDLC representing your project development (development in its broad meaning including testing, analysis, deployment, etc) practices and tools, you may ask a newcomer to make a short presentation for teamleads where they (newcomers) would analyse drawbacks of the process and suggest what could be improved.

If you have no such the description you may ask newcomer to do all the same but starting with interviewing key persons of a project.

This will make them aware of how the things are done in the project, introduce them to the team and the team to them and make them think productive from the very start.

1

In our team we are following below steps to on board new joiners:

  1. Will give an introduction to the team and feel them comfortable with the team. We are having an induction presentation specific to our team. It explains about the introduction to the processes followed for testing/collaboration with other teams, tools used etc. One of senior team member will present that to the new member.

  2. Then walk through of the project which he/she is going to work on and give the related project documentation test cases, test automation scripts. Tell him/her to review it and give their suggestions.

1

Here are my experiences when you're working with Scrum process:

  1. Reading, study Business requirement and give your feedback or some ambiguous things you don't understand. (This step is really important). Clarify Business requirement as much as you can.
  2. Do the estimation based on Business requirement.
  3. Analyze and give your feedback on the build plan provided from dev team if the build plan is so tight to test.
  4. Use Positive, Negative and Destructive (if needed) to design TCs. Do the pair review TCs with your teammate.
  5. Perform test, keep track on issues and go along with dev team when you faced with critical or blocker bugs.
  6. Verify bugs.
  7. Retest some special cases if you have spare times.
  8. Lesson learned. (What you did good keep the momentum and if not learn from your mistakes).

Learn from your mistakes then take note. Hope you have a good career in the near future.

1

I would use a three/two way split of the following for the first few weeks:

  • going through manuals/information/presentations to learn business logic and high-level software usage/installation etc.
  • going through existing test plans in order to learn how the software usually works
  • (if needed) learning tools to be used

In my experience, this is how not to bore the new employee to death with just the business logic (that might be actually interesting but in overwhelming volumes) and not to give them test plans without any background.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.