Test Automation Is Software Development, Not Configuration
Somewhere between "we need more coverage" and "just automate it," a quiet assumption slips in: that test automation is a setup task. Something you configure once, like a linter, and then forget. This is the assumption that quietly kills test suites.
A test suite is not configuration. It is a second codebase that runs against your first one. It has an architecture, or the lack of one. It accumulates duplication, coupling, and dead code. It has technical debt that compounds at interest. Treat it as throwaway config and it will rot into exactly the brittle, flaky liability everyone complains about, then blames on "automation" as if automation were the problem.
If It Is Code, It Has Architecture
Production code without structure becomes unmaintainable, and nobody is surprised when it does. Test code is no different. A suite where every test hardcodes its own selectors, builds its own data, and repeats its own setup is not a test suite; it is three hundred copies of the same mistake. The same principles that keep production code alive, separation of concerns, abstraction layers, the page-object or screenplay patterns, apply here with equal force. A locator that changes should be updated in one place, not two hundred.
If It Is Code, It Needs Review
A test that is written once and never read again is a test nobody trusts. Test code deserves the same pull-request review as production code: is this asserting the right thing, is it readable, will the next person understand why it exists? A test that passes for the wrong reason is worse than no test, because it manufactures false confidence. Review is how you catch that before it ships.
If It Is Code, It Carries Debt
Every shortcut in a test, a hardcoded wait, a copy-pasted helper, a brittle assertion on exact text, is a loan. It works today and charges interest every sprint after. A suite that is never refactored does not stay still; it decays, until a ten-minute feature change triggers a two-day test-fixing marathon. Scheduled refactoring of the test codebase is not overhead. It is the maintenance that keeps the whole thing solvent.
The Role This Implies
If automation is software development, then the person writing it is a software engineer who specializes in verification, not a tool operator who fills in config. They read stack traces, design for change, and own the quality of their own code. That is the craft this series turns to from here.
So look honestly at your own suite: is it engineered like a product you intend to keep, or configured like something you hoped you would never have to open again?