Compartilhar via


Painel Qualidade (Agile e CMMI)

Você pode usar o painel de controle de qualidade para obter uma visão geral de progresso ocorrido no teste, desenvolvimento e criar áreas como eles se relacionam com a qualidade do software em desenvolvimento. A equipe pode usar o painel de controle de qualidade de aprender e tomar decisões que oferecem suporte a metas da equipe em torno de qualidade do produto.

Ao usar esse painel, você pode analisar o andamento do teste, criar estados, progresso em Resolvendo e fechando bugs, taxa de reativações de bugs, a porcentagem de código foi testado e as tendências de alterações de código. Cada uma dessas métricas é plotada das últimas quatro semanas.

Neste tópico

  • Dados exibidos no painel

  • Atividades necessárias para controle de qualidade

  • Solucionar problemas de qualidade

Você pode usar esse painel para responder às seguintes perguntas:

  • É o esforço de teste na faixa?

  • A equipe está testando a funcionalidade apropriada?

  • São correções da equipe de alta qualidade?

  • Os testes estão parados?

  • A equipe tem testes suficientes?

  • Gargalos estão ocorrendo?

Requisitos

Mesmos requisitos definidos na Painéis de portal do projeto.

Dados exibidos no painel

Os membros da equipe podem usar o painel de controle de qualidade para determinar a qualidade geral do produto que estão desenvolvendo. Em casos ideais, taxas de aprovação de teste, bugs e código variação Mostrar todos a mesma imagem, mas geralmente eles não. Quando você encontrar uma discrepância, você deve examinar mais de perto a compilação apropriado e a série de dados. O painel qualidade combina os resultados de teste, a cobertura de código de teste, variação de código e bugs, para ajudá-lo a compreender muitas perspectivas ao mesmo tempo.

Para saber mais sobre as Web Parts que são exibidos no painel qualidade, consulte a ilustração e a tabela a seguir.

Product Quality Dashboard

Dica

O andamento do plano de teste relatório está disponível apenas quando a equipe cria planos de teste e executa testes.

Relatórios de andamento, compilação e gráficos de código, Step 1 por meio de Step 6, não aparecem quando o data warehouse para o projeto de equipe não está disponível.

Para saber mais sobre como interpretar, atualizar ou personalizar os gráficos que aparecem no painel qualidade, consulte os tópicos na tabela a seguir.

Web Part

Dados exibidos

Tópico relacionado

Step 1

Gráfico de área empilhada dos resultados do teste de todos os casos de teste, agrupados por seus últimos resultados gravados – Nunca execute, bloqueado, Falha, ou aprovado - durante as últimas quatro semanas.

Test Plan Progress Excel Report

Relatório Progresso do Plano de Teste

Step 2

Empilhadas colunas que mostram quantas compilações Falha ou Succeeded durante as últimas quatro semanas.

Build Status report

Relatório do Excel Status da Compilação

Step 3

Um gráfico de área empilhada da contagem cumulativa de todos os Bugs, agrupados por estado, durante as últimas quatro semanas.

Bug Progress Excel Report

Relatório do Excel Andamento de Bugs

Step 4

Um gráfico de área empilhada de quantos bugs a equipe tem reativados do estado resolvido ou fechado durante as últimas quatro semanas.

Bug Reactivations Excel Report

Relatório do Excel Reativações de Bugs

Step 5

Gráfico de linhas que mostra a porcentagem de código testada por criar testes de verificação (BVT) e outros testes durante as últimas quatro semanas.

Code Coverage Report

Relatório do Excel Cobertura de Código

Step 6

Empilhadas gráfico de área que mostra quantas linhas de código a equipe adicionou, removeu e modificou nos check-ins antes da compilação durante as últimas quatro semanas.

Code Churn Report

Relatório do Excel Variação de Código

Step 7

Lista dos próximos eventos. Essa lista é derivada de uma Web Part do SharePoint.

Import Events Web part

Não aplicável

Step 8

Contagem de itens de trabalho ativos, resolvidos e fechados. Você pode abrir a lista de itens de trabalho selecionando cada número. Essa lista é derivada de uma Web Part do Acesso Web da Equipe.

