Acompanhar bugs

Conforme você realiza testes para verificar seus requisitos, é obrigado a encontrar bugs. Use o item de trabalho do bug para descrever e rastrear o progresso de cada bug que encontra.

Para obter mais informações sobre como criar itens de trabalho de bug, consulte Executando testes manuais usando o Team Web Access. Conforme os bugs são encontrados, siga o processo neste tópico para fornecer a prioridade, verificar se eles foram corrigidos e certificar-se de que você tem um registro de trabalho e as decisões que foram envolvidas.

Triagem de bugs

As reuniões de triagem devem ser realizadas em intervalos definidos após o trabalho de desenvolvimento e depois que o teste foi iniciado no projeto. A frequência com a qual você realiza as reuniões e o tempo de duração das mesmas dependem da sua situação.

Normalmente, as reuniões de triagem de bugs são realizadas por um gerenciador de projetos e assistidas pelos líderes da equipe e, talvez, analistas comerciais e participantes que podem falar sobre os riscos de projeto específicos. O gerenciador de projetos pode usar a consulta Bugs Ativos para ver bugs novos e reabertos, de modo a gerar uma lista de bugs que passarão pela triagem.

Antes do início da triagem, elabore um conjunto de critérios para determinar os bugs que devem ser corrigidos e em qual prioridade. Os critérios normalmente identificarão a gravidade de bugs, bugs que são associados a recursos de valor significativo (ou custo de oportunidade de atraso significativo) ou outro riscos do projeto.

Os critérios de triagem devem ser armazenados na pasta Documentos do seu projeto de equipe. Ao longo do tempo, o documento será atualizado. Assume-se que o projeto tem o controle de versão ativado e que os critérios específicos que estão sendo usados em um determinado momento no projeto podem ser recuperados para fins de evidência de auditoria e de avaliação.

No início do projeto, você decidirá provavelmente corrigir a maioria dos erros que foram triados. No entanto, à medida que o projeto continua, os critérios de triagem (ou barra) podem ser gerados para reduzir o número de erros que são corrigidos.

Gerar a barra de critérios de triagem e permitir que os bugs relatados permaneçam sem correção é um conflito. É uma decisão que diz que corrigir o erro é menos importante que atender o escopo, o orçamento, e a agenda do projeto.

Use seus critérios para determinar quais bugs devem ser corrigidos e como definir o Estado, a Prioridade, Gravidade e outros campos. Por padrão, o modelo fornece quatro prioridades: 1 para "deve ser corrigido", até 4 para "sem importância". Se você alterar as definições no modelo de processo, você deverá atualizar a orientação, o texto de ajuda, e todos os critérios de documento corretamente.

Correção de erro

Depois que um bug é passado para triagem e fornecida sua prioridade, ele deve ser atribuído a um desenvolvedor para maiores investigações.

O item de trabalho com bug tem uma guia para as etapas de reprodução, que deve fornecer o que você precisa para reproduzir o bug. No entanto, você também pode ser capaz de usar o IntelliTrace lhe ajudar a reproduzir erros difíceis. Para obter mais informações sobre o IntelliTrace, consulte Acompanhando a qualidade do software.

Depois que o desenvolvedor decide por um plano de ação, ele deve observar suas decisões no item de trabalho de bug.

Decida sobre a correção

Trabalhando com outros membros da equipe, o desenvolvedor pode recomendar uma correção com implicações para outras seções do código e que possa exigir testes de regressão significativos. Todas as conversas que se relacionarem a avaliação de risco, como uma correção, devem ser registradas no histórico de item de trabalho de bug porque documenta a evidência de gerenciamento dos riscos e a análise útil da decisão para uma auditoria ou avaliação do Standard CMMI Appraisal Method for Process Improvement (SCAMPI). Para obter mais informações sobre CMMI, consulte Plano de fundo para CMMI.

Atualizar e executar testes de unidade para correção do bug

Os testes de unidade verificam a implementação correta de uma unidade de código. Escrever e executar testes de unidade identifica erros antes do início dos testes e, portanto, ajuda a reduzir o custo do controle de qualidade. Os desenvolvedores devem escrever testes de unidade para qualquer código que será escrito como parte da implementação de uma tarefa de desenvolvimento ou da implementação de uma correção para o erro. Para obter mais informações, consulte Teste de unidade de código.

Você pode preferir escrever o teste de unidade antes de fazer qualquer correção de código em uma estratégia de desenvolvimento de primeiro teste. Esse tipo de estratégia é preferido por desenvolvedores de software ágeis. A CMMI não exige que os testes de unidade sejam gravados em uma sequência específica, somente que essa verificação efetiva de funcionalidade seja obtida.

As evidências que os testes de unidade foram escritos e executados são necessárias para uma avaliação CMMI. Certifique-se de vincular os testes aos itens de trabalho de tarefas para correção de código e vincular essas tarefas ao item de trabalho de bug. Isso fornece a rastreabilidade da evidência que um avaliador líder de SCAMPI buscará.

Revisar e refatorar o código para corrigir o bug

Uma revisão de código é usada para garantir que o código novo ou alterado localize uma barra de qualidade estabelecida antes que o código seja integrado à compilação diária. As considerações de qualidade são padrões de codificação, compatibilidade com a arquitetura e o design, desempenho, legibilidade e segurança. As revisões de código também fornecem percepções adicionais de outros desenvolvedores sobre como o código deve ser gravado. Para obter mais informações sobre como revisar e refatorar o código, consulte Implementar tarefas de desenvolvimento.

Fechar bugs

Depois que um bug é corrigido, deve ser atribuído a um testador para verificar se o problema foi resolvido antes do item de trabalho de bug ser fechado.

Verificando uma correção

Para verificar uma correção, o testador deve tentar reproduzir o bug, procurar o comportamento inesperado adicional e, se necessário, reativar o bug.

Ao verificar uma resolução de bug, você pode descobrir que o bug não foi corrigido completamente ou discordar da resolução. Nesse caso, você discute o erro com a pessoa que o solucionou, chega a um acordo, e reativa possivelmente o erro. Se você reativar um erro, certifique-se de incluir as razões para reativar o erro na descrição do erro de modo que a informação seja preservada.

Fechando o item de trabalho de bug

Um bug é fechado por muitas razões. Em casos simples, o erro é marcado como corrigido e também pode ser fechado. No entanto, um erro pode ser adiado para a próxima versão do produto, ser provado não ser reprodutível, ou ser confirmado como uma cópia. Cada um desses motivos deve ser documentado, e o erro deve ser fechado corretamente para garantir que não haja nenhuma confusão sobre o motivo de estar fechado.