Testes em Metodologias Ágeis?! E Se For o Contrário?

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.


6 comentários:

  1. Desatual disse...:

    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

  1. Onde eu trabalho também foi criado o scrum board do desenvolvimento, mas mesmo assim, não vou dispensar o quadro de processo de testes. Um quadro só para testes faz você ter um visão mais centrada. Aliás, os dois quadros ajudam muito, cada qual fornecendo informações diferentes.
    Por mim, está mais do que aprovado!
    Qualquer dúvida, estou à disposição.

  1. Twins Sis Jo disse...:

    olá Maira!! Parabéns pelo blog!! Extremamente informativo, inteligente e bem bolado!! Comandado por vc, uma loira linda, doce e crânio, vai dar o que falar!!! Um beijo Grande! Twins Sis JO

  1. Sobrevivente disse...:

    Gostei. Trabalho em uma empresa onde utilizamos metodologia ágil e sua sugestão veio de encontro a algumas necessidades que temos aqui. Possivelmente vou adotar sua sugestão e fazer algumas adaptações para nossa realidade.

    Valeu, obrigado e parabéns.

  1. Muito obrigada pelo comentário.
    Acredito que adaptar às necessidades de cada empresa é o que gera bons resultados. Não adianta tentar impor a metodologia, sem que as pessoas não estejam preparadas para trabalhar nesse ambiente.
    Sucesso!

  1. Ricardo disse...:

    Exatamente, as diferentes metodologias e frameworks podem sim ser usadas em conjunto, se feito coerentemente será sempre benéfico. Uma coisa não precisa excluir outra que funciona bem.

Postar um comentário

 
Monster Bug