Automated User Interface (UI) testing has a deserved reputation for being a morass of low-value, high-cost pain. Developers are already over-burdened trying to get the work in front of them completed and into the delivery pipeline. Why should they look to take on additional work in helping create functional tests at the User Interface level?
Every developer should care about delivering better value to their customers, regardless whether their customers are internal or external. Better value means the delivered software is in alignment with what those customers true needs are (often not what they asked for). Better value means software that is performant enough in the customer's environment to keep the customer's users happy. Better value means few, if any bugs escaped out to the customer requiring support and patches.
Important sounding stuff, no? And these are just a few of the reasons why developers ought to take interest and have a stake in UI-level testing.
UI testing is time consuming, both for the initial creation and ongoing maintenance. With that in mind, teams that are already busy building the software can't afford to disrupt their current flow for low-value, senseless automation.
Instead, teams should focus on the most critical, high value features. What's keeping your stakeholders awake at night? Generally it's around two broad areas: Can we make money? and Are we going to get sued?
Flippant prose aside, these really are two solid areas to focus on: are the features that impact revenue (or your business-critical work) stable and working? Are you properly securing highly sensitive data? Of course you'd use those as a starting base; the point being: talk with your stakeholders and understand the most critical areas of the system.
Take a shopping cart system as an example. Simple testing of the checkout system UI isn’t enough. You’d want to ensure your integrations with third-party payment providers such as PayPal, Discover, and Visa was rock-solid. If integrations with those providers aren’t working properly then your company is likely losing revenue and incurring extra customer service costs due to failed transactions.
That's the place where you begin building your UI scripts, not automating checks around look and feel or icon placement!
UI tests should be viewed as an extension and companion to other types of testing you are (or should be) doing already. A well-tested system will have a mix of different test types. Lisa Crispin and Janet Gregory use a "testing pyramid" as an example in their book Agile Testing.
Unit tests--those with no dependencies--should make up the majority of automated tests in a system because they're fast to write and run, and maintenance costs are lowest. The middle of the pyramid is integration tests--those crossing service boundaries--since they're slower to run and costlier to write and maintain. UI tests with their high costs should be at the top of the pyramid: a few carefully chosen tests that exercise high-value flows.
Let’s take some examples from computing wages as part of a payroll system. Here’s how things might break out:
These last paragraphs centered on automated tests. You should be having some form of manual testing going on as well! I won't get into the debates around the various schools of testing. Suffice it to say you should have skilled testers exploring through your system alongside your automated tests.
Interactions across boundaries are a frequent source of bugs. It's not surprising because invoking those calls, managing their lifecycle, and handling errors/exceptions is a relatively difficult task. Integration tests help drive great design and solid API behavior across those boundaries, but it's not enough to stop there.
Testing a workflow from the UI all the way down to the database is the final step in ensuring your systems' interactions are behaving properly. Is your UI not updating properly after a CRUD action? An integration or unit test wouldn't have caught that. Is caching interfering with rows in your displayed grid updating? Whoops! Discovering that's the domain of a functional UI test too.
Automation frameworks can also serve as acceptance criteria for new work, regardless of whether you're using some form of specification toolset (See Gojko Adzik's wonderful book Specification By Example) or just tying your automation to acceptance criteria in Telerik TeamPulse.
Cucumber is one popular tool that lets teams create text specifications over the top of drivers like Telerik Testing Framework or WebDriver. Cucumber lets you write things like:
Below is a similar scenario using an automated test in Telerik Test Studio tied to acceptance criteria in TeamPulse.
Using automation in this fashion helps you ensure what you're building is as close as possible to what the customer's actually looking for. You're gaining not only a regression safety net, you're also gaining confidence the system's functioning as your customers expect. You'll also gain a bit of living documentation if you're taking care in how you write your acceptance criteria.
Too often UI tests are seen in the domain of the "test team." Long years of hard knocks and struggling (or outright failing) automation efforts have finally started to bring about some much-needed change in how and where UI tests are being created. Successful teams are bringing testing and development activities and roles much closer together--and many teams are outright mixing them totally in "whole team testing" delivery flows.
Even if developers don't create the UI tests themselves, they're in a great spot to help the automated suites be extremely successful.
Developers can make the UI much more testable by scattering good IDs across critical elements. They can also help UI tests deal with tricky asynchronous situations by providing appropriate latches when async calls have completed. Backing APIs to help leverage system functionality for test setup and teardown? Devs are all over that.
As an example, the following snippet of code will update the ID row in a Kendo UI Grid to be based on the ContactName text from a record:
For devs who feel general UI automation isn't cool enough, think about a couple seriously geeky types of testing: Performance and Load. UI testing is the gateway to seeing just how well your system holds up in the real environment. Get a few UI tests in place, and it's an easy step to begin working with CPU utilization rates, cache hits, disk bottlenecks, and time to first byte metrics.
Developers can bring great value to their organizations by learning the fundamentals of UI automation. Even if developers don't do the majority of the UI automation, understanding how the process and tools work means devs can ensure the system is as testable as possible. Devs can lend a hand writing the automation to ensure it's as robust as possible, and they can utilize their system knowledge to help flesh out critical aspects of the test infrastructure.
Tools like Telerik Test Studio's plugin for Visual Studio make it simple for developers to quickly help adding value to their automated test suites. Developers can either quickly add value to automation written by testers, or they can quickly build stable, flexible automated tests themselves. Moreover, developers will see great additional features if they’re also using Telerik UI controls. Wrappers for many Telerik controls provide additional functionality to instantly verify things like row counts in Rad or Kendo UI grids, check the count of nodes in a KendoTreeView, or deal with complex scope changes of elements on the page.
Figure 1: Working with different element scopes in a RadGrid
Figure 2: Quick validation of node count in a Kendo UI TreeView
Have we gotten your interest yet? The next posts in this short series will dive into specifics for some of Telerik’s popular controls. You’ll be seeing more details around Kendo UI and AJAX controls!
Are you finding UI testing useful in your organizations? How are you working together with your testers? Let us know in the comments!
Jim is an Executive Consultant at Pillar Technology. He is also the owner of Guidepost Systems. He has been in various corners of the IT world since joining the US Air Force in 1982. He’s spent time in LAN/WAN and server management roles in addition to many years helping teams and customers deliver great systems. Jim has worked with organizations ranging from startups to Fortune 100 companies to improve their delivery processes and ship better value to their customers. When not at work you might find Jim in the kitchen with a glass of wine, playing Xbox, hiking with his family, or banished to the garage while trying to practice his guitar.
Subscribe to be the first to get our expert-written articles and tutorials for developers!