Does Domain Expertise Really Matter?


Many job descriptions include a requirement for domain expertise to filter candidates for testing jobs. But is expertise really necessary before joining a team? Does it ensure a good tester? Justin Rohrman digs into his experiences in difficult business domains, what expertise means, and how it applies to software testing.

Domain expertise is the most popular way I have seen to filter candidates for software testing jobs before they even get into a building to talk with the team. Testers are expected to be masters of—or at least able to talk about—many different areas: testing, programming, development processes (agile, waterfall, Scrum), and the business. On top of that, the job description says something like “Candidate must have five years’ experience in financial services.”

I think filtering on domain expertise is usually the wrong way to get good testers.

Let’s take a deeper look at what expertise means, how it applies to software testing work, and some of my experiences working in difficult business domains.

Specialized Domains

I’ve worked in a few difficult business domains in my time as a software tester, but the ones that stand out the most are pricing science and behavioral health.

Pricing Science
One of the first software jobs I had was at a pricing science company. We built software that ran Bayesian math algorithms to generate prices. If you have ever purchased an airline ticket, then chances are the price you paid was generated by that product.

I came into this company as a very junior tester. I had to learn about the business domain, professional software development, software testing, and more. I had a mixed strategy to become useful in the business domain quickly. The first thing I did was gain some primary source knowledge on pricing by reading a book about the basic principles of pricing. After that I spent time with our sales people and our customers to learn how people use the product by talking with them and watching how they work.

After just a few months, I was able to talk about pricing, and our product, in a reasonable way. I started thinking in terms of deals, price adjustments, and price indexes.

This company valued learning and invested in that.

Behavioral Health
Another platform I worked on was created for doctors to help document casework at behavioral health clinics. This company was very focused on domain expertise. Most product managers, support staff, and even a few people on the technical staff spent time working at a behavioral health facility at some point.

The most complex part of this job was mapping together clients, procedures, and doctors to insurance providers. There were only a couple of people on the team who were familiar with that part of the product. I wanted to develop some knowledge (and simplify the work) by spending time with them to document the state machine. They were too busy, and managers never supported my idea.

User Comments

1 comment
Jon Hagar's picture

So in a short paraphrase (always risky to do), your view is "it depends".  Domain knowledge may be a good thing and developing more can not hurt. 

So a question is, can a tester with beer-mat knowledge work in a team of people on a complex subject where another member of the test team has contributory expertise?  

My experience is that this is how many test teams work in complex fields. Each person bring some expertise. 

March 29, 2017 - 5:17pm

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.