Há bastante tempo eu brigo com algumas pessoas que dizem “Está PRONTO” e quando você vai ver percebe um monte de furos. Normalmente o conceito de pronto é relativo, isto é, cada um tem sua própria percepção.

No projeto que estou trabalhando pude perceber isso de uma forma bastante desagradável. A documentação fornecida pelo cliente não é clara o bastante para resolver todas as dúvidas e com isso, precisamos conversar com os usuários e tirar as dúvidas. Até aí nada demais. Para consolidar a discussão fazemos mockups, escrevemos as principais regras de negócio e passamos para o cliente dar o OK. Para os desenvolvedores, usamos um wiki para descrever os campos, regras e eventos de cada tela.

Acreditamos durante algumas semanas que isso fosse o bastante, mas logo percebemos que mesmo com isso várias regras de negócio foram esquecidas ou implementadas de forma incorreta. Foi quando lançamos mão de uma técnica chamada “Como demonstrar”. Acrescentamos a cada história uma sessão “Como demonstrar” listando todos os cenários possíveis de testes.

OK, isso é basico, você me diz. Realmente, eu respondo, me lembro que no início do projeto, há uns 2 meses, as primeiras histórias que escrevemos tinha uma sessão “Como demonstrar” no verso do cartão. Porém, além de inútil, ficou incompleto. Chegamos a duas possíveis conclusões:

1. Nossas histórias estavam grandes demais, e por isso os cenários de testes eram muitos para o tamanho do cartão.
2. Haviam poucos cenários no cartão, não cobrindo todos os requisitos da história.

Com isso, naturalmente paramos de escrever os cenários de testes, iludidos que os testes unitários nos dariam um direção sobre como testar as coisas. Porém, estamos trabalhando em um projeto que tem muitas regras, costumamos até dizer que para cada 10 exceções existe uma regra. Nesta hora, percebemos que a nossa definição de pronto deveria obrigatoriamente incluir cenários de testes de aceitação.

Mas, para começo de conversa, fazer esses cenários não é algo trivial. São necessários vários dados de testes para gerar bons cenários de formulários com muitas regras e consultas/relatórios com muitos dados e filtros. Mas, sem isso, o desenvolvedor estava com muita dificuldade de simular e até demonstrar para o cliente todos os cenários.

Até agora foi só conversa, então vou mostrar um pouco da forma que estamos escrevendo a sessão “Como demonstrar”. No wiki, criamos uma tabela com os campos abaixo e para cada cenário (regra ou exceção) relacionamos as entradas e resultado esperado. Para uma tela de login, ficaria algo assim:

Lembrando que tem que haver um banco de dados com o usuário sauloarruda/secret para os testes passarem. Após passar em todos os testes, fazemos mais alguns testes exploratórios procurando novos cenários e problemas. Se encontrarmos algo, criamos uma nova linha na tabela e colocamos o status como Pendente. Simples assim.

Esses cenários também são bons candidatos para automatização de testes usando alguma ferramenta como Webdriver ou Selenium, além de ser uma boa orientação para criação dos testes unitários. Com isso, alteramos nossa forma de trabalho para o desenvolvedor escrever os cenários de testes antes de iniciar o desenvolvimento.

Enfim, é isso. Deixem suas sugestões!