Software test professionals often face challenges and complain that, writing test cases or test scripts takes enormous time and results into huge rework when the specifications change in the rapid development or agile development environment.
In software testing, test cases are the core deliverables of the test artifacts, more like a source code that gets delivered as the end result of a software program. Often, project managers, test managers or internal stake holders advise tester to ignore test documentation in the rapid development environment and rather ask them to continue with only exploratory or random testing to minimize testing efforts, later resulting into several production issues. Avoiding test cases is as good or as bad a not writing the source code at all. Imagine a program without the source code or a PC without hardware!!!
Test flow diagrams (TFD) is a graph based techniques which is one of the solutions to particular situations aimed at reducing gigantic set of test cases that are often descriptive although enormously helpful. The use of graphs is not a breakthrough in software testing nor have software test professionals studied this technique during their academic curriculums. These techniques are not widely used or used enough in software testing as much as they are used in software design flow diagrams or use case diagrams.
By graphing a set of features, one can easily use path coverage techniques to construct robust test cases that are able to evidence a higher degree of insight into the test specifications and also easily identify gaps during requirement coverage analysis. The Graphing technique is an approach to test design that promotes modularity and completeness. The graphical nature of the TFD gives producers, developers, and testers the capability to easily review, analyze, and provide feedback on test designs. Few companies create test cases based on TFDs, while few do not create test cases. They feel that, instead of maintaining a set of test cases or test scripts, it is easier to rework a test flow diagram for frequent specification changes that normally occur in an agile development environment. Ideally we use these techniques where the features include any of the below:
Test flow diagram can consist or support numerous modeling methodologies like State Transition Diagrams, Flow Charts, Petri Nets etc.
A test flow diagram should represent the tester’s interpretation of the behavior and flow of the software. A Test flow diagram is created by assembling various test components of a system called elements which is then interconnected or connected called as flows according to the defined business rules based on requirement specifications and the positive, negative and exceptional test scenarios. The elements may comprise of objects, events, states, actions and behavior of the software program. Every test flow diagram has a starting and termination point much like the ones represented in flow charts and use cases.
Test flow diagrams are graphical models that represent the object’s behavior within an application from a tester’s perspective.
These graphs present useful models for:
Generally a test flow diagram has more to a graph than just a picture of the graph. In a structured test process, test flow diagrams provide a justification for the scope of testing and testing charters.
Compiled by Multiple Authors
Comments by readers will be forwarded to the author. Response to comments will be posted subject to the editorial guidelines & policies of Rishabh Software.
Want to know about how following the best practices for software testing can help your next software application? Feel free to Get in touch with us to know how our dedicated software testing team can certify your applications and deliver optimum quality.