On preventing your test suite from becoming too user interface-heavy

In August of last year, I published a blog post talking about why I don’t like to think of automation in terms of frameworks, but rather in terms of solutions. I’ve softened a little since then (this is probably a sign of me getting old..), but my belief that building a framework might lead to automation engineers subsequently trying to fit every test left, right and center into that framework still stands. One example of this phenomenon in particular I still see too often: engineers building a feature-rich end-to-end automation framework (for example using Selenium) and then automating all of their tests using that framework.

This is what I meant in the older post by ‘framework think’: because the framework has made it so easy for them to add new tests, they skip the step where they decide what would be the most efficient approach for a specific test and blindly add it to the test suite run by that very framework. This might not lead to harmful side effects in the short term, but as the test suite grows, chances are high that it becomes unwieldy, that the time it takes to complete a full test run becomes unnecessarily long and that maintenance efforts are not being outweighed by the added value of having the automated tests any more.

In this post, I’d like to take the practical approach once more and demonstrate how you can take a closer look at your application and decide if there might be a more efficient way to implement certain checks. We’re going to do this by opening up the user interface and see what happens ‘under the hood’. I’m writing this post as an addendum to my ‘Building great end-to-end tests with Selenium and Cucumber / SpecFlow‘ course, by the way. Yes, that’s right, one of the first things I talk about during my course on writing tests with Selenium is when not to do so. I firmly believe that’s the on of the very first steps towards creating a solid test suite: deciding what should not be in it.

The application under test
The application we’re going to write tests for is an online mortgage orientation tool, provided by a major Dutch online bank. I’ve removed all references to the client name, just to be sure, but it’s not like we’re dealing with sensitive data here. The orientation tool is a sequence of three forms, in which people that are interested in a mortgage fill in details about their financial situation, after which the orientation tool gives an indication of whether or not the applicant is eligible for a mortgage, as well as an estimate of the maximum amount of the mortgage, the interest rate and the monthly installments payable.

Our application under test - the mortgage orientation tool

What are we going to automate?
Now that we know what our application under test does, let’s see what we should automate. We’ll assume that there is a justified need for automated checks in the first place (otherwise this would have been a very short blog post!). We’ll also assume that, maybe for tests on some other part of the bank’s website, there is already a solid automation framework written around Selenium in place. So, this being a website and all, it makes sense to write some additional checks and incorporate them into the existing framework.

First of all, let’s try and make sure that the orientation tool can be used and completed, and that it displays a result. I’d say, that would be a good candidate for an automated test written using Selenium, since it confirms that the application is working from an end user perspective (there is value in the test) and I can’t think of a lower level test that would give me the same feedback. Since there are a couple of different paths through the orientation tool (you can apply for a mortgage alone or with someone else, some people have a house to sell while others have not, there are different types of contracts, etc.), I’d even go as far as to say you’ll need more than one Selenium-based test to be able to properly claim that all paths can be traversed by an end user.

Next, I can imagine that you’d want to make sure that the numbers that are displayed are correct, so your customers aren’t misinformed when they complete the orientation tool. This would lead to some massive issues of distrust later on in the mortgage application process, I’d assume.. Since we’ve been able to add the previous tests so easily to our existing framework, it makes sense to add some more tests that walk through the forms, add the data required to trigger a specific expected outcome and verify that the result screen we saw in the screenshot above displays the expected numbers. Right?

No. Not right.

It’s highly likely that the business logic used to perform the calculation and serve the numbers displayed on screen isn’t actually implemented in the user interface. Rather, it’s probably served up by a backend service containing the business logic and rules required to perform the calculations (and with mortgages, there are quite a few of those business rules, I’ve been told..). The user interface takes the values entered by the end user, sends them to a backend service that performs calculations and returns the values indicating mortgage eligibility, interest rate, height of monthly installment, etc., which are then interpreted and displayed again by that same user interface.

So, since the business logic that we’re verifying isn’t implemented in the user interface, why use the UI to verify it in the first place? That would highly likely only lead to unnecessarily slow tests and shallow feedback. Instead, let’s look if there’s a different hook we can use to write tests.

