Um conjunto sucedido de testes, geralmente apanham um pequeno conjunto de defeitos. Contudo se estes defeitos ou outras observações não forem devidamente endereçadas, o esforço do teste acaba por ser desperdiçado. A atividade de gestão destes casos que vão surgindo é normalmente chamada de gestão de incidentes. É um processo que segue todos os defeitos desde o seu aparecimento até à sua resolução e respectiva verificação. Todos os incidentes devem ser registados. A elaboração de um relatório de incidente eficiente proporciona que os defeitos sejam mais rapidamente resolvidos e que a gestão de projeto consiga tomar decisões corretas com base nessa informação.
Um bom relatório deve ser específico de modo a refletir exatamente o que consiste o problema. Para fazer isto o defeito deve possuir informação acerca de como o mesmo pode ser reproduzido, informando o leitor de que passos exatamente são necessários para reproduzir o problema.
Um relatório de um defeito deve ser único. O que quer dizer que não se deve criar vários defeitos para as várias manifestações do mesmo problema. Ou porque diferentes exemplos de entrada resultaram num mesmo erro. Claro que vão existir situações em que um tester que não tenha conhecimento interno sobre o modo como a estrutura da aplicação está definida pode facilmente interpretar duas manifestações de um problema em pontos distintos da aplicação como casos diferentes. Para este tipo de problemas provavelmente só a experiência e uma boa comunicação como a equipa de desenvolvimento ajuda a perceber a distinguir estes casos. Caso contrário o segundo defeito a ser analisado pela equipa de desenvolvimento vai acabar muito provavelmente com um “Rejeitado, Porque não consegui reproduzir”. Não quer dizer com isto que o erro não existiu, mas a correção da primeira incidência inviabilizou a reprodutibilidade da segunda. A ocorrência frequência deste tipo de situações ajudam a “minar” a credibilidade da equipa de testes.
Outra boa prática é evitar de abrir defeitos em duplicado. Uma equipa de Quality Assurance (QA) pode ser composta por vários elementos, e é perfeitamente natural que duas pessoas diferentes reparam num mesmo erro da aplicação. Estas pessoas por sua vez vão registá-lo no sistema de controlo de defeitos. Mas se o elemento que irá efetuar o segundo registo não tiver o cuidado de verificar no sistema que o defeito não existe vamos novamente ficar com um duplicado, e invariavelmente um deles vai acabar com o estado rejeitado.
Quando uma equipa de QA (esta dica pode e deve ser estendida a toda a equipa de trabalho, QA, desenvolvimento, gestão) é composta por vários elementos é fundamental que todos os elementos falem uma língua em comum para evitar descrições de um mesmo problemas de um modo completamente diferente. Caso uma situação destas possa acontecer, no exemplo descrito acima mesmo uma procura no sistema de rastreio de defeitos pelo problema que estamos a registar vai ser infrutífera porque os dois elementos usam terminologias diferentes. Esta situação pode ser ainda mais grave se existirem divergências deste género entre a equipa de testes e a equipa de desenvolvimento. Defeitos podem ser rejeitados apenas porque a equipa de desenvolvimento não os percebeu.
São apenas algumas dicas sobre como abrir e gerir defeitos. Espero que ajude.
Bom, Até à Próxima.
