What are regression tests?

The plumber fixes the pipe in the bathroom and two days later there is no hot water in the kitchen: the repair broke something else. In software this happens often enough to have a name — regression — and regression testing is the net stretched underneath it. After every change, a suite of checks replays functionality that already worked, from login and basket to payment and reports, and confirms it still behaves. These tests are not hunting for defects in the newly built feature, which is a different job; they defend what already worked, which happens to be the part of the product your customers use today and the part that brings in the money. That is why the question to put to any software supplier is direct: what do you run before every release to make sure you have not broken what works? A serious answer describes a suite executed automatically on every change, with results anyone can look at, rather than a promise to have a quick look first. The suite also grows over the life of a product, because every bug fixed properly leaves behind a test that stops it returning, and that accumulation is what makes a long-lived application cheaper to change in its third year than it was in its first.