Automation is an investment decision
A check creates value when repeated evidence improves a decision. Its cost includes design, data, execution, diagnosis, and maintenance.
High manual effort does not automatically justify automation. An unstable feature or subjective outcome can make software feedback more expensive than focused human review.
Estimate value over the expected life of the behavior. A check used for two releases has a different return from one used on every change.
Look for a stable question
Good candidates have controlled inputs, observable evidence, repeat demand, and a consequence that matters. API contracts and core calculations often fit this shape.
Poor candidates depend on changing layouts, external systems you cannot control, one-time migrations, or visual judgment that requires interpretation.
Split a broad scenario when only part is stable. Automate the calculation and investigate the new interface manually.
Choose the cheapest useful level
A component or API check usually gives faster and clearer feedback than a browser journey. Use the browser when the integrated user path is the question.
Do not duplicate the same assertion at every level without a reason. Each check should own a distinct failure signal or protection boundary.
Include production monitoring when some questions cannot be reproduced realistically before release. Monitoring complements pre-release evidence rather than replacing it.
Revisit the decision
Track failures, defect detection, diagnosis time, execution time, and maintenance effort. Remove checks that no longer influence a decision.
A previously poor candidate can improve after the product gains test data controls or stable interfaces. A useful check can decay after architecture changes.
Write a short automation decision with the risk, evidence, level, dependencies, owner, and review trigger. This makes maintenance intentional.