What is Black Box Testing? Advantages & Techniques

What is Black Box Testing ??

Black-box test techniques also known as behavioral or behavior-based techniques in software testing the method in which internal structure/design/working of the system is not known to the tester and test cases are based on an analysis of the appropriate test documents (e.g., formal requirements documents, specifications, use cases, user stories, or business processes).

These techniques are applicable to both functional and nonfunctional testing. Black-box test techniques concentrate on the inputs and outputs of the test object without reference to its internal structure.

Common characteristics of black-box test techniques include the following:

Ø Test conditions, test cases, and test data are derived from a test basis that may include software requirements, specifications, use cases, and user stories

Ø Test cases may be used to detect gaps between the requirements and the implementation of the requirements, as well as deviations from the requirements

Ø Coverage is measured based on the items tested on the test basis and the technique applied to the test basis.

Example of Black Box testing could be a user testing any website like google and verifying the output conditions based on the input provided.

Advantages of Black Box Testing

v Testing can be conducted even by a tester who does not have any programming knowledge.

v Test would be designed and executed more from an end-user point of view.

v Testing can also be done by an independent/unbiased person.

Black Box Testing Techniques

Now let’s discuss in detail a few black-box testing techniques.

Equivalence Partitioning

In Equivalence partitioning we usually divide test data into partitions (also known as equivalence classes) in such a way that all the members of a given partition are expected to be processed in the same way. There are equivalence partitions for both valid and invalid values.

Ø Valid values are values that should be accepted by the component or system. An equivalence partition containing valid values is called a “valid equivalence partition.”

Ø Invalid values are values that should be rejected by the component or system. An equivalence partition containing invalid values is called an “invalid equivalence partition.”

Ø Partitions can be identified for any data element related to the test object, including inputs, outputs, internal values, time-related values (e.g., before or after an event) and for interface parameters (e.g., integrated components being tested during integration testing).

Ø Any partition may be divided into sub-partitions if required.

Ø Each value must belong to one and only one equivalence partition.

Ø When invalid equivalence partitions are used in test cases, they should be tested individually, i.e., not combined with other invalid equivalence partitions, to ensure that failures are not masked.

Failures can be masked when several failures occur at the same time but only one is visible, causing other failures to be undetected.

To achieve 100% coverage with this technique, test cases must cover all identified partitions (including invalid partitions) by using a minimum of one value from each partition. Coverage is measured as the number of equivalence partitions tested by at least one value, divided by the total number of identified equivalence partitions, normally expressed as a percentage. Equivalence partitioning is applicable at all test levels.

Boundary Value Analysis

Boundary value analysis (BVA) is an extension of equivalence partitioning, but can only be used when the partition is ordered, consisting of numeric or sequential data. The minimum and maximum values (or first and last values) of a partition are its boundary values.

Example of Boundary value analysis would be let’s suppose we have an input field on the screen that accepts a single integer value as an input, using a keypad to limit inputs so that non-integer inputs are impossible. The valid range is from 1 to 5, inclusive.

So, there are three equivalence partitions:

invalid (too low); valid; invalid (too high). For the valid equivalence partition, the boundary values are 1 and 5. For the invalid (too high) partition, the boundary values are 6 and 9. For the invalid (too low) partition, there is only one boundary value, 0, because this is a partition with only one member.

In the example above, we identify two boundary values per boundary. The boundary between invalid (too low) and valid gives the test values 0 and 1. The boundary between valid and invalid (too high) gives the test values 5 and 6. Some variations of this technique identify three boundary values per boundary: the values before, at, and just over the boundary. In the previous example, using three-point boundary values, the lower boundary test values are 0, 1, and 2, and the upper boundary test values are 4, 5, and 6.

Behavior at the boundaries of equivalence, partitions are more likely to be incorrect than behavior within the partitions. It is important to remember that both specified and implemented boundaries may be displaced to positions above or below their intended positions, may be omitted altogether, or maybe supplemented with unwanted additional boundaries. Boundary value analysis and testing will reveal almost all such defects by forcing the software to show behaviors from a partition other than the one to which the boundary value should belong. Boundary value analysis can be applied at all test levels. This technique is generally used to test requirements that call for a range of numbers (including dates and times). Boundary coverage for a partition is measured as the number of boundary values tested, divided by the total number of identified boundary test values normally expressed as a percentage.

Decision Table Testing

Decision tables are a good way to record complex business rules that a system must implement. When creating decision tables, the tester identifies conditions (often inputs) and the resulting actions (often outputs) of the system. These form the rows of the table, usually with the conditions at the top and the actions at the bottom. Each column corresponds to a decision rule that defines a unique combination of conditions that results in the execution of the actions associated with that rule. The values of the conditions and actions are usually shown as Boolean values (true or false) or discrete values (e.g., red, green, blue), but can also be numbers or ranges of numbers. These different types of conditions and actions might be found together at the same table.

The common notation in decision tables is as follows:

For conditions:

v Y means the condition is true (may also be shown as T or 1)

v N means the condition is false (may also be shown as F or 0)

v — means the value of the condition doesn’t matter (may also be shown as N/A)

For actions:

v X means the action should occur (may also be shown as Y or T or 1)

v Blank means the action should not occur (may also be shown as – or N or F or 0)

A full decision table has enough columns to cover every combination of conditions. The table can be collapsed by deleting columns containing impossible combinations of conditions, columns containing possible but infeasible combinations of conditions, and columns that test combinations of conditions that does not affect the outcome.

The common minimum coverage standard for decision table testing is to have at least one test case per decision rule in the table. This typically involves covering all combinations of conditions. Coverage is measured as the number of decision rules tested by at least one test case, divided by the total number of decision rules, normally expressed as a percentage.

The strength of decision table testing is that it helps to identify all the important combinations of conditions, some of which might otherwise be overlooked. It also helps in finding any gaps in the requirements. It may be applied to all situations in which the behavior of the software depends on a combination of conditions, at any test level.

State Transition Testing

Components or systems may respond differently to an event depending on current conditions or previous history (e.g., the events that have occurred since the system was initialized). The previous history can be summarized using the concept of states. A state transition diagram shows the possible software states, as well as how the software enters, exits, and transitions between states. A transition is initiated by an event (e.g., user input of value into a field). The event results in a transition. If the same event can result in two or more different transitions from the same state, that event may be qualified by a guard condition. The state change may result in the software taking an action (e.g., outputting a calculation or error message).

A state transition table shows all valid transitions and potentially invalid transitions between states, as well as the events, guard conditions, and resulting in actions for valid transitions. State transition diagrams normally show only the valid transitions and exclude invalid transitions.

Tests can be designed to cover a typical sequence of states, to exercise all states, to exercise every transition, to exercise specific sequences of transitions, or to test invalid transitions.

State transition testing is used for menu-based applications and is widely used within the embedded software industry. The technique is also suitable for modeling a business scenario having specific states or for testing screen navigation. The concept of a state is abstract – it may represent a few lines of code or an entire business process.

Coverage is commonly measured as the number of identified states or transitions tested, divided by the total number of identified states or transitions in the test object, normally expressed as a percentage. For more information on coverage criteria for state transition testing.

SHARE THIS