Quero ser um caçador de bugs no TDC2012

Um pouco da minha palestra Quero ser um caçador de bugs apresentada na Trilha Testes University do TDC2012.

De uma maneira geral definimos bugs como não conformidades com a especificação. Mas se eu fiz um projeto de acordo com a especificação que me foi dada e o resultado alcançado não é o esperado, isso também pode evidenciar um bug? Na minha opinião, sim. Foi um problema de especificação ou de planejamento, ou alguma outra coisa, mas é um problema. Então generalizando, eu gosto de pensar em bugs como tudo o que está diretamente ligado ao produto e que impede que alcancemos o resultado esperado com ela.

E como os bugs nascem? Acredito que a grande maioria dos bugs nasçam de comunicação problemática. O cliente as vezes não passa uma informação ou passa de forma ambígua achando que o resultado final é óbvio; o analista as vezes não faz as perguntas corretas, o desenvolvedor muitas vezes implementa qualquer coisa que lhe é passada sem muitos questionamentos e até mesmo quando o testador vai atuar, esse também não se preocupa em ir atrás da informações. Sempre que uma situação dessas ocorre, morre uma fada, quer dizer, nasce um bug :)

E quando a gente pode encontrar esses bugs? Só quando a aplicação está pronta e ela vem pra teste? Claro que não! Se problemas de comunicação fazem bugs nascerem, então é justamente se comunicando que a gente pode evitar que eles nasçam. E essa comunicação não precisa estar associada necessariamente a reuniões formais. Muitas vezes conversando com seus colegas no cafezinho, no fumódromo, ou outras áreas comuns, quem sabe até no banheiro :) é possível perceber que um bug está se desenvolvendo ou prestes a nascer.

Muitas vezes encontramos os bugs já crescidinhos porque a atuação do tester é no final do projeto. Depois que está tudo pronto, todos os bugs já estão adultos e mais chatinhos de resolver. Isso torna a qualidade cara, ou melhor, o controle de qualidade, essa rede de proteção no final do projeto é cara. Quanto mais cedo conseguirmos identificar um problema, melhor. Não deixem chegar na fase de testes. Se vocês desconfiam que vai nascer um bug, já dá pra trocar uma ideia com o desenvolvedor. O teste deve ser uma atividade preventiva e de todos os membros do time.

Como estar preparado para encontrar esses bugs? Claro que experiência é sempre um diferencial, mas não dá pra comprar experiência na esquina. Então o caminho é estudar técnicas, ferramentas, manter-se atualizado através de leitura de blogs, participação em listas de discussão, etc. Bom, você já está lendo esse post, então já está em uma boa direção.

Bom, mas e quando a gente acha um bug? O que fazer? Ele deve ser corrigido? Deve ser catalogado?

Nem todos os bugs precisam ser corrigidos. Eventualmente a correção de um bug pode ser bem mais cara do que a convivência com ele. Essa em geral não é uma decisão do time de testes, mas sim do cliente que vai conviver com aquela praguinha. Se ele não vai se incomodar, nós também não.

Ah, mas se acharmos um bug temos que prendê-lo, cataloga-lo, pendura-lo numa moldura para que todos vejam, certo? Não necessariamente. Tudo depende da política da sua empresa e do enfoque que você quer dar nos bugs. Eu não vejo problema algum em chegar no lado do desenvolvedor, avisar que tem um bug em algo que ele trabalhou ou está trabalhando e se der ele já resolve ali mesmo e fica no “ninguém viu”. Se existe algum motivo pelo qual você acha que eu falei uma heresia, pense um pouco e veja se realmente é. Muitas vezes nem fazemos nada com toda essa informação que catalogamos e mais! As vezes o tempo de você chegar no desenvolvedor e ele corrigir o problema é até menor do que você ficar simulando de novo e de novo, coletando evidências e preenchendo bug trackers. O que é mais útil pra você? Pense.. É uma resposta que depende de contexto.

Falando em bug tracker, será que uma ferramenta para gerenciar os bugs é realmente essencial? Será que eu não poderia gerenciar os bugs com post its mesmo? Se você trabalha com um quadro kanban (times que usam scrum geralmente usam um desse) você não poderia utiliza-lo para colocar uns post its de defeito também junto aos post its de atividades? No seu contexto pode ser melhor usar um bug tracker, mas se você não sente que está perdendo nada em não usar, eu acho muito mais prático, fácil e produtivo o uso de post it para isso.

Mas talvez você tenha mesmo que usar um bug tracker por N razões do seu contexto. Então, o que é importante ter um bug tracker quando eu vou reportar um bug? Eu considero como itens básicos:

. um título – um breve resumo de uma linha que faça com que o bug seja identificável facilmente
. como reproduzir e dados de teste
. ambiente em que o problema foi encontrado (se você testa em mais de um ambiente)
. criticidade – o quanto esse bug incomoda
. módulo – em que parte da aplicação foi encontrado
. evidência

Ai está uma coisa importantíssima. Já que você optou por usar um bug tracker, é bem provável que os defeitos que você abre não sejam corrigidos na mesma hora e esse já é um bom motivo para colocar uma evidência de que houve o problema. Isso facilita o entendimento do programador na hora de corrigir.

Na hora de reportar um bug, tenha certeza que você sabe que comportamentos você efetuou que desencadearam a praga.

. Teste com cuidado
. Reproduza o problema mais de uma vez
. Isole o problema, identifique a causa
. Generalize, veja outras áreas correlatas em que o mesmo problema ocorre
. Seja objetivo na sua descrição
. Revise o bug antes de submetê-lo na ferramenta, afinal, você é tester, mas também erra

Continuarei falando um pouco mais da palestra no próximo post.

Comentários são bem vindos :)

Quer ver os slides? Olha aqui no slideshare.