Why dialog maps are most beneficial

A dialog map shows the nagivation paths between dialog windows that belong to a certain use case.  In the example dialog map extract below we could leave the message boxes off, since they have no bearing on the number of navigation paths. However, we may have message boxes that give users more options than just to press the 'OK' button.  So, we better always include message boxes.

Fig. 1: Extract from a dialog map

Standard functionality such as the user help subsystem, and exception conditions like “system failure” are not included in the dialog map. The dialog map would become too cluttered and, for reviews with the customer, this level of detail will prove sufficient.  Of course, standard functionality as described in the GUI style guide needs to be demonstrated to the customer but that can be done once using a suitable use case.

A dialog map gives us an opportunity to describe flows of events in a more formal way.  We can attach properties to dialog windows.  Every property description contains a description of what we need the dialog window for.  Also, we can describe the flow of events within that dialog window.  Our description pattern will exactly follow the pattern we so far use to describe a flow of events at the use case scope. However, our table will only have a few rows.

An example (extract):

	Action
System	Shows information
Account Manager	Authorizes or rejects order

We definitely need a tool to manage the life-cycle of dialog maps.  However, today, there is no tool on the market.  For the time being, UML activity diagrams can be "mis"used to draw dialog maps.  Dialog windows would take the place of activities.

A tool can automatically determine all possible navigation paths through a dialog map. Some of these navigation paths are practically executable while some are only theoretically executable.  A user-executable navigation path is the equivalent of a use case scenario and, at the same time, results in a test case.  A modeler can manually identify non-executable paths and mark them accordingly.

We can generate a test case scenario for every navigation path, be it executable in reality or not.  Non-executable paths become test scenarios anyway.  A test scenario is based on a template.  So, every test scenario describes the state at the start of the test case scenario (eg. order entry window is visible, fields contain default values), the inputs necessary to start the test case scenario (eg. user enters the customer's name), the flow of events and the expected state at termination of the test case scenario.

Test case scenarios can be generated by a tool as skeletons.  Of course, a tool cannot generate everything.  However, it can relieve a designer from the burden of having to manually create all the test case scenarios.  A designer would just need to edit the generated test case scenarios.

There are many other benefits associated with generating test case scenarios.  With an iterative project approach we run a system test in every iteration (if we have produced executable code, of course).  We know from experience that requirements undoubtedly change.  As a consequence, we need to update many test case scenarios according to changes to our specicfications, designs and code. Soon, this will become almost unmanageable and discrepencies between use cases and their associated test case scenarios are a reality. Only utmost discipline would avoid this, but we have never seen this level of discipline in a real-life project.

After changes have been applied to a dialog map we can always regenerate all test case scenarios.  However, the previously edited test case scenarios are gone. So, there is some unavoidable rework. On the other hand, we can be sure that neither a scenario has been forgotten nor that we have a scenario which has no corresponding navigation path any more. 

A simple calculation reveals how much we benefit from generating test case scenarios.  If we consider the dialog map above to result in some 20 or so navigation paths we can easily figure out how much manual work we will save.  If one test case scenario took us an average of 30 minutes to create manually and generation saved 50% of the time required, we instantly see what we gain. 

In large projects, we run into a five digit number of test case scenarios for system test. Thus, thousands of work hours can be saved, let alone that generated test case scenarios are less error-prone and quality is improved tremendously.

© Jenz & Partner GmbH, 2000

Products or trade names are trademarks or registered trademarks of their respective owners