Estratégia de testes aplicadas ao Scrum

Muitos confundem Scrum como metodologia de desenvolvimento de software. Scrum é uma metodologia ágil de gestão de projetos!
Scrum pode ser utilizado para qualquer tipo de projeto, sendo de software ou não.

A Empresa deve identificar qual a metodologia de Engenharida de Software que ela vai utilizar. FDD (Feature Driven Development), XP. Cada uma tem estratégias diferentes para testes. XP tem Integração Contínua e Test Deiven Development, FDD tem os testes de aceitação, e nada impede que se monte um processo que misture algumas práticas das duas metodologias.

Deve-se criar um plano de gerencia de configuração e mudança para que se determine como os componentes produzidos em cada iteração de desenvolvimento de software serão integrados, o que depende muito da arquitetura do sistema.

Como sua equipe especifica os testes? Como são executados os testes? Qual o tipo do sistema? Como é a Engenharia de Software na Empresa? Requisitos, Projeto, Implementação?

Ai vai a minha contribuição:

Estamos iniciando a implantação de Scrum em  nossas equipes de desenvolvimento. Já concluímos em torno de 20 Sprints entre diversos sistemas.

Até o momento estamos tendo muito sucesso na forma como estamos conduzindo os testes, onde estamos acertando muito bem as estimativas das atividades de testes e a forma de como testar. Mas para isso estamos tendo que aplicar algumas características específicas para esse sucesso, pois em primeiro lugar devemos como Analistas de testes, garantir a total aderência entre o requisitado e o produto entregue. Abaixo algumas das características:

1 - Profissionais especializados em testes automatizados e testes de caixa branca e caixa preta;

2 - Alto nível de senioridade dos profissionais de testes;

3 - Alto comprometimento e pró-atividade dos profissionais de testes;

4 - Atividades dos testes (caixa branca e caixa preta) dentro dos Sprints;

5 - Testes de aceitação em conjunto com o Cliente, onde os profissionais de testes orientam e apoio o cliente a realizar os testes de aceitação;

6 - Atividades dos testes divididas em Planejamento de testes, Execução dos testes, Documentação dos testes, Reteste das implementações “bugadas” para conjuntos de implementações;

7 - Estamos utilizando ferramentas free para a gestão das atividades dos estes (TestLink, Bugzilla, Jmeter, Cobertura, Eclipse).

8 - Diariamente incentivamos os profissionais dos testes a lerem um pouco sobre Scrum de uma forma geral;

9 - Realização pró-atividade nos testes de caixa branca (criação de Junits para validar frameworks e pls) no sentido de eliminar os bugs de baixa severidade nos testes de caixa preta, onde a equipe de testes fica focada na validação das regras mais complexas, ou seja, aonde realmente pode “quebrar” o sistema.

10 - Criação de casos de testes padrões, para obtermos grande reaproveitamento e ganharmos em eficiência e eficácia nos testes;

Todas essas atividades listas já estamos realizando de forma padrão nos Sprints e estamos tendo muito sucesso no cumprimento dos prazos e principalmente na qualidade do produto.

Estamos iniciando um trabalho de automatizar os testes no momento da criação dos casos de testes, ou seja, criarmos os casos de testes dentro dos scripts de testes automatizado. Isso é algo totalmente novo e desafiador, mas acredito que irá revolucionar as evidências dos testes onde teremos como objetivo, termos todos os testes criados e executados automatizados. Logo insiro novos comentários.

Scrum realmente precisa do apoio incremental do XP para ficar -perto da perfeição-, porém, o XP não indica a posição do profissional cuja habilidade primária é testar, ele fala de TDD, okay, só que o TDD é uma prática voltada a 1. criar um bom design do software, 2. unir o util ao agradável onde o bom design, incrementa o software e de lambuja tu já tem o teste para ele, mas quem faz isso é o desenvolvedor. Pair Testing é interessante também, onde voce aloca um testador ao lado do desenvolvedor para resolver questões de bugs e/ou criação de testes de unidade. Automatizar os testes também é interessante, desde que (novamente se apoiando no XP) você consiga colocar os scripts para rodar no BUILD -ie. integracao continua-, para ser Ágil com “A” maiusculo. Creio que vocês estão no caminho certo, mas falta uma pitadinha de XP… faça não só os testadores estudarem scrum/xp mas também os desenvolvedores. Quando faltar testador, aloque desenvolvedores para auxiliar ELES devem ser a sombra do outro. Outra coisa: quem garante a entrega do produto é o testador, ele precisa conhecer o negócio tal como o analista de negócio, não deixe um testador faltar a uma reunião de negócio, não deixe o testador sair de uma reunião com duvidas, NÃO permita que a palavra final seja do desenvolvedor, se ambos estiverem em duvida, quem decide eh o product owner. E o principal: a equipe deve estar unida com a idéia de desenvolvimento agil, ninguem manda em ninguem senão o scrum master -este por sua vez, deve conhecer scrum a fundo e não ter o cérebro voltado ao desenvolvimento cascata para não ter no final uma cascata-agil-

