Menu

Rastreamento de bug de projeto ao vivo, métricas de teste e aprovação de teste - treinamento de controle de qualidade gratuito - dia 6

live project bug tracking

Experimente Nosso Instrumento Para Eliminar Problemas

Esta é a parte final do nosso “ Treinamento de teste de software em um projeto ao vivo ' Series.

Será sobre defeitos e também alguns tópicos restantes que marcarão a conclusão da fase de Execução de Teste do STLC.

No artigo anterior , enquanto a execução do teste estava acontecendo, encontramos uma situação em que o resultado esperado do caso de teste não foi alcançado. Além disso, identificamos alguns comportamentos inesperados durante o Teste Exploratório.

Rastreamento de bug de projeto ao vivo, métricas de teste e aprovação de teste

O que acontece quando encontramos esses desvios?

Obviamente, temos que registrá-los e rastreá-los para garantir que esses desvios sejam tratados e, eventualmente, corrigidos no AUT.

# 1) Esses desvios são chamados de defeitos / bugs / questões / incidentes / erros / falhas.

#dois) Todos os casos a seguir podem ser registrados como defeitos

  • Requisitos ausentes
  • Requisitos de trabalho incorretamente
  • Requisitos extras
  • Inconsistências do documento de referência
  • Questões relacionadas ao meio ambiente
  • Sugestões de aprimoramento

# 3) O registro de defeitos é feito principalmente em planilhas do Excel ou por meio do uso de um software / ferramenta de gerenciamento de defeitos. Para obter informações sobre como lidar com defeitos por meio de ferramentas, tente usar os seguintes links:

O que você aprenderá:

Como registrar os defeitos de maneira eficaz

Vamos agora tentar ver como registrar os defeitos que encontramos no artigo anterior em uma planilha do Excel. Como sempre, é importante escolher um formato ou modelo padrão.

método java que leva um array

Normalmente, as seguintes colunas fazem parte do Relatório de Defeito:

  • ID de defeito: Para identificação única.
  • Descrição do Defeito: É como um título para descrever brevemente o problema.
  • Módulo / seção do AUT: Isso é opcional, apenas para adicionar mais clareza e indicar a área do AUT onde o problema foi encontrado.
  • Passos para reproduzir: Qual é a seqüência exata de operações a serem realizadas no AUT para recriar o bug deve ser listada aqui. Além disso, se algum dado de entrada for específico para o problema, essa informação também deve ser inserida.
  • Gravidade: Para indicar a intensidade do problema e, eventualmente, o impacto que isso pode ter no funcionamento do AUT. As diretrizes sobre como atribuir e quais valores atribuir neste campo podem ser encontradas no documento do plano de teste. Portanto, consulte o Documento do plano de teste do artigo 3 .
  • Status: Será discutido mais adiante no artigo.
  • Captura de tela: Um instantâneo do aplicativo para mostrar o erro quando ele aconteceu.

Esses são alguns dos campos 'obrigatórios'. Este modelo pode ser expandido (por exemplo, para incluir o nome do testador que relatou o problema) ou contratado ( Por exemplo, o nome do módulo removido) conforme necessário.

Seguindo as diretrizes acima e usando o modelo acima, um exemplo de log / relatório de defeitos pode ser parecido com este:

Relatório de defeito de amostra para o projeto OrangeHRM Live:

Relatório de defeito do OrangeHRM

=> Clique aqui para baixar o relatório de defeitos do projeto ao vivo

Abaixo está o relatório de defeito de amostra criado na ferramenta qTest Test Management: (Clique na imagem para ampliá-la)

Relatório de amostra de defeito

Os defeitos não são bons quando os registramos e os mantemos para nós. Teremos que atribuí-los na ordem certa para que as equipes envolvidas atuem neles. O processo - quem atribuir ou que ordem seguir também pode ser encontrado no documento do plano de teste. É principalmente semelhante a (Clique na imagem para ampliá-la)

Ciclo de defeito:

Ciclo de vida de defeito 1

