Test Party

Inspirados em uma Lightening Talk assistida por alguns membros da equipe, realizamos uma Test Party (ou Testing Day, como também é conhecido). Uma Test Party consiste em um momento onde todos os envolvidos no desenvolvimento (desenvolvedores, QA, "gerência", e P.O.s) realizariam testes no sistema, em busca de possíveis erros, de forma que estes não cheguem à produção. O uso de pontuação e gratificação ao final serviriam como estímulo aos participantes.
No nosso caso, participaram as equipes de desenvolvimento e QA. O objetivo era deixar o sistema mais confiável e aumentar a interação das equipes com o sistema do ponto de vista de usuário e não de desenvolvedor.


Os participantes foram organizados em duplas através de sorteio. As regras foram então apresentadas para as duplas:
- O que testar? Deixamos livre a decisão sobre o que cada dupla iria testar, pois o sistema possui diferentes funcionalidades e, portanto,  havia a possibilidade de que a intersecção dos erros encontrados fosse pequena.
- Como testar? Os testes seriam feitos manualmente, de acordo com um objetivo da dupla (realização de uma tarefa no sistema) ou focados na funcionalidade sendo testada. Casos de teste ou erros encontrados poderiam ter scripts de reprodução/automatização criados.
- Pontuação: 1 ponto para bug encontrado, 2 pontos para caso de teste automatizado, e 3 pontos para script que reproduza o bug. A ferramenta utilizada foi o Selenium IDE (pela facilidade e agilidade no uso).
- Gratificação: chocolate para a dupla vencedora.
- Juiz: uma analista de QA foi designada como juiza, confirmando se o comportamento encontrado era de fato um erro e atribuindo os pontos para cada dupla. 

Todos entraram no clima de competição e cada ponto obtido era comemorado pelas duplas. A dinâmica foi bem recebida pela equipe, que se empenhou em fazer bons testes, com mais probabilidade de encontrar erros. 
Algo interessante foi o pouco overlap que ocorreu entre os bugs encontrados, pois cada equipe explorou aspectos diferentes do sistema. Até mesmo em áreas exploradas por mais de uma dupla, diferentes bugs foram encontrados por cada uma. Isso ocorreu não necessariamente pela quantidade de erros naquela região, mas pelo tipo de abordagem de cada dupla.

Em retrospectiva com as equipes, após a "festa", reflexões sobre os pontos positivos e negativos foram feitas. A técnica ajudou os desenvolvedores a sair da zona de conforto e ter contato com problemas que os usuários enfrentam durante o uso. Mesmo com a reformulação do sistema e a aplicação de boas práticas de desenvolvimento, foi possível ver que somente estas não resolvem todos os problemas, e erros podem "escapar" e chegar ao usuário final. A ideia é que o raciocínio utilizado para encontrar os erros seja aplicado na programação, evitando que se repitam.

Sugestões para as próximas edições incluem: 
- Cada dupla ter definidos os seus usuários e os seus participantes específicos para os testes, para não haver conflitos;
- A versão do sistema que será utilizada para os testes deve ser implantada com maior antecedência;
- Definir horário de início e fim, ao invés de aguardar que as duplas terminem suas tarefas;
- Fazer a "festa" fora do horário de expediente para que todos possam se dedicar sem ficar preocupados com as tarefas que "deveriam estar fazendo". Fazendo fora do expediente também permite um clima mais informal, sem pessoas entrando na sala e estranhando as tiaras coloridas e o "clima de festinha" em pleno expediente.

Os erros encontrados foram registrados na nossa ferramenta bug tracker (com seus respectivos scripts de reprodução), geraram tarefas para programação e estão em fase de correção.

A técnica gerou bons resultados e teve feedback positivo. Muitos dos bugs encontrados já foram resolvidos, o uso do Selenium foi incentivado e membros que ainda não o utilizavam com frequência passaram a usar.

Aguardemos então as próximas edições. :)

Nenhum comentário:

Postar um comentário