Architecture Decision Record (ADR)
// Definition
A short document capturing a significant architectural decision: the context that made the decision necessary, the options considered, the chosen option, and the consequences. ADRs prevent future engineers from unknowingly reversing deliberate design choices — for example, reverting a ThreadLocal driver pattern to a static field because it 'looked simpler'.
// Related terms
Test Automation Framework
A structured set of guidelines, abstractions, and shared infrastructure that supports the creation and execution of automated tests. A framework addresses concerns that individual tests cannot — driver lifecycle management, configuration across environments, reporting, and test data — so each test only describes what to verify, not how to set up and tear down the environment.
Framework Architecture (Layered)
An organisational pattern for test automation code where concerns are separated into distinct layers — typically: Test Layer (what to verify), Page/Service Layer (how to interact), Utility Layer (shared helpers), Configuration Layer (environment settings), and Driver/Engine Layer (browser or API client setup). Dependencies flow downward only: tests import pages, pages import utilities, nothing imports from the test layer.
Technical Debt
The implicit cost of choosing a quick or expedient solution today over a more durable one. In testing, it accumulates as flaky tests, missing coverage, and brittle locators that slow every future change.