What is Domain Testing in Software Testing? (with Example)

By : Thomas Hamilton Thomas Hamilton
Hours Updated

⚡ Smart Summary

Domain testing checks an application by feeding it the smallest useful set of inputs, covering valid, invalid and boundary values, and confirming that only values inside the accepted range produce the required output.

  • 🔘 Core idea: Split each input domain into equivalence classes and test one representative value per class, not every possible input.
  • ☑️ Boundary focus: Values at a class edge, and just outside it, expose off-by-one defects far more often than mid-range values.
  • ✅ Paired techniques: Equivalence class analysis decides the grouping; boundary value analysis decides which member of each group to run.
  • 🧪 Worked example: A ticketing module assigning competitions by age and gender reduces four age classes to a short, high-value test set.
  • 📈 Knowledge dependency: Judging whether an output is correct needs business rules, so the technique suits small, well-understood chunks of logic.
Read More

Domain Testing in software testing with equivalence classes and boundary values

What is Domain Testing?

Domain testing is a software testing process in which the application is tested by giving a minimum number of inputs and evaluating its appropriate outputs. The primary goal of domain testing is to check whether the software application accepts inputs within the acceptable range and delivers required output.

It is a functional testing technique in which the output of a system is tested with a minimal number of inputs to ensure that the system does not accept invalid and out of range input values. It is also treated as one of the important white box testing methods. It further verifies that the system should not accept inputs, conditions and indices outside the specified or valid range.

Domain testing differs for each specific domain, so you need domain specific knowledge in order to test a software system.

Simpler Practice of Domain Testing

In domain testing, we divide a domain into sub-domains (equivalence classes) and then test using values from each subdomain. For example, if a website (domain) has been given for testing, we will be dividing the website into small portions (subdomain) for the ease of testing.

Domain might involve testing of any one input variable or a combination of input variables.

Practitioners often study the simplest cases of domain testing under two other names, “boundary testing” and “equivalence class analysis.”

Boundary testing – Boundary value analysis (BVA) is based on testing at the boundaries between partitions. We will be testing both the valid and invalid input values in the partition/classes.

Equivalence class testing – The idea behind this technique is to divide (i.e. to partition) a set of test conditions into groups or sets that can be considered the same (i.e. the system should handle them equivalently), hence ‘equivalence partitioning.’

That simplified form applies for domain testing –

  • Only to tests of input variables
  • Only when tested at the system level
  • Only when tested one at a time
  • Only when tested in a very superficial way

It can be simplified as below:

Variable Valid Class Equivalence Class Invalid Class Equivalence Class Boundaries & Special cases Notes
X 0-100 0
100
<0 -1
>100 101

Explanation:

  • If a field accepts ranges from 0-100, the field should not accept -1 and 101, as they are invalid entries and beyond the boundaries.
  • The field should accept values such as 0, 100 and any number between them.

Building tables like these (in practice)

  • To build an equivalence class analysis over time, put the information into a spreadsheet. Start by listing variables. Add information about them as you obtain it.
  • The table should eventually contain all variables. This means all input variables, all output variables, and any intermediate variables that you can observe.
  • In practice, most such tables are incomplete. The best ones list every variable and add detail for the critical ones.

Domain Testing Strategy

While domain testing, you need to consider the following things,

  • What domain are we testing?
  • How to group the values into classes?
  • Which values of the classes to be tested?
  • How to determine the result?

What domain are we testing?

Any domain which we test has some input functionality and an output functionality. There will be some input variables to be entered, and the appropriate output has to be verified. The diagram below shows that input-to-output relationship.

Domain testing strategy showing input variables flowing into a domain and producing an output

Domain Testing Example

Consider a single input test scenario:

C = a+b, where a and b are input variables and C is the output variable.

Here in the above example, there is no need of classification, nor is any combination of the variables required.

Consider the below multiple inputs and appropriate output scenario:

Consider a games exhibition for children. Six competitions are laid out, and tickets have to be given according to the age and gender input. The ticketing is one of the modules to be tested for the whole functionality of the games exhibition.

According to the scenario, we got six scenarios based on the age and the competitions:

  • Age >5 and <=10, boy should participate in Storytelling.
  • Age >5 and <=10, girl should participate in Drawing Competition.
  • Age >10 and <=15, boy should participate in Quiz.
  • Age >10 and <=15, girl should participate in Essay writing.
  • Age <=5, both boys and girls should participate in Rhymes Competition.
  • Age >15, both boys and girls should participate in Poetry competition.

Here the input will be Age and Gender, and hence the ticket for the competition will be issued. This case is where partition of inputs, or simply grouping of values, comes into the picture.

How to group the values into classes?

Partitioning some values means splitting them into non-overlapping subsets.

