Hoje iremos discutir sobre alguns tipos de testes e como eles podem ser usados para aumentar a qualidade e a confiabilidade no desenvolvimento de software. No último post sobre "A importância dos Testes" vimos que sistemas em produção são muito mais sensíveis à bugs, gerando custos maiores para manutenção, além disso, sistemas complexos tem maior propensão ao surgimento de bugs.

O Scrum não faz alusão à prática de testes, mas eles podem ser incorporados na definição de história pronta no desenvolvimento de software, fortalecendo o critério de aceitação e confiabilidade da aprovação da história. Nesse contexto o importante é que os próprios membros da Equipe Scrum desenvolvam os testes, dado que o Scrum enfatiza que todo processo seja conduzido por apenas uma Equipe multidisciplinar e auto-organizada.

A definição de História Pronta pode incluir que testes sejam realizados. A responsabilidade de elaborar os casos de testes podem ser tanto da própria Equipe ou dependendo das características do projeto, o próprio Product Owner pode se responsabilizar pela elaboração dos casos de teste, mesmo não sendo umas de suas atribuições.

Os testes mais usados são:

1. Testes unitários. São feitos testes para cada componente ou função desenvolvido. Em geral são usados ferramentas que apoiam essa prática. Exemplos de ferramentas mais conhecidas: JUnit, QUnit, TestNG, NUnit.

2. Testes de sistema. Um membro da equipe que não teve participação ativa no desenvolvimento da história é escolhido. O teste aborda todas as funcionalidades desenvolvidas na história afim de encontrar bugs, quanto mais criterioso melhor. A cada bug encontrado novas tarefas são criadas e resolvidas.

3. Testes funcionais automatizados. Em geral são feitos dentro de uma história para reforçar a aceitação e garantir que a funcionalidade continue funcionando. Os testes automatizados são feitos e mantidos para que novas funcionalidades não interfiram em funcionalidades já existentes e devem ser executados periodicamente, quanto maior a frequência, mais rápido as falhas são descobertas. No desenvolvimento Web, uma ferramenta muito boa é o Selenium.

Todos os testes podem ser incorporados ao Scrum de forma simples: cada teste pode ser incluído como uma tarefa em cada uma das histórias e reforçando, as tarefas de testes não devem ser feitas por membros que participaram do desenvolvimento da história pois há perda de imparcialidade. Para histórias complexas é uma boa prática desmembrar as tarefas de testes para facilitar.

Com as tarefas de testes incluídas nas histórias, o Burndown Chart só é alterado de fato quando os testes são feitos e a história é finalizada. Bugs que pertencem a Sprint atual e que forem surgindo durante a execução dos testes devem ser criadas novas tarefas dentro da mesma história. Caso haja bugs suficientes para impedir a continuação, o teste é interrompido e reiniciado quando todos os bugs forem resolvidos. Se Bugs de Sprints anteriores forem descobertos então novas histórias devem ser criadas e priorizadas pelo P.O. Eles podem ser incluídos se for uma demanda do P.O e em comum acordo com a equipe, como explica no post "O que fazer se o planejamento da sprint falhar?".

Enfim, testar não é uma tarefa fácil mas não há razões para deixar de incorporar testes na sua rotina de desenvolvimento dado pelos benefícios obtidos. Erros reincidentes são os piores erros que podem surgir e são facilmente evitados seguindo uma frequência de execução de testes, ela garante que erros não vão se repetir.