O tema "Metodologia Ágil" ganha cada vez mais destaque, e se tornou um assunto muito comentado entre os profissionais de TI.
Muito se fala em introduzir testes em metodologias ágeis, mas porque não introduzir metodologias ágeis no processo de testes?
Atualmente, na empresa onde trabalho, os princípios da metodologia ágil estão no processo inicial, portanto, meu principal contato com o assunto foi durante a matéria de Engenharia de Software na faculdade, ensinada muito superficialmente. Além da faculdade, eu lia algumas matérias e posts sobre o assunto, mas nada se compara com o contato direto no trabalho. Mas enfim, após aprender alguns métodos, eu tentei inserí-los ao processo de testes, e um dos resultados foi esse:
Um scrum board dedicado apenas aos testes. Cada post-it representa uma versão de software lançada, e cada cor representa o segmento dos software. Nesse caso, rosa representa o segmento de supermercados, amarelo o de locadoras e assim por diante. O quadro é separado por quatro grupos:
Para Homologar: Nesse grupo ficam as versões que os testes ainda não foram iniciados, ou versões que serão lançadas futuramente. Nessa primeira etapa, os planos de testes são desenvolvidos, baseados nas principais funcionalidades do sistema, nas alterações e correções realizadas;
Em Teste: Quando uma versão está nesse grupo significa que os testes foram iniciados, e estão em execução;
Em Espera: Versões que foram testadas, mas que estão no aguardo de correções ou alterações, e terão que passar para a fase de teste de regressão, quando for lançado um novo Release Candidate contendo as modificações;
Concluídos: Todas as versões homologadas.
Com o scrum board todos os envolvidos no projeto podem acompanhar o processo de homologação do sistema. É possível verificar também que os desenvolvedores estão concentrando maiores esforços no segmento de supermercados, e que um determinado software possui constantes versões (o que poderá indicar que bugs não são identificados, e são lançadas várias versões corretivas).
Ao final do mês, poderá ser gerado um relatório contendo informações sobre quantas versões foram lançadas, quantos bugs identificados em cada versão, quanto foi investido, e qual foi o gasto para identificar os erros. O scrum board é "zerado" e inicia-se novamente a alimentação de informações.
Esse foi um método interessante que encontrei a fim de monitorar as versões em testes, e possuir dados concretos para tomadas de decisões.
Olá,
Gostei de seu método de controle com o board, parece bem funcional. Eu utilizo um quadro semelhante mas para todo processo de desenv, não somente de testes. Estou pensando em te clonar :) e criar um quadro somente para automação!
Vlw