As we discussed earlier there are two types of partitioning:

  • Equivalence partitioning – Equivalence partitioning is a software testing technique that divides the input data of a software unit into partitions of equivalent data from which test cases can be derived. In principle, test cases are designed to cover each partition at least once.
  • Boundary value analysis – Boundary value analysis is a software testing technique in which tests are designed to include representatives of boundary values in a range. The idea comes from the boundary.

For the above example, we are partitioning the values into subsets. We are partitioning the age into the below classes:

  • Class 1: Children with age group 5 to 10
  • Class 2: Children with age group less than 5
  • Class 3: Children with age group 10 to 15
  • Class 4: Children with age group greater than 15.

RELATED ARTICLES

Which values of the classes to be tested?

The values picked up for testing should be boundary values:

  • Boundaries are representatives of the equivalence classes we sample them from. They are more likely to expose an error than other class members, so they are better representatives.
  • The best representative of an equivalence class is a value in between the range.

For the above example we have the following classes to be tested:

For example, for scenario #1:

Class 1: Children with age group 5 to 10 (Age >5 and <=10)

Boundary values:

  • Values should be equal to or lesser than 10. Hence, age 10 should be included in this class.
  • Values should be greater than 5. Hence, age 5 should not be included in this class.
  • Values should be equal to or lesser than 10. Hence, age 11 should not be included in this class.
  • Values should be greater than 5. Hence, age 6 should be included in this class.

Equivalence partition values:

Equivalence partition is referred to when one has to test only one condition from each partition. In this, we assume that if one condition in a partition works, then all the conditions should work. In the same way, if one condition in that partition does not work, then we assume that none of the other conditions will work. For example,

(Age >5 and <=10)

As the values from 6 to 10 are valid ones, one of the values among 6, 7, 8, 9 and 10 has to be picked up. Hence selected age “8” is a valid input age for the age group between (Age >5 and <=10). This sort of partition is referred to as equivalence partition.

Scenario Boundary values to be taken Equivalence partitioning values
Boy – Age >5 and <=10 Input age = 6
Input age = 5
Input age = 11
Input age = 10		 Input age = 8
Girl – Age >5 and <=10 Input age = 6
Input age = 5
Input age = 11
Input age = 10		 Input age = 8
Boy – Age >10 and <=15 Input age = 11
Input age = 10
Input age = 15
Input age = 16		 Input age = 13
Girl – Age >10 and <=15 Input age = 11
Input age = 10
Input age = 15
Input age = 16		 Input age = 13
Age<=5 Input age = 4
Input age = 5		 Input age = 3
Age >15 Input age = 15
Input age = 16		 Input age = 25

How do we determine whether the program passed or failed the test?

Passing the functionality not only depends upon the results of the above scenarios. The input given and the expected output will give us the results, and this requires domain knowledge.

Determining the results of the example: the screen below shows the ticketing output for each age and gender combination.

Ticketing output for each age and gender combination used to determine domain testing results

Hence, if all the test cases of the above pass, the domain of issuing tickets in the competition gets passed. If not, the domain gets failed.

Domain Testing Structure

Usually, testers follow the below steps in domain testing. These may be customized or skipped according to our testing needs.

  • Identify the potentially interesting variables.
  • Identify the variable(s) you can analyze now and order them (smallest to largest and vice versa).
  • Create and identify boundary values and equivalence class values as above.
  • Identify secondary dimensions and analyze each in a classical way. (In the above example, Gender is the secondary dimension.)
  • Identify and test variables that hold results (output variables).
  • Evaluate how the program uses the value of this variable.
  • Identify additional potentially-related variables for combination testing, where decision table testing helps.
  • Imagine risks that do not necessarily map to an obvious dimension.
  • Identify and list unanalyzed variables. Gather information for later analysis.
  • Summarize your analysis with a risk/equivalence table.

FAQs

Both labels appear in practice. Classes derived from the specification make it a black box technique; classes derived from the code make it white box. The analysis itself is identical.

It covers error-prone edges with very few test cases. The limits are real: boundaries are hard to pin down precisely, and whole workflows are never exercised, so it complements other methods rather than replacing them.

Equivalence partitioning is one step inside domain testing, which also orders variables, adds boundary analysis, handles secondary dimensions and output variables, and ends in a risk table.

The two overlap without being identical. This article covers input-domain analysis, while industry usage such as healthcare domain testing means testing with sector knowledge, which is still needed to judge expected results.

AI assistants read a requirement and propose candidate equivalence classes, edge values and missing invalid cases. A tester still confirms the real boundaries, since a wrongly inferred range yields a confident but useless test set.

GitHub Copilot writes parameterised test methods once the classes and edges appear in the prompt or the code. Unstated business limits must be supplied by the tester.

Every combination grows multiplicatively, so it is rarely practical. Analyse each variable alone first, then use pairwise or orthogonal array selection for the risky combinations.

Testing only valid classes and skipping negative testing, using an inclusive boundary where the rule is exclusive, and ignoring output variables entirely.

Summarize this post with: