Olá, pessoal!

No artigo de hoje, vou falar o que os testers fazem enquanto o time desenvolve. Já 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 artigo de hoje.

Lets go…

E o que o tester faz enquanto o team desenvolve? Vai à praia?

Antes de mais nada, queria reforçar algo em que acredito: todo projeto agile deveria ter no mínimo um tester. Falo isso porque vejo alguns comentários na comunidade, dizendo que, à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 têm 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, na pior das hipóteses, 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 neste artigo, 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 a 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.

Isso consome tempo, e é bom ter tudo pronto antes de o primeiro item ficar pronto. Os testers participam das reuniões diárias (afinal de contas, eles são membros do time) e do planning, então nada melhor que já ir montando os testes seguindo a ordem de prioridade dos itens que foram definidos pelo PO.

É preciso adicionar um item no quadro de task para o tester e ir acompanhando as atividades dele durante as daily meetings? Não ou sim. Eu acredito que não. No primeiro Sprint, eu não faria isso; talvez no próximo. Como tudo é um aprendizado, vamos ver o que podemos aprender no Sprint 1 com essa 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, o que acredito que ele não fará, porque o PO não está muito interessado no “como” será feito ou qualificado, desde que atenda aos critérios de qualidade e aos 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 meetings 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ã àsxX 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 interatividade entre tester e desenvolvedores em um projeto de 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 artigo.

Abraços, see ya!