ABT Foundations • Module 1
Introduction to Action-Based Testing
The foundation of structured test automation
Module 1 of 30
The Reader's Dilemma
Dear Marilyn, I work in software development, and our testing process is a mess. We have hundreds of automated tests, but every time the application changes, we spend more time fixing broken tests than we do developing new features. It feels like we're running on a hamster wheel—the more tests we write, the more maintenance we create. Is there a more logical way to approach test automation? — Frustrated in Phoenix
Marilyn's Reply
Dear Frustrated, Your predicament reminds me of a locksmith who creates a unique key for every door in a building. When a lock changes, they must recut that specific key. Multiply this by hundreds of doors, and you've created a maintenance nightmare. The solution isn't to stop making keys—it's to create a master key system. In testing, this principle is called Action-Based Testing (ABT). Instead of encoding the mechanics of testing (click here, type there, wait for this), you encode the intent (login, add to cart, checkout). The mechanics live in one place—the Action definition. When the application changes, you update one definition. All your tests continue to work. It's the difference between O(n) maintenance and O(1) maintenance. The cost of test automation isn't in writing tests—it's in maintaining them. ABT shifts that cost from linear to constant.
"The cost of test automation isn't in writing tests—it's in maintaining them."
Your Learning Journey
Now that you understand the context, let's dive deeper with our four-part learning structure:
The Spark
3 min
The Gauntlet
5 min
The Crucible
5 min
The Imprint
2 min