Question 1

What is an ADR (Architectural Decision Record)?

Accepted Answer

An ADR is a short, dated document that captures one significant decision — its context, what was decided, why, what alternatives were considered, and what consequences are expected. ADRs are immutable: when a decision is superseded, write a new ADR rather than editing the old one.

Question 2

When should QA write an ADR?

Accepted Answer

When changing test framework, introducing a new CI gate, changing coverage requirements, adopting a new test pyramid shape, or any decision that future team members will need to understand to question the status quo. If the answer to 'why do we do X?' has to be 'because Slack history,' write an ADR.

Question 3

What is the difference between RFC and ADR?

Accepted Answer

RFC (Request for Comments) is the deliberation phase — open question, multiple paths, comments invited. ADR is the record after a decision is made. Many teams use both: RFC stage produces an ADR once accepted. This template supports both via the Status field (Proposed → Accepted).

Question 4

Why list alternatives considered?

Accepted Answer

Future team members will ask 'why didn't we just use X?'. Listing alternatives with their pros and cons shows the decision wasn't accidental. It also forces honest comparison at decision time — a forcing function against confirmation bias.

Question 5

What does 'immutable' mean for ADRs?

Accepted Answer

Once accepted, don't edit an ADR. If circumstances change, write a new ADR that supersedes the old one. The 'supersedes' chain becomes institutional memory: anyone can trace why the team is now at decision N by walking the chain N → N-1 → … → 1.

QA RFC / ADR Template (2026)

Alternatives Considered

Consequences

Keep it small, keep it dated, keep it immutable

Test Strategy

Definition of Done

Quality Goals & SLOs

AI Feature Test Plan