02121 Ingeniørarbejde - Softwareteknologi        Januar 2010
Brief note on GUI-testing

By Paul Fischer

Testing a GUI depends on how the whole program is structured. If you use a Model-View-Control approach (and we hope you do) then the test of correctness of the system itself should be done on the model.

The GUI itself should not know much about the problem, e.g., if the user request an operation, the GUI should ask the model whether the move is possible or legal and not check this itself.

Thus testing the GUI comes down to testing the interactive functionality:

• Is the system state always correctly DISPLAYED? (The model makes sure that the system state is valid). Make sure that you generated all essentially different states of of the model.
• Make sure that the possible events and also event sequences have been checked, like first clicking button A then button B and vice versa.
• If you use files, check that everything works if files do not exist, have the same names, etc.
• Is it possible to request every operation?
• Check that all types of operations are possible and correctly displayed.
• Check that you get the expected reaction when making an illegal operation.

Each test-case (identified by a name or a number) should be documented by the following items:

• Purpose: Purpose of test-case
• Pre-state:  Required state of the GUI before the test
• Action:  Activity performed by the user, eg. clicking on a particular button.
• Post-state:  Expected observable state of the GUI after the test action have been performed.

The test result should state whether the expected post-state was observed or not.

A test may consist of a suite of test-cases where the post-state of one case implicitly becomes the pre-state for the next case.