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).