I had a conversation recently with a colleague whose small company had contracted out their testing. One of the (several) problems of this arrangement, he said, was that the testers had created automated UI tests, but they were having trouble keeping the tests up to date. The colleague asked me what I thought they should do about it.
I gave him my standard spiel about the cost/benefit of automated testing: as a general rule, UI testing is the least cost effective automated testing that you can undertake. The main reason is its high maintenance cost; you have to update your tests pretty much every time you change the UI. And in my experience, the UI changes a whole lot more than the underlying layers.
After delivering this sermon, I asked my colleague what other types of automated testing they have. He said that they have a few unit tests that are not run on a regular basis and do not all pass anyway (so, basically, no other automated tests).
Based on this information and other things that my colleague told me, my conclusion was that the automated UI tests were not their real problem. I recommended that they give up on the automated UI tests altogether and focus on developing a comprehensive suite of lower level tests that run and pass on a daily basis, starting with unit tests. Once they have that base well covered, then they should start thinking about automated UI tests.
I got the distinct impression that my solution was not at all what my colleague wanted to hear. He wanted to solve the specific problem of the automated UI tests using their existing QA resources (the contract test team). I told him instead that they actually have a different, and broader, problem and that his company needs a more comprehensive approach to solving it.
Unfortunately, we tend to get so focused on specific problems that we forget to step back and look at the bigger picture. We miss the forest for the trees.