Teste de Software - Como Entrar um bug (defeito)

Ampliar imagem

Como testes de software melhora a qualidade de software e fornece uma solução de custo eficaz, que atenda aos requisitos dos clientes, torna-se necessário fazer um defeito em um bom caminho, rastrear o defeito, e manter um registro de defeitos para referência futura, etc

Como um testador testa um aplicativo e se ele / ela descobre qualquer defeito, o ciclo de vida do defeito começa e torna-se muito importante para comunicar o defeito para os desenvolvedores para obtê-lo fixo, acompanhar o status atual do defeito, descobrir se tal defeito (defeito similar) jamais foi encontrado na últimas tentativas de testes, etc Para este efeito, os documentos criados anteriormente manuais foram usados, que foram distribuídos para todos os associados com o projeto de software (desenvolvedores e testadores). Hoje em dia, muitas ferramentas de relatórios de bugs estão disponíveis, o que ajuda no controle e gerenciamento de erros em uma maneira eficaz.

Como relatar um bug?

É uma boa prática para tirar fotos da tela de execução em cada etapa durante o teste de software. Se qualquer caso de teste falhar durante a execução, ele precisa ser falha na ferramenta de relatórios de erros e um erro tem de ser comunicada / logado para o mesmo. O testador pode escolher primeiro relatar um bug e depois não o caso de teste na ferramenta de relatório de erros ou não um caso de teste e relatar um bug. Em qualquer caso, o ID do erro que é gerada para o erro relatados devem ser ligado ao caso de teste que falhou.

No momento de relatar um bug, todos os campos obrigatórios a partir dos conteúdos de erro (como o Projeto,, Status, Descrição, Resumo, detectada por, atribuída a, data de chumbo teste detectou, detectado na versão, fechado na versão, data prevista de Encerramento, data real do Encerramento, gravidade, Prioridade e Bug ID, etc) estão cheios e descrição detalhada do erro é dado junto com os resultados esperados e reais. As telas, tomadas no momento da execução do caso de teste, estão ligados ao bug para referência pelo desenvolvedor.

Após relatar um bug, uma ID do erro original é gerado pela ferramenta de relatório de erros, o que é, então, associada ao caso de teste que falhou. Este ID bug ajuda em associar o erro com o caso de teste falhou.

Após o erro é informado, ele é atribuído o status de "novo", que vai mudando com o progresso do processo de correção de bugs.

Se mais de um testador está testando o software, existe a possibilidade de que algum outro pode testador já relataram um bug para o mesmo defeito encontrado no aplicativo. Em tal situação, torna-se muito importante para o aparelho de teste para saber se algum erro foi relatado por um tipo similar de defeito. Se sim, então o processo de ensaio tem de ser bloqueado com o erro gerado anteriormente (neste caso, o teste deve ser executado quando o erro é corrigido). E se não houver tal bug relatado anteriormente, o testador pode relatar um bug novo e deixar o caso de teste para o bug recém-criado.

Se nenhuma ferramenta de relatório de erros é usado, então, nesse caso, o teste é escrito de uma forma tabular em um arquivo com quatro colunas contendo etapa de teste nenhum resultado, Descrição teste Step, resultado esperado e real. Os resultados esperados e reais são escritos para cada etapa e do caso de teste é feito para deixar para a etapa em que o caso de teste falhar.

Este arquivo contém caso de teste e as capturas de tela tomadas são enviadas para os desenvolvedores de referência. Como o processo de controle não é automatizado, torna-se importante para manter a informação atualizada do bug que foi levantado até o momento em que é fechado.

(Observação: O procedimento acima de relatar um bug é geral e não se baseia em qualquer projeto maior parte do tempo, os procedimentos de notificação de erros, os valores utilizados para os vários campos usados ​​no momento de relatar um sistema de rastreamento de bugs e erros,. etc, podem mudar de acordo com o projeto de teste de software e necessidades da empresa.)...