Mais um post da série de contradições em teste de software…
Não use ferramentas de bug track
Quando se trabalha em um time ágil, co-localizado e de maneira iterativa, muitas vezes é mais eficiente corrigir os bugs assim que eles são achados em vez de gastar tempo cadastrando os mesmos e tendo que gerenciá-los em uma ferramenta de bug tracking. O tempo perdido para cadastrar e gerenciar um bug é frequentemente maior do que para corrigí-lo, portanto, neste caso, é melhor evitar.
A maioria dos testadores não se sentem confortáveis com esta abordagem, ao menos no início, porque pode parecer que eles não estão achando bugs. Mas os testadores nunca deveriam ser medidos por quantos bugs eles cadastraram. Fazer isso incentiva os testadores a burlar o sistema, aumentando erros insignificantes e divisão de bugs, que é um desperdício do tempo de todos. E isso aumenta ainda mais a divisão entre testadores e desenvolvedores, já que a produtividade de um está atrelada em achar problemas no trabalho do outro.
Uma vez que os testadores descobrem que seu trabalho não é cadastrar bugs, mas em vez disso, entregar histórias livres de bugs, eles ficarão bem mais confortáveis em não cadastrar e rastrear bugs. A única medida real da qualidade dos testes realizados são bugs não encontrados, os quais não são registrados de qualquer maneira.
Uma abordagem interessante é simplesmente registrar bugs em post-its no quadro de histórias do time. Isso é uma forma mais light, visto que o único tempo perdido é para escrever o bug, e assim que resolvido, ele pode ser amassado e jogado fora. Um ato simbólico de esmagar o bug.
Utilize uma ferramenta de bug track
“O que é medido pode ser melhorado”
~ Peter Drucker
Se você tem membros da equipe remotos, você realmente não pode evitar o uso de uma ferramenta para gerenciar bugs. Ela garante que você está comunicando e rastreando o progresso de forma eficaz através das fronteiras geográficas.
Sem alguma forma de ferramenta de rastreamento de bugs em seu projeto, é difícil manter um controle histórico de erros e como eles são resolvidos. Sem isso, pode levar a alguns dos piores erros reaparecendo. Os chamados, sapos-cururus.
Cuidada com o sapo-cururu!
Se você não estava ciente, sapos-carurus são uma espécie altamente invasiva de sapos na Austrália, que foram introduzidos para controlar besouros de cana nativos, mas acabaram ameaçando a vida selvagem natural. Eles tem duas característica notáveis:
- Eles secretam veneno tóxico que afeta o que está ao seu redor; e
- Eles tem uma incrível capacidade de sobreviver, até mesmo as mais duras das condições (em Queensland há competições para matar sapos-carurus, mas eles são incrivelmente difíceis de matar: justamente quando você pensa que está feito ele se recupera e volta a vida).
Portanto, um sapo-cururu é visto em um projeto como um bug que:
- Causa outros bugs através da secreção de veneno tóxico; e/ou
- Parece voltar a vida, mesmo que você tenha certeza que já está morto e enterrado.
Sem rastrear esse tipo de sapo-cururu, e como você o matou/corrigiu, você continuará vendo-os resurgir. Você pode facilmente identificar quando foi a última vez que ocorreu, o que você fez e porque não deveria estar acontecendo de novo.
Por isso é muito importante haver testes automatizados de regressão, já que testes de regressão automatizados podem e DEVEM também simular bugs já corrigidos.
Você deve manter a ferramenta de bug tracking o mais leve possível. Esta deve permitir rápido registro e resolução de bugs. Evite a tentação de introduzir um “fluxo de defeitos” de qualquer descrição: empodere as pessoas a fazer a coisa certa no sentido do rastreamento e resolução de bugs, não faça isso mais difícil do que pode ser.
Uma abordagem ainda melhor é incorporar rastreamento de bugs em sua já existente ferramenta de gestão de histórias de usuário. O Trello, por exemplo, permite listas de verificação sobre os cartões de histórias de usuário e são uma ótima maneira de rastrear bugs de forma leve e flexível.
TRADUÇÃO/ADAPTAÇÃO DE PRIDE AND PARADE, DE ALISTER SCOTT
Agradecimentos finais pela revisão e colaboração de Gabriel Oliveira.
TALKING ABOUT TESTING 
Ótimo post, Walmyr!
Eu sou fã da utilização de ferramentas de bug tracking, porque não tenho memória, então acho imprescindível documentar os problemas encontrados, para futura referência em situações semelhantes.
Concordo plenamente que a produtividade do tester não deve ser medida em número de bugs abertos, acho que isso realmente é um “vício cultural” que precisa ser eliminado para melhorar o relacionamento dentro da equipe.
Não consigo acreditar que alguém possa sugerir isso para a sua empresa ou equipe. Na minha empresa, desenvolvemos a nossa própria ferramenta, com base no Mantis, Jira, Redmine e Trello. Ou seja, ela tem o melhor de todas estas. Hoje eu gasto 5 minutos para abrir um chamado de Bug, pois temos uma máscara padrão de abertura de erros, completamente detalhada, onde o testados indica o navegador, ambiente, URL, usuário e número do processo. Na minha opinião algumas pessoas estão surtando com esse negócio de AGILE. Onde fica o histórico da correção? Onde fica o conhecimento? Ágil não deve ser sinônimo de preguiçoso. É muito lindo se dizer ‘ágil’, não registrar nada em lugar nenhum. Quero ver quando o conhecimento sair da empresa!
Em breve pretendo escrever algo a respeito em meu blog, pois estão evangelizando os novos QAs para um lado completamente errado!
Olá Mário, obrigado por expor seu ponto de vista.
Primeiro, creio que você não pode generalizar sua opinião, dizendo que “não consegue acreditar que alguém possa seguir isso para sua empresa ou equipe”. Conheço casos onde isso é realidade e o time é focado em entrega de produtos com qualidade, não em artefatos que não agregam valor final ao cliente, tais como relatórios de bugs.
Muito legal sobre terem criado uma ferramenta que usa o que há de bom em cada uma das ferramentas já existente, mas não vamos esquecer que: mais funcionalidades não significa uma ferramenta melhor. Vamos lembrar do KISS (Keep it simple, stupid!) Sem agressão tá, só pra lembrar mesmo. E também, lembremos de não querer re-inventar a roda.
Sobre o lance da preguiça, creio que os melhores programadores são os mais preguiçosos, pois, descobrem formas de fazer de forma automática o trabalho chato e repetitivo, podendo focar no que importa e agrega valor para ambos os lados, tanto para o cliente, quanto para si próprio. Questões como programação em par, por exemplo, são abordagens feitas em times ágeis para que o conhecimento não fique preso às pessoas, e não exige o uso de ferramentas de bug tracking.
Por fim, lembramos que mostrei os dois pontos de vista. Vantagens de usar ou não ferramentas de rastreamento de bugs, e creio que o melhor uso mesmo é para times distribuídos, mas tudo depende, e é claro que em muitos casos pode ser útil para times co-localizados, dependendo da maturidade do time.
Valeu pelo comentário e manda o link do seu post quando estiver no ar.
Boa semana! =D
Ótimo post! Contando um “testemunho” do que passamos aqui. Mais ou menos 2 anos atrás quando o papel de QA foi incorporado nos times de desenvolvimento nós nos preocupamos em sempre registrar os defeitos na nossa ferramenta de Gestão de Projetos Ágeis para tirar métricas, até porque estávamos começando a mudar todo processo de desenvolvimento de forma que a qualidade estivesse presente em todas as fases. Hoje já não olhamos mais para isso (é claro que quem quiser registrar não é impedido de fazê-lo, principalmente se é algo muito complexo de reproduzir e precisa de um detalhamento maior, a ferramenta ajuda bastante nisso e também em manter o histórico da correção, para eventuais consultas posteriores). Porém, mais do que isso, estamos realmente focando em antecipar os problemas e fazer as entregas com mais qualidade e em menor tempo. Com a utilização dos princípios da Entrega Contínua, alguns produtos já conseguem entregar em 4 horas, ou seja, depois que o dev commita para o repositório, em cerca de 4 horas a mudança já está em PRD. Temos alguns pontos que ainda podem ser otimizados mas tenho certeza que isso só está sendo possível devido a essa mudança de pensamento de que o testes serve pra achar e registrar defeitos, na verdade o mais efetivo é realmente tentar evitar que eles ocorram.