Project Work Items Web part

Não aplicável

9

Lista de compilações recentes e o respectivo status. Você pode ver mais detalhes escolhendo uma compilação específica. Essa lista é derivada de uma Web Part do Acesso Web da Equipe.

Recent Builds Web part

Legenda:

Build in Progress : Compilação não iniciada

Build Not Started : Compilação em andamento

Build Succeeded : Compilação com êxito.

Build Failed : Falha na compilação.

Build Stopped : Compilação interrompida

Build Partially Succeeded : Compilação parcialmente bem-sucedida

Executar, monitorar e gerenciar compilações

10

Lista dos check-ins mais recentes. Você pode ver mais detalhes escolhendo um check-in específico. Essa lista é derivada de uma Web Part do Acesso Web da Equipe.

Recent Checkins Web part

Desenvolver código e gerenciar alterações pendentes

Atividades necessárias para monitorar a qualidade

Para o painel qualidade sejam úteis e precisos, a equipe deve executar as atividades descritos nesta seção.

Atividades necessárias para acompanhar o andamento do plano de teste

Para o relatório de andamento do plano de teste sejam úteis e precisos, a equipe deve executar as seguintes atividades:

  • Definem casos de teste e histórias de usuários e criar testado por links entre os casos de teste e histórias de usuários.

  • Definir planos de teste, e atribuir os casos de teste para planos de teste.

  • Para testes manuais, marque os resultados de cada etapa de validação no caso de teste como aprovada ou reprovada.

    Importante

    Os testadores devem marcar uma etapa de teste com um status se se trata de uma etapa de teste de validação.O resultado geral para um caso de teste reflete o status de todas as etapas de teste que o testador marcado.Portanto, o caso de teste terá um status de falha se o testador marcado qualquer etapa de teste com falha ou não marcou.

    Para testes automatizados, cada caso de teste é marcado automaticamente como aprovada ou falhou.

  • (Opcional) Para oferecer suporte a filtragem, atribuir iteração e área caminhos para cada caso de teste.

    Dica

    Para obter informações sobre como definir caminhos de iteração e área, consulte Adicionar e modificar área e caminhos de iteração.

Atividades necessárias para acompanhar o andamento de bugs e reativações de bugs

Para os relatórios de andamento de bugs e reativações de bugs sejam úteis e precisos, a equipe deve executar as seguintes atividades:

  • Defina Bugs.

  • Atualização de estado de cada Bug como as correções de equipe, verifica, fecha ou reativa a ele.

  • (Opcional) Especifique o iteração e área caminhos de cada Bug se você quiser filtrar por esses campos.

Atividades necessárias para acompanhar criam status, cobertura de código e variação de código

Para o Status da compilação, cobertura de código e variação de código relatórios sejam úteis e precisos, os membros da equipe devem executar as seguintes atividades:

  • Configurar um sistema de compilação. Para usar o Team Foundation Build, você deve configurar um sistema de compilação.

    Para obter mais informações, consulte Configurar e gerenciar seu sistema de compilação.

  • Criar definições de compilação. Você pode criar diversas definições de compilação e depois executar cada uma delas para produzir código para uma plataforma diferente. Além disso, você pode executar cada compilação para uma configuração diferente.

    Para obter mais informações, consulte Definir o processo de compilação.

  • Definir testes para executar automaticamente como parte da compilação. Como parte da definição de compilação, você pode definir testes para executar como parte da compilação ou para falhar caso o teste falhe.

    Para obter mais informações, consulte Usar o modelo padrão no processo de compilação.

  • Configurar testes para coletar dados de cobertura de código. Para que os dados de cobertura do código apareçam no relatório, os membros da equipe devem instrumentar testes para coletar os dados.

    Para obter mais informações, consulte Executar testes no processo de compilação.

  • Executar compilações regularmente. Você pode executar compilações em intervalos regulares ou após cada check-in. Você pode criar compilações regulares quando usa o disparador de agenda.

    Para obter mais informações, consulte Criar ou editar uma definição de compilação e Executar, monitorar e gerenciar compilações.

    Dica

    Embora um membro da equipe possa avaliar manualmente uma compilação usando o Build Explorer, essa avaliação não é refletida no relatório Indicadores de Qualidade de Compilação.A avaliação da compilação aparece no relatório Resumo da Compilação.Para obter mais informações, consulte Classificar a qualidade de uma compilação concluída e Relatório Resumo da Compilação.

