Chapter 2: Graphs and Relations
This chapter introduces graphs as the central tool of testing.
Just running through the definitions got me pumped for testing. Every relationship Dr. Beizer described brought about examples in my head from software that I commonly test in my job. Then I saw the Question/Answer of the book. What do you do when you see a graph? Cover it! In 20 years, that has never left me or my test methodology.
I am not an expert on graphing so I did not see anything blatantly left out. I noticed in the undirected links section of definitions that the author didn’t think symmetric relations are not common in testing – I thought that modern software models include load balanced services, as well as multiple threads, which may have those relationships. I have tested those relationships many times.
Regarding the graph types used in testing, I took interest to the those. I felt that the transaction flow model he described doesn’t get enough attention. The finite-state model of menus… modern menus often change based on the current task or context – in the author’s word processing example, one may see a different menu set when editing a table.
While I enjoyed the discussion of transitive/intransitive relationships, I really liked the end. To paraphrase, If specification or programmer is confused about transitivity, then you have a fertile ground for testing.
The examples of the relationship types are helpful. Except the part about equivalence classes. I had to look at 3 web definitions and two YouTube videos before I felt comfortable. Then I reviewed a single partition example and said “oh yeah, I know that.”
The concept of the matrix of relationships between nodes was completely boring, but so much more efficient. If I were modeling with intention to automate coverage of a model, I would use the matrices in some form. But I get why Dr. Beizer says “…the format is cumbersome and error-prone for large matrices.”
The generic testing principles outlined have covered a great deal of my testing lifetime. It’s also the ToC for the rest of this chapter. Each instruction expands to a cookbook for creating a testing tool.
- Define the graph
- Define the relation
- Node Cover
- Link Cover
- Test All Weights
- Design Loop Tests
The instructions are simple, and mostly straight-forward. I didn’t particularly like calling properties as ‘weights’ because I think of weight as a particular type of property. Like the weight might show the likelihood one branch of the graph is used compared to an alternate branch. The author also describes the purpose & significance of each step.
I am not sure the ‘test all weights’ is necessary as a separate step. The properties can be tested within the node cover & link cover. They should be tested there.
In summary, I think this chapter sets up the following chapters by creating vocabulary and tools for them.