Fran O'Hara, diretor e principal consultor da Inspire Quality Services, recentemente compartilhou suas lições aprendidas integrando testes no ciclo de vida do desenvolvimento ágil. A principal mensagem de O'Hara é que competências de teste são necessárias mesmo quando os papéis tradicionais de testes não existem. Quando equipes ágeis focam somente em automatização de testes funcionais, falhas aparecem em termos de testes exploratórios e outras áreas de risco tais como: testes de integração de sistemas e testes não funcionais (desempenho e usabilidade, por exemplo).
Embora o objetivo seja ter equipes multi-funcionais, estas não devem ser compostas somente de especialistas (como um testador, um desenvolvedor, um designer, entre outros) ou por profissionais com formação generalista. Neste último caso a equipe pode não ter as habilidades maduras o suficiente para entregar efetivamente um software. Competências de testes em particular (como levantar casos de teste, esclarecimento de requisitos de negócio ou testes automáticos limpos) tendem a se perder quando organizações interpretam o Scrum ao pé da letra, assim, montando equipes compostas apenas por desenvolvedores (além do Scrum Master e do Product Owner).
De acordo com O'Hara, equipes com profissionais com habilidades de testes regulares tem desempenho melhor do que equipes que não tem, provando a necessidade de misturar as habilidades e até mesmo os traços de personalidades (testadores tendem a ter uma pedante atenção aos detalhes para encontrar equívocos e brechas nos requisitos antes que eles sejam inseridos no produto) da equipe.
Outras competências tipicamente atribuídas para gerente de testes ou qualidade no desenvolvimento tradicional como definição do processo e estratégia de testes e planejamento de testes podem ser necessárias no desenvolvimento ágil, adiciona O'Hara. Por um lado, muitas organizações ainda agrupam novas funcionalidades em grandes versões, que exigem algum nível de integração de sistemas para entregar. Por outro lado, quando equipes de desenvolvimento ágil que fazem testes durante o desenvolvimento (usando TDD e BDD por exemplo) ainda focam tipicamente em aspectos funcionais das estórias de usuário, deixando de fora o desempenho, usabilidade e outros requisitos não funcionais. O último ainda precisa ser executado em algum momento antes da entrega, necessitando assim de coordenação e planejamento.
O'Hara recomenda o apontamento de campeões ou consultores de testes que podem trabalhar aconselhando múltiplas equipes sobre como preencher competências de testes faltantes. O objetivo final é alcançar uma integração completa dos testes nas equipes multi-funcionais, como no cenário C da imagem a seguir:
O'Hara alerta que múltiplas práticas de trabalho são necessárias para alcançar este nível de integração de testes, a partir de uma abordagem de testes de aceitação, incluindo tarefas de testes (como testes de ambiente / configuração inicial ou testes exploratórios) no planejamento da sprint, limitando o trabalho em progresso em algumas histórias de cada vez, evitando que os testes e validações sejam o último passo (por exemplo, "validação" ser a última coluna do quadro de tarefas é um mau sinal), efetivo e frequente refinamento do backlog, foco na qualidade do código (padrões de código, revisões, TDD, BDD) e aderente a uma rigorosa definição de pronto (mesmo em tempos de estresse).
Discutindo os requisitos de uma perspectiva de negócio durante o refinamento do backlog (diminuindo a extensão do planejamento da sprint) é também uma atividade crucial, mas de acordo com O'Hara, para que esta atividade seja efetiva o Product Owner deve trazer para a mesa não apenas funcionalidades de alto nível, mas também um conjunto inicial de critérios de aceitação que podem em seguida ser discutido e refinado pela equipe em pequenas estórias dentro do escopo.
Finalmente, retrospectivas devem focar em melhorar a definição de pronto para ajudar a gerenciar débito técnico e garantir a qualidade interna (código) e externa (funcional e não funcional), diz O'Hara.