Test Flowchart
From dis-Emi-A
The test flowchart is a means of describing what is happening from a user perspective, or sequence perspective. In essence it is the combination of a traditional flowchart and a state diagram.
Contents |
States / Transitions
A state[1] refers to a particular point in the program, or step in processing, along with all the current data in the program. To produce a complete state diagram you would need to place paths for all inputs and consider the status of every variable in the system. For all but the most trivial of programs this is simply not feasible at a high level.
Therefore, in a test flowchart we are interested in identifying all of the compatible states. Compatible states are those in which the set of input is the essentially the same, and all paths out of the state are the same. These represent a kind of logical unit, either in an internal sequence, or presented directly to the user.
Example: If presented a dialog with a series of checkboxes and a few action buttons, the full state diagram would require a new state for every combination of every checked/unchecked status of the checkbox. But when identifying compatible states we know that the whole dialog functions as a whole: the inputs all come together, and the actions available (Okay,Cancel) are equivalent for all inputs. In this case we treat the entire dialog as a single state.
Selection of states is sometimes straightforward, and sometimes tricky, depending on exactly what is being tested. The goal of the flowchart is to model the interesting transitions between states for a particular requirement, therefore one doesn't actually select states, rather one selects all the transitions of interest.
Interesting means those actions, or events, which are described in the requirement being tested. Uninterested means those which are primarily incidental and are not the focus of the requirement.
Example testing the print functionality of a program. The requirement indicates the user must chose the print option, which brings up a printer dialog, and then they can print. There are only two interesting transitions here, the loading of the printer dialog, and the request to print. Therefore we only need 3 states to provide these transitions:The manner in which the controls of the dialog function (such as how a checkbox works) are not of interest to this requirement.
- a starting
- a printer dialog
- the actual printed document
Example testing a custom control. The program has a custom control: a combination of checkbox and editbox. The requirements state how this control works, thus the small interactions between clicking and typing are of interest and will be written on the flowchart.
Inputs
Each transition is labelled with a number of an associated input list. This input list contains all of the inputs associated with the given transition.
Refer Input classification
Symbols
The symbols chosen for the test flowchart are from a fairly common set for flowcharts. They have been primarily adapted to accommodate the level of information needed for a test flowchart.
User State
A user perceptible state should be drawn as a rectangle with the description written inside. Such states include dialogs, web pages, or anything else that is a tangible item for the user.
Internal State
An internal state, or an abstract state that only logically exists, should be drawn as a slanted parallelogram.
Transitions
Flow from one state to another should be done with a line with an arrow on the end pointing to the resulting state. At the beginning of the line should be a number in a circle referencing the input list associated with this transition.
Branches / Conditions
Branches are drawn simply as a line away from the transition in which they modify.
The condition for the branch should be written within brackets []. If the branch has no condition then it is assumed it is always followed -- thus allowing the flow to be split.
Actions
User/internal actions which trigger a state transition are written on the transition line.
The convention for user actions is to put the name of the action they performed in quotes (such as the name of the button or link they pressed).
Compounding
If one state has several actions which transition to the same target state, and use the same set of inputs, then all such actions may be written on the same line.
Entry Point
To mark where the flow starts in the diagram a circle is drawn with a standard transition to the initial state. This transition should be labelled as to what needs to be done to get to the first state. It additionally has an input reference (typically 1).
Sequence Diagram
In some cases, where the states and transitions primarily model the communications between parts of a system (with parallel activity) it is better to use a Sequence Diagram as a flowchart.