I tend to use on of two different tactics to find out if there are better ways to write automated tests in cases like these:

  1. Talk to a developer. They’re building the stuff, so they’ll probably know more about the architecture of your application and will likely be happy to help you out.
  2. Use a network analyzing tool such as Fiddler or WireShark. Tools like these two let you see what happens ‘under water’ when you’re using the user interface of a web application.

Normally, I’ll use a combination of both: find out more about the architecture of an application by talking to developers, then using a network analyzer (I prefer Fiddler myself) to see what API calls are triggered when I perform a certain action.

Analyzing API calls using Fiddler
So, let’s put my assumption that there’s a better way to automate the tests that will verify the calculations performed by the mortgage orientation tool to the test. To do so, I’ll fire up Fiddler and have it monitor the traffic that’s being sent back and forth between my browser and the application server while I interact with the orientation tool. Here’s what that looks like:

Traffic exchanged between client and server in our mortgage orientation tool

As you can see, there’s a mortgage orientation API with a Calculate operation that returns exactly those numbers that appear on the screen. See the number I marked in yellow? It’s right there in the application screenshot I showed previously. This shows that pretty much all that the front end does is performing calls to a backend API and presenting the data returned by it in a manner attractive to the end user. This means that it would not make sense to use the UI to verify the calculations. Instead, I’d advise you to mimic the API call (or sequence of calls) instead, as this will give you both faster and more accurate feedback.

To take things even further, I’d recommend you to dive into the application even deeper and see if the calculations can be covered with a decent set of unit tests. The easiest way to do this is to start talking to a developer and see if this is a possibility, and if they haven’t already done so. No need to maintain two different sets of automated checks that cover the same logic, and no need to cover logic that can be tested through unit tests with API-level checks..

Often, though, I find that writing tests like this at the API level hits the sweet spot between coverage, effort it takes to write the tests and speed of execution (and as a result, length of the feedback loop). This might be because I’m not too well versed in writing unit tests myself, but it has worked pretty well for me so far.

Deciding what to automate where: a heuristic
The above has just been one example where it would be better (as well as easier) to move specific checks from the UI level to the API level. But can we make some more generic statements about when to use UI-level checks and when to dive deeper?

Yes, we can. And it turns out, someone already did! In a recent blog post called ‘UI Test Heuristic: Don’t Repeat Your Paths‘, Chris McMahon talked about this exact subject, and the heuristic he presents in his blog post applies here perfectly:

  • Check that the end user can complete the mortgage orientation tools and is shown an indication of mortgage eligibility and associated figures > different paths through the user interface > user interface-level tests
  • Check that the figures served up by the mortgage orientation tool are correct > repeating the same paths multiple times, but with different sets of input data and expected output values > time to dive deeper

So, if you want to prevent your automated test suite from becoming too bloated with UI tests, this is a rule of thumb you can (and frankly, should) apply. As always, I’d love to hear what you think.

My thoughts on who should create automation, and why there might be a more urgent problem at hand

Recently, there has been quite a bit of discussion on Twitter on what role should be responsible for writing test automation code. From what I’ve read, there are roughly two camps:

  • The camp advocating that developers should be made responsible for writing most, if not all automation code. Their main reason: developers know best how to code, they also know best how the code is structured and works internally, providing them with the best insight into which hooks in the code to leverage for automation (as opposed to blindly doing everything through the user interface).
  • The camp advocating that test automation requires dedicated automation engineers, especially for anything above the unit testing level. Their main reason: it takes specific skills to write and maintain good automation, skills that extend further than ‘just’ development skills.

At the end of last year, I published a blog post on roughly this topic. Rereading it, I still agree with my own opinion I described back then (which is a good thing!), but having thought and read about and discussed this topic some more in the last months, there are some subtle nuances (and one maybe not so subtle one) I’d like to make. Which, in turn, makes for a good topic for another blog post.

First of all, looking back at the question of ‘Who should be responsible for creating automation?’, I think the correct answer is not ‘developers’ or ‘test automation engineers’. The correct answer to this question should be ‘the development team’. This includes developers, automation engineers, testers, designers, the works. I think that deep down, everybody agrees on this (save maybe a grumpy old fashioned developer that thinks writing automation code is way below his standard). A slightly (yet also very) different question here is ‘Who should be primarily tasked with creating automation?’. That’s where the two camps I mentioned above diverge.

