O que é smoke testing? Os cinco minutos que decidem se vale a pena continuar a testar

Um smoke test é uma passagem curta e superficial pelas coisas que uma build tem de conseguir fazer antes de alguém lhe dedicar tempo. Arranca. Alguém consegue entrar na conta. A página principal é desenhada. Um registo é guardado. Se alguma destas falhar, a build é rejeitada e ninguém olha mais além, porque tudo o que viesse depois seria testar uma build que nunca valeu a pena testar.

Não é minucioso de propósito. A minúcia é o que o resto da suíte faz, e corrê-la contra uma build partida desperdiça um dia a provar de quarenta maneiras que a autenticação está em baixo.

De onde vem o nome

Do hardware, e a história é literal. Monta-se uma placa, liga-se a corrente e fica-se à espera de fumo. Se deitar fumo, não vale a pena medir nada: a avaria é grosseira e imediata e a placa volta para trás. Os canalizadores usam a mesma expressão para bombear fumo pelos tubos e encontrar fugas antes de fechar as paredes.

O software adotou o termo pela mesma razão. Uma build que não consegue autenticar um utilizador deitou fumo, e a resposta certa é parar.

O que um smoke test não é

Três termos são usados como sinónimos nas reuniões diárias e são três coisas diferentes.

Smoke test

Vale a pena testar esta build? Amplo e superficial, corre primeiro, em cada build

Teste de regressão

Alguma coisa que funcionava deixou de funcionar? Profundo e lento, corre quando há tempo

Um teste de sanidade é o terceiro: uma verificação estreita de que uma correção específica funciona mesmo, executada depois de uma alteração entrar em vez de antes de os testes começarem. O smoke é amplo e superficial; a sanidade é estreita e superficial; a regressão é ampla e profunda.

A diferença prática está no que acontece quando um falha. Um teste de regressão falhado é um erro para registar. Um smoke test falhado é uma decisão: esta build fica por aqui.

O que entra num

A regra que mantém uma suíte de smoke útil é que tudo o que está nela tem de ser algo cuja falha torne inútil continuar a testar. É uma lista muito mais curta do que parece à primeira vista.

Uma suíte típica para uma aplicação web:

1. A aplicação arranca e a página inicial devolve 200
2. Um utilizador conhecido consegue entrar na conta
3. A lista principal carrega e mostra dados
4. Um registo pode ser criado e lido de volta
5. Um utilizador autenticado consegue sair da conta

Cinco verificações, um minuto ou dois, e nenhuma afirmação sobre comportamento para além de “isto aconteceu de todo”. Sem casos limite, sem mensagens de validação, sem matrizes de permissões. Tudo isso pertence à suíte que corre a seguir.

Vale a pena nomear duas formas de falhar, porque ambas são comuns. Uma suíte que cresce até oitenta verificações já não é um smoke test, é uma suíte de regressão lenta com o nome errado, e as pessoas começam a saltá-la. Uma suíte que só testa a página inicial também não é: vai passar numa build em que mais nada funciona.

Quando corre, e quem olha

Em cada build, antes de tudo o resto, e automaticamente. Um smoke test de que alguém se tem de lembrar é um smoke test que ninguém corre na tarde em que teria feito diferença.

O arranjo habitual é uma etapa de integração contínua que corre depois do deploy para um ambiente de testes e condiciona tudo o que vem a seguir. Se falhar, o pipeline para, a build não é promovida, e a equipa é avisada de imediato: poucos minutos depois do commit, enquanto quem o escreveu ainda se lembra do que mudou.

Essa imediatez é a maior parte do valor. O mesmo defeito encontrado um dia depois custa a alguém uma hora de reconstrução antes sequer de poder começar.

Escrever o primeiro

Comece pelo caminho mais curto que um utilizador real percorre no seu produto, e verifique apenas que cada passo se conclui.

• Escolha cinco coisas, não cinquenta. Se não consegue defender que uma falha torna inútil continuar a testar, não é uma verificação de smoke.
• Use uma conta conhecida e dados conhecidos. Um smoke test que depende do que calhar estar na base de dados vai falhar por razões que não são sobre a build.
• Verifique a existência, não a correção. “O total da fatura é 45,00” pertence a outro sítio. “Uma página de fatura foi desenhada” pertence aqui.
• Mantenha-o abaixo dos cinco minutos. Assim que custar mais do que isso, alguém vai tirá-lo do caminho crítico, e então deixa de condicionar seja o que for.
• Falhe em voz alta. Um pipeline vermelho de que ninguém é avisado é um pipeline verde com passos a mais.

Quando falha

Um smoke test falhado não é um relatório de erro. É o sinal de que é preciso um, e os dois confundem-se com facilidade: “smoke test 3 falhou” não diz nada a quem o vai pegar sobre o que aconteceu.

O que essa pessoa precisa é do mesmo que qualquer defeito precisa: o que era esperado, o que aconteceu em vez disso, em que ambiente, com tudo o que o navegador ou o executor registaram na altura. O nosso guia para escrever um relatório de erro que seja corrigido é a versão longa, e o seu modelo é um ficheiro que pode entregar a quem estiver na triagem.

Para uma falha com que alguém tropeça à mão, em vez de uma que o pipeline apanhou, o contexto é a parte que costuma desaparecer.

A versão curta

Um smoke test responde a uma pergunta: vale esta build o tempo de alguém? Cinco verificações, corridas primeiro, corridas sempre, e uma falha para a linha em vez de encher o tracker. Tudo o resto que queira saber sobre a build é uma pergunta que só vale a pena fazer depois de esta ter sido respondida com um sim.