Série Agile: O tester

Olá Pessoal,

No post de hoje vou falar o que os Testers fazem enquanto o time desenvolve. No post anterior falei sobre o conceito de Done, e um dos tópicos para considerar um item concluído tinha que ser qualificado por um tester. Mas, o que o tester faz enquanto não tem nada pronto para ser qualificado? É isso que vamos ver no post de hoje.

Lets go…

E o que o tester faz enquanto o team desenvolve? Vai para Praia?

Antes de mais nada queria reforçar o que eu acredito: todo projeto agile deveria ter no minimo 1 Tester. Falo isso porque vejo alguns comentários na comunidade, às vezes, que com Agile não precisa mais dos Testers. Não sei de onde tiraram isso. Os Testers são membros do time e eles são tão importantes quanto os demais membros (infelizmente há ainda pessoas que olham assim dev X testers), são profissionais que tem uma habilidade de qualificar se aquilo que você fez de fato atende ao requisito do cliente, do contrário ele vai encontrar falhas e vai te direcionar onde resolver. Quando um  Tester pega um bug, não quer dizer que você, Desenvolvedor, é ruim ou no pior, um animal de quatro patas. Não é isso. Eles apenas dizem: “olha, faltou isso”. Porém alguns desenvolvedores não olham assim e se sentem ofendidos. Há vários fatores que contribuem para um bug no sistema, não é apenas questão técnica. Mas isso não entra nesse post, pois é uma longa história :). Mas de fato, o que os Testers fazem enquanto os desenvolvedores ainda estão trabalhando nos itens do Sprint? Vão à praia e voltam daqui uns dias?

Se isso fosse verdade, eu queria ser Tester \o/, mas a resposta é: Não. Eles não vão à praia. Aqui temos uma pilha de trabalho para eles:

  • Montar os use cases de cada item (ou itens) do Sprint backlog etc;
  • Preparar o ambiente de teste (homologação);
  • Interagir com o team, tirando dúvidas dos itens;
  • Sincronizar informações com o product owner.

Tudo isso consome tempo e é bom ter tudo pronto antes do primeiro item ficar pronto. Os Testers participam das reuniões diárias (afinal de contas ele é membro do time), do planning, então nada melhor que já ir montando os testes seguindo a ordem de prioridade dos itens que foi definido pelo PO.

É preciso adicionar um item no quadro de task para o Tester e ir acompanhando as atividades dele durante as daily meeting?

Não ou Sim. Eu acredito que não, na primeira Sprint eu não faria isso e talvez na próxima sim, como tudo é um aprendizado, vamos ver o que podemos aprender no Sprint 1 com esta abordagem. O motivo de não querer adotar um item exclusivo para o tester é por realmente não achar necessário, exceto se o PO colocasse isso no product backlog, onde acredito que ele não fará isso, porque o PO não está muito interessado no “como” será feito ou qualificado, desde que atenda aos critérios de qualidade e requisitos de negócios estabelecido por ele.  Uma forma seria adicionar uma task a cada item do tipo “preparação para teste” e em uma das daily meeting o desenvolvedor iria dizer: “olha, hoje termino o desenvolvimento e amanhã já tenho o item pronto para ser qualificado”. Então o tester já pegaria a task, colocaria  na coluna de “in progress” e dizendo “tá,eu vou começar a preparar o ambiente hoje e amanhã as X horas posso iniciar a validação”.  Essa foi uma abordagem que achei válida e bem prática até o momento, pois consegui manter a iteratividade entre tester e desenvolvedores em um projeto que participei no mês passado.

E você, como lida com esse cenário? Compartilhe sua experiência :).

Vou ficando por aqui e espero que tenham gostado do post.

Abraços, see ya!