Atomic Habits Applied to Testing: What Works (and What Doesn't)
On March 26, 2026, I was at Swiss Testing Day in Zurich. Among the talks that day, Manuel Felipe Hintermayr's caught my attention with its title: "How 1% can change everything: Micro-habits for maintainable test automation".
The promise is clear. Take James Clear's Atomic Habits framework and apply it to test automation. Small changes, accumulated over time, to make tests maintainable without superhuman effort.
On paper, that's exactly the kind of approach I relate to. In practice, some ideas from the talk are excellent. Others missed the mark for me.
The concept: micro-habits for test automation
The starting idea is borrowed directly from James Clear. In Atomic Habits, he argues that 1% improvements, repeated daily, produce exponential results over time. Hintermayr takes this principle and applies it to test automation.
The parallel holds up. We all know that a poorly maintained test suite doesn't collapse in a day. It's an accumulation of small compromises: a hardcoded selector here, a copy-paste there, a naming convention ignored. Each shortcut is insignificant. The cumulative effect is devastating.
So the opposite should work too. Micro-improvements applied consistently should make tests progressively more robust. The concept is appealing. The adaptation to testing is uneven, but some ideas are truly worth exploring.
Anti-patterns: nothing new, but necessary
Hintermayr starts by listing the classic anti-patterns of test automation. Test code copy-pasted everywhere. Hardcoded selectors and test data. No naming conventions. The famous "it works on my machine". No code reviews on test code.
No experienced tester will be surprised by this list. We know them, we've seen them, we've probably committed them. But the reminder has merit. Especially when paired with the central message of the slide: your tests are a product. Treat them like one.
It's a simple statement, but it's exactly the kind of mindset shift that makes the difference between a team that suffers through its tests and a team that relies on them. If there's one thing to take away from this part of the talk, that's it.
A layered architecture that holds up
The architecture section is more interesting. Hintermayr presents a layered model for structuring test code. At the top, Test Specs contain business logic and scenarios. Below, two abstraction layers: Page Objects for the UI and API Helpers for the backend. At the base, reusable components, centralized configuration, and test data.
The principles behind it are well known: Single Responsibility, DRY, readability. Applying the same standards to test code as to production code. It's not revolutionary, but it's clearly structured and makes the point that test architecture isn't a luxury. It's an investment that pays off with every execution.
The real value of this section is that it sets the stage for what comes next. And what comes next is the best idea of the talk.
The real contribution: Health Checks on Page Objects
The idea is simple. We already have Page Objects that describe UI elements. Hintermayr proposes turning them into an early warning system. A Health Check Generator scans existing Page Objects and verifies three things: do the locators still exist, are the elements available, do the pages load correctly.
In practice, we're talking about one extra line of code and a verification script. Not a six-month project. Not a rewrite. A micro-change in the truest sense.
The result is a monitoring system that runs faster than a full E2E suite and answers three questions before even launching the real tests: what still works, what broke, where did the UI change.
It's testing the tests. Making sure you're ready when the tests are needed. The ROI is immediate and the cost of entry is negligible. For me, this is the strongest idea of the entire talk.
Communication as a micro-habit: good intention, wrong target
The talk then takes an unexpected turn. Hintermayr leaves the code behind and talks about what he learned from theatre. Vocal resonance, Alba Emoting, the link between breathing, posture, and emotion. The idea: the way we communicate is also a micro-habit worth developing in QA.
The intention is commendable. But this kind of advice assumes everyone starts from the same place. Someone who's shy or introverted isn't going to become a speaker because they're told to speak from the gut. That's not a micro-habit problem. That's a personality trait.
What is interesting, though, is what it reveals between the lines. QA isn't a purely technical job. Convincing a developer that a bug is real, negotiating prioritization with a product owner, getting a team to accept a process they don't want: that's human psychology. And in my view, that's the bulk of QA work. But it deserves a full talk, not a single slide at the end of a presentation.
What I take away
This talk doesn't reinvent the wheel. That's not its goal. Taking Atomic Habits and applying it to testing is a good starting point, even if the adaptation is uneven.
The technical parts are the most convincing. The layered architecture is a useful reminder. Health Checks on Page Objects are a concrete, low-cost idea with immediate returns. That's exactly what a micro-change should be: small effort, real impact.
The communication part missed the mark for me, but it points to something true. Software quality isn't a technical problem. It's a human problem that gets solved through systems design. And that deserves much more than a slide at the end of a talk.
Swiss Testing Day is an annual software quality conference held in Zurich. The 2026 edition, "Guardians of Trust -- Defining Quality in a Dangerous Decade", took place on March 26.
I share my insights on QA, gamification, and automation on my blog. Read more at abovet.net/blog and let's connect on LinkedIn.
