Às vezes é difícil para um stakeholder não técnico entender a importância de testar bem antes de colocar a aplicação em produção. Sempre ouvia “eu entendi a importância dos testes, mas preciso lançar isso ao final da próxima Sprint. Se colocar testes unitários vai demorar mais pra entregar, eles não são prioridade”.

Com isso, pensei em analogias para poder explicar a pirâmide de testes. A que vou falar aqui é a analogia do “risoto de sobras”.

Como fazer um risoto de sobras

Lembro muito bem do risoto que minha mãe e tias preparavam no dia seguinte de alguma festa, principalmente as de fim de ano na casa da minha falecida avó, com as sobras. Eu gostava ainda mais quando o risoto ia ao forno.

Fazer esse risoto é bem simples. Peça ajuda de mais duas pessoas no mínimo para formar um time de 3 e otimizar o processo. Pode chamar mais se quiser, mas é recomendável que o time não ultrapasse 9 pessoas.

Instruções:

– faça uma nova panela de arroz e misture com o arroz que sobrou (e que não dá pra todos comerem);
– pegue as sobras das carnes de porco, peru, chester, tender e todas as outras disponíveis. Desfie e misture no arroz;
– pegue todas as outras sobras, pique em pequenos pedaços. Misture na mistura anterior;
– coloque queijo parmesão ralado por cima e leve ao forno até gratinar.

Agora vamos começar as analogias…

Colocando em produção

Ao servir o risoto, cada pessoa a mesa faz o “download” para o seu prato. Aí começam as reclamações:
– tá com gosto azedo.
– isso tá estragado!
– eu achei doce.
– doce? Minha parte estava extremamente salgada!

Cada pessoa relata um bug diferente. Você terá que jogar o risoto fora e tomou um prejuízo grande, já que terá que pedir comida pra família toda agora…

Mas antes, como stakeholder, você quer descobrir o que saiu errado. Mas como descobrir o que está errado dentro dessa mistura toda?

Aplicando a pirâmide de testes

Testes unitários

Vamos voltar no tempo até o momento da montagem da equipe. Para evitar que o ocorrido acima aconteça, cada participante do seu time deveria provar o ingrediente antes de colocá-lo no risoto. O “teste unitário” de cada item deveria ser realizado primeiro.

Os testes unitários mostrariam que o arroz de ontem, que foi deixado fora da geladeira, estaria azedo e que a carne de porco estava estragada.

Os testes unitários servem para testar a menor parte de um sistema. No risoto, testaria se cada ingrediente estava bom para ser adicionado. Num código, testa se cada unidade (função, objeto…) está se comportando e respondendo como deveria frente a vários cenários.

Testes de integração

Mesmo que cada unidade esteja pronta e de acordo com as especificações passadas. É preciso também verificar se, quando colocados juntos, eles combinam, ou seja, se integram.

Vamos primeiro pegar a reclamação que o risoto estava muito salgado. É preciso ir testando a quantidade de sal até que ela fique ideal. Apesar do sal ter passado no teste unitário de validade, no de integração ele retornou um valor muito maior que o esperado, que “quebrou” o risoto.

Na reclamação do muito doce, foi pedido que se colocasse azeitonas pretas. Mas a pessoa que ficou encarregada dessa parte não conhecia bem o negócio e colocou passas. O teste unitário passou, apesar de ter sido desenvolvido errado, mas no de integração não passaria. Nesse caso, o teste unitário tem que ser refeito.

Testes funcionais e exploratórios

Mesmo que a azeitona preta se integre bem com o arroz, por exemplo, talvez não “funcione” se misturar outro ingrediente junto.

A cada incremento do risoto (software) é preciso testar se está “funcionando” como o esperado.

Se alguém resolve colocar castanhas ou amendoim simplesmente porque gosta, apesar de funcionar e ficar gostoso, outros convidados podem não gostar ou terem alergia.

No mundo de software, pode ser que alguém tenha feito uma implementação diferente da que estava na especificação ou até invente uma. Com os testes funcionais identificamos isso.

Como extensão, se alguém deixou passar um pedaço de osso, somente um teste exploratório iria detectar. Nesse caso, o erro estaria em uma parte específica do risoto (código) que somente um usuário na mesa (produção) iria achar.

Testes de regressão

Também devemos “testar” (provar) o risoto a cada implementação. Ao adicionar sal, teste para ver se ficou salgado. Teste a consistência do arroz para ver se precisa de mais água e cozinhar mais.

E coloque o sal e a água aos poucos. Se colocar uma quantidade fixa desses ingredientes, pode ficar salgado, virar uma canja ou ficar cru.

Para o software, teste o software todo a cada nova implementação. E não faça implementações gigantescas, como colocar a quantidade final de sal e água juntos. Faça pequenos e constantes lançamentos, de somente uma funcionalidade, pois se der algo errado, fica mais fácil de consertar.

Testes de aceitação

Por último, deve ser realizado testes com o produto completo antes de ser servido. Não é aconselhável uma só pessoa testar, mesmo que tenha especificações detalhadas, pois o produto final será consumido por várias pessoas. Quanto mais pessoas provarem (testarem), mais qualidade seu produto final vai ter.

No caso do risoto, não é viável fazer um teste automatizado (utilizando uma análise química por exemplo). Os testes tem que ser manuais e exploratórios. Mas no caso de um software, os testes podem (e devem) ser automatizados, deixando os manuais para cenários que não valem a pena o esforço de automação.

Esse texto foi uma maneira diferente de explicar para pessoas sem base de programação a importância de dividir e, principalmente fazer, testes durante o ciclo de desenvolvimento e não só no final.

Testar cada elemento antes de oferecer ao público pode demorar um pouco mais, mas assegura que o produto tenha uma melhor qualidade e que os clientes finais fiquem mais satisfeitos.

Gostou do texto? Deixe seu comentário e compartilhe para que mais pessoas leiam!

Autor: Rodrigo Matola