I think hiring people new to testing is just as important as hiring experienced professionals who can instantly add something to your product & quality needs and company culture.
Someone new to testing is willing to learn and they’ll need a lot of training, coaching and mentoring. And there is a whole lot to learn and plenty of career direction options.
It’s inevitable they’ll make mistakes and you might provide feedback that could discourage them from continuing down the path of a career in software testing.
So how as a leader do you provide feedback to a new tester without discouraging them?
And if you’re open to it, do you have a specific story from your experience as a leader to share?
This question isn’t really exclusive to people new to testing - it’s the general management of people, new or old, in any job, in any capacity.
A key thing is to create a safe environment, where people feel as though they can ask any questions - no matter the skill level, context or difficulty, and to get the best out of individuals or a team of mixed skills, in my opinion, it’s crucial to have this sort of space.
A culture of coaching, learning together, open to ideas and hearing about new approaches. That is how you’ll encourage, nurture and create growth in people.
Of course, things are going to go wrong at times, and addressing these things quickly and constructively, with an approach of understanding what went wrong and coaching around that.
On the whole, my preferred solution would be to hire people that are new to the software testing industry for the reasons you state; They have no experience and are a blank slate ready for information and guidance. Plus they have more enthusiasm than one who is experienced (and will cost more to the company), who although has benefit of experience, they may have also picked up bad habits along the way.
I always start feedback with praise embedded into it (So it reinforces that behaviour) whilst having the developmental aspect included in it.
In terms of feedback;
One thing I try and live by in myself is to take responsibility for your actions, but taking responsibility does not mean taking things personally. This is what I try and teach to our juniors - there is no such thing as ‘bad’ feedback.
I think there are many ways you can provide feedback without discouraging them.
Go through the task as a pair and explain your thinking
Be more of a coach and improve their understanding through questions and
Offer suggestions of what to try, read, watch or think about
Use different approaches to tasks such as identifying risks, heuristics etc.
Especially with new people helping them understand the fundamentals of testing first is key. What it is, how to think and question assumptions. How to give good feedback (or write bug reports if in that environment). Understanding Quality. Testing techniques and specialisms. ‘Technical Testing’. Testability and all the things.
We have a huge No-Blame culture, we provide feedback instantly therefor we don’t do retrospectives since waiting for a retro to provide feedback or scale an issue, is just not worth our time.
Once a ‘new’ tester forgot to test something and there was a bug present, a big one! (For context: We have a No-Bug-Policy)
At that point, the tester knew he fucked up, but as a ‘leader’ it’s your job to comfort them also. It’s not his responsibility, it’s still the teams, so at that point you stand up and say ‘WE fucked up’ – – WE.
You assess why it was skipped during testing in a small group and find a solution to cover it next time.
What also helps is sometimes to start with “It’s no problem, I once… and then you tell a story of how you f***ed up once” I mean it can even be a made up story but it will make the ‘new’ tester feel better and he will learn that way, that accepting failure is a normal thing.
When you make sure that failures are okay, as long as we learn from them, it should be all fine.
In my experience, the tester was very shy at the beginning and now he just rings my bell and say ’ Hey Kristof, I have an issue or I don’t know how too" instead of leaving it out there…
Making yourself approachable will also solve these kinds of problems. You have to MAKE TIME in order to help your Padawan’s.
First I check to see if they are open to feedback (while feedback is both on what is going well and what can be improved, I’m mainly asking this question to see if they are open to suggestions for improvement).
I then share the feedback privately and explain why I am doing it (I want to help them) and share the impact of the behaviour I observed.
In terms of making sure I don’t discourage them, what I also do is work on building the relationship first - I didn’t focus on sharing feedback with anyone in my team (including juniors) until I felt like they knew that any feedback I would share, was because I wanted to help them. (It’s one thing for me to want to help people, it’s another for others to believe that).
Fortunately its been good with our juniors though, because they know they have a lot to learn and are happy to receive feedback on how to get better- even the more seniors in my team are excited to get feedback (and have explictly told me that).
I also make sure to share feedback (both what I notice go well and what I think can be improved) when I notice things - depending on what it is, I may wait until our 1on1 (if I feel detailed context is needed) or I’ll write in the chat soon after. I really don’t want my team to associated “feedback” with criticism.
I would hesitate to call their action a mistake. If you do, you’re implying that their action was misguided or wrong, which implies faulty judgment or reasoning.
In my experience, it’s rare that someone makes a mistake in the sense described above. The action they took was completely justified given their experience and the information at hand. In other words, it wasn’t a problem of their judgment, but of their lack of experience. You can’t gain experience in something until you’ve actually experienced it.
Given that context, you have to trust that your people will take actions that may have undesirable outcomes. You have to build a culture of learning so that they have the space to reflect on the experience and integrate it into their knowledge, which will better prepare them if a similar situation arises in the future.
Feedback, then, is really an opportunity to facilitate reflection and learning, not correction or blame. A great way to start that conversation is by sharing a time when you experienced the same or a similar thing, and the lessons you learned from it. This signals that it’s safe to openly discuss and learn. Be curious and ask genuine questions, you’ll both learn a lot. A win-win situation.
I’m not a leader so, I will answer as a colleague who give feedbacks.
Ask for permission if they want to hear the feedback.
Be specific on event and action not on persons.
My style tend to put the event/action what going on ? → What is my observation ? → How does event /action make me feel ? → What action items can be take or try ?
I also always tell that you don’t have to take all feedback/action. Just take as much as you preferred to take and suited to you.
I am a junior cricket coach and I have that using the player-centred coaching framework PoP helps in giving feedback to testers by focusing on the needs of the person being coached: A coaching framework for testers – TestAndAnalysis
