This is a guest post by Rachel Kibler.
My journey to becoming a good testing mentor has been a bumpy one. My first experience was training Sara.
Sara was a friend of mine from work whom I recruited for my team when one of the other testers left. She had been testing another product but was going to be new to mobile and new to working with a Scrum team. The team hired her because she was friendly and seemed eager to learn.
Things started out well enough. I spent a couple of days working with her, explaining our processes, introducing her to mind mapping, and helping her gather test data. She wrote everything down — everything — and asked lots of questions.
This went on for about a month, with her asking questions, me responding to them, and her writing down the answer. I began to become frustrated, certain that she was asking the same question repeatedly and not consulting her notes. I expected her to be curious and independent, and I was disappointed at how much she was relying on me.
I tried different tacks. Instead of responding to every question, I asked her what she had done to figure out the answer for herself (an effective tactic that had been used on me in my early days as a lawyer). I tried the Socratic method with her. I asked her to save up her questions to ask once every few days, again, trying to instill independence in her.
I have a terrible poker face. Social deduction board games don’t usually go well for me. And so, with Sara, my frustration and impatience showed. I would take a deep breath before responding to a question, and I think I may have just stared at her for some of them. I’m not proud of this. Sara caught on and became resentful.
The relationship between us soured, and by the time I realized what I was doing, the damage was irreparable. The rest of my time on the team with Sara was miserable.
A Chance for Redemption
I left that company and joined another. I was very clear with my new manager about where I thought I had gone wrong with training Sara, and I told him I was rather gun-shy about training someone new. In spite of my apprehension, he gave me someone to train after a few months.
Dorothy had a long history in tech, but she was struggling at our company. Her team was frustrated with her not catching on to their processes, and they felt she was slowing them down unreasonably. She came to my team specifically to work with me.
I did things differently this time. I talked with her about expectations — mine of her, and hers of me — and I listened to her fears and frustrations about work. I asked for consent to not answer every one of her questions, and to ask her what she had done already to figure things out. She said she needed more structure and more documentation. I agreed to try to give her that.
Dorothy and I pair-tested, and that went pretty well. She seemed to do a good job testing within that kind of constraint. Left on her own, though, she constantly asked for more documentation, and, more than that, relied on the documentation as gospel. I couldn’t convince her to experiment and explore, which was central to how we tested. I felt like I had failed her and myself, though my boss didn’t blame me.
About a month after Dorothy left the company, Melinda was hired. She was planning on eventually doing something else at the company, but she was going to start as a tester.
I liked Melinda immediately. She seemed interested and interesting. I went through expectations with her and talked about learning styles. I gave her a long list of things to read and watch when she wasn’t working with me or on another task. However, ultimately, she ended up not being passionate about testing. We moved her to her new role early, and I had now failed at keeping a tester happy for the third time.
But then I got a summer intern! Mitch was new to testing but had just finished his degree in computer science. We started with exercises, which he caught onto quickly enough, and we talked about how testing is different from development.
He was curious, was excited about testing, and had a coding background that he was interested in applying to automation. We periodically paired so I could introduce him to new techniques and products, and he learned quickly. Finally, I succeeded, though I felt like a lot of it was due to him and not to me.
The last person I trained was another intern. Jennifer had gone through a coding bootcamp, where she realized she didn’t want to be a developer. She wanted to be in tech, though, and she thought testing might be fun.
I gave her the list of resources I had compiled before, we paired, I encouraged her to look up answers to questions, and we went through many of the same exercises I had done before. She seemed to enjoy testing, and I enjoyed teaching her. Again, I felt like I had a win after a long string of failures.
Retrospective
I learned a lot throughout this process. I learned that I had to adapt my style of teaching and pay different levels of attention to the person based on how they liked to learn. I learned that it’s a lot easier to train a new tester than someone who has been in tech for a while. And I realized some things I did wrong, as well as some things I did right.
Things I did wrong:
- I let impatience show on my face
- I expected people to be like me, in temperament, drive, and curiosity
- I pushed independence earlier than was appropriate for some people
Things I (eventually) did right:
- I talked about expectations at the beginning and revisited those expectations periodically
- I had a list of resources that the trainee could consult on their own
- I paired with the trainee, frequently at times
I want to continue coaching people how to test, possibly expanding my reach to developers and product owners. Since I have learned from my successes and failures and now know some things to do and some things not to do, I am better equipped as a trainer.
Rachel Kibler is a test lead at Anonyome Labs, which makes MySudo. She can be found on Twitter @racheljoi or on her website at racheljoi.com.
