What testers should know about domain knowledge

Often, QA professionals require industry domain knowledge in order to respond to unique specifications, workflows, or technology adoption.

Often, QA professionals require industry domain knowledge in order to respond to unique specifications, workflows, or technology adoption.

June 15, 2020
Tamas Cser

Elevate Your Testing Career to a New Level with a Free, Self-Paced Functionize Intelligent Certification

Learn more
Often, QA professionals require industry domain knowledge in order to respond to unique specifications, workflows, or technology adoption.

You might be an expert in software testing techniques. But often, QA professionals require industry domain knowledge in order to respond to unique specifications, workflows, or technology adoption. Here’s what to look for, as well as how to obtain domain knowledge in vertical markets, such as hiring talent, using consultants, and taking courses and tutorials.

No matter what role you aspire to in software testing, it pays to gain as much information as you can about the vertical markets where your applications are used. In testing systems for the healthcare field, for instance, you need to be up to speed on HIPAA regulations. If you work in the brick-and-mortar retail industry, you ought to know about how to test point of sale and RFID data.

“Domain knowledge explains the 'why' of what a business is doing and informs the decisions and testing for an application.” --Tim Harrison, VP of QA services at consultancy SQAsquared

But you can’t know everything up-front. What are the most effective ways for testers to pick up industry-specific software knowledge? Which are the best strategies for QA teams wanting to deepen and expand this kind of knowhow?

The buzz phrase for expertise in specific industry sectors, "domain knowledge," has been bandied about for quite some time. In software testing guru Rex Black’s 2003 book, Critical Testing Processes, the author mentions domain knowledge as one of three skill areas managers should look for in hiring and growing testers. (The others? Testing skills and technical skills.) 

In an article the next year, Danny R. Fraught revisited this topic, taking it from the tester's perspective. "How well can you relate to the people who will buy and use the software? Do you understand the problems they're trying to solve and how they will use the software to solve them?" Fraught asked. His list of technical skills advantageous for testers included familiarity with programming languages, end user operating environments, and system administration. 

You won't necessarily be denied a job as an entry-level tester if you aren't adept across domain knowledge, testing, and technical skills. However, at any stage of your career: The more proficiency you can muster, the better off you are.

Importance is on the upswing

You might see the term "domain knowledge" mentioned in connection with technical skills, such as SQL Server, Linux, or mobile apps. In this article, however, we focus on vertical markets. Today, this sort of expertise is more essential than ever.

Largely, that's because of the increasing complexity of both vertical software applications and end user requirements, including compliance with regulatory environments, asserts Jon Quigley, a software tester with more than 30 years of experience, mainly in embedded automotive systems. 

"If a medical application is intended for use in the U.S., it must be HIPAA compliant, and the guidelines for this regulation mainly cover data protection," explains Vladlen Shulepov, CEO of enterprise software development firm RiseappS. When developers create a HIPAA-compliant application, the QA engineers must confirm that its security features are implemented properly. Although HIPAA was first enacted in 1996, it's added lots of new stipulations over time, and further changes could lie ahead. 

Solution checking is hardly the only area of testing and QA where domain knowledge is direly needed. "Profound domain knowledge can add valuable insights to the product of a particular domain,” notes Maxim Ivanov, CEO of Aimprosoft, another company specializing in enterprise software development. With the help of previously-obtained expertise in a certain domain, examples include a better understanding of end users’ needs and creation of corresponding amendments on the earlier development stages; more precise testing scenarios; and defect prioritization, he asserts. 

"From the QA team's perspective, a particular tester/QA engineer will likely be more productive and valuable than the one with a lower degree of knowledge in a certain domain," says Ivanov. 

Tim Harrison, VP of QA services at consultancy SQAsquared, echoes this sentiment. "Knowledge represents the core understanding of the applications being tested,” Harrison explains. “Without an understanding of that application, you're really just punching a keyboard and hoping for the best. Domain knowledge explains the 'why' of what a business is doing and informs the decisions and testing for an application." 

The advantages aren't lost on savvy end users. Nicholas Stuller, founder at My Perfect Financial Advisor, is a non-technical CEO, now on his third financial tech startup. “I have spent considerable time in the early months of my companies working directly with the technical staff. In the cases where the QA team had domain knowledge, it was immeasurably beneficial. There were countless cases where a glitch or bug was easily spotted by someone who knew the industry, and was missed by those who did not," he says. 

With domain knowledge, you understand users better, and that helps you think of new ways to help them.

How testers can get a grip

Given its obvious career-boosting potential, domain knowledge is a hot topic on online forums like Quora. Questions pour in not just from novice testers but also from experienced testers wanting to move from less lucrative industry sectors – such as human resources (HR), perhaps – into better paying fields such as banking and pharmaceuticals.

QA folks who've already climbed vertical market learning curves often advise various forms of self-education. "Start reading newspapers (Not only sports sections) :)" quipped Saurabh Dalvi, an automation tester in capital markets/investment banking. 

Beyond keeping up with industry news by reading newspapers and trade publications, other methods of self-education include perusing technical manuals, attending trade conferences, and interviewing experts. Those with programming skills can also try examining and writing domain-specific apps. 

For example, if a techie wants to break into financial markets, it’s a good idea to download open source software meant for banking, suggested Pramod Kapore. "There you will find actual design and implemented code. You can browse the source [code] and understand the flow clearly and then later you can write a simple project." 

Gaining general knowledge of a domain like banking, though, is no simple matter. "There are so many types of banks out there – retail banks, investment banks, commercial banks and private banks. On top of that, the word(s) 'banking industry' [mean] so many things – customers, products and services, operations, risk management, regulations, etc. It's really not easy to get a handle on everything," acknowledges Gary Tan. 

The best way to fast track, of course, is to land a testing job in your chosen domain and then acquire on-the-job knowledge by interacting with experts where you work. "If you have a QA team leader or a senior engineer with more knowledge of a specific domain, they can always help someone with less experience to learn more about it," Shulepov suggests.

Deepening team knowledge

Many organizations acknowledge a desire to deepen their expertise in domains where they're already strong. A common way to transfer knowledge from seasoned pros to noobs is to keep detailed documentation.

"Domain knowledge is so important that we dedicate multiple times each week as a whole team to stop what we're doing and document things in our wiki,” Harrison explains. “We add, improve, clarify new content and delete outdated documentation. The wikis turn into onboarding documents for new or transferring team members." 

Jamil Goheer, CEO of software testing house Kualitatem, recommends maintaining a "Knowledge Book" containing process information, participants, facts, definitions, and acronyms related to the domain. "This book can then be utilized as a reference guide at any point," he says. 

Organizations also grow their domain knowledge by assigning individual testers to specific tasks based on experience. In Quigley's view, there are four main types of software tests in vertical application testing, each needed for producing desired results and each requiring some degree of domain expertise.

  • Static testing. One of these tests, static testing, happens before the product exists. Qualified team members review specifications, drawings, software design documents, software requirements specifications, code reviews, customer walk throughs, and any other artifact reviews. "This requires time and talent that is willing to critique, in an environment that is safe to perform those critiques," points out Quigley.
  • Compliance testing. In contrast, compliance testing is about testing the product against all specifications and contractual obligations, including – but not at all limited to – regulatory compliance. "In the automotive industry, for instance, we will verify that all gauges are meeting pointer sweep requirements in our instrument cluster," Quigley maintains. You can take compliance testing requirements from a customer spec (where one's available), from the requirements review, or both.
  • Combinatorial testing. Combinatorial testing refers to methods of comprehensively testing software in an inexpensive way, in an attempt to find unexpected bugs that might otherwise go unnoticed in the testing phase. A full explanation of the theories behind combinatorial testing could fill a tome. Essentially, though, it's defined as an approach that systematically examines system settings in a manageable number of tests that cover t-way interactions.
  • Exploratory testing. This type of testing requires more domain expertise than any of the other three types. "Exploratory testing occurs when we allow a reasonably well-seasoned test engineer to go with their 'gut' and feel their way about the product’s performance," Quigley elaborates. "Done well, the test suite grows as the test engineers learn more about the behavior of the products. These productive exploratory tests will be moved over to the test suite, perhaps automated."

Compliance testing needs the least amount of domain expertise. Newcomers can sharpen their chops in domain knowledge by learning about and testing against vertical market customer requirements. "This is where you can 'let the kids play,'" according to Quigley.

Expanding teams into new verticals

Much like individual testers, many independent testing and development houses hanker to garner knowhow about new verticals. Favorite routes include self-education, online tutorials or webinars, classroom training, hiring consultants, adding more full-time staff, and forging industry partnerships. Organizations vary a lot, however, in how they prioritize and use these tools.

Aimprosoft designed two scenarios for broadening its testers' knowledge. "If we have to deal with covering certain micro-gaps in domain knowledge of either our QA engineers or testers, we follow the path of self-education and try to extract the necessary information from online tutorials, written manuals, and guides." says Ivanov. 

"In case we are pursuing the aim on a more profound level, such as the extension of knowledge regarding long-term projects, exploring a completely new for the company area, etc., we either attend local workshops or hire an employee with corresponding expertise. If the project lasts for more than two or three years and we think that the measures mentioned above are not enough, we can invite a specialist to train the members of our QA department," adds Ivanov. 

SQAsquared has also adopted a couple of different strategies. "One of these is taking online webinars from skilled professionals knowledgeable in the area where we're seeking domain knowledge," Harrison says. 

"We've also sought out partnerships with key champions,” Harrison says. “Over the years, we specifically build relationships with those we work with that last beyond the initial engagement.” The individuals move to new companies and spread out into new industries. Personal connections brings in Harrison’s company, giving them an opportunity to consult with individuals who have moved onto new verticals. In other words: They start with established client/consultant trust. “We've found that the relationship route has been the best as we're able to speak candidly with those individuals and reveal where we lack information so that they can help fill in the gaps for us."

What you need to know about five different verticals

Here are a few highlights of what you need to learn about five specific vertical markets. If the domain of your dreams isn't listed below, do a search around the web. You'll be sure to encounter an entirely different set of requirements!

  • Pharmaceuticals. It's crucial to test the accuracy and relevance of the data and numbers entered into pharmaceutical systems, according to Elena Yakimova, head of the web testing department at software testing company A1qa. "A slight change in numbers may result in significant changes and defects. Since the pharma software deals with medicine, incorrect data can have very serious consequences (wrong dosage, for example)," she explains.
  • Healthcare. Aside from keeping on top of the ins-and-outs of HIPAA, be aware that it’s typically necessary to build and test separate or combined applications for provider data, member data, premium billing/payment, broker data, claims entry/validation, and broker commission calculation/payment. The FDA also has certification requirements for medical devices. Healthcare applications can’t be tested in any order desired, either; instead, a certain workflow must be followed.
  • E-commerce. For obvious reasons, e-commerce is another domain where security is particularly critical. Testers also need a solid grasp of technologies such as inventory management, payment processes, session and cookies validation, shopping carts, procurement history, online transaction and processing (OLTP), PCI compliance, and electronic data interchange (EDI).
  • Brick-and-mortar retail. Brick-and-mortar retail solutions contain many of the same components and third-party applications as e-commerce systems, such as inventory management. Brick-and-mortar software, however, may have unique requirements. For instance, point of sale solutions need to incorporate technologies such as RFID and barcode solutions, quick checkout, receipts generation, and payment and billing systems.
  • Insurance. Beyond learning the specific user requirements in life insurance, property insurance, vehicle insurance, and so forth, get familiar with the many software systems used this industry. These include software for insurance certificate issuance, claims, declaration management, billing, policy administration, and insurance agency portals, to name just a few.
Whatever industry you’re involved in, you probably need to ensure someone’s responsible for software quality. This essay makes the case for a Chief Quality Officer.

by Jacqueline Emigh

Jacqueline Emigh (pronounced “Amy”) is an award-winning journalist specializing in technologies used by enterprises, small businesses, and consumers. She has worked full time as an editor for TechTarget, BetaNews, and Ziff Davis. Her stories have also appeared in dozens of other major tech publications, including CIO, Linux Planet, and PC World. Jacqueline holds a B.S. degree in mass communications from Emerson College, with a journalism concentration. From 2017 to the present, she has served as a contributing editor to SD (Software Development) Times.