O risoto de sobras é uma ótima analogia para explicar de forma didática a relevância da pirâmide de testes para os stakeholders
Por Rodrigo Matola
Às vezes é difícil para um stakeholder que não técnico entender a importância de testar bem uma funcionalidade antes de colocar a aplicação em produção. Sempre ouvia: “eu entendi a importância da pirâmide de 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 algumas analogias para poder explicar a pirâmide de testes e sua importância durante o desenvolvimento de um produto digital. Vamos falar agora 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.
Entretanto, fazer esse risoto é bem simples. Com 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. Siga essas 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 sairá caro… Mas antes, como stakeholder, você quer descobrir o que deu errado. Mas como descobrir o que está errado dentro dessa mistura toda?
Aplicando a pirâmide de testes
Voltando ao desenvolvimento de produtos digitais, após a analogia contada acima, podemos entender o quanto é importante o processo de testes para garantir a qualidade do produto final. Para isso, podemos elencar:
Testes unitários
Voltando no tempo, até o momento da montagem da equipe, para evitar que o ocorrido contado anteriormente aconteça, cada participante do seu time deveria provar o ingrediente antes de colocá-lo no risoto. O teste unitário de cada item deve ser realizado primeiro. Esses testes mostrariam que o arroz que foi deixado fora da geladeira, estaria azedo e que a carne de porco estava estragada, por exemplo.
Os testes unitários servem justamente 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, entre outros) 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.
Voltando a analogia do risoto de sobras, 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.
Já 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 uvas-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 deve 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 no risoto simplesmente porque gosta, apesar de funcionar e ficar gostoso, outros convidados podem não gostar ou terem alergia.
No mundo de softwares, 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 é possível identificarmos 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.
Trazendo esse exemplo para o desenvolvimento de softwares, teste-o por completo a cada nova implementação. E não faça implementações gigantescas, como colocar a quantidade final de sal e água juntos, por exemplo. 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 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.
Conclusão
Esse exemplo do risoto de sobras é uma maneira diferente que usamos para explicar a pirâmide de testes para pessoas sem base de programação, a importância de dividir e, principalmente, fazer testes durante o ciclo de desenvolvimento e não apenas no final.
Testar cada elemento de um produto digital antes de oferecer ao público pode realmente demorar um pouco mais. Entretanto, assegura que o produto tenha uma melhor qualidade e que os clientes finais fiquem mais satisfeitos.
Gostou do texto? Tem dúvidas sobre o processo de automação de testes? Deixe seu comentário aqui!
Ainda tem dúvidas de como implementar esses testes, marque um bate-papo conosco, nós podemos te ajudar!
Por que os processos Ágeis não estão ajudando na Transformação Digital?
