User Interface (UI) test automation can add tremendous value to any software team’s development and testing processes; however, too often teams pass by UI automation for a number of reasons. In this post you’ll discover what some of the problems around UI automation are,and you’ll learn specific approaches to avoid those problems. You’ll be able to move your focus from chasing intermittent test failures to adding value to your project’s overall quality strategy.
TOO MANY AUTOMATION EFFORTS STRUGGLE OR FAIL OUTRIGHT
UI test automation has long been a bane to software project teams. Smart groups of people are challenged with suites of automated tests that have become extraordinarily brittle and require far too much time to maintain and update when the system under test changes.There’s a common pattern many teams follow when starting off with test automation. Regardless of who you talk to in the
automation industry, they’ll have a story (Or two. Or three.) that mimics the timeline shown.
Teams start off with automation and are excited about learning a new approach for testing. A few tests are written and the team sees some success. After a few weeks though, the team starts to feel friction around intermittently failing tests. The team is also struggling to make their chosen automation tool work properly in their environment.Enthusiasm continues to wane as the problems and maintenance work piles up. Eventually some teams abandon their automation efforts as a sunk value proposition and return to huge lists of manual regression tests.
TOO MANY AUTOMATION EFFORTS STRUGGLE OR FAIL OUTRIGHT
UI test automation has long been a bane to software project teams. Smart groups of people are challenged with suites of automated tests that have become extraordinarily brittle and require far too much time to maintain and update when the system under test changes.There’s a common pattern many teams follow when starting off with test automation. Regardless of who you talk to in the
automation industry, they’ll have a story (Or two. Or three.) that mimics the timeline shown.
Teams start off with automation and are excited about learning a new approach for testing. A few tests are written and the team sees some success. After a few weeks though, the team starts to feel friction around intermittently failing tests. The team is also struggling to make their chosen automation tool work properly in their environment.Enthusiasm continues to wane as the problems and maintenance work piles up. Eventually some teams abandon their automation efforts as a sunk value proposition and return to huge lists of manual regression tests.
COMMON PROBLEMS
Make no mistake, UI automation is a very difficult problem domain. The technologies used for applications’ UIs can be hard to work with, the tools for automation can be difficult, and UI development practices can add to the burden. Intermittently failing tests are the leading problem for teams. A developer and/or tester works hard to automate a test around a new feature, only to see the test failing in the testing environment. Troubleshooting in the tester’s environment leads only to frustration when the test passes locally. Brittle tests also cause rampant headaches for teams: one
small change to the UI, sometimes a change that doesn’t impact the visible page, can cause tens or even hundreds of tests to fail. Fixing the failing tests can take hours or days due to critical information being scattered across every test. Additionally, tests occasionally have an extraordinary amount of duplication in them because testers have copied the same test over and over while simply changing a few input parameters and the expected output condition.
IDENTIFYING ROOT CAUSES
The common problems listed above tie back to a number of common root causes. For example, intermittently failing tests nearly always trace back to two issues: badly defined element
locators, or synchronization issues when dealing with dynamic content such as AJAX or JQuery-like frameworks. Additionally, talented developers writing automation scripts too often forget basic software engineering/craftsmanship principles such as Single Responsibility Principle (SRP) and Don’t Repeat Yourself (DRY). Getting a solid handle on these specific areas will ensure your
test suites are providing value to your team instead of sucking the life and morale out of your project because of their maintenance costs.
Please click here to read more on this topic.
0 comments:
Post a Comment