Apresentação demonstrando como usar alguns dos principais indicadores do Visual Studio ALM para acompanhamento da evolução de desenvolvimento de seu software.

1. ALM
Application Lifecycle Management
Indicadores – Como Usar

2. Objetivo

3. Explanar o uso de indicadores do ALM para obter o melhor
resultado com as equipes envolvidas.

4. Indicadores

5. Como acessar os indicadores e acompanhar a evolução?
Você pode acessar esses relatórios através do Portal Web do Projeto no Sharepoint Server®, ou do seu
Microsoft Excel®. O link de cada portal se encontra disponível na Web do Projeto do Team Foundation
Server®.
Indicadores
Acessando o Portal do Projeto no Sharepoint Server®, você terá diversas informações em gráficos e planilhas
Excel® para realizar consultas e até customizar sua visualização, conforme sua necessidade.

6. Como acessar os indicadores e acompanhar a evolução?
Indicadores
Há disponíveis relatórios e dashboards em Web e também em formato Microsoft Excel® para gerenciamento
desses indicadores e montagem de filtros conforme suas necessidades.

7. Monitorar a atividade de bugs, reativações e tendências.
Você pode usar os relatórios de bugs para controlar os bugs que a equipe está localizando e o progresso que
a equipe está fazendo para corrigi-los. Com esse relatório você pode tomar decisões para mudar o rumo do
projeto no decorrer de seu desenvolvimento.
Os relatórios associados a essa atividade são:
Indicadores
• Status do Bug
• Relatório de Tendências de Bugs
• Relatório de Reativações

8. Monitorar a atividade de bugs, reativações e tendências.
- Status do Bug
Depois que a equipe começou a localizar e corrigir erros, você pode acompanhar o progresso da equipe para
resolver e fechar bug, exibindo o relatório de estado de bug. Esse relatório mostra a contagem cumulativa de
bug com base no estado, prioridade e na gravidade do bug.
Descrição
Bug Progress
Uma representação visual de contagem cumulativa de todos os
bug, agrupada pelo seu status.
Active Bugs By Priority
Uma representação visual de contagem cumulativa de todos
erros, agrupada por sua prioridade.
7-Day Bug Trend Rates
Gráfico de linhas que mostra a média de número de bugs que a
equipe abriu, resolveu, e fechou, nas últimas quatro semanas
passadas.
Active Bugs by
Assignment
Um gráfico de barras horizontal com a contagem total de erros
ativos atribuídos a cada membro da equipe, agrupada por
prioridade.
Linha vertical
Número de bugs
Linha horizontal
Datas (tempo)
Indicadores
Informação

9. Monitorar a atividade de bugs, reativações e tendências.
- Status do Bug - Interpretação
Você pode examinar o relatório para determinar o progresso de uma iteração (semana) ao longo do tempo.
Especificamente, você pode encontrar respostas para seguintes questões:
A equipe está corrigindo os bugs e fechando rapidamente?
A equipe está corrigindo os bugs de alta prioridade primeiro?
Quantos bugs são atribuídos a cada membro da equipe?
Algum membro da equipe precisa de ajuda para resolver ou fechar um bug?
Indicadores
Que é a distribuição de bugs por prioridade e gravidade?

10. Monitorar a atividade de bugs, reativações e tendências.
- Status do Bug - Interpretação
Um relatório de estado íntegro de bug mostra um aumento nos bugs ativos ao longo do tempo seguidos por um
constante andamento de status de resolvido e fechamento de bugs, como mostra a ilustração a seguir. Quanto mais
a equipe corrigi erros que localiza, mais o número de erros ativos diminui.
Versão “não sadia” de um andamento de
correção de Bugs
Observe que a coloração de bugs ativos
diminui com o decorrer do tempo e a
coloração de bugs fechados predomina
Observe que a coloração de bugs ativos
aumenta com o decorrer do tempo e a
coloração de bugs fechados não predomina
Indicadores
Versão “sadia” de um andamento
de correção de Bugs

