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 the, running, test and/or cases:
“People run away from the name subsidy. It is a subsidy. I am not afraid to call it so. It is paid for the purpose of giving a merchant marine to the whole country so that the trade of the whole country will be benefitted thereby, and the men running the ships will of course make a reasonable profit.... Unless we have a merchant marine, our navy if called upon for offensive or defensive work is going to be most defective.”
—William Howard Taft (1857–1930)
“This place is the longest running farce in the West End.”
—Cyril Smith (b. 1928)
“It is the test of a novel writer’s art that he conceal his snake-in-the-grass; but the reader may be sure that it is always there.”
—Anthony Trollope (1815–1882)
“You all know that even when women have full rights, they still remain fatally downtrodden because all housework is left to them. In most cases housework is the most unproductive, the most barbarous and the most arduous work a woman can do. It is exceptionally petty and does not include anything that would in any way promote the development of the woman.”
—Vladimir Ilyich Lenin (1870–1924)