A partir do processo acima, pode-se notar que os bugs passam por diferentes pessoas e diferentes decisões no processo de serem identificados para corrigidos. Para rastrear e estabelecer transparência quanto ao estado exato de um determinado bug, um campo “Status” é usado no relatório do bug. Todo o processo é conhecido como “ciclo de vida do bug”. Para obter mais informações sobre todos os status e seus significados, consulte este Tutorial de ciclo de vida do bug .

Algumas dicas durante o rastreamento de bug

  • Quando somos novos em uma equipe / projeto / AUT de criação, é sempre melhor discutir o problema que encontramos com um colega para ter certeza de que nosso entendimento do que realmente causa um defeito está correto ou não.
  • Para fornecer todas as informações isso é necessário para reproduzir o problema. Um defeito que retorna para uma equipe de teste com o status definido como “Informações insuficientes” não reflete de forma muito positiva para nós. Confira esta postagem - Como resolver todos os seus bugs sem qualquer rótulo de ‘bug inválido’ .
  • Verifique se um problema semelhante foi levantado antes de criar um novo. Problemas de ‘duplicar’ também são más notícias para a equipe de controle de qualidade.
  • Se houver um problema, ele aparecerá aleatoriamente e não sabemos as etapas / situações exatas em que podemos recriar o problema - levante o problema da mesma forma. Correndo o risco de o problema ser definido como “IrReproduzível / informação insuficiente” - ainda temos que nos certificar de que tratamos de todas as avarias possíveis da melhor maneira possível.
  • A prática geral é que a equipe de QA cria os defeitos de cada um em uma planilha do Excel durante um dia e a consolida no final do dia.

O ciclo de vida completo do defeito

Para o nosso projeto ativo, se seguíssemos o ciclo de vida do defeito para o defeito 1,

como abrir um arquivo eps
  • Quando eu (o testador) o crio, seu status é 'Novo”. Quando eu o atribuo ao líder da equipe de QA, o status ainda é 'Novo', mas o proprietário agora é o líder de QA.
  • O líder de QA analisará o problema e, ao determinar se é um problema válido, o problema é atribuído ao líder de Dev. Nesta fase, o status é 'Atribuído' e o proprietário é o líder de desenvolvimento.
  • O líder de desenvolvimento atribuirá esse problema a um desenvolvedor que trabalhará para corrigi-lo. O status agora será 'Trabalho em progresso' (ou algo semelhante a esse efeito), o proprietário é o desenvolvedor.
  • Para o defeito 1, o desenvolvedor não é capaz de reproduzir o erro, então ele o atribui de volta à equipe de QA e define o status como 'Incapaz de reproduzir”.
  • Como alternativa, se o desenvolvedor pudesse trabalhar nisso e corrigir um problema, o status seria definido como 'resolvido' e o problema seria atribuído de volta à equipe de QA.
  • A equipe de QA irá então pegá-lo, testar novamente o problema e, se for corrigido, definirá o status para 'Fechadas' . Se o problema persistir, o status será definido como 'Reabrir' e o processo continua.
  • Dependendo das outras situações, o status pode ser definido como 'Diferido' , 'Não é informação suficiente', 'Duplicado' , 'trabalhando como pretendido' , etc. pelo desenvolvedor.
  • Este método de registrar os defeitos, relatar e atribuí-los, gerenciá-los é uma das principais atividades realizadas pelos membros da equipe de QA durante a fase de execução do teste. Isso é feito diariamente até que um determinado ciclo de teste seja concluído.
  • Assim que o Ciclo 1 terminar, a equipe de desenvolvimento levará um ou dois dias para consolidar todas as correções e reconstruir o código na próxima versão que será usada no próximo ciclo.
  • O mesmo processo continua novamente para o ciclo 2 também. No final do ciclo, existe uma chance de que ainda possa haver alguns problemas “Abertos” ou não corrigidos no aplicativo.
  • Nesta fase, ainda continuamos com o Ciclo 3? Se sim, quando vamos parar de testar?

Critérios de saída para o teste de projeto ao vivo OrangeHRM

