3 Practical Lessons Learned and Case Study Conclusions

Scott Ambler, in Agile Modelling [Ambler02] defines the purposes of modelling as communication and understanding. As testers we use graphs to help us understand systems, to communicate our understanding to the rest of the development team, and to define our test cases and test scripts.

Agile models are sufficiently consistent [Ambler02]. This is an important point to note in our usage of graphs as they are not as formal as State Transition diagrams or Petri Nets. Our graphs have a high degree of abstraction and don’t have a formal modelling methodology behind them; the edges are not always events, the nodes are not always states and are sometimes processes. This gives a lot of freedom to model quickly and as required.

For Communication

Rather than have people review hundreds of scripts, which they never seem to manage to get around to doing or doing effectively, they can instead review a handful of diagrams.
Graphs communicate my understanding and help other people understand the systems better.
The cliché is that a picture is worth a thousand words. My experience tells me that a graph can summarise several pages of requirements and development specifications.
Sometimes all that has to be done to prevent defects is draw a graph, show it to the developer and ask a few questions.
Sometimes the graphs will make it into the development documentation for future readers.
Show your graphs to other people, don’t keep them to yourself, they are too valuable for that.
Remember, there is more to a graph than just a picture of a graph. The picture is a visualisation of an underlying representation, and this is what you are communicating, you use the picture as a way of communicating it.

For Understanding

Generally when logic or interaction is hard to comprehend in textual form, I draw a graph. And when I am drawing graphs for understanding I use my favourite tool; Paper and Pen.

For Definition

To support script definition, extra step description information is added to the nodes and edges, to tell the tester what to do when traversing a path through the graph.
Don’t try to model everything in a single graph, use multiple graphs.
You don’t have to model everything in a graph, you do have other test techniques too.
You don’t need to get too detailed, keep your graphs manageable.
If you have a set of test scripts which are similar, consider reverse engineering a model of the scripts as a graph.
Graphs can evolve, and become more detailed, as the project matures.

Tool Usage

Graphs on paper, are easier and quicker to construct than in a tool, particularly during exploratory testing

I particularly recommend flipcharts, or A3 pads, but I have in extremis used A4, A5 and post it notes (which I don’t recommend).

Paper has the advantages:

that it doesn’t crash when the system I am exploring crashes my computer
that I have to swap from window to window,
it is easier to record future paths, when I know there is an edge but I don’t know what the terminating node is
that I don’t feel quite as precious about my model when using paper
that I find it easier to make annotations that a computer tool would find clumsy

The tool adds permanence and the ability to process the graphs further.
Graph tools are generally designed for visualisation not for testing, be prepared to write supplementary tools and documents.
Use tools to automatically lay out the graph
Experiment with a number of tools to find the right one for you, and with all tools, get used to it before you start using it in a time critical testing phase.

Test Design

Test Design is different from Test Script design. A test is something that you want to check. A script tells you how to check it in order to determine if a particular test can be passed. When viewing the test process through the eyes of the Script Meta Model, tests are justifications for traversing a path.
In a structured test process graphs can be used to provide a justification for some of the scope for testing, in session-based testing, a graph can provide a justification for some of the test charters.
The standard way of deriving tests from graphs is by covering the paths through the graph ([Beizer95][Binder00][Beizer90]). Despite the utopian ideals of the Script Meta Model, we will not get all our tests from coverage. The graphs we produce are usually not detailed enough.
We get extra tests from the graph by examining it and identifying the behaviour that is not modelled.
Graphs which are modelled too deeply too quickly can become unwieldy and hard to maintain. There has to be a trade off between understanding, communication, and derivation and this will depend on why you drew the graph, the position in the lifecycle, and probably the toolset that you are using to model the graphs.

Test Script Design

A test script and a test design are different. All test scripts could be automatically generated from a very detailed model, all test designs can not.
In essence we derive paths from the graph. Paths can be described as sequences of edges. Because every edge has a start node and an end node, we only need to use edges.
Paths are generated from graphs by the application of strategies to the graph: e.g. node coverage, branch coverage, predicate coverage, cover all loops twice
When we are covering the paths we are not covering the tests. The script meta model shows us that paths are independent from tests. It is possible to build scripts from paths directly but these scripts do not have the contextual aims that the condition model provides, nor does it exercise the data adequately.
A Path is a script, but it is an uninstantiated script. To become a test script, we need to know the data used and the conditions covered.
When I extend the detail in graphs to make them more suitable for script generation, I try to avoid confusing the graph. So I add any important linking edges by adding them as dotted lines, and making start and end nodes different colours. These extra visualisation attributes are important for retaining the communication benefits.
Give each graph, node and each edge a unique ID that you can use in your path edge sequences and in your cross referencing

Page 4

index: [Page 1] [Page 2] [Page 3] [Page 4] [Page 5] [Page 6] [Page 7] [Page 8]