What we understand by Path-based Testing (PT)?​

What we understand by Path-based Testing (PT)?

Sadly, terminology in system testing is a bit heterogenic, so to avoid confusion, let us explain first, what we mean by PT in this project.

PT, as we understand it, formalizes one of the essential approaches in system testing – sequencing actions or steps to be taken in a System Under Test (SUT). It typically consists of the following steps

  1. The process or state space of a selected part or aspect of SUT is modeled via a suitable mathematical structure (usually based on a directed graph)
  2. Test engineer selects a test coverage criterion, determining the “strength” of the test cases (however, to be more accurate, we shall rather say “determining the number of test steps and their combinations”)
  3. Test paths are generated by an algorithm from the SUT model. These test paths (test set) satisfy the given test coverage criterion.

In this sense, path-based testing is a subdiscipline of Model-based Testing (MBT).

Compared to test paths created by a manual way, this model-based approach, when managed well, has typical advantages:

  1. Given test coverage criterion is satisfied. Informally speaking, this is a tool to prevent situations where there are parts of the process that are not tested. 
  2. Unnecessary duplications in the test paths are reduced – meaning unnecessary duplications in a test set that are unnecessary to satisfy a given test coverage criterion. Duplications per se are not principally wrong – they may increase the probability of the tests to detect defects. But most of the projects have limited budgets and time and test sets must be optimized. Obviously, removal of duplications is a much better way than random reduction of test paths or not executing them because time dedicated to testing has run out with the deadline.
  3. The process of test creation is faster – in the ideal case, test cases are generated automatically, and the only part that has to be handled is the modeling of SUT processes. Considering a manual alternative to MBT, test engineers still need to create a model of the process to test, even if in their heads. If this, even informal modeling, is missing, don’t expect effective test cases for the time spent, honestly.

Don’t confuse path-based testing as we understand it with control flow (or data-flow) testing

Sometimes, you might find the term “path testing” referring to executing possible paths in the control flow graph of a program. That might cause confusion. We understand path-based testing as a much broader technique applicable to other, more high-level types of tests, including integration tests or end-to-end (E2E) tests.