 |
APPLICATION NOTE: Multiple Synchronization Modes |
|
APPLICATION NOTE: Multiple Synchronization Modes |
While windows-based applications have become the norm, they have increased the complexity for testers verifying an application. Although user interfaces now provide the user with more aesthetic options, the fact that these options can be invoked in any order has created a more complex environment for testing and the inconsistencies across platforms in terms of colors, fonts, screen size, and the general look-and-feel increases that complexity.
There are a variety of modes in which capture/playback tools can be operated. No vendor implements all of the modes today. It is important to understand the strengths and weaknesses of each of these modes. Because testing is not a single task, but a process that goes on throughout the life of an application, each of these modes has benefits at different times during that process.
The first mode is true time capture/playback. With true time, the keyboard and mouse inputs are replayed exactly as recorded by the tester. Playback timing is duplicated from the server's own timing mechanism, allowing tests to be run as if executed by a real user. The results of the tests indicate any variances from the baseline cases, permitting the tester to determine the implication of those differences. Therefore, if a button moved to a different location in the window, it would be flagged as an error. It is then up to the tester to determine the significance of this error. For instance, the movement of a button will effect documentation even though the program still runs as it did before.
The second mode is character recognition. Character recognition allows the test to search for items that may have moved, or changed fonts since testing a previous version of the application. Character recognition helps extend the life of a test script by allowing it to adjust for minor changes in window layouts or fonts being used. The downside of character recognition is that it requires some additional time to create the scripts. It also may pass a test even though an error should be reported. In this case, a button moving may not be caught and the documentation will go out unchanged. Character recognition can also be used to take a portion of a screen image and convert it to ASCII characters to be saved in a file for printing or use in comparison with other values as part of the test verification procedure.
The final mode is widget or object-level playback. With widget playback, the X and Y coordinates on the screen are no longer significant as the application's widgets are activated directly. Widget testing is the only reasonable way to do portability testing. The same test script can run on multiple hardware and operating system platforms. It should be noted that these tests will not check for Graphical User Interface (GUI) correctness, but will check that the application's engine ran successfully. With widget testing, there may be tests that pass despite conditions where a user could not operate the application interface, such as a command button being hidden behind a window. Therefore, even though widget testing has been run, it is still important to do user-level testing, either manually or with the true time capture/playback mode.
Each one of these modes is advantageous at different stages of testing during the software life cycle. We at Software Research believe the ideal solution is to provide a product that advances the user from true time through the other modes automatically. This lets the user have the most powerful set of choices.