Test Case Design Techniques: How Can Flowcharts benefit testers?

Reading Time: 3 minutes

Flowcharts have been around a while but the benefits for testers of flowcharts has yet to ascertained. In this post we look at how flowcharts can benefit testers and tech case design techniques in the everyday workload.

A new Bloor Research ‘Test Case Generation Market’ report points to flowchart modelling as the method of choice for organizations wishing to improve testing, and foster collaboration between the business and IT.Considering several test case design methodologies, Research Director Phillip Howard concludes that flowchart modelling is the most effective for deriving and maintaining the smallest number of test cases needed to provide maximum coverage. He describes how third party tooling, offering Grid-Tools as his example vendor, now allows non-technical users to easily map requirements to clear, unambiguous flowcharts.

In spite of the simplicity of the design process, these flowcharts contain all the qualitative information about a system enjoyed by other formalized approaches. This means that users can enjoy the benefits of these technical methods, without requiring the technical skill or intimate knowledge of a system.

Like Pairwise approaches, users can reduce the number of test cases while maintaining functional coverage, with Howard describing how test cases can be automatically generated from a flowchart. He offers the example where exhaustive testing would require 210 tests, but pairwise methods reduced this number to just 6.

Further, Howard notes how mapping requirements to a flowchart can incorporate cause and effect modelling. This means that causes, constraints and effects are defined, introducing traceability, so that complexity metrics can be generated.

The greater degree of traceability also makes change requests and maintenance easy. When requirements change, duplicate, redundant or invalid tests can be highlighted and automatically removed.

He also describes how flowchart modelling in particular fosters greater collaboration between the business and IT, where a non-technical user can more easily validate requirements which are represented by a flowchart, than by a graph. By contrast, other formal test case design methods tend to be difficult to implement in practice, and are often inaccessible to the business.

Test Case Design Techniques

Howard notes the high degree of skill required to implement pairwise methods, and how they require prior knowledge of constraints and expected results. In modern applications, no one person is likely to have such intimate knowledge of a system, making comprehensive testing using this method impossible.

Pairwise approaches are also likely to leave the business “gawping” at IT, and so do not score too well based on Howard’s non-technical criterion either. Realistic coverage figures are not possible, as a lack of traceability means that expected results cannot be derived automatically. Howard further notes how users cannot provide design time coverage metrics, either.

This means that a user cannot provide the business with accurate predictions of how long a project will take, or how much it will cost. Communicating the value of a project therefore becomes an uphill battle, while if the project is approved, scope creep and runaway budgets are a likely menace.

By contrast, cause and effect modelling does allow for causes, constraints and effects to be defined, with test cases created from a model or graph. This graph or model is generated from the requirements themselves, introducing traceability, so that complexity metrics can be generated.

However, cause and effect modelling is also difficult to implement in practice. It requires a highly disciplined and consistent approach to requirements gathering, where natural language is used unambiguously. Further, changes made to requirements are hard to implement.

Using Flowchart Modelling

Finally, although Decision Trees incorporate many of the benefits of Flowchart modelling, Howard argues that “flow charts are much more (as opposed to slightly more) amenable to collaboration with business users.”

Flowchart modelling therefore best satisfies Howard’s technical criteria, and most improves harmony between the business and IT. With this in mind, Howard praises Grid-Tools, the only vendor who he believes provides flow chart modelling in addition to combinational techniques and cause and effect modelling. This alone means that “any comparison of product offerings is only going to have one winner”.

Read the full report here

About the Author


Find out more about @georginagt

Leave a Reply