Functional Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 113

software requirements, use cases, only the executable program, and its data.
These requirements are usually met during the middle phases of the development
life cycle when large pieces of code begin to operate together or when software is
purchased from a vendor. If this topic sparks your interest, there are a number of
good textbooks that can give you more details and the results of current academic
research. [34-36]
It is reasonable for anyone (developer or tester) to do the black box test-
ing as long as the person doing the testing is not the person who authored the
code. Software developers usually focus their black box testing on validating
expected behavior of the code (positive testing) against use cases, which gives
them the tendency to ignore unexpected behavior (negative testing). Testers add
value to black box testing by planning and executing both positive and negative
behavior testing because the tester knows that the majority of user-detected
defects arise from unexpected behavior. Much of the research you will find
in black box testing will relate to structured approaches that attempt to pro-
vide 100% positive and negative behavior coverage under certain controlled
circumstances. The best reference for these structured approaches in detail is
Whittaker's textbook.
We will briefl y discuss four generic black box testing techniques.
7.6.1 EquivalenceClassesTechnique
Equivalence class techniques focus on identifying groups of input data that tend to
cause the application under test to behave the same way for all values in the group.
The rationale behind this search for input data test groups is to substantially reduce
the volume of test data needed to verify a specifi c behavior. Two simple examples
will help you understand this rationale better.
The fi rst example is a data fi eld with data values grouped by other character-
istics. Consider the application under test to be a security system with a logon ID
requirement. Furthermore, consider that the security system must validate over
5,000 log on IDs when in production.
The tester might decide to validate every one of the 5,000 logon IDs. Alterna-
tively, if the tester knows that there are only three categories (clerks, supervisors,
and managers) of logon IDs, then perhaps a sampling from each category will
provide suffi cient validation. Consider testing 50 logon IDs from each category.
If any of the 50 logon IDs for a given category is not correctly accepted, consider
increasing the sample size of logon IDs for that category and continue testing. If
the initial sample of 150 logon IDs for all three categories are correctly accepted,
then the tester has achieved the desired test results using only 3% of the possible
test data.
The second example is a data fi eld with a range of possible numerical values.
Consider the application under test to be a hospital admission system, and it is re-
quired to admit patients ranging in age from 1 year old to 99 years old, inclusively.
The tester might decide to test all 99 possible age values. Alternatively, the tester