Coaching Testing Skills
At one point in my career I was able to sit down with each person on my team every couple of days and provide them with feedback and guidance to improve their testing skills. Even better were the days when I could pair with them while planning tests, writing tests, executing tests, and reporting on testing.
It was beneficial as I was able to help employees learn new concepts and improve skills, in a manner that fit for them. The added bonus for me was that I learned something new from them as well. What powerful experiences those were!
Now, as a manager for 18 testers who are spread across several different agile teams, I find it difficult, if not impossible, to coach testing skills one-on-one. On a weekly basis I also spend time coaching the agile teams, management-level initiatives to improve company-wide practices, and the usual management administration. Such is life in a ’start-up’ type of company. As a result, my one-on-one time with each person is limited to 30-60 minutes over two weeks. This seems a miniscule amount given they are working a minimum of 80 hours in that same time period!
I am someone who is motivated and energized in working with others to learn new skills, to understand and be able to apply new skills appropriately, and to have those ‘light bulb’ moments where things just click. Given my work situation, I have been frustrated with how little I have been able to do this. This left me with a problem!
How can I increase the amount of coaching and teaching time each individual is receiving?
Solutions:
- Forget about it: Nope! I’m too invested in helping others learn and grow.
- Clone myself: Not feasible, as in I don’t know how, and it is kind of icky to think about.
- Shift responsibilities to other people: The possible people to offload to are just as overloaded as me.
- Find additional ways to teach and coach skills so each individual gets more opportunities to learn and improve: There are lots of ways to do this! I just need to invest some more time to create these opportunities. Some possibilities:
- Coach a smaller group, and have them coach small subsets of the larger group.
- Direct them to other people who I trust will coach them appropriately.
- Move our 1:1’s to their work space & turn it into a paired testing session.
- Create workshops where they can learn and practice skills.
- Coach other people to create workshops where they can learn and practice skills.
What I’m Doing:
Ongoing learning and growth are important to me. Happily, I discovered that they are important to my department as well. They requested regularly scheduled workshops/training sessions to be reinstated after being cancelled during the agile training the entire engineering organization went through over the summer. They missed them! They missed the learning, new perspectives, and much needed ‘down time’ at work.
So, regular department workshops / training sessions were reinstated on a biweekly basis. We are currently shifting to make them weekly.
Our first workshop back was a brainstorming session to come up with a list of loosely prioritized workshops the team members would like to have provided. They came up with a lot of great topics, which we are adding to on an ongoing basis, and are adapting priorities as needed.
The workshops we are doing are typically 2 hours long, and are created by myself or a team member, and contain both teaching of concepts, and time to explore, practice and apply concepts. We customize workshop focus and content based on the people involved, what they want to learn about, and their current knowledge-base and skill sets. A blend of ‘teaching’ time and ‘experience’ time are proving vital to help people go back to their day-to-day work and integrate new learnings – which when applied to hands-on work become new-found skills when they invest time in practicing them.
The workshops also allow me to engage with everyone both as a group and individually, and determine how I can add more value for them when we have our regular one-on-one conversations.
Final Thoughts:
I am not yet satisfied with the amount of coaching and teaching I am able to provide to each individual. However, I am happy with the progress I am making in increasing the amount of learning opportunities they are getting from me. These workshops have allowed me to stretch the limited time I have to teach, coach, and add more value for all of my department members. This is an improvement, and a step forward to incorporating other learning opportunities for my department.
I plan to share some of the workshop experiences in future blog entries, so keep an eye out for those!
On Teaching Software Testing:
My thoughts on this have been bouncing around in my head for a while – how can we improve on how testing skills are taught? What is the best way to teach and coach them?
For myself, there are things I am doing now which are helpful, but there is so much more I would like to do, and I’m sure could be doing that I haven’t considered yet. I know I am not the only person in that position. So where do we begin?
Matthew Heusser recently blogged on this very topic. He invited people to comment on what types of teaching and training are wanted by organizations for their employees, and what would be most effective for the employees. I added my comments to that entry, alongside some brilliant thinkers in this field. Thank you to Matt for starting a great conversation thread! You can read it at http://blogs.stpcollaborative.com/matt/2009/11/18/you-say-you-want-a-revolution/.
Your turn!
What are your experiences and thoughts on how to coach and teach software testing skills? As a coach/teacher/trainer, what have you done to do this when you have had little time to do it well? As a tester, how do you want to be coached and taught – what would be most effective for you?
I welcome your comments, and encourage you to share them both here and on Matthew’s blog.

Amy Thorne
Ruud Cox
nandagopal.r on
Thanks for writing this — you’re certainly not the only one facing this type of issue. I’m sure others will comment on the specifics of teaching testing skills, so I’ll talk about my thinking given that I have 10 (soon to be 11) programmers who report to me (not to mention the 5 testers on the team).
1. There is an upper-limit on how much you can scale by trying to lead all of these efforts. It’s time to delegate some of the learning responsibility and find ways for small groups of people (4 is about right) to meet on a regular basis as a study group. Similar to the workshops you’re doing, but led by the members themselves. You can kick off the meetings, or close them, but don’t spend all 2 hours in the room/area.
2. Train the coachers: similar to your first possibility, but have people dig deeper in areas of interest to them and then let them lead workshops on those areas.
3. Pair test between development and testers. Not for an entire feature, or even a whole day, but just for an hour or two.
Relative to the managing part (mainly the one-on-ones), I’m finding more and more that working side by side with the people on my team by pairing and allowing the space to go “meta” (i.e., talk about how we’re working with each other and with the rest of the team) during the pairing reduces the need for the one-on-ones. And I get a much better idea of their strengths and weaknesses than even they might be aware of.
;ted