A few weeks ago I had a conversation with a hiring manager about the ideal qualifications for a test leadership role. He said he was planning to get someone who knows a lot about the business, but was not a testing expert, to lead the testing. I argued that to get great testing, you need someone who knows what great testing looks like.

Domain expertise is often overrated. Think about it – software manipulates and displays data. Frequently, an expert tester can pick up on patterns of data manipulation regardless of the domain. And the process of recognizing the patterns brings the risks of the domain to consciousness where they can be examined, discussed, and expanded. Too much familiarity with the domain actually hides risks under layers of assumptions laid down over years of complacency.

Expert testers bring with them a large toolbox of heuristics and a schema of the testing problem space. Domain experts can provide a good picture of the usual array of risks, but without a diverse history in testing they can’t imagine problems other than the ones they have previously encountered. An expert tester new to the domain can immediately initiate a wide variety of tests, from product tours to documentation reviews to product performance evaluations, without knowing a lick of specifics.

Of course their testing only becomes richer and more targeted as they acquire domain knowledge. The test expert can quickly acquire a very functional level of domain knowledge and awareness of quality risks via a review of previously reported issues. Then, given the full picture, they could decide whether to put effort into covering the product for those risks again or to expand coverage over the rest of the risk map that hasn’t apparently been covered before.

Among other things, expert testers are attuned to the team dynamics that affect quality. Ideally, testers are responsive to the team and yet also to voice their concerns over aspects of the product or the process that seems risky. Unfortunately, often testers marginalize themselves at the tail end of the development cycle, or keep themselves in the dark about upcoming changes that could impact their work.

Although a leader with domain expertise can do a great job of testing, as a test lead they may not know how to monitor the health of the team, develop effective test strategies, or coach/mentor their team. Good testing leadership works on multiple fronts to organize the work, keep the testers engaged with the developers and analysts early in the process, and encourage a culture of good coding and testing practices.

These are just some of the reasons why I feel strongly that testing expertise trumps domain expertise as a qualification for great test team leadership. I have seen this comparison play out in front of my eyes as good test leads turn teams around and boost their effectiveness while well-meaning development managers mishandle the testing and release damaging bugs. I’d like to hear your experiences as well. 

What do you think?

Geordie Keitt is a Director in the Doran Jones Testing practice. @geordiekeitt