I was asked by a fellow tester about “walkaway automation”.  Here are my thoughts:

Walkaway automation is 100% automated

No setup steps or manual verification is needed.  It should run with a single command – that can be triggered automatically by the system.

Walkaway automation can run anywhere

It can run on a developer’s box before check-in or in a staging environment.

Walkaway automation does not have external dependencies

It does not depend on the environment, external data, or configuration.  Services are mocked faked, or managed in process.  Dependencies are stubbed or injected. It creates its own data.

Walkaway automation does not have side effects

It leaves no traces, doesn’t modify persistent state, or leave processes running.

Walkaway automation is not brittle

It’s not likely to break if the UI changes and doesn’t rely on functionality that is not part of the public API being tested.  It shouldn’t error because of race conditions

Walkaway automation can be easily maintained

It is modular.  A refactoring change should only need to be made in one place.  If something goes wrong, it sends notification.  It doesn’t try to do something tricky or fancy.  The code is easy to understand and simple.

Walkaway automation clearly documents exactly what is being tested

You can tell from the test name what it is supposed to do.  You know  what systems are being exercised and how.

Walkaway automation is completely deterministic

It should never fail for an unknown reason

Walkaway automation doesn’t produce false positives

When a test fails, it means something is wrong

Walkaway automation doesn’t give a false sense of comfort

It fails unless a specific check passes.  You should have confidence in a passing test.  This is the opposite of false positives.

Walkaway automation runs automatically, all the time

You shouldn’t have to tell it to run, or even be able to forget it runs on every check-in, build, or deployment (depending on the test level).