Software Test Case Engineering: Treating Test Cases as a Product (or An Approach for Finding Defects that have Low Albedo Value)

Member Submitted

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”



Alan then takes us to understand how the graphs can be used to negotiate with critical situations and achieve higher satisfactory results with the help of the graphs



Communication Graphs leading to test development
The project was being conducted in a structured testing and development environment, but it was not going well. The development specifications were ambiguous, being produced late, delivered late to the test team, and they were wrong.


Writing test scripts was taking too long and the constant change resulted in too much rework. As a mitigating strategy I produced a number of graphs which I could use to communicate my understanding to the development team. Normally I didn’t use my graphs in this way, but it seemed fairly sensible that if I was using them to understand the system then I could use the graphs to communicate my understanding of the system. The graphs went through quite a few iterations until they were understood by the development team and everyone was satisfied that they represented what the testers could do to the system. The development team also made a few changes to the system as a result of reviewing the graphs as they identified issues with the system or specification. And where the graphs were not complete, we supplemented them with some high level test case descriptions. An unexpected benefit from all this communication was that the development team reported it was the first time they actually had proper visibility into the test process. They had always been too busy to read the test documentation before or plow through dozens of test scripts to see what the testers would be doing. As the project was running to tight timescales, and we still had to plan the testing, the scripts were documented at a high level of abstraction; with an overall aim, the path through the graph to be taken, the test data to be used, and the various test conditions that would be covered.






Alan summarizes variety of benefits of using graphs for testing-



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

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.