Script-based test automation tools have been around since the early 1990s. In fact, Microsoft’s Visual Test 1.0 was released in 1992. And many of the tools we have now originate from that time. Since QTP, Rational Functional Tester, Winrunner, and many others take advantage of framework types to automate GUI testing. These frameworks in the last two decades have undergone drastic changes. They have evolved in the search to improve test automation. They have matured to minimize maintenance overhead, provide highly tested and reliable test scripts, and offer simpler ways to build test automation. In this article we will limit our scope to these frameworks and review why they faded into obscurity.
Recording and playback:
While this involves little to no code writing, the manageability of automation code makes record/playback only viable on a small scale. The fundamental problem with this approach is literally the problem of scale. If we want another automated test, we’ll register another script which will eventually result in two scripts being kept as the interface of the AUT has changed over time. The more tests we log, the more automation code needs to be maintained, which will become too heavy a burden on the test budget. In record and playback, each automated test case is a sequence of actions with encoded test data. This is not a good approach according to software engineering principles in the first place. Second, automation recovery starts when we play the same automation to test subsequent versions of the app. But, in this approach, each test is executed once per version and is not used repeatedly to increase test coverage. Therefore, managing such automation code makes this approach impractical for large-scale automation. Therefore, just because of the cost of maintenance, test automation has gone from record and replay.
Data Driven:
Compared to recording and playback, the data-driven framework addresses two main pain points: maintainability and test coverage. The test data is stored in a separate file that is read by the script for use as input to AUT. Each script is written and maintained by test specialists, but can be used repeatedly with different data sets to increase test coverage. This also imparts confidence in the reliability of the script. But, the test is not just about entering data. It involves simulating real life trading scenarios to test the AUT thoroughly. Therefore, testers need the facility to specify the actual tests. They need an approach to specify which data to use and from which data file.
Keyword driven:
This takes test automation to the next level. Now it is not the script that drives the test, but the test data itself. The test data with the use of keywords sequences the actions to be followed. When the automated test case is executed, it will read the test data and call the relevant script specified by the keyword, AUT passing the data for that line. Therefore, keywords are scripts written by test specialists to perform all actions necessary to test the business/functional task for which this script was written. With this approach, testers have full control over what to do and in what order. But, the development of the automation code is still specific to AUT. The speed and amount to which the AUT UI is subjected changes, as does the maintenance of the scripts. Therefore, for large-scale test automation, we still need to find ways to decrease the need to maintain scripts on a regular basis.
UI object map based on:
In the quest to improve test automation, the UI Object Map framework solves all three test automation challenges. It addresses maintainability, reliability, and ease of test script development. This framework takes instructions from test data, recognizes the object class to act on, and then performs the specified action on that object by calling a script for that particular object class, passing actions and data to it. This means that the scripts are no longer AUT-specific, but specific to the UI object class. There is no script for a specific instance of an object but for the class of the object. Once the script for a UI object class is written, it can be reused in any automation project that uses this UI object class. Through this framework, scripts automate the UI object class. And every time the AUT is modified, you only need to change the object map and data, not the scripts for the UI object class. The only time this should be changed is when new UI objects are introduced or when the behavior of the existing UI object class changes.
