Agile Testing

Na empresa anterior eu trabalhava como Test Engineer em um ambiente cuja metodologia era AUP (Agile Unified Process). O cliente trabalhava com RUP enquanto dentro da empresa essa realidade era adaptada a um ambiente de desenvolvimento Ágil.

Vou registrar brevemente como foi a experiência.

Bom… no nosso caso, era definido um Backlog do produto com todas as tarefas a serem executas e as prioridades.

A iteração era de duas semanas (os ciclos não devem ser muito longos). Então no início de cada uma tínhamos a reunião de Sprint para definir o que entraria na iteração atual, ou seja, o que vai ser entregue ao final de duas semanas.

No nosso caso, definimos um conjunto de casos de uso e deixamos uma margem de tempo para os testes e bug fixing dentro ainda da iteração. O tempo de desenvolvimento incluía também o tempo gasto com testes unitários pelos desenvolvedores.

Quando inicia a iteração, os desenvolvedores começam a implementar os Casos de Uso. Enquanto isso a equipe de teste especifica os Test Cases para os mesmos. A margem para teste serve para os testes de componente que atualmente são executados usando os Test Cases Especificados (na mesma iteração) através de inspeção visual – não automatizamos nada ainda. A idéia futura é justamente automatizar pelo menos a parte de validação de campos para que os testes de regressão não sejam tão maçantes.

Assim que um Caso de Uso terminou de ser implementado, os desenvolvedores constroem os testes unitários enquanto a equipe de teste obtém a versão do sistema mais atualizada e já testa para reportar os bugs o mais rápido possível.

Além disso, esqueci de comentar, que enquanto a equipe de desenvolvimento está definindo no primeiro dia da iteração as estimativas (consequentemente o que vai ser desenvolvido na iteração), é feito o teste de componente “official” do que foi entregue na iteração passada juntamente com os bugs e melhorias a serem planejados para uma próxima iteração.

Temos também as “Daily meeting”, reuniões diárias que servem para expor o que foi feito no dia anterior, o que vai ser feito hoje e os problemas encontrados. Todas estas reuniões são breves, de no máximo 15 minutos, extrapolando para 30 minutos. Isto tudo para não perdermos tempo nem o foco no que precisa ser entregue.

Dentro de um contexto, a equipe local fazia os testes até o nível de componente, no cliente eram feitos os testes em outros níveis para assim lançar uma release do produto. Quando os testes chegam lá, eles usam RUP. Atualmente, não sei como isto ficou definido naquela empresa, então posso apenas afirmar que os testes de componentes não estão mais sendo feitos pela equipe brasileira.

Na realidade, cada empresa tem que se adequar àquilo que vai dar mais ganho de produtividade à equipe e um resultado com melhor qualidade. Cada projeto tem suas particularidades, então resta saber como “rebolar” para usar as melhores práticas de cada metodologia.

É como ir à feira e comprar somente o essencial!
Feira

Anúncios

Um comentário sobre “Agile Testing

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s