Scrum enfatiza que todo o processo seja conduzido por UMA equipe formada por pessoas de diversas areas (tester, coder, designer). Portanto ter diferentes equipes trabalhando no mesmo produto me parece um equivoco.

Isso é bom. Na minha opiniao, agile nao é sobre quao rapido vc chega no produto final, mas sua capacidade de utilizar o feedback obtido para adaptar o processo as suas necessidades.

Um dos nossos objetivos, principalmente para os profissionais dos testes, é conhecer o máximo o negócio, o cenário onde o sistema será implantado, ou seja, conhecer as necessidades dos nossos clientes.

Encentivamos muito o contato/comunicação entre os “Conhecedores do negócio/Cliente” e os Analistas de testes, onde temos um canal de comunicação muito aberto, claro e mútuo, e sempre quando surgem dúvidas, são esclarecidas diretamente e pontualmente, com o máximo de agilidade e ganhos para o projeto.

Qual é o seu papel no projeto Rodrigo?

No meu projeto atual foi definido que cada item do backlog que contem uma nova funcionalidade ou uma mudanca numa funcionalidade existente so e considerado finalizado apos os testes do mesmo. O teste de QA e uma tarefa do item do backlog.
Eu acho que ficou legal assim. Acho que ideal e considerar os testes unitarios como parte integrante da codificacao e nao considerar o item do backlog finalizado sem fazer um teste de QA.

Apos pesquisar sobre estratégias de testes, veja a que melhor se aplica ao que vcs vão fazer e, se necessario, modifique para melhor lhe servir.

Arnaldo, sou o Analista de testes responsável em planejar e adequar as atividades de testes dentro das equipes de desenvolvimento Scrum.

Rubem Azenha:

No meu projeto atual foi definido que cada item do backlog que contem uma nova funcionalidade ou uma mudanca numa funcionalidade existente so e considerado finalizado apos os testes do mesmo. O teste de QA e uma tarefa do item do backlog.
Eu acho que ficou legal assim. Acho que ideal e considerar os testes unitarios como parte integrante da codificacao e nao considerar o item do backlog finalizado sem fazer um teste de QA.

Aqui também trabalho assim com as equipes… É meio radical, se pensar ao pé da letra. Porém para contornar um pouco mais de perto o processo, usamos o famoso ( e às vezes tosco hehehe) “dividir pra conquistar”. rs

Aqui na empresa consideramos os testes unitários como uma etapa da equipe de desenvolvimento.
Para os testes consideramos atividades de testes de caixa branca e caixa preta, e sempre avaliamos a necessidade de outras técnicas de testes (carga/stress, performance, instalação, usabilidade, etc.).

Um dos nossos grandes desafios, é o paralelismo entre as atividades de desenvolvimento e testes, pois algumas vezes são concluídas as atividades de desenvolvimento e ainda permanecem as atividades de testes (após a conclusão das atividades de desenvolvimento o sprint é concluído após 2 a 3 dias). Quando é possível utilizamos os desenvolvedores para executar testes, mas para planejar e especificar fazemos questão de serem especialistas em testes. O QUE VOCÊS ACHAM DISSO?

Perguntas:
Qual o nível de documentação de testes utilizada nas equipes Scrum?

O defeitos/bugs identificados dentro do Sprint, devem ser corrigidos no próximo Sprint ou devem ser planejados para o próximo?

Caso a sugestão seja corrigir os Defeitos/Bugs dentro do Sprint em andamento, devemos prever uma atividades de Correção de defeitos/bugs?

Qual o nível de documentação de testes utilizada nas equipes Scrum?

Em breve teremos essa mesma dúvida onde trabalho, mas li sobre o assunto e sugiro a seguinte leitura (é citada uma ferramenta, que ainda não utilizei, para documentação dos testes): http://www.lbd.dcc.ufmg.br/bdbcomp/servlet/Trabalho?id=10373

O defeitos/bugs identificados dentro do Sprint, devem ser corrigidos no próximo Sprint ou devem ser planejados para o próximo?

No link acima também fala-se sobre o assunto. Onde trabalho:

• se o bug é crítico, é considerado uma “tarefa pára-quedas” e é resolvido prioritariamente
• se não é crítico (ou seja, “pode-se esperar e planejar”), o bug vai para o bugtracker (JIRA no caso)
• se é um bug minúsculo identificado ao final do Sprint (na reunião de Review, por exemplo), utilizamos o período entre Sprints (nos intervalos entre as reuniões de Planning) para resolvê-los, de forma a não “sujar” o próximo sprint com bugs pequenos.

Caso a sugestão seja corrigir os Defeitos/Bugs dentro do Sprint em andamento, devemos prever uma atividades de Correção de defeitos/bugs?

Não “prevemos” uma atividade de correção de bugs. Onde trabalho utilizamos como descrito acima.