complete path testing

home

Articles

Blog

Books

Tools

Links

FAQ Page

complete path testing

What
A test case design technique in which test cases are designed to execute all the paths of a component.

Testing paths through a component is largely a white box test technique. This is because the tester needs access to the code. Typically path testing would be conducted towards component testing. In addition if complete path testing is done, this will contribute to exhaustive testing

Why?
Components are the building blocks of software. If we can not be sure about their internal workings how can we expect to trust a system that is built from them?

Only by identifying and executing the different paths or routes through the component, can we be sure that all the behaviour the component will exhibit has been tested. For some software failure is simply not an option, typically these are safety critical systems such as medical software. So unlike normal path testing, all the paths through the software are tested.

Who?
Ideally someone with independence from the person who designed and/or coded the component. However this is quite rare and it usually ends up with the developer who did the coding. Not satisfactory, but this is the real world.

Where?
Invariabliy at the developing organisations home site.

When?
Execution of the tests should be as close as possible to the completion of the code.

How?

dynamic analysis where the code is actually exercised is the method here.

Tests can be either manual or automated. Various tools are available including static analyzers and run time analysis tools.

The tester needs to be aware of the various paths through the component. From this he can decide the paths to be tested. This figure is then used to calculate the target for path coverage. of 100%.

All the paths required to ensure the components behaviour is functionally correct. In addition as many alternative paths should be tested. Commonly the first paths not to be tested are those useful in negative testing. This however runs the risk of not exposing serious defects, when the user takes a path that he should not.

The more life or business critical the component or software, the more paths will be tested. Thus a component for the Space Shuttle will probably have path coverage of 100%

In the long run, though path testing has to be part of a wider culture of testability. Analysts and designers need to be aware of complexity. If they continue to demand complex objects, then path testing becomes ineffective due to the number of paths a tester is required to traverse.