É aqui que empregamos o que chamaríamos de “Critérios de Saída”. Isso é predefinido no documento Plano de Teste. É simplesmente na forma de lista de verificação que determinará se concluímos o teste após o ciclo 2 ou partimos para mais um ciclo. Parece o seguinte, quando preenchido levando em consideração algumas respostas hipotéticas às seguintes questões relativas ao projeto OrangeHRM:

Critérios de saída de teste

Quando olhamos com atenção para a lista de verificação acima, há métricas e aprovação mencionadas lá que não discutimos antes. Vamos falar sobre eles agora.

Test Metrics

Estabelecemos que, durante a fase de execução do teste, os relatórios são enviados a todos os outros membros da equipe do projeto para dar uma ideia clara sobre o que está acontecendo na fase de execução de QA . Essas informações são importantes para todos, a fim de obter validação sobre a qualidade geral do produto final.

Imagine que eu relato que 10 casos de teste foram aprovados ou 100 casos de teste foram executados - esses números são apenas dados brutos e não fornecem uma perspectiva muito boa sobre como as coisas estão acontecendo.

As métricas desempenham um papel vital no preenchimento dessa lacuna. As métricas estão em palavras simples, números inteligentes que a equipe de teste coleta e mantém . Por exemplo, se eu disser que 90% dos casos de teste foram aprovados, faz mais sentido do que dizer que 150 casos de teste foram aprovados. Não é?

Existem diferentes tipos de métricas coletadas durante a fase de execução do teste. Quais métricas exatamente devem ser coletadas e mantidas por quais períodos de tempo - essas informações podem ser encontradas no documento do plano de teste.

A seguir estão as métricas de teste mais comumente coletadas para a maioria dos projetos:

  • Porcentagem de aprovação dos casos de teste
  • Densidade de defeitos
  • Porcentagem de defeitos críticos
  • Defeitos, número de severidade inteligente

Confira o Relatório de status anexado a este artigo para ver como essas métricas são usadas.

Relatório de aprovação / conclusão do teste

Como temos que notificar todas as partes interessadas que o teste começou, também é dever da equipe de QA avisar a todos que o teste foi concluído e compartilhar os resultados. Portanto, normalmente um e-mail é enviado da equipe de QA (geralmente o Líder de Equipe / Gerente de QA) dando uma indicação de que a equipe de QA aprovou o produto anexando os resultados do teste e a lista de problemas abertos / conhecidos.

Amostra de e-mail de aprovação de teste:

Para: Cliente, PM, equipe de desenvolvimento, equipe de banco de dados, BA, equipe de QA, equipe de ambiente (e qualquer outra pessoa que precise ser incluída)
O email: Olá, equipe,

A equipe de QA assina o software OrangeHRM versão 3.0 após a conclusão bem-sucedida dos 2 ciclos de teste funcional do site.

Os casos de teste e seus resultados de execução são anexados ao e-mail. (Ou mencione o local onde eles estão presentes. Ou, se estiver usando um software de gerenciamento de teste, forneça detalhes sobre o mesmo.)

A lista de problemas conhecidos também está anexada ao e-mail. (Novamente, quaisquer outras referências que façam sentido podem ser adicionadas.)

Obrigado,
Líder da equipe de controle de qualidade.

Anexos: Relatório de execução final, relatório final de problema / defeito, lista de problemas conhecidos

Assim que o e-mail de finalização do teste for enviado pela equipe de QA, o processo de STLC será oficialmente concluído. Isso não marca necessariamente a conclusão da fase de “Teste” do SDLC. Ainda temos o teste do UAT para terminar para que isso aconteça. Achar mais detalhes sobre o teste UAT aqui .

Após a conclusão do UAT, o SDLC passa para a fase de implantação, onde entra em operação e fica disponível para ser consumido por seus clientes / usuários finais.

É isso!

Este tem sido o nosso esforço para levar a experiência mais viva do Projeto QA aos nossos leitores. Deixe-nos saber seus comentários e perguntas sobre esta série de treinamento de QA de teste de software online gratuito.

Leitura recomendada

^