I have learned various theoretical testing methods and test case generations through university's quality assurance course.

One of the techniques that interest me is Graph Coverage which is a theory to visualize each operation (e.g. click a button) as a node and the transition as edge (DAG).

Prime Path Coverage is used to create high coverage while minimizing the number of test cases. This is very useful for functional testing.

For example, if we are to test a web application, the operations that can be done to use the application can be represented as a graph, and we can find the prime paths in the graph in order to derive test cases. We can always use equivalence partitioning to feed in different inputs to the paths to test for correct outputs. The combination of graph coverage and equivalence partitioning can help QA to find the minimum number of test cases that cover the most.

While this method sounds pretty functional on paper, how practical is this technique and how often this is used in the industry?

4 Answers 4


That is an appealing idea but there are serious impediments to making it work:

  • You need to create the DAG. This can be a lot of work. Either you try to crawl the UI to auto-discover the DAG (that's a research project -- see Atif Memon's research at the University of Maryland or you create (and update) the DAG manually, for each release.
  • If you want to test for more than crashes, you also need a model for how the UI should behave, e.g. a state machine. This too can be a lot of work.

In practice, QA teams do not have the time to maintain DAGs and UI models, so they focus on ad-hoc approaches. Making DAG-based testing effective will require better tools than we have today.


No. In my opinion its usage really depends on factors like project nature, development model etc.

  • Such graphs, techniques, methodologies may be used in long-term projects with highly complex and functional application

  • On other hands these could be considered over-kill on a 3-6 months project with a less functional application or in an agile environment

If we talk industry wise, then my wild-guess is usage of such techniques could not be more than 30%. So, while these are not very common but that does not make them 'bookish only. I hope you got the point :)


It's not common in rapid development per project but graphic representation of data, especially front-end, is very useful over a long period of time OR even multiple projects AT a time. My best answer is it's most likely more common in bigger companies with bigger teams as well as cross-team cooperation that agile is/has been inspiring in teams. However if Prime Path Coverage can reduce the number of test cases which in turn reduces test case maintenance AND provide insight into business intelligence and end user experience then I'll bet it's popular in and around forward thinking startups or SMME's.


Such approach might be required is some extreme cases like nuclear power station or software for a space probe (where you have no second chances), but for standard applications (95%) such approach will be overkill.

QA is chronically understaffed, and it is rational business decision. Adding new features gains new customers (and sustains business), while announcement on a yearly industry conference that "despite upgrading to new libraries, our software still works" will not get you much press attention. If your old software has no known bugs (is perfect), while your competitor has just few bugs (no major ones) but features your app is lacking, guess which business will grow and which will stagnate?

So in real world, your goal is not to analyze all combinations of the possible inputs, and test cases covering them, but regression test more common "happy paths", and listen to your customers and fix what is most annoying for them. Usually there is more bugs to be fixed than resources available to do it. So you triage, and some bugs will become obsolete before that got fixed because application changed enough that they are not relevant anymore.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.