- my favourite tool; Paper and Pen.
- 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.
- 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