Test Manager vs. Test Coach

I've been working as a Test Coach for almost two years and I will soon be seeking to hire people into the role. One common attitude that I hear is:

"Test Coach. Oh, that's just the agile name for a Test Manager."

It's true that if you work in an organisation that uses a traditional delivery model with separate design, analysis, development and testing teams, then you are more likely to see the title Test Manager for the person who leads testing. If you work in an agile model with cross-functional teams, then you are more likely to see the title Test Coach for the person who leads testing. But the two roles are not synonymous; it isn't simply a rebranding exercise.

Here are some key differences from my experience.

A Test Manager has a team of testers who report directly to them. They are responsible for hiring the team, determining and recording individual development goals, approving time sheets and leave requests.

A Test Coach has no line management responsibilities. The testers will be part of a cross-functional team that is managed by a team leader or delivery manager. A coach has a limited ability to lead through authority, instead their role is a service position. The Test Coach can influence hiring decisions and support testers to achieve their individual development goals. The language of coaching is different and it requires a different approach.

A Test Manager leads a group of testers who primarily identify as testers. If asked what they would do, the tester's response would be that they're a tester. The testing community is inherent, created by co-location and day-to-day interaction with testing peers.

A Test Coach leads a group of testers who primarily identify as contributors to an agile team. If asked what they do, the tester's response would be that they're part of a particular delivery team. They might mention that their main role in that team is testing, but to identify their place in the organisation it's often the delivery team that is mentioned first. The testing community must be fostered through planned social and knowledge sharing activities for testers who work in different areas, which are often activities lead or championed by the coach.

A Test Manager has ownership of the testing that their team undertake. They are likely to be accountable for test estimates, test resourcing, the quality of test documentation, and may be involved in release governance or sign-off procedures. 

A Test Coach has none of these responsibilities. In an agile environment they are owned by the delivery team who estimate together, review each others work, and collectively determine their readiness for release. The decision making sits outside of the Test Coach role, though they might be called on for counsel in the event of team uncertainty, disagreement, or dysfunction.

A Test Manager drives their testers. They're active participants in their day-to-day work, with hands-on involvement in tracking and reporting testing activities.

A Test Coach serves their testers. They usually won't get involved in specific testing activities unless they are asked to do so. Coaching interactions are driven by the person who needs support with testing, which is a wider group than only testers. The coach is proactive if they identify a particular need for improvement, but their intervention may be with a softer approach than that of a manager.

The Test Manager will know the solution under test inside-out. In order to properly meet their accountabilities they need to be involved in some degree of detail with the design and build of the software. Test Managers are also adept in identifying opportunities for improvement within the processes and practices of their team, or the products that they work with.

The Test Coach is unlikely to be an expert in the product under development or the wider system architecture. They will have some knowledge of these aspects, but as they are removed from the day-to-day detail their understanding is likely to be shallower than the testers who are constantly interacting with the system. A coach generally has a more holistic view for identifying opportunities for improvement that span multiple teams and disciplines.

A Test Manager is the escalation point for testers. Regardless of the problem that a tester is unable to resolve, the Test Manager is the person who will support them. The issues may span administrative tasks, interpersonal communication, professional development, delivery practices, project management, or testing.

A Test Coach is an escalation point for testing-related problems only. The types of issues that come to a coach are generally those that impact multiple delivery teams e.g. refactoring of test automation frameworks or stability of test environments, or those within a team that require specialist testing input to solve e.g. improving the unit test review process or fostering a culture where quality is owned by the team not the tester. These issues may not be raised by a tester, but can come from anyone within the delivery teams, or beyond them. A Test Coach might also be asked to contribute to resolution of non-testing of problem, but these discussions are usually lead by another role.

A Test Manager will identify training opportunities that are aligned with the development goals of their staff and arrange their attendance. They will be abreast of workshops and conferences in the area that may be useful to their team.

A Test Coach will do the same, but they are more likely to identify opportunities to deliver custom training material too. The coach has the capacity to create content, the knowledge to make the material valuable, along with some understanding of teaching to engage participants effectively e.g. learning styles, lesson planning, and facilitation.

Both roles are leading testing in their organisation. The roles are different because the context in which they operate is different. In a nutshell, a Test Manager leads testers and a Test Coach leads testing. The focus shifts from people to discipline.

I hope that this explanation offers clarity, both for leaders who are looking to change their role and for testers who are working within a different structure.

These observations are based on my own experience. If your experience differs, I would welcome your feedback, questions or additions in the comments below.

Not right now

I spent an hour of my Wednesday morning participating in Tuesday Night Testing, an online Lean Coffee discussion run by Simon Tomes who is based in the UK. There were a number of great conversations, but one in particular has stayed with me through the day.

Can you think of a time that you've been really busy at work? A day when it seems like every task you complete generates two more? Where you're ruthlessly prioritising and snatching every available moment between meetings?

Now imagine one of the rare occasions on that day where you're at your desk with a solid hour to focus. From the corner of your eye, you see one of your colleagues approaching and you realise that it's because they need something from you. It may be a quick question, it may be a request for a longer piece of your time.

Your heart sinks.

You want to help them, but you also want to finish what you were doing. You don't want to be rude, but you also don't want to allow them to interrupt your train of thought.

"Do you have a minute?" they ask.

What do you do?

This scenario was posed during our discussion and there were a few different strategies shared. As a person who struggles to say 'no', this topic made me realise that I've evolved an alternative approach to an outright refusal. Here's how you might approach this situation in the same way that I do.

Don't say 'no'. Instead say 'not right now'. You're still being upfront and stopping the interaction in its tracks. But instead of refusing to help, you're simply deferring the conversation to a later time.

Follow up the 'not right now' by taking ownership of resuming the conversation yourself. Don't ask your colleague to come back later. That creates another opportunity for them to interrupt you at an inopportune moment and force you to context-switch. Instead, offer to go to their desk or office.

Provide specific information about when that later time will be, so that it's clear to your colleague that you're not just attempting to avoid the discussion entirely. You might get back to them within the next hour, after lunch, before the end of the day, or the end of the week. Whatever the period is, be specific about when you're available to chat.

"Do you have a minute?" they ask.

"Not right now. I'll come and find you after lunch, will you be at your desk about 1pm?" you reply.

I don't use this type of response all the time. Often I am interruptible and, at these times, I really enjoy having spontaneous conversations with colleagues. But on occasions where I am particularly busy, I find this method of deferring, along with ownership of rescheduling, is one that works well for me.

Thank you Amit Wertheimer, Andrew Morton, Cassandra Leung, Claire Reckless, Tracey Baxter and our organiser Simon Tomes for an interesting discussion. I'd recommend getting involved in future Tuesday Night Testing sessions.