[Home] [Essays] [Book_Reviews] [Tools] [Links] [News] [Blog] [About]

Page 2

1     Introduction. 3

1         Introduction

As a child I hated making models. I would inevitably glue some strange bit of plastic to the table, discover an extra bit of plastic that didn’t go anywhere and paint the shapeless, glue encrusted thing, really badly. My models were always wrong, they never looked like the picture on the box, and worse, they didn’t look anything like the real thing.

But now that I’m a tester, I love models and can’t get enough of them. I use them all the time and show them to everybody. My models are still not correct, fundamentally all models are incorrect, but provided my models are good enough to aid me in my testing and look enough like the real thing, I have no complaints, well, maybe just one or two. Those complaints come down to lack of tool support, but I’ll be explaining how to get round that later on.

The main model I use is the di-graph, the directed graph, which from this point onwards, I will generically refer to as the graph. Graphs are well covered in the testing literature, Beizer has 2 books that cover the subject [Beizer95][Beizer90] and there is additional information in [Binder00]. But the tool support for graphing in testing is minimal.

One of the main reasons for writing this paper is that, and I generalise wildly here, I don’t think that structural graph models are used enough in testing. I certainly don’t encounter many testers using graphs, which is a shame as graphs are well covered in the testing literature, and they are enormously helpful. I could suppose that this might be due to testing tool support, but I don’t really believe that. Perhaps other testers just haven’t been through the same testing experiences as I have? So one thing I’m going to do in this paper is present an account of my use of graphs in testing.

I will recount my early experiences with graphs, documenting lessons learned the hard way so that you don’t have to, documenting my changing thought processes as I learned how to use them effectively and documenting the tools that I have used to support my use of graphs in testing.

The use of graphs in testing is not a panacea, but it is useful, it is a technique that is easy to learn and has numerous benefits. Sometimes I don’t apply it, but you have to learn a technique so that you know when to apply it and when to discount it.

Graphs will be presented as useful models for:

-          deriving test conditions

-          understanding systems

-          communicating the tester’s view of the system

-          automating the production of test scripts

-          assessing a variety of coverage measures

-          visualising and reporting coverage measures

This is not a paper about state transition diagrams or other formal test design techniques. Graphs by their nature are abstract and are only formal in terms of their notation, this paper will show you how to harness that for the benefit of your testing process.

At the end of this paper; or before, if you want to skip to the appendices and start downloading tools, I hope that you will give graphs a try in your testing at the appropriate points. If you need to be convinced about the merits of graphs in testing then keep reading, but first, let me start at the beginning.

Page 2