Better User-Centric Test Automation

Code-Centric Tests

Most automated testing is code-centric.  Written for developers, by developers.  Unit tests, and some low level integration tests.  This is good and necessary, and it helps developers tremendously, especially when refactoring their code and adding new features to make sure they didn’t break any existing features.

User-Centric Tests

It would be nice to have more user-centric test automation.  Tests that not only act like a user acts, but makes sense to users.  Tests that get used (run frequently) and provide real value (prevent bugs).

User-centric test automation suffers from a number of problems.  They are frequently verbose, brittle, and opaque.  They are slow and hard to maintain.  They don’t make sense to either developers or business.

Let’s look at a few of these issues.

Verbose Tests

Test automation often gets wrapped up in procedural (click here, type this) or implementation (clear cookies, populate test database) details.  This obscures their true purpose and makes them hard to understand and difficult to maintain.

Brittle Tests

Partly because of their verbosity and complexity test automation is often brittle.  Either you have a lot of steps with significant duplication, or you have too much abstraction that means only a  expert can modify them.

Opaque Tests

Tests are often written in a way to make execution easier, or in a shorthand (keyword, data-driven) that makes them not understandable to someone unfamiliar with the syntax.

Testing Silos

People talk about the bad old days when developers would throw the product over the wall to testers, who treated it like a black box.  They’re usually talking about manual testing, but test automation suffers from the same break down.  Developers have their automated (unit) tests and Testers have their automated (functional) tests, and there is no correlation between the two.  And there is often poor correlation between business requirements and automated tests as well.

Wouldn’t it be nice if we could solve these issues…or at least find areas for improvement?

Help me fix it

I’m working on ways to improve this and would love your feedback.   Anyone interested in a virtual round table to talk about these sorts of user-centric test automation issues?

Regression is progress

What would you think of a web framework that advertises itself as:
  • having no session handling
  •  imposes a specific testing framework
  • has an exclusionary “API” that tries to be self contained with the philosophy that it is “all you will never need”
  • using static controllers
  • requiring you to handling requests asynchronously
  • being yet another clone of Rails
  • using Scala for templates
  • written in Java but goes out of it’s way to avoid the existing java ecosystem
It’s called Play.