What experiences do you have with onboarding onto a new project?

It’s new article day and a new day for releasing articles (We’ve moved to Tuesdays!)

This week we have an article from @kinofrost who has shared his thoughts on different ways in which we can onboard new testers quickly:

There’s quite a comprehensive list of ideas in the article. So I thought I’d ask the question:

What experiences do you have with onboarding onto a new project?

Can you share stories of times it went well, or perhaps not so well. I once started a project in which my manager said “Just play with the system, you’ll pick it up”. Needless to say it didn’t go that well…

6 Likes

Very good ideas within the article.

I regularly jump into projects and products sometimes with a couple of hours notice and I’m fairly comfortable doing that with my testing hat on.

Having enough products and experience under my belt usually means I can relate things to something previous, often its a 20 min introduction to product, confirm I cant do any harm and I can jump right in to exploring the product. That tends to give me a plethora of questions so having someone to bounce those off is key to being able to give value within a few hours.

What I’ve found more challenging is often the setup to get access to certain dev environments, that could be credentials that need to be added by a third party, set up on those systems, quick access to specific branches etc. The easier this is made the quicker a new tester can get their hands on the product.

I had one project where it had good guidelines but only if I was on a mac which I wasn’t and it took time and help to get up and running, plus side I made a lot of contacts quickly trying to sort things out and they took on board my ideas and improved it for the next person.

This delay can have a psychological impact on someone joining as they want to add value straight away so important that teams are aware of this and discuss openly and provide assistance, better
still if this step is always paired.

This challenge can get a bit more complex if like I do want to be able to do local builds and access to code, I rarely code so README’s whilst they maybe obvious to regular developers can be tough on those who don’t regularly build locally particularly combined with an different OS and maybe even IDE. Accepting that this can take time and its fairly normal is part of it, developers also take time setting up but again pairing at this critical stage is good.

Dailies also very useful to keep on track and focus on the important things, exploration is prone to tangents and in the first few days it can seem unnatural to block those out, later once you find your feet they are great though.

On the topic of tangents, remote work makes this more challenging and I do not think its totally being dealt with yet, remote is really tough in my view for juniors finding their way.

One final note that the article touches on, giving someone a scripted regression test to run through to learn about a product is both lazy management and a very poor way for someone to learn a product, don’t kid yourself otherwise because you don’t have enough time to properly help onboard someone.

1 Like

Cassandra H. Leung (@cassandrahl) shared advice in this handy post:

They recommend exploring the following elements:

  • Domain Knowledge
  • Access
  • Building Relationships
  • Kick-Starting Quality and Testing
  • Personal Development
2 Likes

The times its gone well is when we’ve been there from the initial realisation of the product. All players in the team from Product, Dev, test, devops etc. are all learning together and its great.

A tricky scenario for onboarding is when we’re developing a POC. The initial conversations are very dev centric, worrying about the architecture and the need to have a working demo - so we’re not by default invited. There is almost a paranoia that we’ll start raising bugs and delay the POC. So for the onboarding we have to sell our services. We know what a POC is and we can adapt to make sure it is the best demo you can have, just by working with the team and evaluating it and also highlight any architectural issues with testability. If the POC works, then we won’t be on the back foot onboarding when it has a proper product roadmap/backlog.

The worst scenario is onboarding on an old product. I’ve been onboarded on a product that was initially built as a startup i.e. 1 developer, no management systems, stories, documents, no roadmap etc. with the product built to meet the customers specific needs. You join the project after its been going a few years with a bigger more mature team, all that history is nowhere and your only reference was the time we started keeping those references. So sometimes that onboarding style, is to challenge the purpose of the product and take a step back and ask “What would I test if I started from scratch?”.

1 Like