Joining a product team that’s never worked with dedicated testers before can be challenging. Team members may feel unsure or even resistant, and it can take time to find your place and show the value of testing.
Your point of Simply start testing really resonated with me. I’ve found that being hands on and helping people to understand by SHOWING them testing (rather than just talking about it) really helps. Remember that engineers are not taught testing and a lot of what you say will be new to them, so helping and showing is really important.
As someone being the first tester in an organisation you’ll be a change agent, which means having the skills to advocate and evangelise testing and support the testing you’ve recommended.
Patience to reiterate things multiple times.
Communication skills to sell ideas and win people over.
Resilience to be able to work at the basics and go from there.
Pragmatism to not try for too much (or lose people by going to hard on quality).
In terms of specific advice: brush up on your ability to sell testing into a team, learn to be patient with the time it’ll take to make changes and learn how to speak to engineers using their own words (be confident in talking engineering topics).
I have 1 example where I was brought into a team that didn’t have a tester and it was for an MVP product. The team was 4 devs and a product manager…who was more of a project manager. The devs had put together a selenium framework and they were finding it difficult to keep up to date. So thats how the role came about, they wanted a tester to just keep the selenium tests going.
So on day one I had a walk through of the product with the product manager and was asking questions like “So what business problem is this product solving?”, “Who is your typical user?” etc. those were questions he wasn’t expecting from me. I sat down and “simply started testing” with the limited information I had and was reeling off the bugs into Bugzilla. It was an open plan office and I heard the main architect turn around to the devs and say “Have you seen these bugs? They’re brilliant, all consistently written, all reproducible”. So there were seeing me as a benefit not hinderance which was a good sign, so built a good relationship fairly quickly with the team.
They wanted to do an on location trial of the product (it was basically a hard copy file tracking system detecting electronic tags moving from one area to another) and I said let me go along I’d love to see how its used. That week long trial I worked with the users and had a regular dialog with the architect. Lets just say, that the selenium framework went down the priority list rapidly.
So my advice for anyone going into a product team as the sole dedicated tester:
be confident in how you work, don’t be told what to do if the reasoning isn’t evidenced
be open about how you work and be ready to adapt to bring the team with you
make sure that you and the team understand the vision of the product
enjoy yourself and be comfortable you are going to make a positive difference
Was going to suggest exactly the same things, well said @ghawkes .
I just started a role as the 1st dedicated tester, and after 2 months, mostly learning stuff, I have very little to show. but I have had to be flexible, yet stick to my guns to get a CI/CD full-system going again. The last full CI/CD was put in by a summer student and that died during the covid panic. Explore every thing you can, and make notes for later on, so that you don’t get distracted from the mission. But it’s not like Rome was built in a day is all I will add though to Gary’s advice.
Loved your tips on how to build trust, @demivm. I think that’s such a crucial part of the work. When I onboard with a new company, I take the time to meet one-on-one with each developer and acknowledge what they might be thinking.
I’m there to:
Make them look good (I joke about this, but it’s true)
Work with them so that we can create something we’re proud of
Find the issues so that we can talk about them. I am not there to block anything but to inform the team.
Coming at it from the perspective that I am here to help puts people at ease, I think. At least, I haven’t heard anything otherwise
Such excellent tips! My own experiences joining teams - often as the first tester ever to join the team - I used a similar approach. You have taken the fear out of this for a lot of folks!
Being the first tester can feel lonely at first, but it’s also a huge opportunity.
You get to shape how the team thinks about quality not just testing. And when they start seeing you as part of the build process, not just the final checkpoint, that’s when the real magic happens.
Also:
Don’t try to change everything at once. Observe. Understand their rhythm.
Be curious, not critical.
Celebrate small wins.
And keep your sense of humor. You’ll need it when you hear things like, “We didn’t test it, but it works on my machine.”
There are some amazing gems of advices already given. I will try to keep it classic & cliché:
Be curious
Ask questions (no question is stupid even if in your head it looks stupid, ask it anyway!)
Being a tester isn’t just a role, its a mindset, if something feels off in your gut - say it out loud. It can be either the friction in the process, in people management, customer relations or tech stack.
Record everything! Either in your local note pad just one liner, or in any project management tool thats used. ie: Jira.
Make notes whatever comes to mind, bring it in 1:1, retros.
Embrace the mistakes, its ok.
Research & read latest trends in software testing industry.
Last but not least: Start small, there will be days that it will be overwhelming, just take a step back and restart!
I will try to keep it classic & cliché: