Domain Testing Explained In Simple Terms

Domain testing is the most frequently used strategy among QA specialists. The different kinds of domain-based testing techniques are used for checking all kinds of programs and applications you may think of, from the simplest games to the most complicated banking equipment.

How is that possible? The answer is very simple. QA specialists can’t afford to run all the existing tests to define possible weaknesses. That’s why they choose a couple of powerful tests that are going to represent the rest – the most likely and the most dangerous hypothetical situations.

Here is your simple explanation of domain testing in software testing with example.

What is domain testing?

Domain testing is an approach based on dividing the range of possible values of a variable into sub-ranges (software testing domains) with the subsequent selection of one or more values from each domain for testing.

To put it simply, in domain testing you think about all the possible tests of certain functions, then group them into sets of smaller tests. The next step is to check cases from each subset, one by one.

Input domain testing uses a minimum number of inputs to check the output of a system. The purpose of this process is to prove that the tested system will accept only certain inputs that lie within the acceptable range. The system is expected to deliver the required outputs only and block any invalid input values. Everything that happens between input and output is a mystery at the beginning of the process.

Despite the wide range of fields for application, the significance of domain testing in software testing methodologies shouldn’t be underestimated. This technique helps to reduce the range of tested values without losing the effectiveness of testing. The correct application leads to a decrease in the number of tests without affecting the quality of testing.

Read more: How to Improve the Quality of Software Testing – 7 Effective Ways

What is domain software?

Let’s take, for instance, the financial sphere. Banking apps can be used by a wide variety of people regardless of their occupations or other things. The solutions developed specifically for banks and corporations that specialize in finances do belong to domain software. These are the programs that make the functioning of those establishments possible and won’t be used anywhere else beyond. Just like that, health apps you download on your smartphone are not domain software, but the programs installed on hospital computers and tablets are.

What is meant by domain knowledge?

Domain knowledge is a good understanding of a particular sphere. It means that a person is familiar with specific terms and different nuances of the discipline.

Domain knowledge is a huge advantage for a QA specialist. It helps to reduce the delivery cycle and shorten development time, improve customer service and enhance flexibility. Very often this value doesn’t expire after a particular project ends. For instance, payment domain testing is a part of numerous systems.

For some spheres, domain knowledge is extremely significant, like online banking, retail, healthcare system, etc. So how to get domain knowledge in testing? QA specialists acquire skills and experiences, both theoretical and practical during the working process when trying to get a better understanding of a product you are working on. It is also useful to read specialized literature and check similar software.

What are domain bugs?

It would be logical to suppose that domain bugs are the failures determined during domain testing, and that is true. Nevertheless, you understand this better after you find out how to test for them.

Every domain is defined by its boundaries. It means that during this kind of test, QAs work with the points located directly on the borderlines. Each point allows checking at least two domains at a time, sometimes even more. We focus on different kinds of points to determine all the potential risks:

• Interior point with all other points that are within relatively small distance located in the same domain.
• Boundary point has neighboring points both inside and outside of its domain.
• Extreme point lies between two distinct points of the same domain.
• On point is located straight on the boundary.
• Off point is close to the boundary but usually in the adjacent domain (in close domain boundaries).

Domain Testing Strategy

A testing process always starts with a question. What is the banking domain in software testing? What is insurance domain testing? What domain knowledge does a QA specialist need to handle this specific case? Every domain has boundaries by which it is defined, and points situated near those boundaries are checked during tests.

Domain testing strategy is an attempt by a QA specialist to find answers to the questions:

1. What domain should be tested?
2. How to group the values into classes?
3. What values should I test?
4. How am I going to determine the results?

Domain testing structure

Each software solution has specific points to pay attention to. It is important to identify the variables that are potentially interesting and order them. It doesn’t matter whether a QA assistant decides to start from the smallest and move to the largest or vice versa. When it comes to building the strategy, the process is quite universal. There is a simple step-by-step structure that fits every testing scenario:

1. Decide what can go wrong with boundaries.
2. Find the way to handle each case.
3. Pick several points to test for each recognized error.
4. Use one test point to check the adjacent domains.
5. Check off redundant test points. Start running the tests.
6. Determine if any boundaries are faulty.
7. Verify each boundary of all the domains.

What is domain testing with example?

The best way is to explain domain testing with an example. You already know that the process of input domain testing is about selecting a limited number of test cases from a huge group of possible scenarios (nearly infinite, actually). Some QA experts explain it as a table you are to fill, just like the one below.

Let’s imagine a real-life situation. There is a group of children and a list of activities. They will be awarded tickets to a theme park (or any other entertainment facility) for performing a certain activity. Each will receive a ticket based on the gender and age inputs.

In general, the whole entertainment functionality is subjected to the test. Ticketing is one of the domains, on which we are going to focus. Age parameters will be our boundary values that allow building numerous possible scenarios. This is what we know currently:

• Children younger than 5 years old are to tell a poem.
• Boys between 5 and 10 years old are to draw something.
• Girls between 5 and 10 years old are to sing a song.
• Boys older than 10 are to compete in sports.
• Girls older than 10 are to participate in a quiz.
• Everyone older than 15 is to write an essay.

Based on the described above algorithm, a QA specialist groups the values into classes – age groups. After that, it is time to pick the boundary values – the highest and the lowest age value in a group. The next step is building scenarios with the expected results for each. Schematically, it will look like this:

Domain testing by UTOR

Domain testing in software testing is a simple and challenging task at the same time. This strategy is based on knowledge, experience, sometimes on creativity and serendipity. The domain testing example explained above proves that QA specialists have some superpowers – to predict software behavior and protect users from troublesome situations.

Worried about insecurities the boundary points might hide?

Just leave a message, and we’ll check your product for domain bugs and likely behaviors.