Apresentamos a você o Derek e a Emma. Ambos são engenheiros de teste de software. O Derek trabalha para uma empresa chamada ContactCo, que está construindo um aplicativo para uso na web, que permite que os usuários adicionem e gerenciem seus contatos. Já a Emma trabalha para uma concorrente da ContactCo, chamada ContactsRUs. A ContactsRUs está construindo um aplicativo semelhante ao que a ContactCo está construindo.
A Emma está muito orgulhosa de sua capacidade de criar frameworks de automação de teste. Assim que o desenvolvimento do novo aplicativo se iniciou, ela começou a trabalhar em um pacote de automação para Interface de Usuário. Ela escreveu dezenas de testes automatizados, bem organizados, e os configurou para serem executados com cada build que os desenvolvedores liberaram para testes. Todos os testes passaram, então ela está muito confiante com a integridade do aplicativo. Ela também criou um conjunto de testes para Smoke Test que serão executados em cada implantação e em cada ambiente. Se os Smoke Tests forem aprovados, a implantação continuará automaticamente para o próximo ambiente, durante todo o processo de deploy para produção. Se os testes falharem, a implantação será revertida e o processo de implantação será interrompido. Depois de apenas três semanas, ela terá um sistema de CI / CD (Integração Contínua / Entrega Contínua) funcionando e todos a elogiarão pelo excelente trabalho que ela fez.
Já o Derek começou seu envolvimento com o novo aplicativo da ContactCo participando das reuniões de design de produto e fazendo perguntas. Ele leu as histórias do usuário para entender o usuário final e saber que tipos de ações ele realizará. Conforme o aplicativo foi tomando forma, ele foi fazendo muitos testes exploratórios manuais, tanto na API quanto na Interface de Usuário. Ele experimentou o aplicativo em vários navegadores e com vários tamanhos de tela. Ao final das primeiras duas semanas de desenvolvimento, ele encontrou vários bugs de UI e API que os desenvolvedores corrigiram.
Em seguida, Derek trabalhou com os desenvolvedores para descobrir quais testes unitários e de integração eles estão executando atualmente e sugeriu alguns testes que poderiam estar faltando. Ele conversou com toda a equipe para determinar qual seria a melhor estrutura automatizada para testes de API e UI e trabalhou com eles para configurá-la. Ele ficou muito tempo pensando sobre quais testes deveriam ser executados na etapa de construção e quais deveriam ser executados na etapa de implantação; e ele pensou sobre quais testes deveriam ser executados exclusivamente para a API para minimizar a quantidade de automação da UI. Depois de ter desenhado uma boa estratégia de teste, ele começou a escrever seus testes automatizados. Ao final da terceira semana de desenvolvimento, ele escreveu alguns testes automatizados, mas planeja adicionar mais e não configurou o processo de CI / CD ainda.
No final das três semanas, a ContactCo e aContactsRUs liberaram seus aplicativos para Produção. Qual aplicativo você acha que teve mais sucesso? Leia mais para descobrir!
**********
O aplicativo do Derek na ContactCo foi um grande sucesso entre os usuários. Eles comentaram sobre como a interface do usuário é intuitiva e, no final da primeira semana, nenhum bug foi relatado. Os clientes deram sugestões de recursos que gostariam de ver adicionados ao aplicativo, e a equipe da ContactCo já começou com uma nova rodada de reuniões de design de produto, das quais Derek participa. Quando não está em reuniões, ele continua trabalhando para incrementar a estrutura de teste automatizado e configurar o CI / CD.
O aplicativo da Emma na ContactsRUs foi colocado em produção e no mesmo dia a empresa começou a receber ligações de clientes. A maioria dos clientes da ContactsRUs usa o navegador Edge, e aconteceram uma série de problemas de renderização nesse navegador que a Emma não detectou. Por que ela não os pegou? Porque ela nunca testou no Edge!
No dia seguinte, a empresa recebe um relatório informando que os usuários podem ver contatos pertencentes a outros clientes. A Emma achou que isso não poderia ser possível, porque ela tem vários testes de UI que fazem login como vários usuários e ela verificou que eles não podem ver os dados uns dos outros. Acontece, porém, que há uma falha de segurança; se um cliente faz uma chamada de API para obter uma lista de contatos, TODOS os contatos são retornados, não apenas os contatos associados ao seu login. A Emma nunca fez check-out da API, então ela perdeu esse bug crítico.
Os desenvolvedores trabalharam até tarde da noite para consertar a falha de segurança antes que alguém pudesse explorá-la. Eles já perderam alguns de seus clientes por causa disso, mas lançaram a correção e esperam que este seja o último de seus problemas. Infelizmente, no terceiro dia, Emma recebeu uma mensagem irritada do PO da equipe informando que a função de pesquisa não estava funcionando. “Claro que funciona”, respondeu Emma. “Tenho um teste automatizado que mostra que funciona.” Quando Emma e o PO investigaram, eles descobriram que a função Pesquisar funciona bem com letras, mas não funciona com números, então o cliente não pode pesquisar seus contatos pelo número de telefone. Este era um caso de uso crítico para o aplicativo, mas Emma não sabia disso porque não compareceu às reuniões de produto e não prestou atenção aos critérios de aceitação da funcionalidade. Como resultado, eles perderam mais alguns clientes que contavam com esse recurso para trabalhar com eles.
A(s) Moral(is) da História
Você ficou surpreso com o que aconteceu com ContactsRUs? Pode ter parecido que eles teriam sucesso porque implementaram CI / CD tão rapidamente em seu aplicativo. Mas CI / CD não tem importância se você negligenciar essas duas etapas importantes:
- Compreenda o produto que você está testando. Saiba quem são seus usuários finais, o que eles desejam do produto e como o usarão. Preste atenção nas reuniões de planejamento e participe da criação dos Critérios de Aceitação para histórias de desenvolvimento.
- Procure por bugs no produto. Muitos engenheiros de teste de software vão direto para a automação sem se lembrar de que sua função principal é ENCONTRAR OS BUGS. Se houver bugs em seu produto, os usuários finais não vão se importar com seu código realmente bem organizado!
Toda boa fábula merece um final feliz! Espero que você tenha aprendido com o Derek e a Emma e tenha certeza de entender e testar seu software antes de escrever uma boa automação.
Este texto é a tradução autorizada de “A Tale of Two Testers”, por: Kristin Jackvony, The Thinking Tester.
