What
"A test case design technique in which test cases are designed to execute paths of a component."
BS 7925-1.British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST)

Testing paths through a component is largely a white box test technique. This is because the tester needs access to the code. have access to the code. Typically path testing would be conducted towards full component 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. This does not necessarily mean that all the paths must be tested. Only those that will a) satisfy us that the requirements of the components have been met, and b) enable us to give credible technical and business information to stakeholders for confidence.

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?

Path testing is primariliy a dynamic analysis activity.

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. (Assuming the 100% path coverage is not the target.) The decision on which paths to test should be derived from the requirements. With experience an element of risk assessment can be entered.

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 100% path coverage.

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.