Talk:Domain testing

This article is terrible.

COMPLETE REWRITE NEEDED

[NOTE: This item is offered for discussion. It makes several unreferenced assertions, and includes dead links to several potential Wikipedia entries which the author feels would be valuable contributions.]

The existing entry confuses three different testing approaches, one of which —— the subject of the topic —— is not even mentioned:

1. "Domain testing is one of the most widely practiced software testing techniques [and provides] a method of selecting a small number of test cases from a nearly infinite group of candidate test cases."
2. "Domain knowledge plays a very critical role while testing domain-specific work."
3. [Not mentioned] "Domain testing is a formalized fault-based method, based in domain theory, for evaluating the congruence between required and implemented bounded input data domains."

The first sentence describes partition testing, a general strategy of which almost all practical test design methods (such as equivalence partitioning, state transition testing, and path testing) are specialized applications. In partition testing, a single member is selected from a partition, a set of values such that any member of the set should force the execution of the identical path through a given test item (i.e., the test item will exhibit the same set of behaviors in response to any member of the set). Domain testing is an implementation of partition testing, but is not identical to it.

The second sentence describes what might be better called domain-driven testing, in which test activities are organised around inherent knowledge of the problem domain, rather than around a formal problem specification or product specification. Domain-driven testing may be associated with domain-driven design of software. Performed by sample end-users working without test scripts and without reference to specifications, domain-driven testing is an important part of acceptance testing and usability testing.

The third sentence offers a definition of "domain testing" as described in much greater detail by authorities such as Boris Beizer (Software Testing Techniques, Black-Box Testing) and Robert Binder (Testing Object-Oriented Systems). This approach was pioneered by White and Cohen ("A Domain Strategy for Computer Program Testing", IEEE Transactions on Software Engineering, Vol. SE-6, No.3, May 1980), with a more powerful (because simpler) version subsequently described by Jeng and Weyuker ("A simplified domain-testing strategy", ACM Transactions on Software Engineering and Methodology, Vol.3, No. 3 (July 1994), pp. 254-270).

In domain testing, the concepts of a "domain" and a "partition" are interchangeable for most purposes. The difference is that "domain testing" (specifically) applies a body of theory regarding domains and domain defects that is derived from mathematics, and which provides precise guidance in the selection of test data values likely to expose defects. "Partition testing" generally, in contrast (including equivalence partitioning) uses heuristic ("trial-and-error") methods to select test data values.

A popular misunderstanding is that domain testing combines equivalence partitioning and boundary value analysis. Equivalence partitioning uses "typical" or "midpoint" values of ordered partitions, which generally offer a very low likelihood of causing the test item to fail. Domain testing avoids the use of such values. Boundary value analysis exploits the proposition that, where equivalence partitions are defined by a set of boundary conditions, it is in defining the partition boundaries that defects are most likely to occur, and boundary values are consequently more likely to cause failures than midpoint values. Domain testing does exploit this concept, but, in order to prevent an exponential explosion of test cases in the case of multi-dimensional domains, tailors its use according to the likelihood of specific types of boundary defect.

Multi-dimensional domains are characterized by the interaction of partitions defined across two or more input variables (e.g., a specified range of heights versus a specified range of weights). The general strategy for a domain of any number of dimensions (in its simplified form) is to test the boundary values of each dimension in turn, holding the values of all other dimensions (if any) at "midpoint" values. This strategy will be adequate for most commonly-encountered domains, but variations exist which may apply i special cases (e.g., computed or irregular boundaries).

Donmillion (talk) 14:38, 16 April 2014 (UTC)