11. Monitorar a atividade de bugs, reativações e tendências.
- Status do Bug - Interpretação
Faixa - Bugs Ativos, Resolvidos e Fechados.
A faixa de bugs ativos está aumentando com o passar do tempo ultrapassando os bugs resolvidos ou fechados. A equipe está localizando
mais bugs do que pode resolver ou fechar.
Pergunte-se:
Os membros da equipe estão sendo realocados para outros bugs, projetos, tarefas?
A faixa de bugs ativos não está se alterando com o passar do tempo. Uma tendência suave no número de erros ativos indica que a equipe
não está localizando bugs.
Pergunte-se:
A cobertura de testes é suficiente?
Outros problemas estão bloqueando a capacidade da equipe de localizar bugs? Quais? Problemas de ambiente, entendimento do requisito,
bugs impeditivos, etc.
Indicadores
Outros problemas estão bloqueando a capacidade da equipe em resolver e corrigir bugs? Quais? Ambientes, entendimento de regras, etc.

12. Monitorar a atividade de bugs, reativações e tendências.
- Status do Bug - Interpretação
Faixa - Bugs Ativos, Resolvidos e Fechados.
A faixa de bugs resolvidos ou fechados não estão se alterando. Quando o número de bugs que estão sendo resolvidos ou que deveriam estar
sendo fechados não sofrem alteração por longos períodos de tempo, os membros da equipe podem não ser capazes de resolver ou fechar
esses bugs.
Pergunte-se:
Os membros das equipes estão sendo alocados em outras tarefas, ou super-alocados?
Os membros das equipes estão definindo corretamente os status de bug?
Indicadores
As prioridades das equipes estão definidas corretamente?

13. Monitorar a atividade de bugs, reativações e tendências.
- Status do Bug - Interpretação
Faixa - Bugs Assinados e Prioridades
As atribuições de erro não são distribuídas igualmente.
Pergunte-se:
O número de bug ativos de alta prioridade é maior que o número de bugs ativos de prioridade inferior. Quando o número de bugs de alta
prioridade é muito maior que o número de bugs de prioridade inferior, o trabalho pode não progredir, pois as vezes, um projeto progride em
itens de prioridade inferior primeiro.
Pergunte-se:
A equipe está corrigindo os bugs na ordem de prioridade definida pelo time?
As prioridades dos bugs estão sendo bem definidas?
Indicadores
A equipe precisa equilibrar a carga de trabalho designando bugs para outros integrantes do time?

14. Monitorar a atividade de bugs, reativações e tendências.
- Relatório de Tendências de Bugs
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.
Descrição
7-day arrival rate
Média de andamento de bugs abertos, agrupados em 07 dias.
7-day resolved rate
Média de andamento de bugs resolvidos, agrupados em 07 dias.
7-day closed rate
Média de andamento de bugs fechados, agrupados em 07 dias.
Linha vertical
Número de bugs
Linha horizontal
Datas (tempo)
Indicadores
Informação

15. Monitorar a atividade de bugs, reativações e tendências.
- Relatório de Tendências de Bugs - 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.
Na linha azul a equipe está abrindo bugs
muito mais rápido do que resolvendo e
fechando, causando “afunilamento”
Indicadores
Versão “não sadia” de um andamento de
status de Bugs

16. Monitorar a atividade de bugs, reativações e tendências.
- Relatório de Tendências de Bugs - Interpretação
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.
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?
Indicadores
Pergunte-se:

17. Monitorar a atividade de bugs, reativações e tendências.
- Relatório de Tendências de Bugs - Interpretação
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:
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.
Indicadores
O progresso dos testes indicam um problema com o código ou os testes?

18. Monitorar a atividade de bugs, reativações e tendências.
- Relatório de Tendências de Bugs - Interpretação
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?
Indicadores
A equipe deve revisar as prioridades de testes?

19. Monitorar a atividade de bugs, reativações e tendências.
- Relatório de Reativações
Indicadores
Depois que a equipe resolve e fecha os bugs, você pode usar o relatório de reativações para determinar como
efetivamente essas correções estão sendo feitas. As reativações são geralmente bugs resolvidos e fechados
prematuramente e reabertos em seguida.

