Quality assurance is the set of practices intended to ensure that a product meets its requirements and functions correctly, encompassing the processes, standards, and activities that produce quality rather than only the activities that check for its absence. The distinction from quality control, which is the inspection of finished output, is more than terminological: assurance is concerned with preventing defects, control with detecting them.
The traditional arrangement, in which a separate team tests completed work in a distinct phase before release, has well-documented weaknesses. Defects are found long after they were introduced, when the context has been forgotten and the cost of correction is highest. The delay between writing and testing means developers receive no timely feedback about their own error patterns. And responsibility for quality is transferred to a group with no control over how the work was produced.
Modern practice distributes the responsibility rather than concentrating it. Developers write automated tests as part of building, code review catches problems before they reach any environment, continuous integration runs verification on every change, and quality specialists focus on test strategy, exploratory testing, and the areas automation cannot reach. The specialist role becomes one of enabling and designing verification rather than performing all of it.
The test pyramid describes the sensible distribution of automated verification. A broad base of unit tests runs quickly and pinpoints failures precisely. A smaller layer of integration tests verifies that components work together. A narrow top layer of end-to-end tests exercises complete journeys through the real system. Inverting this, with heavy reliance on slow and brittle end-to-end tests, produces suites that take hours to run, fail unpredictably, and are eventually ignored.
Exploratory testing remains essential and is frequently undervalued in automation-focused organizations. Automated tests verify that specified behaviour still works; they cannot notice that a flow is confusing, that an error message is unhelpful, that a combination nobody considered produces nonsense, or that a change has made something worse in a way no assertion covers. Skilled manual investigation finds categories of problem that no test suite will.
Quality obligations extend well beyond functional correctness. Accessibility, performance under realistic conditions, security, behaviour on the devices and connections the audience actually uses, and correctness of data handling are all quality attributes, and organizations that verify only functional behaviour ship products that work correctly while failing substantial parts of their audience.
Test data management is an unglamorous constraint that determines how much of this is achievable in practice. Realistic data is necessary to find realistic defects, while production data frequently cannot be used directly because of privacy obligations, and synthetic data that is too clean hides exactly the problems worth finding. Establishing a supply of representative, compliant test data is usually a prerequisite for meaningful verification rather than a detail.
The economic argument for prevention is well established. The cost of correcting a defect rises sharply with how late it is discovered, from trivial when caught during development to substantial when found in production, where it also carries operational and reputational cost. Investment in earlier detection is therefore justified on cost grounds alone, independently of the customer experience argument.
Because quality is determined by how work is produced rather than by what happens at the end, the practices belong within delivery rather than after it. In practice this is established within product development as part of the definition of done, with the accessibility and experience criteria drawn from UX audit standards and the performance thresholds from web performance budgets, so that what is verified matches what the product is actually required to deliver.