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.

Quero ser um caçador de bugs - TDC-SP

Na próxima semana vou palestrar no TDC-SP! \o/
Estarei na trilha de testes university falando sobre bugs para a galera que está iniciando na area de testes.
O objetivo da palestra é discutirmos como nascem os bugs, como trata-los, o que é importante quando reportamos um bug, se ferramentas de bug tracking são essenciais, como entender melhor o projeto e desenvolver a equipe avaliando bugs.

Espero vocês lá! :)

Inscrições promocionais do Agile Brazil 2012 encerram-se próximo dia 25/06

A Agile Brazil é a mais relevante conferência brasileira sobre Métodos Ágeis de desenvolvimento de software.

Em 2012, a conferência será sediada em São Paulo no mês de setembro e não poderíamos planejar nada menos do que a maior conferência ágil do Hemisfério Sul, reunindo grandes empresas e os mais experientes profissionais do mercado brasileiro de agilidade, sem falar nos convidados internacionais de primeira linha. Todos eles estarão compartilhando suas experiências em cursos, palestras, workshops, relatos de experiência, debates e muito mais. Não perca!

Veja no site os convidados especiais e cursos da Virada Agil.

Precos promocionais ate 25/06 !!

www.agilebrazil.com.br

TDC Call4Papers

O TDC está chegando e a Call4Papers vai apenas até domingo! Você já submeteu a sua palestra? Já fez a sua inscrição e aproveitou os preços baixíssimos desse super evento? Não fique de fora. É uma super oportunidade de networking. Saiba mais

Pesquisa crowdtesting

Oi pessoal,

uma aluna minha da Unisinos está preparando a sua monografia sobre Crowdtesting como trabalho de conclusão da especialização.

Vocês já participaram de algum projeto assim? Essa parte da pesquisa tem o objetivo de fazer uma avaliação sob a perspectiva dos testadores. Agradeço se puderem responder o questionário abaixo. Ao final do projeto eu dou uma palhinha do trabalho aqui. :)

https://docs.google.com/spreadsheet/viewform?formkey=dHF6QzBTcHlPNHBScmRPWG91Z1VOZ1E6MQ

Novo blog sobre cursos de testes

Depois de fazer a pesquisa sobre especializações em Teste de Software pelo Brasil, que resultou em uma planilha com uma lista de cursos, criei o blog Avançando no Teste de Software.

O objetivo é ter um ponto de consulta de cursos em todo o Brasil. Por enquanto estou colocando os cursos de pós graduação indicados pela comunidade, mas a ideia é que o blog tenha cursos técnicos e inclusive graduações que possuam disciplina de Teste de Software.

Quer indicar um curso para o blog? Comenta no post de Introdução do blog Avançando no Teste de Software e eu vou criando as páginas.

Configurando visibilidade de produtos no bugzilla

A correria anda grande e quase não tenho postado, mas esse eu achei que valeria a pena vir compartilhar.

Precisei configurar o bugzilla para um grupo de beta testers utilizarem. O objetivo era que os beta testers reportassem os bugs na mesma ferramenta que já estamos usando internamente para reportar os bugs para o time de desenvolvimento, evitando retrabalhos como copiar descrições ou importar/exportar de outras ferramentas.

Até ai, tudo bem, mas como os beta testers estão testando livremente, sem nenhum treinamento na aplicação e não tem nenhuma formação em teste, eles podem abrir bugs que seriam apenas sugestões e não defeitos, ou ainda abrir defeitos em funcionalidades que não foram desenvolvidas, entre outros mal entendidos que enxeriam a caixa dos desenvolvedores de questões não pertinentes e acabariam atrasando o trabalho deles.

Para isso então, criamos módulos separados dentro do mesmo projeto que seriam visíveis apenas para os beta testers enquanto os bugs já conhecidos, que os desenvolvedores já estão trabalhando, ficariam visíveis apenas para a equipe interna. E ai começou a trabalheira de encontrar como poderíamos omitir alguns produtos para uns e outros produtos para outros usuários.

O caminho natural foi procurar no manual do bugzilla, mas apesar de o manual explicar os parâmetros do bugzilla, ao menos para minha equipe não ficou claro como fazer o passo a passo para que funcionasse. Fuçando no google e no bugzilla, encontramos uma solução:

Menu Administration > Parameters > Group Security

Tem um parâmetro chamado usevisibilitygroups que deve ser ligado:

Feito isso, será necessário criar dois grupos de usuários. Esse foi o nosso erro mais insistente. Imaginamos a principio que como todos já estavam vendo os bugs, seria necessário criar apenas um grupo e limitar a visualização desse grupo. Mas na verdade não conseguimos fazer funcionar assim. Apenas quando criamos os dois grupos conseguimos gerenciar corretamente a visualização.

Para criar os grupos:

Menu Administration > Groups > Add Group

Há uma explicação no próprio bugzilla sobre como preencher os campos abaixo:

Lembre-se, crie os 2 grupos!

Agora vamos setar a visibilidade desses dois por produto.

Menu Adminsitration > Products e escolha um produto

Agora para cada produto será necessário dizer quem ve e posta bugs neles e quem não vê (e consequentemente não posta bugs).

Acesse um produto e vá em Edit Group Access Controls. Devem aparecer os dois grupos criados. E essa foi a configuração que funcionou pra nós.

Configuração para produtos acessíveis apenas pelos beta testers:

Configuração acessível pelos outros usuários que não são beta testers:

E não esquecer o mais importante agora: colocar cada usuário no grupo correto.

Menu Administration > Users > Search

Espero que você não tenha muitos usuários no sistema, agora será necessário atualizar um por um.

Observação: Nesse caso em que setamos a configuração de acesso para todos os produtos e todos os usuários, usuários novos que não pertençam a nenhum grupo não poderão abrir bugs.

Espero que o post seja útil para economizar um tempinho para você ou, se você tiver um jeito mais pratico, faz um post e linka aqui. :)