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…

4 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