Practical examples of using software testing techniques, p. 1

software testing techniques examples

Testing techniques allow processing requirements (testing conditions) into test cases. They help define the “flows” and test data, and can be divided into black box, white box and experience-based techniques. In this part of the article we’ll introduce them all, and then focus solely on the black box testing, providing valid, practical examples.White box and experience-based techniques will be discussed in the second part of the series.

Black box testing

Tests based on these techniques concentrate on launching a program in conditions that are maximally similar to the natural ones (actual system handling). One of black box advantages is no need to acquire skills such as analyzing and reading code.

We can distinguish:

  • equivalence partitioning
  • boundary value analysis
  • cause-effect decision table testing
  • state transition testing
  • use case based testing
Pic. 1 Black box testing [own study]

White box testing

They can be used regardless of other techniques (e.g. during unit tests), but they work best as a black box testing supplementation. After creating a test set based on specification, we analyze which structural elements of the code were not covered with these tests and the test suite is completed with cases that cover the missing fragments. The basis of creating tests in the structure-based technique is code. These techniques — as the name suggests — focus on the software’s structure and not on its functionality. That’s why they are not a sufficient testing method — they don’t use specification to design tests.

We can distinguish:

  • code statement testing and coverage
  • decision testing and coverage
Pic. 2 White box testing [own study]

Experience-based testing techniques

  • bugs guessing
  • explorational testing
  • checklist-based testing

Black box — techniques and examples

Equivalence partitioning

One of the fundamental rules of testing states that it’s not feasible to perform a thorough testing. Thanks to the equivalence partitioning technique, we can reduce a potentially unlimited set of test data to a finite number of cases with an equal number of equivalence classes.

Boundary Value Analysis (BVA)

Analysing and setting the boundary values is performed to design a test which is aimed directly at the edges of the interval (condition) as they’re usually most error-prone. To choose the boundary values for tests, we need to select predetermined equivalence classes, and then establish the values located in their boundaries: right before and right after them.

Example no. 1

Here’s a presentation of setting the equivalence classes:

Pic. 3 Equivalence classes and boundary values [own study]

While purchasing 10 pieces of a certain commodity the price stays the same. However, if a client buys more than 10 pieces (e.g. 11), he’s granted with a free delivery. Purchasing at least 50 pieces (from the 50th piece), the customer gets a 10% discount. There’s also a limitation in which a client can’t order more than 99 pieces.

The designated intervals of the equivalence classes according to the dependence described above will look like this:

0 pieces — no purchase,

<1,11) pieces — regular price,

<11,50) pieces — free delivery,

<50,99) pieces — free delivery and a 10% discount,

>99 pieces — it’s not possible to order the commodity.

A closed parenthesis “<” means that the value is included in a certain collection, and an open parenthesis “(“ means that the value doesn’t belong to the collection.

As a result, we have five equivalence classes for tests, their boundary values being: 0, 1, 10, 11, 49, 50, 99, 100.

Equivalence partitioning and boundary value analysis techniques work well while partitioning the collection of possible values for classes and considering them separately. However, their main weakness is that they don’t include combinations of varied input values.

Cause-effect decision table testing

Working out the decision tables, a tester identifies the conditions (usually input data) and the resulting actions (usually output data) of the system. They create array lines in which the conditions are located above and the actions below.

Example no. 2

Steps to proceed:

Step 1. Establishing a subject and elements of tests. In this case, there’s one test subject, and it’s an online store.

Step 2. Derivation of test conditions. Test conditions include conditions and actions. In this example, we can distinguish 4 conditions and 1 action. They add up to five test conditions with the following form:

C1: A customer’s subscription to the mailing database;

C2: A customer gets a discount for subscribing to the mailing database;

C3: The discount is active (it hasn’t been used before);

C4: The products in the basket meet the promotion terms

and one action:

C5: (A1) The 10% discount is charged.

Step 3. Derivation of the coverage elements. The decision table allows defining the coverage elements. Table no. 1 describes the decision rules of the discussed case.

Table 1. A decision table for an online store

where *= condition irrelevant

Step 4. Defining test cases.

Final tables have been transformed into a table of test cases, presented in Table 2.

Table 2. Test cases

An example for opening a TC2 test case

State transition testing

Pic. 4 State transition diagram. General model of states and transitions between them [own study]

A general model of states and transitions between them is presented in the Pic. 4. The system in state 1 transits into state 2 after the action. This transition is presented with an arrow which goes from state 1 to state 2 as the action happens.

The hypothesis of an error states that errors occur as a result of an incorrect implementation of a software’s actions sequence (e.g. error in the business logic).

State transition tests can be designed to provide a coverage of a typical states sequence, testing all the states or all the transitions, certain transitions sequence or incorrect transitions.

Example no. 3

The assumption was that the application allows only two attempts of entering an incorrect password. During the third try, the system automatically closes the app.

Pic. 5 Diagrams of the state transition in the application for booking a parking space [own study]

The state diagrams help determine correct and incorrect state transitions for testing.

Table 3. State Table Transitions

Use-case based testing

Example no. 4

The name of the use case: Registering for a training.

Description: An employee who has an account on the platform can be registered for a chosen training.

Actors: An employee.

Initial conditions: An employee has to be registered in the system.

Minimal guarantee: An employee is informed that he or she has passed the registration process for training.

Guarantee of success: An employee is registered for the training and has all the necessary materials.

Main scenario:

  1. An employee chooses a training and registers for it.
  2. An employee gets information about the finished process of registration and is provided with the necessary materials.

Alternative scenario:

(SA1) An employee who is not logged in cannot register for the training.

(SA2) An employee is in the middle of registering for the training, loses a web connection and is informed about an interrupted process of registration.

Table 4. Table of test cases for the main and alternative scenario of the use case of Registering for a training.

In test cases, the tests refer to scenarios (requirements), so the coverage will always be 100%.

The last example of black box technique finishes the first part of the article. In the next one, we’ll describe other software testing techniques, such as white box testing and testing based on experience.

human-centric software design & development. check out our website: www.iteo.com