Atenção: esse artigo tem um vídeo complementar. Clique e assista!
Neste artigo foram apresentadas as principais alterações sofridas pela atividade de testes ao longo dos últimos anos, principalmente influenciadas pelas metodologias ágeis. A experiência em projetos Scrum foi considerada e alguns pontos foram levantados como sugestões de melhoria para o que acontece hoje, seguindo as premissas do manifesto ágil e a ideia de desenvolvimento incremental de software.
Para que serve
O artigo tem a intenção de ser uma referência para as pessoas que estão deixando de realizar os testes em Waterfall e estão ingressando no mundo ágil. Além disso, o texto também contém lições aprendidas durante os últimos projetos e como os times andam desenvolvendo os testes de maneira incremental.
Em que situação o tema útil
O tema é útil para os profissionais de Engenharia de Software em geral (principalmente Testers e Scrum Masters) que planejam iniciar projetos utilizando metodologias ágeis ou até mesmo para aqueles que já as utilizam, mas estão enfrentando problemas com os resultados dos seus testes ou com as tarefas de testes dentro das equipes.
Em treinamentos, normalmente começamos a falar sobre quais os conceitos que não são mais utilizados pela disciplina de testes antes mesmo de falar sobre como ela funciona em ambientes ágeis. Isto porque muita coisa mudou e o ideal é que todos possam ter um tempo para notar as principais características e diferenças do que era feito em Waterfall e de como fazemos hoje, no Scrum. Esse também foi considerado o jeito mais intuitivo de começar este artigo.
Antes, trabalhávamos com “times de Testes”. Analistas, Testadores, Engenheiros, juntos em times onde todos eram da área de Testes. Hoje, temos times multifuncionais, todos os analistas de testes ficam alocados dentro destes times, trabalhando diretamente com desenvolvedores, webdesigners, analistas de banco, arquitetos, scrum masters e product owners. Estes profissionais são considerados os pontos focais da qualidade dentro dos times, mas não os únicos responsáveis por ela na entrega do produto. A Figura 1 demonstra as duas estruturas, o modelo antigo de Equipes de Testes e o novo modelo, onde estes profissionais já aparecem alocados dentro de seus novos times multifuncionais.
Figura 1. Times de testes x Times Ágeis.
Estrutura física dos times
Localização física é outro ponto extremamente importante, já que propicia uma melhor comunicação entre o time quando planejada corretamente. Não basta os profissionais da qualidade estarem inseridos nos times, estes também devem estar sentados ao lado dos outros membros da equipe e terem acesso aos desenvolvedores. Este posicionamento nada mais é do que uma maneira de facilitar o entendimento dos requisitos, a execução dos testes em si (e dos retestes inclusive) e toda a comunicação de fato. Caso contrário, mudaríamos muito pouco do cenário antigo para o proposto em metodologias ágeis. A Figura 2 demonstra o posicionamento dos membros de uma equipe Scrum: sem divisões e o mais próximo possível.
Figura 2. Posicionamento dos membros de uma equipe Scrum.
Sprint 0
Os testes podem e devem ser iniciados desde o primeiro dia da sprint, às vezes até antes da reunião de planejamento das atividades (planning meeting). Como podemos fazer isto? O analista de testes deve ser o responsável por revisar os requisitos vindos do cliente para que a maior parte das dúvidas seja retirada e as estórias do sprint que virá possam ser revisadas antes de serem passadas para todo o time. Desta forma, no momento da planning, o requisito já foi revisado e está claro o suficiente para ser discutido, estimado e quebrado em estórias.
Ter este Sprint 0, isto é, este momento antes da sprint de desenvolvimento, em que podemos conhecer melhor o negócio é, sem dúvida, um dos pontos pelos quais pode-se observar maior número de melhorias na qualidade dos projetos. Ter um requisito mais trabalhado e um time que conhece mais do negócio no qual está trabalhando é algo que só contribui para o resultado final da construção do software.
...
