Test Case Design for Automated UI Tests

users to go a long way down a certain single path before they get to the functions we need to test. Starting my tests at arbitrary points in the application is not at all what users see. And, isn't that the point of UI testing?

Imagine if we had a tree with branches instead of a circle with lines. Every test path has to start at the root of the tree and go up the trunk, then down a big branch, then a limb, then a twig, then a leaf. Now, imagine there is a test failure on the trunk path. How many tests fail now? All of them. Imagine a test failure on a big branch. How many tests fail? A significant number.

Maximizing the number of starting locations for your automated tests minimizes the number of automated test failures for any given defect in the application, making failure diagnosis much easier. Take another look at your circle. Every place where one line crosses another is a place where both paths might fail based on a single defect in the application. But, I suspect that your diagram shows that any single defect in the application will affect very few of your lines inside the circle, so you continue to get good information from the paths through the application that are not affected.

It is true that designing tests this way does not emulate a user's experience with the application, but no test automation ever emulates a user's experience. I suggest that proper evaluation of a user's experience takes a skilled, dedicated human being. Test automation serves a much different purpose, and the more effective we can make our automation, the better off we will be.

Adding Features 
Finally, let's go back to our circle and talk about one more advantage of designing automated tests with various starting points and various different paths through the application. Draw another circle, maybe a quarter the size of the big circle. Draw it on top of the big circle, so that part of the new circle is outside the big circle and part is inside the big circle.

This represents a new feature. Outside the big circle you have no lines, no coverage at all. Inside the big circle there are probably a few paths through the UI that are affected by the new feature. Hopefully, there won't be too many, because they are the existing tests that will have to be changed to accommodate the new feature.

Once again, by having many starting points for our tests and many different paths through the application, we have saved ourselves a lot of work when a new feature comes along.

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.