Compartilhar via


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