Menu

Este cenário explica como é importante documentar os erros frequentemente encontrados

this scenario explains how important it is document frequently encountered errors

Experimente Nosso Instrumento Para Eliminar Problemas

Você acredita que os erros de software ocorrem apenas uma vez e que, ao serem corrigidos, nunca mais reaparecem? Eu sinto que cerca de 30% dos erros ocorrem novamente.

Neste artigo, quero abordar como é importante documentar alguns dos erros encontrados com frequência.

Abaixo, você encontrará alguns áreas comuns onde os problemas são vistos e um modelo para documentá-los.

Espero que seja útil!

Documentando os erros freqüentemente encontrados

imagem fonte

Cenário 1

O código está implantado e pronto para QA. John, o testador está pronto com seus casos de teste. No meio do teste, ele se depara com um problema. Ele sente que foi notado várias vezes antes, mas John não sabia como resolver isso.

Documentando erros 1

Documentando erros 2

Tanto John quanto Sheryl foram procurar Smith, que havia visto o mesmo erro antes e o havia resolvido antes. Infelizmente, Smith estava de licença naquele dia.

O que John deve fazer agora? John deve tentar entrar em contato com Smith para encontrar uma solução, mesmo quando Smith não está disponível?

Portanto, se um problema ambiental for visto repetidamente em várias versões, é uma boa ideia documentar os detalhes e coloque-o em um local compartilhado. Isso eliminará a dependência de qualquer indivíduo e ajudará todos os membros da equipe a encontrarem uma solução por conta própria quando isso acontecer.

Cenário # 2

John está testando uma nova versão e se deparou com um erro conhecido novamente. Desta vez, ele sabe que foi criado um defeito para ele em uma das versões anteriores. Mas a questão é: “como faço para encontrar o número do defeito e outros detalhes associados?”

Nesse caso também, o que você acha que ajudaria John?

Essas são possibilidades.

Mas, na minha opinião, se tais questões forem bem documentadas em uma área separada e compartilhadas com a equipe, isso agrega valor e economiza tempo.

O que você aprenderá:

Algumas das áreas com erros frequentes:

1) Arquivo de parâmetro - Com base em minha experiência com a ferramenta Informatica, em muitos casos, notei o arquivo param apontando para uma conexão de banco de dados incorreta. Isso resultou nos mesmos problemas várias vezes. O principal motivo foi que a conexão foi compartilhada entre dev e QA. Assim, o arquivo param sempre teve que ser atualizado conforme as necessidades para evitar o erro.

2) URL apontando para banco de dados incorreto

3) Problemas de acesso - Os usuários enfrentam problemas quando têm permissões de acesso insuficientes ou incorretas ao banco de dados ou, neste caso, um documento descrevendo as etapas a serem executadas ou pessoa / pessoas a serem contatadas seria muito útil.

4) Problema de dados de teste - Usar formato ou valores incorretos de dados geralmente resultará em problemas.

5) Problemas de banco de dados - O tempo limite de conexão do banco de dados é um problema comum. Parte do tempo de inatividade é temporário, planejado e, às vezes, podemos precisar da ajuda do DBA. Os usuários são notificados com antecedência sobre a manutenção planejada, mas para erros temporários e resolução, os testadores definitivamente precisam

A maioria dos erros repetidos são geralmente problemas ambientais .

Contudo, problemas de código não pode ser ignorado. A discussão acima é genérica e não inclui problemas de código porque os problemas de código são mais específicos para seu aplicativo, estrutura, linguagem de programação, etc.

código de classificação de inserção c ++

Uma pequena área de defeitos também pode ser entrada de dados ou erro de uso humano s .

DownloadModelos para rastrear erros frequentemente encontrados

Formato Word

=> Baixar modelo de rastreamento de erros (mundo)

Formato Excel

=> Baixe o modelo de rastreamento de erros (Excel)

Benefícios da documentação de erros frequentemente encontrados

1) Elimina a dependência - No Cenário 1, John era dependente de Smith para resolução. Se houvesse um documento para referência de John, não seria o caso.

2) Resposta mais rápida - Considere o cenário 2. Um testador não teria que passar por toda a lista de defeitos já registrados se houvesse um documento dedicado para problemas de alta frequência.

3) Ajuda os novos membros da equipe a serem autossuficientes

4) Auxilia na resolução de erros humanos

Conclusão

Eu diria que é definitivamente benéfico documentar os problemas mais frequentes, pois seria uma referência maravilhosa e um valor agregado.

Pode ser entediante documentar enquanto a execução do teste está em andamento, mas como prática recomendada, podem ser feitas notas grosseiras durante a execução, que podem ser posteriormente resumidas e atualizadas em documentos compartilhados.

Leitura recomendada

^