Solucionar problemas de qualidade

A tabela a seguir descreve problemas de qualidade específicos que o painel qualidade pode ajudá-lo a monitorar e identificar as ações que a equipe pode executar.

Problema

Relatórios para analisar

Notas de solução de problemas

Falhas de compilação

Status de compilações

Uma compilação noturno é a pulsação de projetos de desenvolvimento de software. Quando as compilações não estão sendo concluídas com êxito ou não estão passando nos testes de verificação de compilação (BVT), a equipe deve corrigir o problema imediatamente.

Testes com falha

Progresso do Plano de Teste

Variação de Código

Quando as taxas de testes com falha e a variação de código são altas, a equipe pode investigar por que o software está falhando com freqüência. As causas podem incluir práticas de desenvolvimento flexível ou testes muito rigorosos para um ciclo de iteração iniciais.

Testa passando, mas com uma alta taxa de localização de bugs

Progresso do Plano de Teste

Andamento de Bugs

Quando vários testes passarem no mesmo período como muitos Bugs encontrados, a equipe pode investigar as seguintes possibilidades:

  • Não podem ser suficientemente rigorosos testes para o estágio atual do produto. Em primeiras iterações, são bons testes simples. No entanto, testes devem ter maior integração e cenários como o produto amadurece.

  • Testes podem estar desatualizados ou testar a funcionalidade de errado.

  • Técnicas de teste diferentes podem oferecer resultados melhores.

  • Bugs estão sendo geradas, mas não está sujeito ao teste. Quando erros são relatados e não estão vinculados a um caso de teste, eles não estão sujeitos a testes de regressão.

Os testes são obsoletos

Progresso do Plano de Teste

Cobertura de Código

Variação de Código

Quando vários testes forem bem-sucedidos, altera uma quantidade significativa de código e diminui de cobertura de código, a equipe pode não estar executando os testes que exercitem o novo código.

Como testes não são desenvolvidos com a mesma taxa como as alterações de código, cobertura de teste pode se tornar menor adequada.

Equipe não está testando, fechar ou reativar a Bugs resolvidos

Andamento de Bugs

Quando ocorre uma caixa no relatório de andamento de bugs para Bugs resolvidos, os desenvolvedores estão Resolvendo erros, mas os testadores não verificado e fechar. A equipe deve investigar por que desenvolveu esse padrão.

Testes muito pouco

Progresso do Plano de Teste

Variação de Código

Quando a equipe está executando alguns testes, variação de código é alta e cobertura de código é menor do que o esperado, a equipe talvez seja necessário alocar mais recursos para teste. Além disso, a equipe deve garantir que testadores enfoque as mesmas funções que o restante da equipe.

Reativações

Reativações de Bugs

Quando a equipe reativa Bugs em uma taxa alta ou crescente, os testadores freqüentemente estão rejeitando correções dos desenvolvedores. A equipe deve resolver esses problemas para evitar a alocação de recursos significativos para retrabalhando as correções rejeitadas. As causas em potencial incluem relatórios de bugs baixa, gerenciamento de laboratório de teste inadequado ou triagem muito agressiva.

Testes de unidade inadequada

Cobertura de Código

Variação de Código

Quando um decréscimo de cobertura de código coincide com um aumento de variação de código, os desenvolvedores podem verificando no código sem qualquer teste de unidade correspondente para abordá-lo.

Na maioria dos casos, a cobertura de código possível atingir 100% se a equipe pratica o desenvolvimento controlado por teste ou técnicas semelhantes. Se os testes de unidade são reutilizadas como BVTs, cobertura de código deve aparecer nos relatórios correspondentes.

Consulte também

Conceitos

Painéis de portal do projeto