ALM - Acompanhamento de Bugs
Imagine que você tem um projeto de desenvolvimento de software que depende de uma entrega no prazo exato, onde o cliente é extremamente crítico e não há “brechas”para falhas, e você precisa ter em tempo real como está o andamento do desenvolvimento, mas nesse caso, precisamente as correções de Bugs, que normalmente é o que mais atrasam um projeto.
No Visual Studio ALM vocë possui um relatório específico para isso, é o chamado Tendências de Bugs ou bug Trends.
Para usar é fácil:
Abra o Web Access do TFS e vá no link do Portal de Projeto de seu projeto.
http://qualidadeeti.files.wordpress.com/2013/12/image_thumb15.png?w=244&h=92
Você pode ter um Dashboard, informando os ultimos 07 dias e como está o status de correção dos mesmos.
http://qualidadeeti.files.wordpress.com/2013/12/image_thumb16.png?w=244&h=180
E também um relatório em Reports – Bugs – Bugs Trends
http://qualidadeeti.files.wordpress.com/2013/12/image_thumb17.png?w=244&h=83
http://qualidadeeti.files.wordpress.com/2013/12/image_thumb18.png?w=244&h=65
http://qualidadeeti.files.wordpress.com/2013/12/image_thumb19.png?w=244&h=224
O relatório de tendências de bugs calcula a média de andamento do número de bugs que a equipe abriu, solucionou, e fechou com base nos filtros que você especificar.
http://qualidadeeti.files.wordpress.com/2013/12/image_thumb20.png?w=244&h=74
Interpretação
Você deve aguardar as taxas de bugs variarem, baseadas em onde você está (período) em seu ciclo de desenvolvimento. A equipe deve encontrar menos erros em iterações (semanas) adiantadas do que em uma iterações (semanas) anteriores.
Com o produto estabilizando no final de um ciclo de desenvolvimento, a equipe deve encontrar bugs com menos frequência.
Linhas – 7 day arrival rate, 7-day resolved rate, 7-day closed rate
A equipe está encontrando números de bugs mais ou menos idênticos em períodos de tempo sucessivos. Se a equipe encontra o mesmo número de bugs semana após semana ou de iteração após iteração, você pode investigar a causa. No início do ciclo de teste, os testes podem não ser rigorosos ou avançados suficiente para localizar vários bugs. Em interações adiantadas, essa situação é esperada, pois revela amadurecimento do código.
Pergunte-se:
As situações de testes são suficientes para os casos de uso e requisitos que estão sendo desenvolvidos?
Os testes tornaram-se obsoletos ou estão testando a funcionalidade de forma incorreta?
São testes rigorosos?
A equipe está encontrando muitos bugs em períodos curtos. A equipe pode localizar bugs facilmente em código superficial, no código recentemente integrado (build), com testes rigorosos, ou durante um evento específico.
A equipe está encontrando poucos bugs em períodos curtos. A equipe pode se esforçar para encontrar bugs em um código de alta qualidade ou testes ineficazes.
Pergunte-se:
O progresso dos testes indicam um problema com o código ou os testes?
A equipe está resolvendo muitos bugs em períodos curtos. Uma taxa alta de resolução indica que a equipe está fazendo bom progresso.
Pergunte-se:
Status resolvido do bug é fechado prontamente? O índice de fechado deve se parecer com o índice de resolvido.
A equipe está resolvendo bugs rapidamente mas não os está fechando. Os membros da equipe que estão atribuídos para verificar correção de bugs podem ter prioridades mal definidas ou distribuídas.
Pergunte-se:
Os membros da equipe de testes estão super-alocados?
A equipe deve revisar as prioridades de testes?
Bom, é isso aí, espero ter ajudado e até a próxima!
Um abraço.
Alan Carlos