Testes de fumaça (smoke testing): a build sequer liga?

Um teste de fumaça responde a uma única pergunta antes de qualquer outra: a build liga? Se inicia, se você abre o app e as funções principais respondem sem travar, a build merece testes de verdade. Se não, você a rejeita ali mesmo e poupa a equipe de horas testando algo que estava morto desde o começo.

O nome vem da eletrônica, não do software. Quando você montava um circuito novo, ligava na tomada e observava se saía fumaça. Se saísse fumaça, não fazia sentido continuar medindo com o multímetro: o aparelho estava frito. Essa mesma ideia (uma verificação tosca e rapidíssima para decidir se vale a pena continuar) é o que hoje chamamos de smoke testing.

01 · a portaO que é um teste de fumaça e o que não é

Um teste de fumaça é um conjunto pequeno de verificações que confirmam que as funções mais críticas de uma build funcionam em nível básico. Não busca profundidade: busca amplitude superficial. Toca no essencial (a aplicação inicia?, a tela principal carrega?, dá para fazer login?, o fluxo central responde?) e para por aí.

O ISTQB o define como um subconjunto de todos os casos de teste definidos, que cobre a funcionalidade principal de um componente ou sistema, para confirmar que as funções cruciais trabalham mas sem se preocupar com detalhes finos [1]. Esse é o ponto: é uma porta de entrada, não uma inspeção completa.

O teste de fumaça não diz "isto funciona bem". Diz "isto merece ser testado a sério".

O que um teste de fumaça não é: não é uma suíte de regressão, não valida regras de negócio a fundo, não cobre casos limite nem caminhos estranhos. Se você tentar enfiar tudo isso, ele deixa de ser um teste de fumaça e perde sua única virtude, que é a rapidez. Um smoke test que leva quarenta minutos já fracassou como smoke test.

02 · a confusãoFumaça e sanidade não são a mesma coisa

Quase todo mundo mistura smoke testing com sanity testing, e dá para entender por quê: os dois são verificações rápidas e superficiais. Mas respondem a perguntas diferentes e chegam em momentos diferentes.

O teste de fumaça olha para a amplitude: toca nas funções principais de toda a build, recém chegada, para decidir se ela é estável o bastante para ser testada. O teste de sanidade (sanity) olha para a profundidade estreita: quando já houve uma correção ou uma mudança pequena, confirma que aquela área específica se comporta de forma razoável antes de investir numa regressão completa. O ISTQB descreve o teste de sanidade como a execução para determinar se uma parte do sistema continua funcionando de forma razoável após uma mudança menor [1].

Uma forma de lembrar: a fumaça pergunta "a build inteira está viva?"; a sanidade pergunta "este remendo pontual faz sentido?". A fumaça costuma rodar sobre cada build; a sanidade, sobre builds já estáveis nas quais se mexeu em algo concreto.

03 · o pipelineOnde o smoke test se encaixa no seu fluxo

O teste de fumaça brilha na integração contínua. Toda vez que uma build é gerada (por um merge, por um deploy num ambiente de testes), um smoke test automatizado roda primeiro e decide em minutos se a build continua viva. Se falha, o pipeline para, avisa, e ninguém mais perde tempo com aquela versão.

A ordem importa por economia: os testes mais baratos e rápidos vão primeiro. Rodar uma suíte completa de horas sobre uma build que mal compila é jogar recursos fora. O smoke test é o filtro de baixo custo que protege os testes caros que vêm atrás. Essa ideia de escalonar (muitas verificações baratas embaixo, poucas e caras no topo) é a lógica da pirâmide de testes descrita por Cohn [2], e o smoke test é a primeira comporta dessa subida.

Um bom smoke test tem três propriedades: é rápido (segundos ou poucos minutos), é estável (se falha, é porque a build falhou, não porque o teste é frágil) e é automatizado (roda sozinho, em cada build, sem que ninguém precise lembrar). Um smoke test manual que alguém executa "quando lembra" perde quase todo o seu valor como porta.

Para posicionar isso no seu processo você não precisa de nada exótico: bastam cinco ou dez casos que cubram os caminhos que mais doem quando quebram. Iniciar, autenticar, carregar o dado principal, completar a ação central. Se esses quatro respiram, a build está viva e você pode soltar a suíte de verdade. Se um cai, você já sabe que não faz sentido continuar: há fumaça, e o trabalho volta para o desenvolvimento.

Cinco minutos de fumaça compram horas de testes que você não desperdiça.

O smoke testing não é glamouroso nem profundo, e é exatamente essa a sua graça. É a pergunta mais barata que você pode fazer a uma build, e a resposta que mais tempo economiza. Antes de testar a fundo, confirme que ela liga.