TL;DR
In the previous post, we discussed Graph Node Coverage Criteria. Today we explain how application data fits into Directed Node Graph Coverage. We will introduce you to software testing based on the remarkable book, Introduction To Software Testing by Paul Ammann and Jeff Offutt.
Every program in the world transforms data based on its instructions.
Developers create source code and data that will be accepted and transformed into other data. Software testers analyze application data and create tests that exercise applications in such a way as to reveal important application risks (or their absence).
If you are testing and have not thought much about test data before executing tests, you are doing unskillful testing.
Data Flow Coverage In Directed Node Graph
How to use test data to trigger different paths in Directed Node Graph? Each data value needs a memory where it is stored. Then, that data is set to some value. We say data is now. defined. Can you think of any Chrome browser variable that is set not by you after the moment that you clicked the Chrome icon?
When data is read from the memory location, we say that data is used. Now comes the fun part, definitons and usage could happen on every graph node or edge. We define data flow graph coverage paths that are hitting those definitions and usages.
More fun starts when the developer forgets to define data initial value or when data is not used between two definitions. Coverage for Directed Node graph becomes more complicated when we add to the number of edges and nodes and the number of variables used in the Directed Graph. Add to that variable interaction, and you know that you have enough testing until the end of your life.
But a skillful tester does not want to tests all those combinations; a skillful tester knows how to sample important combinations. With a Directed Node Graph of your application in front of your eyes, this task is much easier.
