A/B Testing is a structured way of comparing two versions of a process, product or design under controlled conditions to see which performs better. Long associated with software and marketing, it applies equally well on the shop floor whenever a team needs objective evidence about whether a change actually improves the outcome.
Version A is the current state, the baseline. Version B contains a single, deliberate change. Both versions run under conditions as similar as possible, and a pre-defined metric decides which wins. The test only produces trustworthy results when the sample is large enough, the metric is agreed in advance, and only one variable changes between A and B.
An operator proposes a new fixture that they believe reduces cycle time. Instead of adopting it based on opinion, the team runs the old fixture for a full shift and the new one for the next, collecting cycle-time data for each part. If the difference is real and repeatable, the new fixture becomes the standard. If it isn't, the proposal is set aside and the team learns something. Either outcome is a win.
A/B testing protects continuous improvement from the two failure modes that quietly waste effort: adopting changes that don't actually help, and rejecting changes that would have helped. By making comparison explicit, it moves the team from "I think this is better" to "the data shows this is better by this much." That evidence is what makes standards worth defending.
A/B testing is PDCA compressed into a comparison. It builds the habit of asking, before every change, "how will we know if this actually worked?" That single question, answered with numbers instead of opinions, is one of the most valuable habits a Kaizen culture can develop.
