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.

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.