Técnicas ágeis recomendam ter adequados testes unitários e de aceite para construir um robusto escudo de testes em volta da aplicação. Entretanto, no mundo real, nem todas as aplicações tem sorte suficiente para ter seu escudo de testes. Em uma interessante discussão no grupo Agile Testing, membros sugeriram caminhos para testar aplicações que não tem nenhum teste automatizado.
Asad Safari iniciou a discussão quando ele mencionou que sua aplicação não tinha nenhum teste, os desenvolvedores do time não eram familiares com testes unitários e o time estava correndo contra um prazo de 3 semanas para testar a aplicação. Ele estava em busca de sugestões para testar sobre tais circunstâncias. Philip respondeu que esteve várias vezes nessa situação e recomendou o seguinte:
- Adicione um módulo opcional que coordene sua aplicação com entradas aleatórias ou fixadas.
- Adicione registros de execução no seu programa que divida a saída de mensagens de erro e de assertividade em um arquivo.
- Escreva um único grande teste unitário que execute todo seu programa, forneça tais entradas, e registre a execução em um arquivo.
- Escreva uma única grande asserção que valide que o registro de execução deve não ter erros.
- Adicione uma exceção a tal asserção para cada erro que o registro deve ter.
- Agora começe a corrigir os erros. Cada vez que um for corrigido, remova sua exceção.
Philip recomendou que debaixo da cobertura deste teste enorme, o time poderia começar escrevendo testes pequenos e focados, como e quando o tempo permitir. Ele também sugeriu que, embora a equipe possa sentar sobre os problemas pelas próximas 3 semanas, o tempo para começar a escrever e executar pequenos testes é agora. Adam Sroka concordou com a sugestão e adicionou,
Sim, muitos times respondem a pobre qualidade por diminuir e produzir menos valor, que a qual não faz realmente nada de qualidade. Nós precisamos de uma solução mais pragmática. ...A falácia é que testar agora não é de grande valor porque não podemos fazer isso complementamente como fariámos se nós tivessemos feito desde o início. Não podemos mas ainda é de grande valor.
Não convencido com os pensamentos, Brian Spears adicionou que Agile não é mágica e que não seria possível chegar em uma solução em 3 semanas. Ele disse:
Agile não é mágica. A solução para esse tipo de situação emergencial, quando existe uma, são muitas longas horas, que claramente não é uma solução Agile.
Adam contra-argumentou sugerindo que muitos times adotam Agile assim que entram em situações como essa. Essa é a melhor chance para times serem pragmáticos e darem os primeiros passos no sentido de fazer software melhor.
Annette sugeriu que a corrente situação está propícia para fazer horas e horas de testes manuais e que testes automatizados nesse estágio seriam consumidores de tempo. A recomendação foi começar com as funcionalidades principais e dependedoras de receita, da aplicação. Annette também recomendou o livro, Agile Testing de Lisa Crispin e Janet Gregory. Charles Bradley fez um sugestão similar com a adição de uma promessa condicional. Ele sugeriu:
Seu tempo é limitado, então maximize o ROI em qualquer forma que seja melhor na perspectiva do negócio. Manualmente teste os problemas infernais desse projeto, e tente obter, dos tomadores de decisão acima de você, que eles NUNCA MAIS IRÃO FAZER ISSO PARA O TIME novamente...e ao invés disso, eles irão PLANEJAR com tempo (e dinheiro) em testes automatizados...logo quando o trabalho para a próxima versão começar ou talvez mesmo quando as correções pós-lançamento começarem.
Assim, a corrente situação pode não ser a melhor para preparar um completo escudo de testes e o time pode ir melhor com testes manuais. Isso entretanto não tira a importância de ter um conjunto apropriado de testes na primeira oportunidade que surgir. Como Jonathan Rasmusson disse:
Tudo o que você pode fazer é corrigir os erros, e então manulmente testar da melhor forma que puder antes da liberação em produção. Isso é tudo o que você pode fazer nesse ponto. A maior e mais importante questão é o que você vai fazer DEPOIS que você atingir seu prazo de três semanas.