Hands-on Examples of Common Test Design Techniques

Test design techniques help every software development project improve its overall quality and effectiveness. There’s a multitude of software testing techniques in the automation landscape. Each of them has its own strengths and weaknesses. This blog post will give some of the most popular test design techniques, divided into categories. But first and foremost, I suggest you learn the overview of Test Design Techniques in Software Development before seeing each technique in detail.

Specification-based or Black-box Test Design techniques

Use these techniques to determine the external factors—such as technical specifications, design, and customer’s requirements, etc.—of a software program. Testers view the software as a black box with inputs and outputs. The purpose is to validate the quality and correctness without disrupting the internal details.

• Equivalence Partitioning:
  The idea of this approach is grouping the inputs with the same attributes to partitions. Code is not visible to testers. Your task is to pick one condition out of each partition, which covers all possible scenarios, to execute test cases. If a condition of a partition is valid, other conditions are valid too. Likewise, if a condition in a partition is invalid, other conditions are also invalid. This helps reduce the number of test cases.Equivalence classes can be subgrouped into two:
  1. Positive tests (clean tests):
  – tests based on defined requirements
  – tests based on common circumstances
  2. Negative tests (dirty tests):
  – tests based on errors/defects
  – test based on special circumstances

Example: A 10-character read from the keyboard
Begin -> Read (AAAAAAAAAA) Print -> End
Equivalence classes for “positive” tests:
– All 10 inputs consist of the same character in upper case, repeated for each letter of the alphabet.
– All 10 inputs consist of the same character in lower case, repeated for each letter of the alphabet.
– All 10 inputs are different, mixed case.
Equivalence classes for “negative” tests:
– All 10 inputs are numeric.
– Mixed numeric and alphabetic inputs.
– Embedded blanks
– Input consists of one valid character.
– Input consists of one invalid character.
– Input includes special characters (*, & %, etc.)
– Input consists of 11 characters

• Boundary Value Analysis:
  This is one of the software testing techniques in which test cases are designed to include values at the boundaries. If the input is within the boundary value, it is considered ‘Positive testing.’ If the input is outside of the boundary value, it is considered ‘Negative testing.’ The goal is to select test cases to execute boundary values. In other words, the behavior of Negative testing is more likely to be incorrect than the behavior of Positive testing; and boundaries are an area in which testing is more likely to yield defects.
  Step 1: Identify equivalence classes
  Step 2: Identify the boundary corresponding to each equivalent class
  Step 3:  Create test cases for each boundary value by selecting a point on the boundary.

Example:
If the input value is an array with boundaries of a and b (a <b) then the following test cases can be designed:
– The boundary a
– The boundary b
– Any value smaller than a
– Any value larger than b
– Any value between a and b.
Test each boundary value with a variable

• Decision Table Testing:
  This technique can be used in test design because it helps testers explore the effects of combining different input values when adhering business rules. A Decision Table is a tabular representation of conditions versus test actions. Conditions are considered as inputs, while actions are considered as outputs.
  Step 1: Build a decision table
  Step 2: Build the test case table

Example:

• State Transition Diagrams:
  Using this approach, the tester analyzes the behavior of an application under test (AUT) for different input conditions in a sequence. You can provide both positive and negative input test values and record the system behavior. Any system in which you get a different output for the same input is a finite state system.
  Step 1: Modeling the system with the finite state machine or state transition diagram
  Step 2: Build the State Table to review the state transition that can cause errors
  Step 3: Design test cases from the State Table and the diagram

Example:

• Use Case Testing:
  Use case testing is a functional testing technique, meaning programming skill is not required. It helps the tester determine which test scripts are executed on the entire system from the beginning to the end of each transaction.
  Step 1: Identify all scenarios from Use Case
  Step 2: For each scenario, define at least one test case and the condition set for that test case to be executed
  Step 3: For each scenario, determine the test data for the test

Example:

Structure-based or White-Box techniques

This is a testing method in which the internal structure of applications is transparently seen and tested. The tester chooses inputs to exercise paths through the code and determines the appropriate outputs. Programming knowledge is required.

• Statement Coverage or Line Coverage:
  In this technique, every statement in the source code is executed at least once. Thereby, we can check what the source code is and is not expected to do. However, we cannot test the false condition in the source code.
  Statement coverage = (No. of statements Executed/Total no. of statements in the source code)*100

Example:

You can execute all statements by writing a single test case through the a-c-e. That is, by placing A = 2, B = 0 and X = 3 at point a, each statement will be executed once (in fact, X can be assigned any value).

• Condition Coverage or Predicate Coverage:
  Condition coverage is seen for Boolean expression. Condition coverage ensures whether all the Boolean expressions have been covered and evaluated to both TRUE and FALSE.

Example:

There are 4 conditions: A> 1, B = 0, A = 2, X> 1. Thus, test cases are needed to promote states where A> 1, A <= 1, B = 0 and B <> 0 are present at points a and A = 2, A <2, X> 1, X <= 1 are present at point b. The full number of test cases that meet the criteria and paths that are passed by each test case are:
1. A = 2, B = 0, X = 4           a-c-e
2. A = 1, B = 1, X = 1           a-b-d

• Decision Coverage or Branch Coverage:
  Test coverage criteria require enough test cases so that each condition in a decision takes on all possible outcomes at least once, and each point of entry to a program or subroutine is invoked at least once. That is, every branch (decision) is either true and false. It is helpful to invalidate all branches in the code to make sure that no branch leads to any abnormal behavior.

Example:Decision coverage can be achieved by at least 2 test cases covering the a-c-e and a-b-d or a-c-d and a-b-e. If we choose the second possibility, then the two test-case inputs are A = 3, B = 0, X = 3 and A = 2, B = 1, X = 1.
Decision Coverage is more powerful than Statement Coverage but is still weak. For example, only 50% chance is that we will find the path where X is unchanged (for example, only if you choose the first possibility). If the second decision fails (if x<1 instead of x>1), this error will not be detected.

• Multiple Condition Coverage:
  Every combination of ‘true’ or ‘false’ for the conditions related to a decision has to be tested in this technique.

Example:
if {(X or Y) and Z} then
With this condition, we have the following test cases:
TEST CASE1: X=TRUE, Y=TRUE, Z=TRUE
TEST CASE2: X=FALSE, Y=FALSE, Z=FALSE
TEST CASE3: X=FALSE, Y=FALSE, Z=TRUE
TEST CASE4: X=FALSE, Y=TRUE, Z=FALSE
TEST CASE5: X=TRUE, Y=FALSE, Z=TRUE

Experience-based technique

These  techniques are logically drawn from the experience in designing test cases and test conditions:

• Exploratory Testing:
  Usually, this process is carried out by domain experts. They perform testing just by exploring the functionalities of the application without having the knowledge of the requirements. Testers can explore and learn the system while using these techniques. High severity bugs are found very quickly in this type of testing.
• Error Guessing:
  Error guessing is one of the testing techniques used to find bugs in a software application based on the tester’s prior experience. In Error guessing, no specific rules are applied.

Conclusion

These are only three test design techniques besides the hundreds to choose from. Each one serves best for specific types of problems in software. If we use one test design technique more than the others, our test coverage will suffer. Remember to choose the most suitable technique for your projects, not the most popularly used one.