One of the catalysts of the recent discussion on this topic is this blog post from Alan Page. His blog post was based on a series of Tweets Alan sent, which were in turn extensively annotated by Richard Bradshaw in another blog post. Whether or not you agree with their respective standpoints, I think both blog posts are recommended reading material for anybody working in the test automation space. Most of you will probably have read it already, but if you don’t, make sure you do.

My opinion? In an ideal world, where developers have the time, the knowledge as well as the drive that’s required to create useful automation, the dedicated automation engineer might be going the way of the dinosaur. Personally, I don’t see that happening in the foreseeable future, though. And this opinion is backed up by what I see with most of the organizations I’ve worked with over the past year and a half (10+ in numbers, in case you’re wondering). In most teams, developers either lack the time (mostly a bad excuse), drive (also a bad excuse) or knowledge (this is excusable but should be fixed anyway) to concern themselves with creating automation. The same goes for their testers.

As a result, they rely upon their own automation engineers to help them create, run and maintain their automation, or they hire someone from outside the organization. This is where I often come in, either to create the automation myself and learning employees how to extend, run and maintain it, or in a mentoring or coaching role, where I observe and help teams define their own automation strategy. And the number of projects that I see advertised (either directly to me or on freelance job boards and email lists) does not indicate a decline in the need for dedicated automation engineers either. Rather the contrary.

In the end, though, it does not (yet) matter to me WHO is tasked with creating and maintaining automation. Even stronger put, I don’t think it’s the most important problem (or discussion) that needs to be tackled with regards to automation, at the moment. Instead, I’d love to see more discussion, teaching and mentoring on what constitutes good automation, and how to implement automation in a way so that it is maintainable, reliable and valuable in the long run.

I don’t know if it’s just the time of the year, or the fact that I keep getting passed exactly the wrong (or right, depending on how you look at it) code bases, but in the last couple of weeks I’ve witnessed some truly horrifying pieces of automation cr*p. Selenium scripts where every third line was a Thread.sleep(). Cucumber step definition methods containing Selenium object locators. Horrible variable names (what in the name of Peter is ‘y’ supposed to tell me?). Writing a new Selenium test case for every possible combination of input and output parameters, even though the sequence of sendKeys() and click() actions stays exactly the same. And much more of such goodness.

Arguably the biggest gripe I have with this: these abominations were created by external consultants. Who had been working on them for months. And probably got paid a handsome hourly fee by their (and my) client for their efforts. That makes the problem at hand twofold:

  • Bad thing: there are too many self proclaimed ‘automation consultants’, ‘architects’, even the ‘senior’, ‘principal’, or Peter knows what else versions of them, that couldn’t write a decent test if their life depended on it.
  • Even worse thing: their clients don’t have the time or knowledge (probably the latter) to take a look and recognize what absolute garbage those expensive ‘consultants’ deliver.

Now that software development and delivery cycles are speeding up ever more, and teams are increasingly relying on automation to safeguard the quality of the releases they’re putting out into the world, it’s becoming due time to do something about this. Educate both the people responsible for creating automation and the teams that rely on their efforts about what constitutes good automation, and give them the tools to monitor and act upon automation quality. If we as test automation crafts(wo)men don’t start doing this sooner rather than later, I’m afraid that crappy automation becomes the new bottleneck in modern software development, just like all that testing was at the end of waterfall projects in times past.

Once we’ve tackled that problem, let’s move on to who’s the best fit to write what we agree upon is good automation.

Good test automation…

Good test automation…

  • Enhances testing instead of trying to replace it
  • Helps testers do their job, instead of trying to replace them
  • Is treated as a first class citizen software development project (including, but not limited to, proper planning, design and testing, as well as accounting for maintenance)
  • Goes beyond the programming of automated checks, if that helps the team
  • Is focused, informative, trustworthy and repeatable

How good is your automation?

Thanks to (among many, many others) Richard Bradshaw, Michael Bolton, Jim Hazen and Angie Jones for continuously driving forward discussions on and the development of the craft. I learn something new every day, thanks to all of you.