Automated Testing Institute

I must admit that I am generally not a big fan of automating functional tests through the user interface; especially in well-architected applications where the business logic is separated from the user interface. UI automation, as discussed in Agile Testing: A Practical Guide for Testers and Agile Teams by L. Crispin and J. Gregory (Addison-Wesley 2009), is usually expensive to write and maintain, and typically provides very little return on investment. However, I do understand this isn’t always the case, and in some situations we may not have the ability to test at a lower layer so we must automate functional tests through the presentation layer. I also know that some functional testing through the user interface helps verify logic in event handlers and validates that user interface elements ‘connected’ to the business logic layer are properly handling inputs and outputs.

Scripted tests that navigate the user interface, however, are subject to many challenges and limitations. There are many commercial and free open source tools and frameworks that are available to help testers create automated test scenarios that verify an application under test (AUT) via the user interface. However, many of these tools use a proprietary scripting language and require an artificial abstraction layer between the test code and the AUT. In addition, scripted tests that navigate a user interface via control labels, access key mnemonics, or tab index order are susceptible to failure from changes in the UI; and especially on different language versions. Another limitation of UI scripted tests – specifically those created by record/playback – is the typical prescriptive step-by-step nature of the test design. Prescriptive test scenarios that simply exercise the "happy path" or reuse the same hard-coded test data repeatedly usually provide little value. Click to read the rest