← writing

What belongs in a smoke suite, and what does not

A smoke suite that takes fifteen minutes is not a smoke suite. Deciding what earns a place is mostly about what a deploy is allowed to break.

A smoke suite answers one question: did this deploy break something a user would notice in the first minute. That framing decides everything else. If a test does not help answer that question, it belongs in regression, not smoke.

The question is about blast radius, not importance

Every feature feels important to the person who owns it. That is the wrong axis. The right one is: if this path is broken and we ship anyway, how many users hit it, and how fast. Login, checkout, the main dashboard load: these are smoke. A settings toggle three menus deep is not, even if it matters.

Speed is a feature of the suite

A smoke suite exists to gate deploys, so it runs on every deploy. If it takes fifteen minutes, people route around it, and a suite people route around is worse than no suite because it gives false comfort. I keep smoke under a few minutes. That budget forces the blast-radius decision to stay honest.

Regression is where depth lives

Everything that did not make the smoke cut is not homeless. It goes in regression, which runs less often and is allowed to be slow and thorough. The split is not smoke versus unimportant. It is fast-and-shallow-on-every- deploy versus slow-and-deep-on-a-schedule.

Get this split right and two good things happen at once: deploys stay fast, and a red smoke run is a real emergency instead of noise.

Start a conversation

Building something that needs a stronger quality signal?

Let's talk about the product, the risks, and where faster feedback could make the biggest difference.