Running The Test Cases
At first the strategies were migrated and adapted from the CLI testing strategies. A popular method used in the CLI environment is capture/playback. Capture playback is a system where the system screen is “captured” as a bitmapped graphic at various times during system testing. This capturing allowed the tester to “play back” the testing process and compare the screens at the output phase of the test with expected screens. This validation could be automated since the screens would be identical if the case passed and different if the case failed.
Using capture/playback worked quite well in the CLI world but there are significant problems when one tries to implement it on a GUI-based system. The most obvious problem one finds is that the screen in a GUI system may look different while the state of the underlying system is the same, making automated validation extremely difficult. This is because a GUI allows graphical objects to vary in appearance and placement on the screen. Fonts may be different, window colors or sizes may vary but the system output is basically the same. This would be obvious to a user, but not obvious to an automated validation system.
To combat this and other problems, testers have gone ‘under the hood’ and collected GUI interaction data from the underlying windowing system. By capturing the window ‘events’ into logs the interactions with the system are now in a format that is decoupled from the appearance of the GUI. Now, only the event streams are captured. There is some filtering of the event streams necessary since the streams of events are usually very detailed and most events aren’t directly relevant to the problem. This approach can be made easier by using an MVC architecture for example and making the view (i. e. the GUI here) as simple as possible while the model and the controller hold all the logic. Another approach is to use the software's built-in assistive technology, to use an HTML interface or a three-tier architecture that makes it also possible to better separate the user interface from the rest of the application.
Another way to run tests on a GUI is to build a driver into the GUI so that commands or events can be sent to the software from another program. This method of directly sending events to and receiving events from a system is highly desirable when testing, since the input and output testing can be fully automated and user error is eliminated.
Read more about this topic: Graphical User Interface Testing
Famous quotes containing the words running, test and/or cases:
“What was any art but an effort to make a sheath, a mould in which to imprison for a moment the shining, elusive element which is life itself—life hurrying past us and running away, too strong to stop, too sweet to lose?”
—Willa Cather (1873–1947)
“We do not quite say that the new is more valuable because it fits in; but its fitting in is a test of its value—a test, it is true, which can only be slowly and cautiously applied, for we are none of us infallible judges of conformity.”
—T.S. (Thomas Stearns)
“The world men inhabit ... is rather bleak. It is a world full of doubt and confusion, where vulnerability must be hidden, not shared; where competition, not co-operation, is the order of the day; where men sacrifice the possibility of knowing their own children and sharing in their upbringing, for the sake of a job they may have chosen by chance, which may not suit them and which in many cases dominates their lives to the exclusion of much else.”
—Anna Ford (b. 1943)