A release of a billing application failed in production because the new database schema renamed a column that a nightly export job still referenced by its old name. Which testing practice should be added before future schema deployments?
Select an answer to reveal the explanation.
Short Explanation
A renamed column is like changing a street name without telling the mail carrier. Schema compatibility testing runs everything that talks to the database against the new layout before it ships. Load tests won't catch it for you, because the failure is about names, not traffic.
Full Explanation
Schema compatibility testing verifies that the applications, reports, jobs and integrations that depend on a database still work against a proposed schema. It combines automated checks of tables, columns, data types, nullability and constraints, comparing the new schema with what consumers expect, with execution of dependent workloads in a test environment. A renamed or dropped column, a narrowed data type or a changed default is detected before release, and the team can add a compatibility view, a transitional column or coordinated application changes. Stress testing measures behavior under load; a query that references a nonexistent column fails immediately at any volume, so load testing adds nothing here. A restore test proves that backups are recoverable, which is valuable for continuity but says nothing about whether consumers match the new schema. A gap analysis compares current and required capabilities during planning and is not a pre-deployment test of a specific schema change. Exam caveat: the objectives pair schema compatibility with column and table quality checks, so expect both to appear together. Operational check: maintain an inventory of every object and column referenced by each dependent job, diff it automatically against the proposed schema in the deployment pipeline, and block release on any unresolved reference.