4.3 Specification based or black-box techniques (K3)

In the Functional or Black-Box approach, also called Behavioral Testing, we derive test data from the specified functional requirements without regard to the final program structure. It is also termed data-driven, input/output driven, or requirements-based testing. Black box testing mainly refers to functional testing, because we are concerned only with the functionality of the software module. In testing, we exercise various inputs and compare the outputs against specification to validate the correctness. We derive all test cases from the specification and do not consider the implementation details of the code.

In Black box testing we focus on evaluating the function of a program or application against its specification. Specifically, this technique determines whether the combination of inputs and operations produce expected results. As a result, input data is critical for black box test cases.

4.3.1Equivalence partitioning (K3)
Inputs to the software or system are divided into groups that are expected to exhibit similar behavior, so they are likely to be processed in the same way. Equivalence partitions (or classes) can be found for both valid data and invalid data, i.e. values that should be rejected. Partitions can also be identified for outputs, internal values, time-related values (e.g. before or after an event) and for interface parameters (e.g. during integration testing). Tests can be designed to cover partitions. Equivalence partitioning is applicable at all levels of testing.

Equivalence partitioning as a technique can be used to achieve input and output coverage. It can be applied to human input, input via interfaces to a system, or interface parameters in integration testing.

Equivalence partitioning is based on partitioning the inputs and outputs of a system and exercising each partition at least once to achieve coverage. The coverage item is an equivalence partition. For 100% coverage we require to prepare tests that, when executed, exercise every partition.

§ Identify equivalence classes for each input type.
· Range - one valid, two invalid classes.
· Year between 1902 and 2038
§ Exists/constraint (must be) - one valid class (input satisfying constraint), one invalid class (input not satisfying constraint).
· Start date must precede End date.
§ Sub-classes - an equivalence class may be divided into sub-classes if inputs are handled differently depending on value.

Output partitions
Consider the migration of data from one database to the other, where source database fields require a data conversion during the migration. Consider, for example, the Age field, which in the target database is replaced by the Age-band field. Analysis of the two fields reveals that in the source system the field description is: Optional, Numeric. The field may be empty (null), hold a value between 0 and 120 (an age) or have incorrect values in some cases. The target field is defined as a 1 character alphabetic field with field description as Mandatory, Ages banded as A= 0 to 17, B= 18 to 64, C=65 and over.

Thus for Age:
Input partitions: 0-17, 18-64, 65 – maximum
Output partitions: A, B, C, D
Boundaries: 0, 18, 65, maximum age (check value)
Invalid input partitions: non-numeric, null, less than 0, above maximum age (not specified – need to check).
Invalid output partitions: E, null, numeric (not specified, based on tester’s perceptions of what might go wrong, this list may vary, as different testers may choose different examples)

4.3.2Boundary value analysis (K3)
Behavior at the edge of each equivalence partition is more likely to be incorrect, so boundaries are an area where testing is likely to yield defects. The maximum and minimum values of a partition are its boundary values. A boundary value for a valid partition is a valid boundary value; the boundary of an invalid partition is an invalid boundary value. Tests can be designed to cover both valid and invalid boundary values. When designing test cases, a test for each boundary value is chosen.

Boundary value analysis can be applied at all test levels. It is relatively easy to apply and its defect finding capability is high; detailed specifications are helpful.

This technique is often considered as an extension of equivalence partitioning. It can be used on
equivalence classes for user input on screen as well as, for example, on time ranges (e.g. time out,
transactional speed requirements) or table ranges (e.g. table size is 256*256). Boundary values
may also be used for test data selection.

A technique that consists of developing test cases and data that focus on the input and output boundaries of a given function. BVA enhances Equivalence Partitioning by selecting elements just on, and just beyond the borders of each Equivalence Class. Derive test cases by considering Equivalence Classes from output as well as input.

For Example:
For an input field Year range 1900 to 2000, the Boundary Value Analysis in this case would be 1899, 1900 and 2000, 2001. A program that edits credit limits within a given range ($10,000 - $15,000) has Boundary value analysis as:
§ Low boundary plus or minus one ($9999 and $10001)
§ On the boundary ($10000 and $15000)
§ Upper boundary plus or minus one ($14999 and $15001)

4.3.3Decision table testing (K3)
Decision tables are a good way to capture system requirements that contain logical conditions, and to document internal system design. They may be used to record complex business rules that a system is to implement. The specification is analyzed, and conditions and actions of the system are identified.

The input conditions and actions are most often stated in such a way that they can either be true or false (Boolean). The decision table contains the triggering conditions, often combinations of true and false for all input conditions, and the resulting actions for each combination of conditions. Each column of the table corresponds to a business rule that defines a unique combination of conditions that result in the execution of the actions associated with that rule.

The coverage standard commonly used with decision table testing is to have at least one test per column, which typically involves covering all combinations of triggering conditions.

The strength of decision table testing is that it creates combinations of conditions that might not
otherwise have been exercised during testing. It may be applied to all situations when the action of the software depends on several logical decisions.

4.3.4State-transition testing (K3)
A system may exhibit a different response depending on current conditions or previous history (its state). In this case, that aspect of the system can be shown as a state transition diagram. It allows the tester to view the software in terms of its states, transitions between states, the inputs or events that trigger state changes (transitions) and the actions which may result from those transitions. The states of the system or object under test are separate, identifiable and finite in number. A state table shows the relationship between the states and inputs, and can highlight possible transitions that are invalid.
Tests can be designed to cover a typical sequence of states, to cover every state, to exercise every
transition, to exercise specific sequences of transitions or to test invalid transitions.

State-transition testing tests all of the states that an object can have, the events under which an object changes state (transitions), the conditions to fulfill before the transition occurs (guards), and the activities undertaken during the life of an object (actions). State-transition testing is very useful for testing the behavior of individual objects over the full set of use cases that affect those objects. State-transition diagrams are not useful for describing the collaboration between objects that cause the transitions.

The UML notation for state-transition diagrams is shown below:

For those not familiar with the Notation used for state-transition diagrams, some explanation is in order. 

A condition during the life of an object in which it satisfies some condition, performs some action, or waits for some event.
An occurrence that may trigger a state transition. Event types include an explicit signal from outside the system, an invocation from inside the system, the passage of a designated period of time, or a designated condition becoming true.
A Boolean expression, which, if true, enables an event to cause a transition.
The change of state within an object.
One or more actions taken by an object in response to a state change.

State transition testing is much used within the embedded software industry and technical automation in general. However, the technique is also suitable for modeling a business object having specific states or testing screen-dialogue flows (e.g. for internet applications or business scenarios).

4.3.5Use case testing (K3)
Tests can be specified from use cases or business scenarios. A use case describes interactions
between actors, including users and the system, which produce a result of value to a system user.

Each use case has preconditions, which need to be met for a use case to work successfully. Each use case terminates with post-conditions, which are the observable results and final state of the system after the use case has been completed. A use case usually has a mainstream (i.e. most likely) scenario, and sometimes alternative branches.

Use cases describe the “process flows” through a system based on its actual likely use, so the test
cases derived from use cases are most useful in uncovering defects in the process flows during real-world use of the system. Use cases, often referred to as scenarios, are very useful for designing acceptance tests with customer/user participation. They also help uncover integration defects caused by the interaction and interference of different components, which individual component testing would not see.


Post a Comment