Test Case Design for Automated UI Tests

[article]
Summary:
In this article, Chris McMahon offers an approach to implementing automated tests at the user interface level in a way that is visually simple and should save a lot of work when analyzing and maintaining tests down the road.

Almost everyone agrees that having automated tests at the user interface (UI) level is worthwhile, but analyzing and maintaining such tests can become very expensive very quickly if the tests are implemented poorly. As you grow your automated UI test suite, consider an approach like the one I'm about to describe.

Consider your application as a circle, where all the application functions are inside the circle and the circumference of the circle provides an arbitrarily large number of access points to those functions.

The Starting Points
On your circle, draw a dot on the circumference. Now, draw another dot on the circumference a good distance away from the first. Now draw one on the circumference between the others. These represent starting places for your automated tests. As an example, let's say that the application you need to test will manage users, money, and time (since a lot of software does exactly that).

If you are testing a Web application, each dot you draw on the circumference of your circle will be represented by a unique URL.

The Destinations
Inside your big circle draw three very little circles in arbitrary places. Label them "U," "M," and "T" in very small letters. Each of these little circles represents an end state of the application.

Now, draw lines from the points on the circumference of the circle to the small circles inside. Each of these lines represents a path through the application. Your automated test will start at the outside of the circle and take a certain number of steps to arrive at a place within the circle.

If the automated test traverses the path through the UI without any assertions failing, then the test will pass.

Draw several more of these paths through the UI within your circle. Label them U1, U2, U3, M1, M2, M3, T1, T2, T3. You have a complex application; it will certainly take more than one test to validate that everything is working correctly.

When you are done, your circle will be covered by a web of lines of various lengths and directions. Some lines will intersect. Some won't. Some areas might have greater density of lines than others. Hopefully, the circle will be more or less evenly covered by lines.

This diagram of paths through the UI is a representation of a well-designed set of automated UI tests. It represents feature coverage, not code coverage. Also, the paths through the application are mostly orthogonal to each other. I'll talk about why this is important shortly, but first let's take a look at what can go wrong.

Objections
One objection goes like this: Regardless of how many starting points I have, every new test has to log on to the application. Why doesn't the diagram show the single login point for every test?

Any routine, repetitive action that does not contribute directly to validating the behavior of the application being examined should be hidden away in a fixture within the test harness. In the case of login, each test should do it upon starting up, so that the tester doesn't have to code those steps explicitly for every single test case.

In fact, any time a tester is forced explicitly to code several test steps over and over to achieve some goal, those steps should become a fixture available with a single call. Another example is Search. A typical search function takes three steps: highlight an input box, type search text, click a Search button. The test harness should expose a one-step "Search" feature for test designers to use.

Another objection goes like this: My application requires

About the author

Chris McMahon's picture Chris McMahon

Chris McMahon is an experienced software tester. He lives in a small town deep in the Four Corners area of southwest Colorado. He is a dedicated telecommuter committed to building and growing high-performing distributed agile software development teams. Email him at christopher.mcmahon@gmail.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!