Recently I have tried to move into the realm of test coaching. It’s an interesting field. Mostly cause nobody seems to have heard of the role.
I have had phone calls with recruiters looking for QA folk. They get in touch via LinkedIn mostly, and only one has ever asked me what a test coach was. I find it interesting that the people in charge of hiring QA’s don’t know what a test coach is, let alone does.
What I think most moving into the coach role do is just become a coach out of necessity. For example you are the only QA in the company, or there are not enough testers for the amount of work developers are churning out. So QA folk help teams to use collaborative techniques such as BDD and WIP limits. This of course introduces cool side effects like slack time, which testers can use to teach developers fun testing. I don’t just mean manually running through acceptance criteria or test cases (these can with help of the developers, be automated). I mean fun techniques like exploratory testing, which can be a very rewarding activity.
Once the developers understand HOW we test, they can easily sub in for an over worked QA. This then frees up the QA to get into a more coaching role. If you are the only QA in a company, or maybe one of very few over multiple teams, you can start helping other teams. Get one team working well together and testing upfront, devs testing other devs work. This means you can jump team and do it again. To me this is the role of a test coach. Someone who can teach others to test and once done, they can leave the team to work without them.
OK so what happens if your company has too many QAs? Maybe there is a tester per developer. On paper this looks AWESOME, right? But what can happen is the wall between dev and test remains, and in fact is harder to smash as developers can think it doesn’t matter how fast I get through work, there are LOADS of testers. But in reality even with more people trying to find problems, nothing beats helping to stop them from being started. So how can a coach help here? Well, the role of QA is quite quickly becoming, automation engineer. Which is cool, but in my opinion if you are writing code, you are a developer! A coach can enable automation engineers to become developers. They can do this using the above techniques and encouraging pairing.
I don’t understand the point of having some folk writing test code, and others writing production code. Surely coding is coding, and if paired up with devs, testers can become devs quite quickly. So now we have not just a multifunctional team, but multifunctional people.
Doing this you may hear something to this effect, “testers and developers are DIFFERENT people, they THINK different, testers will NEVER be able to code, and developers will NEVER want to test”. I believe this to be totally untrue.
In fact most software testers have a computer science degree and did not have a clue what a QA was until one day they got a job as one. When you do hear something like that, just ask to trial paring for a few weeks, and see if the team learn anything. What I have found enabling pairing, is a happier team. Yes, you get greater quality, but you also get testers who thrive as developers, and stop feeling like second class citizens to the teams developers.
Once you have coached your way through the teams, what next? You can start looking for waste in other places. Maybe security reviews are taking too long, or releases are difficult. Can you as a test coach help there? Of course you can.
This is what test coaching means to me, but it seems to be quite a new concept in terms of companies. What does it mean to you? How can we help more companies to see the value of a coach, and not just a box ticking QA?