"Qual a diferença entre smoke e sanity?" e "retest é a mesma coisa que regressão?" são perguntas que parecem decoreba, mas têm um propósito prático: cada um desses tipos responde a uma pergunta diferente sobre a build, e rodar o errado na hora errada custa tempo. Saber distinguir é o que organiza a rotina de quem testa todo dia.

O mapa rápido

Build nova chegou
       │
       ├── Vale a pena testar?           → SMOKE   (amplo e raso)
       │
       ├── Aquela área específica está ok? → SANITY  (estreito e fundo)
       │
   Corrigiram um bug?
       │
       ├── O bug sumiu mesmo?            → RETEST  (mesmo caso, mesmos passos)
       │
       └── A correção quebrou outra coisa? → REGRESSÃO (o entorno e o resto)

Smoke test — "a build sobe?"

O nome vem da eletrônica: ligava-se a placa e, se saísse fumaça, nem valia continuar. O smoke é um conjunto amplo e raso de verificações dos fluxos mais críticos: a aplicação inicia? O login funciona? A home carrega? Se o smoke falha, a build é rejeitada antes de gastar esforço com testes mais profundos.

É o primeiro portão do pipeline — roda automatizado a cada deploy, em minutos. Um smoke vermelho significa "nem adianta continuar".

Sanity test — "essa parte específica faz sentido?"

O sanity é o oposto em forma: estreito e profundo. Depois de uma mudança pontual (uma correção, um ajuste de regra), você verifica só aquela funcionalidade em detalhe, sem varrer o sistema todo. É uma checagem rápida de racionalidade: "mexeram no cálculo de frete — o frete continua coerente?".

Smoke é largo e raso (muitas áreas, superficialmente). Sanity é estreito e fundo (uma área, a fundo). Os dois são checagens rápidas de "vale seguir?", mas em direções opostas.

Retest (teste de confirmação) — "o bug sumiu?"

Quando um defeito é corrigido, o retest executa exatamente o mesmo caso que falhou, com os mesmos passos e dados, para confirmar que agora passa. É pontual e determinístico: ou o bug específico foi embora, ou não foi. Sem retest, você fecha um bug no "confia".

Regressão — "a correção quebrou o resto?"

Toda mudança tem efeito colateral em potencial. O teste de regressão roda novamente um conjunto de casos já existentes ao redor da mudança (e idealmente do sistema) para garantir que o que funcionava continua funcionando. É o tipo que mais cresce com o tempo e o principal candidato à automação — uma suíte de regressão manual vira gargalo rápido.

A confusão clássica: retest confirma a correção do bug X; regressão verifica se a correção de X não estragou Y e Z. Andam juntos, mas respondem a perguntas diferentes.

Lado a lado

Como isso aparece no pipeline

Na prática eles se encaixam numa ordem: o smoke roda primeiro e barata builds quebradas; passando, a regressão automatizada cobre o entorno; o sanity e o retest entram quando há uma correção específica para validar. Mapear cada um ao momento certo evita tanto o desperdício de rodar a suíte inteira para uma mudança trivial quanto o risco de liberar sem checar os efeitos colaterais.

Conclusão

Não são sinônimos nem detalhe acadêmico: smoke decide se vale testar, sanity foca o ponto mexido, retest confirma a correção e regressão protege o resto. Usar o termo certo deixa claro para o time o que foi verificado — e isso é metade da comunicação de qualidade.

"What's the difference between smoke and sanity?" and "is retest the same as regression?" seem like rote-memorization questions, but they have a practical purpose: each of these types answers a different question about the build, and running the wrong one at the wrong time costs time. Knowing how to tell them apart is what organizes the routine of anyone who tests every day.

The quick map

New build arrived
       │
       ├── Is it worth testing?               → SMOKE   (broad and shallow)
       │
       ├── Is that specific area OK?          → SANITY  (narrow and deep)
       │
   A bug was fixed?
       │
       ├── Is the bug really gone?            → RETEST  (same case, same steps)
       │
       └── Did the fix break something else?  → REGRESSION (the surroundings and the rest)

Smoke test — "does the build come up?"

The name comes from electronics: you powered up the board and, if smoke came out, there was no point continuing. The smoke test is a broad and shallow set of checks on the most critical flows: does the application start? Does login work? Does the home page load? If the smoke test fails, the build is rejected before spending effort on deeper tests.

It's the pipeline's first gate — it runs automated on every deploy, in minutes. A red smoke test means "no point continuing".

Sanity test — "does this specific part make sense?"

Sanity is the opposite in shape: narrow and deep. After a targeted change (a fix, a rule tweak), you verify only that functionality in detail, without sweeping the whole system. It's a quick rationality check: "they touched the shipping calculation — is shipping still coherent?".

Smoke is wide and shallow (many areas, superficially). Sanity is narrow and deep (one area, thoroughly). Both are quick "is it worth going on?" checks, but in opposite directions.

Retest (confirmation testing) — "is the bug gone?"

When a defect is fixed, the retest runs exactly the same case that failed, with the same steps and data, to confirm it now passes. It's targeted and deterministic: either that specific bug is gone, or it isn't. Without a retest, you close a bug on trust.

Regression — "did the fix break the rest?"

Every change has potential side effects. Regression testing reruns a set of already existing cases around the change (and ideally across the system) to make sure what used to work still works. It's the type that grows the most over time and the main candidate for automation — a manual regression suite quickly becomes a bottleneck.

The classic confusion: retest confirms the fix of bug X; regression checks that fixing X didn't break Y and Z. They go together, but answer different questions.

Side by side

How this shows up in the pipeline

In practice they fit into an order: smoke runs first and blocks broken builds cheaply; if it passes, automated regression covers the surroundings; sanity and retest come in when there's a specific fix to validate. Mapping each one to the right moment avoids both the waste of running the whole suite for a trivial change and the risk of releasing without checking side effects.

Conclusion

They are neither synonyms nor an academic detail: smoke decides whether testing is worthwhile, sanity focuses on the spot that was touched, retest confirms the fix and regression protects the rest. Using the right term makes it clear to the team what was verified — and that's half of quality communication.