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?