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.

In this, 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.

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

Domain testing is the most frequently used strategy among QA specialists. QA specialists can’t afford to
run the entire existing test case set to define possible weaknesses. That’s why they choose a couple of
powerful tests that are going to represent the rest.

Domain

1. An input domain is a set.

2. If the source language supports set definitions (E.g. PASCAL set types and C enumerated types)
less testing is needed because the compiler does much of it for us.
3. Domain testing does not work well with arbitrary discrete sets of data objects.

Domain software

Software built for a specific work domain. Example: health apps that are used on smartphone are not
domain software, but the programs installed on hospital computers and tablets are classified under
domain software.

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.
Domain bugs

It would be logical to suppose that domain bugs are the failures determined during domain testing.
Every domain is defined by its boundaries. It means that during this kind of tests, QAs work with the
points located near directly on the borderlines. Extreme point lies between two distinct points of the
same domain.

Model

1. Before testing, a routine must classify the input and set it moving on the right path.
2. An invalid input (e.g., value too big) is just a special processing case called 'reject'.
3. The input then passses to a hypothetical subroutine rather than on calculations.
4. In domain testing, we focus on the classification aspect of the routine rather than on the
calculations.
5. We can infer that for each case there must be atleast one path to process that case.

Domain closure:

A domain boundary is closed with respect to a domain if the points on the boundary belong to the
domain.

If the boundary points belong to some other domain, the boundary is said to be open.
The importance of domain closure is that incorrect closure bugs are frequent domain bugs. For example,
x >= 0 when x > 0 was intended.

Domain dimensionality:

 Every input variable adds one dimension to the domain.

 One variable defines domains on a number line.
 Two variables define planar domains.
 Three variables define solid domains.
 Every new predicate slices through previously defined domains and cuts them in half.
 Every boundary slices through the input vector space with a dimensionality which is less than
the dimensionality of the space.

Bug assumption:

 The bug assumption for the domain testing is that processing is okay but the domain definition
is wrong.
 An incorrectly implemented domain means that boundaries are wrong, which may in turn mean
that control flow predicates are wrong.
 Many different bugs can result in domain errors. Some of them are:
o Double Zero Representation: In computers or Languages that have a distinct positive
and negative zero, boundary errors for negative zero are common. (IEEE 754).
Negatively signed zero relates to the concept of approaching 0 from below as a one-
sided limit, which may be denoted by x → 0−, or x → ↑0. The notation "−0" may be
used informally to denote a small negative number that has been rounded to zero.
o Floating point zero check: A floating point number can equal zero only if the previous
definition of that number set it to zero or if it is subtracted from itself or multiplied by
zero. So the floating point zeros check to be done against an epsilon value.
o Contradictory domains: An implemented domain can never be ambiguous or
contradictory, but a specified domain can. A contradictory domain specification means
that at least two supposedly distinct domains overlap.
o Ambiguous domains: Ambiguous domains mean that union of the domains is
incomplete. That is there are missing domains or holes in the specified domains. Not
specifying what happens to points on the domain boundary is a common ambiguity.

Consider a games exhibition for Children, 6 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 in for the whole functionality of 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.

o Overspecified Domains: The domain can be overloaded with so many conditions that
the result is a null domain. Another way to put it is to say that the domain's path is
unachievable.
o Boundary Errors: Errors caused in and around the boundary of a domain. Example,
boundary closure bug, shifted, tilted, missing, extra boundary.
o Closure Reversal: A common bug. The predicate is defined in terms of >=. The
programmer chooses to implement the logical complement and incorrectly uses <= for
the new predicate; i.e., x >= 0 is incorrectly negated as x <= 0, thereby shifting boundary
values to adjacent domains.
o Faulty Logic: Compound predicates (especially) are subject to faulty logic
transformations and improper simplification. If the predicates define domain
boundaries, all kinds of domain bugs can result from faulty logic manipulations.
Specified vs Implemented Domains

Implemented domains cannot be incomplete or inconsistent. Every input will be processed, possibly
forever. Inconsistent domains will be made consistent. Conversely, specified domains can be incomplete
and/or inconsistent.

 Incomplete means that there are input vectors for which no path is specified.
 Inconsistent means that there are at least two contradictory specifications over the same
segment in the input space.

Nice domains

Domains are and will be defined by an imperfect iterative process aimed at achieving (user, buyer,
voter) satisfaction.

Some important properties of nice domains are: Linear, Complete, Systematic, Orthogonal, Consistently
closed, Convex and Simply connected.

The bug frequency is lesser for nice domain than for ugly domains.

Linear and non linear boundaries

 Nice domain boundaries are defined by linear inequalities or equations.

 The impact on testing stems from the fact that it takes only two points to determine a straight
line and three points to determine a plane and in general n+1 points to determine a n-
dimensional hyper plane.
 In practice more than 99.99% of all boundary predicates are either linear or can be linearized by
simple variable transformations.
Complete boundaries:

Nice domain boundaries are complete in that they span the number space from plus to minus infinity in
all dimensions.

Following figure shows some incomplete boundaries. Boundaries A and E have gaps.

Such boundaries can come about because the path that hypothetically corresponds to them is
unachievable, because inputs are constrained in such a way that such values can't exist, because of
compound predicates that define a single boundary, or because redundant predicates convert such
boundary values into a null set.