20. Monitorar a atividade de bugs, reativações e tendências.
- Relatório de Reativações – Interpretação
Você deve esperar o relatório variar baseado em seu ciclo de desenvolvimento. A taxa de reativação
demonstra o numero de erros supostamente corrigidos onde as correções apresentaram falhas.
Versão “não sadia” de um relatório de
reativação
Indicadores
Versão “sadia” de um relatório de
reativação

21. Monitorar a atividade de bugs, reativações e tendências.
- Relatório de Reativações – Interpretação
Há um número alto de reativações de bug. Uma taxa alta de reativação de bug pode indicar que a equipe está
fechando bugs prematuramente.
Pergunte-se:
Há testes de unidade sendo executados?
O laboratório de testes está gerenciado de forma correta, não influenciando nos resultados?
A cobertura de testes é suficiente para os cenários descritos?
São outros problemas raízes que causam as reativações?
Indicadores
A descrição do bug oferece suporte suficiente para a resolução do erro pelo time de desenvolvimento?

22. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
Você pode usar o relatório de andamento de requisitos para analisar o nível de esforço que a equipe tem
gasto em cada caso de uso que está sendo implementando. Usando este relatório, você pode determinar
rapidamente se qualquer trabalho recentemente foi concluído em cada tarefa e o trabalho restante.
•
•
•
•
•
Relatório Burndown e Burn Rate
Relatório de Trabalho Restante
Relatório de Status de Todas as Iterações
Relatório de Progresso de Requisitos/Casos de Uso
Relatório Visão Geral de Requisitos/Casos de Uso
Indicadores
Os relatórios associados a essa atividade são:

23. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório Burndown e Burn Rate
Informação
Descrição
Hours complete
Horas completadas das tarefas na iteração
Hours remaining
Horas restantes das tarefas na iteração
Ideal Trend
Tendência ideal
Actual Trend
Tendência real
Linha horizontal
Horas (tempo)
Linha vertical
Datas (tempo)
Indicadores
Depois que uma equipe trabalhou em uma ou mais iterações, você pode determinar a taxa de progresso da equipe
examinando o relatório de taxa de Burndown. Burndown mostra a tendência de trabalho concluído e o restante durante um
período de tempo especificado. A taxa de Burn Rate fornece cálculos da taxa concluída e necessária de trabalho baseado no
período de tempo especificado. Além disso, um gráfico a seguir mostra a quantidade de trabalho concluído e restante que é
atribuído a membros da equipe. Você pode exibir o relatório da taxa de Burndown e de Burn Rate baseado em horas
trabalhadas ou no número de itens de trabalho que foram resolvidos e fechados.

24. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório Burndown e Burn Rate (Configuração)
Para que o Relatório de Burndown e o Burn Rate seja útil e preciso, a equipe deve realizar as seguintes atividades para o
rastreamento de itens de trabalho:
Indicadores
- Definir as tarefas, requisitos e bugs, e especificar a iteração e os caminhos para cada área.
- Especificar e atualizar os campos para cada tarefa ou sub tarefa conforme forem trabalhados.

25. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório Burndown e Burn Rate - Interpretação
Você pode examinar o relatório para determinar o progresso que a equipe fez em uma iteração ou ao longo do tempo.
Você pode encontrar respostas para as seguintes questões:
Versão “sadia” de um relatório de
reativação
Versão “não sadia” de um relatório de
reativação
Indicadores
A equipe adicionou trabalho durante a iteração? Houve mudanças constantes de escopo? Qual a velocidade da equipe para
concluir as tarefas? Quanto de trabalho pode se concluir com o tempo restante? Quando a equipe pode concluir o trabalho?

26. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório Burndown e Burn Rate - Interpretação
Indicadores
Quando o Burn Rate (Taxa de Queimadura) da equipe não encontra o Burn Rate (Taxa de Queimadura) planejada, o relatório
de Burndown mostrará uma linha de Tendência Real distante acima da linha de Tendência Ideal . A linha de Tendência Real
irá cruzar o eixo X significativamente mais do que a data de término planejada. Essas características indicam que o equipe
não concluirá todos os requisitos que foram planejados para essa interação antes do previsto. Quando o progresso real é
menor que o progresso planejado, o esforço necessário é maior do que a equipe estimou, as tarefas são mais difíceis, o time
subestimou ou não consideraram outros fatores que precisarão ser revistos depois da conclusão.

27. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório de Trabalho Restante
Informação
Descrição
Hours complete
Horas completadas das tarefas na iteração
Hours remaining
Horas restantes das tarefas na iteração
Linha horizontal
Horas (tempo)
Linha vertical
Datas (tempo)
Indicadores
O relatório de trabalho restante resume os dados que foram detectados durante o intervalo de tempo especificado para
cada tarefa, caso de uso/requisito, ou bugs com base nos critérios de filtragem que foram especificados para o relatório.

28. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório de Trabalho Restante – Interpretação
O relatório restante de trabalho exibe informações que você pode usar para entender o quanto a equipe está progredindo e
se a equipe irá concluir as tarefas dentro do tempo alocado. Você pode responder perguntas como:
Quanto rápido é a equipe que trabalha no projeto?
Há trabalho sendo adicionado durante a iteração? A equipe está expandindo o escopo de trabalho?
Aproximadamente quando a equipe pode fazer o trabalho?
É muito trabalho em execução?
O fluxo de trabalho está sendo impedido ou bloqueado?
Quando a equipe irá concluir a iteração atual?
Indicadores
Quanto de progresso pode fazer a equipe com o tempo disponível?

29. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
Um relatório íntegro de trabalho mostra o andamento regular em resolver e
em fechar tarefas, como mostra a ilustração a seguir. A forma retangular de
diagrama indica que o trabalho estimado corresponde ao trabalho
necessário.
A ilustração a seguir mostra uma versão não íntegra de relatório restante de
trabalho. O progresso é feito por várias semanas de cada vez, indicado pela
linha plana de itens de trabalho que permanecem em um estado inalterado.
Além disso, o número de itens de trabalho aumenta após o ponto médio de
iteração, que indica que foram introduzidas mais tarefas.
Indicadores
- Relatório de Trabalho Restante – Interpretação

30. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório de Status de Todas as Iterações
O status em todas as iterações apresenta um instantâneo de trabalho que a equipe realizou através de várias iterações,
como a ilustração a seguir mostra.
Descrição
Requirements closed
Requisitos concluídos.
Progress (Hours)
Progresso estimado em horas.
Bugs
Bugs encontrados.
Iteration
Divisão em semana, iteração, versão.
Original Estimate
Tempo original estimado da iteração.
Completed
Progresso completado da iteração.
Remaining
Progresso restante da iteração.
Active
Bugs ativos.
Resolved
Bugs resolvidos.
Closed
Bugs fechados.
Indicadores
Informação

31. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório de Status de Todas as Iterações – Interpretação
Você poderá responder perguntas como:
O escopo de trabalho para cada iteração corresponde à capacidade de equipe?
O número de casos de uso/requisitos fechados em cada iteração corresponde a suas expectativas?
Versão “sadia” de um relatório de status
Versão “não sadia” de um relatório de
status
Indicadores
Quantos casos de uso/requisitos pode enviar a equipe hoje?

32. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório de Status de Todas as Iterações – Interpretação
Caso o status não seja integro, qualquer relatório de iterações pode mostrar um ou mais
dos seguintes indicadores:
Nenhum caso de uso/requisito foi fechado em uma ou mais iterações.
Você pode querer examinar o tamanho desse requisito para determinar se a equipe pode
“quebrar” em requisitos menores e menos complexos.
O número de tempo estimados e concluídos varia amplamente dentro e entre as
iterações.
Você pode querer examinar quanto você está dimensionamento os requisitos e quanto a
equipe está estimando o trabalho. Quando a hora estimada e concluída correspondem
dentro de uma iteração, indica que a equipe está bem posicionada e progride em uma
taxa aceitável.
Progresso inconsistente feito por iterações passadas.
Você pode desejar determinar se quaisquer problemas de bloqueio não foram
identificados ou não foram rastreadas anteriormente.
Indicadores
Versão “não sadia” de um relatório de
status

33. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório de Progresso de Requisitos
O relatório de progresso dos requisitos mostra o status de conclusão conforme determinado por tarefas que foram definidas
para implementar o requisito.
Descrição
Progress (% Completed)
O valor numérico representando a porcentagem de trabalho
concluído com base no rollup da linha de base e tempo para
concluir todas as tarefas que são vinculadas ao requisito ou a
seus requisitos filhos.
Hours Completed
Uma representação visual de horas concluídas.
Recently Completed
Um representação visual das horas concluídas recentemente
dentro do tempo especificado.
Hours Remaining
Horas restantes para todas as tarefas vinculadas ao requisito ou
a seus requisitos filhos.
Indicadores
Informação

34. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório de Progresso de Requisitos
Requisitos que aparecem no relatório.
As listas de relatório de progresso dos requisitos e os requisitos destacados estão de acordo com os seguintes critérios:
Os requisitos aparecem por ordem da importância, com base na sua classificação atribuída.
Os requisitos aparecem no tipo normal quando estão no estado fechado.
Os requisitos aparecem no tipo cinza quando a iteração ou área atribuída são fora do conjunto filtrado mas tem as tarefas
ou os requisitos filho que estão dentro do conjunto filtrado de iterações ou de áreas do produto.
Indicadores
Os requisitos aparecem em negrito quando estão em estado ativo ou resolvido.

35. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório de Progresso de Requisitos – Interpretação
Quais requisitos a equipe fez progresso, e quais estão quase concluídos?
Requisitos que a equipe fez progresso mostrará uma faixa verde dentro da barra de progresso.
Os requisitos que estão quase completos indicarão uma % de elevação e a barra de progresso estará quase completamente verde, e poucas
horas serão listadas na coluna de Horas Restantes.
Os requisitos que não foram trabalhados não mostrarão nenhuma faixa verde claro dentro de barra de progresso.
Requisitos que têm a maioria de trabalho a ser concluído ainda?
Os requisitos que têm a maioria de trabalho a concluir mostrarão uma faixa azul significativa dentro de barra de progresso e um grande
número de hora na coluna de Horas Restantes.
Indicadores
Requisitos que não foram trabalhados pela equipe?

36. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório de Progresso de Requisitos – Interpretação
O trabalho está bloqueado em um requisito?
Os requisitos que não mostram nenhuma faixa verde claro na barra de progresso pode indicar um problema de bloqueio.
Se a equipe não concluiu qualquer trabalho de um requisito por várias semanas, convém determinar e identifica os problemas de bloqueio ou
de recurso.
De acordo com os requisitos que ainda estão ativos, convém adiar alguns requisitos para uma iteração mais recente de modo que a equipe
possa se concentra em concluir outros requisitos na iteração atual.
Indicadores
Podemos entregar tudo que nós planejamos? Quais metas devemos remover do escopo?

37. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório Visão Geral de Requisitos
O relatório de visão geral dos requisitos apresenta um instantâneo de trabalho que foi executado para o conjunto filtrado de
requisitos para a data atual.
Descrição
% Hours Completed
Mostra a porcentagem de trabalho concluído com base na linha
de base para todas as tarefas vinculadas ao requisito ou a seus
requisitos filhos.
Hours Remaining
Horas restantes para todas as tarefas vinculadas ao requisito ou
a seus requisitos filhos.
Test Points
Representa o número de situações de testes que estão
vinculados a seus requisitos ou requisitos filhos.
Test Results
Representa a porcentagem das situações dos testes, agrupados
de acordo com o status do seu ensaio mais recente, onde
opções Passou (Verde), Falha (Vermelho) ou Não executado
(Preto).
Bugs
Mostra o número de erros associados à situação de teste ou
requisito, onde as opções Ativo (Azul) e Resolvido (Dourada). Se
o requisito é associado a um requisito filho, os valores
representam um rollup de todos os erros, tanto dos pais como
filhos.
Indicadores
Informação

38. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório Visão Geral de Requisitos
A lista de Relatório de Visão geral dos Requisitos tem os requisitos destacados de acordo com os seguintes critérios:
Os requisitos aparecem por ordem da importância, com base na sua classificação atribuída.
Os requisitos aparecem em negrito quando estão em estado ativo ou resolvido.
Os requisitos aparecem no tipo cinza quando a iteração ou área atribuído são fora do conjunto filtrado, mas tem as tarefas
ou os requisitos de filho que estão dentro do conjunto filtrado de iterações ou de áreas do produto.
Indicadores
Os requisitos aparecem no tipo normal quando estão no estado fechado.

39. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório Visão Geral de Requisitos – Interpretação
O Relatório de Visão Geral de Requisitos mostra o andamento de trabalho total em três áreas que são importantes para
concluir e fechar um requisito:
Tarefas implementadas para concluir cada requisito.
Bugs identificados que indicam problemas com a qualidade dos requisitos.
Versão “sadia” de um relatório de
requisitos
Indicadores
Execução de teste para garantir a qualidade dos requisitos implementados.

40. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório Visão Geral de Requisitos – Interpretação
Um relatório não está íntegro quando mostra uma ou mais das seguintes situações:
A equipe está fazendo mais progresso dos requisitos que têm uma prioridade mais baixa de que os requisitos que têm uma
prioridade mais alta;
Os testes estão falhando para um requisito, mas nenhum item de trabalho de bug está sendo criado.
Indicadores
Mais testes estão falhando do que está passando;

41. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório Visão Geral de Requisitos – Interpretação
Esse relatório pode-lhe responder as seguintes questões:
Estado de trabalho
A quantidade de trabalho que permanece para cada requisito corresponde a suas expectativas?
Quantas situações de teste são definidas para cada requisito? Quantos testes estão passando?
Há requisitos que são implementados que não têm uma situação de teste definida para ele?
Progresso de qualidade
Quantos testes foram executados para cada requisito, e quantos passaram?
Quantos bugs ativos cada requisito tem?
Os bugs estão sendo são resolvidos ou permanecem ativos?
Indicadores
Os requisitos de maior prioridade são implementados primeiro?

42. Controlar a integridade do projeto, taxa de andamento de equipe e
conclusão da tarefa.
- Relatório Visão Geral de Requisitos – Interpretação
Avaliação de risco
Quais requisitos que estão em risco?
Quais requisitos que não são estáveis o suficiente para a versão?
Indicadores
Quais requisitos que podem ser enviados a equipe hoje?

43. Determinar o trabalho adicional.
Você pode usar o relatório trabalho planejado para determinar a quantidade de trabalho da equipe adicionada
a uma iteração após iniciado.
O relatório associado a essa atividade é:
Indicadores
• Trabalho não planejado

44. Determinar o trabalho adicional.
- Trabalho não Planejado
Informação
Descrição
Added Later
Tarefas adicionadas após o planejamento
Planned
Tarefas planejadas antes do fechamento
Linha horizontal (Number of Work Item)
Numero de itens de trabalho
Linha vertical
Datas (tempo)
Indicadores
O relatório de Trabalho não Planejado é útil quando a equipe planeja uma iteração identificando todos os itens de trabalho
que pretendem resolver ou fechar durante a iteração. Os itens de trabalho que são atribuídos a iteração na data de criação
do planejamento são considerados trabalho planejado. Todos os itens de trabalho que são adicionados à iteração em
seguida a data que são identificados como trabalho não regulares.

45. Determinar o trabalho adicional.
- Trabalho não Planejado – Interpretação
Você pode usar esse relatório para responder às seguintes questões:
Quanto trabalho foi adicionado após a iteração ter começado?
Indicadores
Muito trabalho está sendo adicionado durante a iteração?

46. Monitor de atividade de teste.
Você pode usar os relatórios de teste para rastrear o progresso da equipe para desenvolver casos de teste e
determinar como eles abordam os requisitos.
Os relatórios associados a essa atividade são:
Indicadores
• Relatório de Preparação dos Casos de Testes
• Relatório de Progresso do Plano de Testes

47. Monitor de atividade de teste.
- Relatório de Preparação de Casos de Testes
Informação
Descrição
Linha horizontal Number of Test Cases
Numero de casos de testes
Design
Casos de testes em estado de confecção
Ready
Casos de testes prontos para serem executados
Linha vertical
Datas (tempo)
Indicadores
O relatório de preparação de casos de teste fornece um gráfico da área que exibe quantas situações de teste estão no
estado de Design ou de Pronto durante o período de tempo que você especificar. Examinando esses dados, você pode
facilmente determinar como rapidamente a equipe está criando situações de teste e as que estão prontas para teste.
Quando você cria uma situação de teste, é definida automaticamente ao estado de exibição design. Depois que a equipe
revisar a situação de teste, então um membro da equipe deve alterar o estado para Pronto, que indica que a situação de
teste está pronto para ser executada.

48. Monitor de atividade de teste.
- Relatório de Preparação de Casos de Testes - Interpretação
Você pode examinar o relatório para determinar o progresso da equipe em uma iteração ou ao longo do tempo. Por
exemplo, você pode responder a essas questões:
Quantos casos de teste estão prontos para serem executados?
Quantas situações de teste deve a equipe ainda escrever e examinar?
Todas os casos de teste estarão prontos para serem executados no final da iteração?
Indicadores
Quando todos os casos de teste estarão prontos para serem executados?

49. Monitor de atividade de teste.
- Relatório de Preparação de Casos de Testes - Interpretação
Observe que os estados não mudam com
o passar das semanas
Versão “íntegra” de um planejamento de
testes
Observe que há um progresso regular dos
estados
Indicadores
Versão “não íntegra” de um planejamento
de testes

50. Monitor de atividade de teste.
- Relatório de Preparação de Casos de Testes - Interpretação
Quando os casos de teste estarão prontos para serem executados.
Quando todas as situações de teste permanecem em um estado de design, algum problema está bloqueando o andamento.
Você pode investigar a causa desse bloqueio.
O número de situações de teste que são definidas para um projeto deve ser maior ou igual ao número de casos de
uso/requisitos que a equipe está implementando.
Indicadores
O número de situações de teste não é suficiente.

51. Monitor de atividade de teste.
- Relatório de Progresso do Plano de Testes
Os dados que aparecem no relatório de progresso de plano de teste são derivados de data warehouse e de resultados de
teste que são gerados quando os testes são executados usando Microsoft Test Manager. O relatório apresenta um gráfico da
área que mostra o resultado mais recente executado, qualquer teste nos planos de teste especificados ao longo do tempo.
Descrição
Passed
Número de casos de testes que passaram
Failed
Número de casos de testes que falharam
Blocked
Número de casos de testes que foram bloqueados
Never Run
Número de casos de testes que nunca foram executados
Other
Numero de casos de testes foram executados e atribuídos
aos seguintes estados: desligado, tempo limite, em
andamento.
Indicadores
Informação

52. Monitor de atividade de teste.
- Relatório de Progresso do Plano de Testes – Interpretando
Você pode controlar quantas planos de teste foram executados e quanto estão falhando. O relatório de progresso de plano
de teste exibe o valor cumulativo de todos os planos de teste, agrupados pelo status de resultado.
Perguntas respondidas:
Quantos testes estão passando?
Quantos testes são bloqueados?
Indicadores
Quantos testes estão falhando?

53. Monitor de atividade de teste.
- Relatório de Progresso do Plano de Testes – Interpretando
Como mostra a ilustração a seguir, há uma
curva sadia onde com o tempo os casos
de testes com status de passado
sobrepõem os demais estados
Versão “não íntegra” de um progresso de
plano de testes
Como mostra a ilustração a seguir, o
número de situações de teste que está
passando, falhando, ou nunca é executado
não tem mudanças.
Indicadores
Versão “íntegra” de um progresso de
plano de testes

54. Muito obrigado!