Do you, as my dev team does, see user interface testing getting more important? What's behind this? What's your advice for doing UI testing well?
A few years ago, I advised teams to keep their UI thin, and keep business logic in the code where it belongs. However, times and technology have changed. Software users expect a fast, rich and easy user interface experience. These days, that often means lots of business logic in the presentation layer and fancy Ajax-y features that guide users quickly to their goals. The need for software to work on many different devices and operating systems adds another dimension of complexity.
My advice is always to get your team together and think of some experiments to try to solve a difficult testing problem such as how to perform adequate user interface testing. Consider what drives value for the business. Do customers value speed over all other qualities? Do the applications need to provide entertainment above all? Is the system at the core of a company's operations? Identify the riskiest areas and start with those.
Developers need to understand the whole picture of each feature and how it relates to the rest of the system. In my experience, it's important to drive UI development with examples, and, where there is much business logic, executable tests. Tests that serve as specifications become living documentation later on. Push test automation down as far as possible. If you can test an algorithm at the unit, API or service level, by all means, do so. But there can be a good ROI on testing business rules at the UI level.
Today's test frameworks and drivers allow us to do powerful test automation at the user interface level. My current team has tests that drive two browsers simultaneously to verify concurrency between sessions, repeating the tests in a variety of browsers. While automation can provide documentation and a safety net for future changes, the UI must still be judged by human senses. Experienced exploratory testers are a must, and they should consider pairing with actual customers or customer proxies to make sure the user experience is good enough.
Be sure to develop your user interface testing features incrementally and iteratively. Have you ever tried to develop a five-step UI wizard only to reach the deadline with four steps completely finished but the fifth step completely missing? That's of no use to anyone. Identify a "thin slice" or "steel thread" through the five steps, and start there. It might be as simplistic as navigating from one page to the next, with no real functionality. But that is code you can write, test, automate tests for and show to your customers. Then you can incrementally flesh it out with more features. You might still be missing a few features by the deadline, but your five-step wizard is usable anyway.
Be sure to measure outcomes once you deliver to production, too. Our jobs don't end with the release. Find ways to get feedback about whether the UI provided an adequate user experience and met business goals. Use that information to drive not only future features, but also your approach to testing them.
Dig Deeper on User acceptance testing
Related Q&A from Lisa Crispin
Agile leader Lisa Crispin explains a more organic, more Agile approach to test reporting. Continue Reading
When it comes to Agile planning, average time over many iterations is a more important metric than individual story estimates. Continue Reading
Most inexperienced Scrum teams overcommit on what they will deliver, and when. Agile leader Lisa Crispin says that does more harm than good. Continue Reading