New: Practical guidance for AI-assisted quality engineering
AskAQA / Quality Engineering / What Should Be Automated?
Quality Engineering · Cornerstone Guide 04

What Should Be Automated?

A practical framework for deciding what to automate based on risk, repetition, stability, feedback value, and maintenance cost.

11 min readFor QA engineers, SDETs, developers, automation specialists, architects, and technical quality leaders.

The better automation question

Do not start with “Can this be automated?” Start with “Will automating this create enough repeated value to justify building and maintaining it?”

Strong candidates: meaningful risk + repetition + objective result + stable interface + useful feedback.

Strong candidates

  • Critical regression paths
  • Smoke tests
  • Stable APIs
  • Data validation rules
  • Repeated calculations
  • Permission matrices
  • Contracts
  • Cross-browser checks
  • Large combinations
  • CI quality gates

Weak candidates

  • One-time checks with little expected reuse
  • Highly subjective usability judgments
  • Rapidly changing prototypes
  • Exploratory investigation
  • Low-risk scenarios with expensive setup

Automation value model

FactorQuestion
RiskWhat happens if the behaviour fails?
FrequencyHow often will this run?
StabilityWill the interface remain reasonably stable?
FeedbackDoes automation produce earlier or more frequent evidence?
Manual effortHow expensive is repeated manual execution?
MaintenanceHow costly will the test be to keep healthy?

Choose the right layer

Business workflow → selected E2E UI rendering → UI / visual API rule → API Service contract → contract / integration Calculation → component / unit Data mapping → data validation
Measure meaningful coverage, such as P1 regression automation—not raw automated test count.

Turn quality concepts into engineering practice

Connect automation, APIs, performance, data, environments, AI, governance, and release decisions.

Ask a QA Question

AskAQA AI assistant

Ask a QA

Ask me about automation, API testing, test architecture, coverage, CI/CD quality gates, performance, integration testing, or other quality engineering topics.

Do not include passwords, confidential information, or personal data in your question.