Whereas Functional Testing test plans are generated from the Requirements documents, Structural Testing Test Plans are generated from the application itself.

Whilst there will always be a significant amount of overlap between the two test plans(Functional and Structural), both should still be created as there are differences in the types of errors captured by each.

The process for creating the test plans is much the same, and the same techniques of Cause Effect graphing or using Excel can be used. However you are working through the application instead of the requirements. So if for instance you have the following Dialogue Application:-

You would work through the application checking the rules on each component and adding them to the Cause Effect diagram as appropriate. However this is not as simple as it first appears as to be able to work through the code of a Dialogue Application you need to be aware of the timing of events.

For a single pass application, the steps are as follows:-

This means that in terms of stepping through the code, rules and formulae with an initialise timing need to be considered before customer timing rules, these in turn come before section based rules and formulae and so on.

This can be especially challenging if there are multiple formulae at the same timing, e.g. multiple Customer Timing formulae. This is one of the reasons that from a design point of view, it is a better idea to have a single formula at each timing point, and this can then be used to set multiple "User" variables.

Once you have your complete set of test cases, these can then be rationalised in the usual manner.

The main thing to remember is that Structural Testing is testing that your code does what you expect the code to do.  It won't check that your documents behave as the business expect but it is useful in terms of identifying any unexpected behaviours.

Next: Make Testing Easy On Yourself