The advantage of complete boundaries is that one set of tests is needed to confirm the boundary no
matter how many domains it bounds.

If the boundary is chopped up and has holes in it, then every segment of that boundary must be tested
for every domain it bounds.

Systematic boundaries

Systematic boundary means that boundary inequalities related by a simple function such as a constant.

For example, the domain boundaries for u and v differ only by a constant. Relations like the following
are required
where fi is an arbitrary linear function, X is the input vector, ki and c are constants, and g(i,c) is a decent
function over i and c that yields a constant, such as k + ic.

The first example is a set of parallel lines, and the second example is a set of systematically (e.g., equally)
spaced parallel lines.

If the boundaries are systematic and if you have one tied down and generate tests for it, the tests for
the rest of the boundaries in that set can be automatically generated.

Orthogonal boundaries

Two boundary sets U and V (See Figure 4.3) are said to be orthogonal if every inequality in V is
perpendicular to every inequality in U.

If two boundary sets are orthogonal, then they can be tested independently

In the example, we have six boundaries in U and four in V. We can confirm the boundary properties in a
number of tests proportional to 6 + 4 = 10 (O(n)).

If the boundaries are tilted, then the intersections are to be tested. From a linear number of cases to a
quadratic: from O(n) to O(n2).

Actually, there are two different but related orthogonality conditions.

Condition 1: Sets of boundaries can be orthogonal to one another but not orthogonal to the coordinate
axes. The first case allows simplifying intersection testing.
Condition 2: Boundaries can be orthogonal to the coordinate axes. This case means boundaries are
functions of single variable.

Closure consistency:

Consistent closure means that there is a simple pattern to the closures - for example, using the same
relational operator for all boundaries of a set of parallel boundaries.

Convex:

A geometric figure (in any number of dimensions) is convex if you can take two arbitrary points on any
two different boundaries, join them by a line and all points on that line lie within the figure.

Nice domains are convex; dirty domains aren't.

You can smell a suspected concavity when you see phrases such as: ". . . except if . . .," "However . . .,"
". . . but not. . . ." In programming, it's often the buts in the specification that kill you.

Simply connected:

Nice domains are simply connected; that is, they are in one piece rather than pieces all over the place
interspersed with other domains like with more “buts” and “excepts”, etc in the specifications.

Simple connectivity is a weaker requirement than convexity; if a domain is convex it is simply connected,
but not vice versa.

For example, suppose we define valid numbers as those lying between 10 and 17 inclusive. The invalid
numbers are the disconnected domain consisting of numbers less than 10 and greater than 17.
Ugly Domains

 Some domains are born ugly and some are uglified by bad specifications.
 Every simplification of ugly domains by programmers can be either good or bad.
 Programmers in search of nice solutions will "simplify" essential complexity out of existence.
Testers in search of brilliant insights will be blind to essential complexity and therefore miss
important cases.
 If the ugliness results from bad specifications and the programmer's simplification is harmless,
then the programmer has made ugly good.
 But if the domain's complexity is essential (e.g., the income tax code), such "simplifications"
constitute bugs.
 Nonlinear boundaries are so rare in ordinary programming that there's no information on how
programmers might "correct" such boundaries if they're essential.

Ambiguities and Contradictions:

 Domain ambiguities are holes in the input space.

 The holes may lie within the domains or in cracks between domains.
 Two kinds of contradictions are possible: overlapped domain specifications and overlapped
closure specifications

Simplifying the topology

  The programmer's and tester's reaction to complex domains is the same - simplify
 There are three generic cases: concavities, holes and disconnected pieces.
 Programmers introduce bugs and testers misdesign test cases by: smoothing out concavities
(Figure a), filling in holes (Figure b), and joining disconnected pieces (Figure c).

Domain Testing Strategy:

1. The domain-testing strategy is simple, although possibly tedious (slow).

2. Domains are defined by their boundaries; therefore, domain testing concentrates test points on
or near boundaries.
3. Classify what can go wrong with boundaries, and then define a test strategy for each case. Pick
enough points to test for all recognized kinds of boundary errors.
4. Because every boundary serves at least two different domains, test points used to check one
domain can also be used to check adjacent domains. Remove redundant test points.
5. Run the tests and by posttest analysis (the tedious part) determine if any boundaries are faulty
and if so, how.
6. Run enough tests to verify every boundary of every domain.

Domain bugs and how to test for them:

1. An interior point is a point in the domain such that all points within an arbitrarily small distance
(called an epsilon neighborhood) are also in the domain.
2. A boundary point is one such that within an epsilon neighborhood there are points both in the
domain and not in the domain.
3. An extreme point is a point that does not lie between any two other arbitrary but distinct points
of a (convex) domain.
 4. An on point is a point on the boundary.
5. If the domain boundary is closed, an off point is a point near the boundary but in the adjacent
domain.
6. If the boundary is open, an off point is a point near the boundary but in the domain being
tested.

Testing One Dimensional Domain:

Testing on one dimensional domain is done for closures. The closures can be wrong (i.e., assigned to the
wrong domain) or the boundary (a point in this case) can be shifted one way or the other

 If it is assumed that the boundary was to be open for A. The bug to be looked for a closure error
is that which converts > to >= or < to <=. One test (marked x) on the boundary point detects this
bug because processing for that point will go to domain A rather than B.
 If there is a boundary shift to either the side, then the point from the B domain, where it should
be processed is shifted to A to be processed there.