Ciclo de vida do defeito - Como você já deve saber, a execução do teste é a fase em que o testador realmente executaria os scripts de teste. O processo de execução dos scripts de teste varia de empresa para empresa e pode ser diferente em diferentes projetos dentro da mesma empresa.
Atualmente, existem ferramentas disponíveis para execução de testes, ferramentas como - Quality Center, Microsoft visual studio e assim por diante. O processo real de execução de cada etapa para comparar o resultado real e o esperado permanece o mesmo para o testador funcional, independentemente das ferramentas utilizadas.
- E se o comportamento real não for igual ao comportamento esperado?
Quando um testador descobre que o resultado real do teste não é igual ao resultado esperado, um defeito é registrado.
- Como registrar um defeito?
Atualmente, existem muitas ferramentas disponíveis, algumas das ferramentas de registro de defeitos são o ClearQuest da IBM, o Quality Center da HP, ferramentas de código aberto como o ciclo de vida de defeitos no JIRA e assim por diante.
Existem alguns dos campos obrigatórios comuns nas várias ferramentas de registro de defeitos. Esses campos são:
- Ciclo de vida do defeito Descrição
- Resumo do ciclo de vida de defeitos
- Defeito registrado por
- Defeito atribuído a
- Severidade do Defeito
- Prioridade de Defeitos
- Instantâneos adicionais
- Número da liberação / Nome
Ciclo de vida do defeito
Defeito O ciclo de vida começa com o registro de um novo defeito. Sempre que um defeito é registrado, ele entra no estado "Novo".
Testador - Novo Defeito
A quem atribuir um novo defeito?
Um testador pode atribuir um defeito a um desenvolvedor ou a um líder de desenvolvimento. Essa decisão de atribuição de defeitos varia de projeto para projeto. Em alguns locais de trabalho, existe um processo de ciclo de vida de defeitos para atribuí-lo diretamente a um desenvolvedor respectivo e, em alguns locais, o defeito é atribuído primeiro a um lead dev e o lead dev, por sua vez, o atribui a um desenvolvedor.
Atribuição de Defeitos (Novo) - Desenvolvedor de Ciclo de Vida de Defeitos
Designação de Defeitos (Novo) - Dev Leadà Developer
Análise de Defeitos
O desenvolvedor analisará o defeito para verificar se é reproduzível. Aqui, a contribuição mais importante do testador é incluir todos os detalhes necessários no defeito. Resumo do defeito, descrição detalhada do defeito são os campos que ajudam as partes interessadas a entender o defeito de uma só vez. O resumo do defeito deve sempre ter apenas as informações de alto nível do defeito. Ao mesmo tempo, ele deve ter informações suficientes para descrever a visão geral do defeito em uma linha.
A descrição do defeito é o local em que o testador deve incluir todas as informações necessárias, como Ambiente, Cenário, Dados de teste usados, Resultado Esperado, Resultado Real, Referência a arquivos / dados e referência ao instantâneo.
Aqui está uma breve visão geral de vários elementos da Descrição detalhada de defeitos -
Meio Ambiente
Ambiente de teste em que o defeito foi encontrado. Geralmente, os projetos têm vários ambientes de teste nos quais a equipe de teste realiza o teste. Por exemplo - AT (ambiente de teste de montagem), PT (ambiente de teste de produto), UAT (ambiente de teste de aceitação do usuário) e assim por diante. O objetivo de ter vários ambientes é fornecer flexibilidade dentro da equipe de desenvolvimento e teste para que o código seja implantado em qualquer ambiente disponível para iniciar o teste no prazo.
Há momentos em que o teste do produto (também chamado de teste do sistema) e o teste UAT se sobrepõem; portanto, é necessário ter vários ambientes para continuar testando em paralelo.
Há casos em que a equipe de desenvolvimento precisa de um ambiente adicional para depurar os problemas relatados pela equipe de teste. Além disso, a equipe de desenvolvimento possui um ambiente dedicado para tarefas de teste de unidade.
Portanto, com vários ambientes, é necessário mencionar no defeito um ambiente específico em que o problema foi encontrado.
Cenário
Cenário é o conjunto de etapas executadas pelo testador que levou a um defeito. Aqui, um testador deve mencionar todas as etapas que o desenvolvedor pode executar para reproduzir o defeito. Geralmente, há momentos em que o defeito é relatado pelo testador, mas o desenvolvedor não é capaz de replicar o mesmo e, portanto, o defeito é rejeitado. Isso pode ocorrer devido a etapas incorretas / etapas ausentes mencionadas na descrição. Etapas claras ajudam todos a entender o defeito e replicá-lo sem ter a dependência de procurar um testador para obter insumos. Um cenário bem documentado possui etapas fáceis de ler, entender e precisas a serem seguidas para replicar o defeito.
Dados de teste
Um testador deve mencionar os dados usados durante o fluxo de teste que levaram a um problema. Essas informações oferecem ao desenvolvedor a chance de usar dados semelhantes para reproduzir o defeito e encontrar a causa raiz do mesmo.
Existem alguns cenários em que um testador encontra um defeito usando dados específicos, mas o mesmo problema não é reproduzível usando dados semelhantes. Isso pode acontecer devido à corrupção de dados, portanto, a inserção de dados oferece a chance de descobrir a causa raiz do defeito. Um desenvolvedor pode não descer para o nível do código se for o caso de corrupção de dados. Esse tipo de defeito pode ser convertido em defeito de dados.
Resultado esperado e real
Este é o destaque do campo de descrição detalhada, em que um testador prova que o erro encontrado é realmente um defeito. A menção clara do resultado esperado deixa claro para todos os interessados que consideram o erro como um defeito. Imagine que um defeito seja registrado com todos os detalhes, mas não especifica o resultado esperado do cenário!
Normalmente, um testador insere apenas o resultado esperado pode estar em uma linha ou duas, no entanto, é muito importante mencionar a fonte do resultado esperado. Fonte aqui referência ao documento onde o resultado esperado é mencionado. Pode ser um documento de requisito ou uma referência de storyboard.
Referência a arquivos / dados
Às vezes, o defeito envolve a geração de arquivo ou entrada como um arquivo. Nesse tipo de cenário, o testador deve fornecer informações do arquivo que foi usado e que causou o problema no aplicativo. Esses arquivos podem ser anexados usando a ferramenta de gerenciamento de defeitos ou a referência para o mesmo pode ser fornecida. Esses locais de referência devem ser acessíveis por todas as partes interessadas.
Referência ao instantâneo
Os instantâneos desempenham um papel muito importante quando você deseja mostrar a mensagem exata de erro de quebra de página, conforme exibido na tela ou quando deseja mostrar os detalhes de navegação na tela. O instantâneo fornece uma rápida idéia sobre o defeito encontrado, a tela na qual o defeito foi encontrado, os dados usados na tela e assim por diante. Todas as ferramentas de gerenciamento de defeitos têm provisão para anexar os instantâneos. Às vezes, o testador também pode anexar planilhas do Excel ou documentos do Word.
Esses foram os vários componentes do registro de defeitos e as práticas recomendadas para cada um deles. Voltando ao ciclo de vida do defeito, uma vez que o defeito é atribuído a um desenvolvedor, ele o analisará usando os dados fornecidos no item de defeito. Se, de acordo com a análise, o problema registrado for realmente um defeito, o desenvolvedor "abrirá" o defeito para trabalhar em sua correção.
Cursos recomendados
- Serviços da Web no pacote de treinamento Java
- Treinamento sobre desenvolvimento de jogos em C ++
- Treinamento completo sobre hackers éticos
- Vegas Pro 13 Cursos de Formação
Novo - Aberto
Um defeito no status Aberto mostra que ele está na placa de desenvolvimento e os desenvolvedores estão trabalhando em sua correção. Caso a análise descubra que o problema registrado não é um defeito, isso pode ocorrer quando houver uma lacuna no entendimento do comportamento esperado do sistema. Se a análise indicar que o defeito é inválido, o desenvolvedor rejeitará o defeito. A terminologia é "Rejeitada" ou "Retornar ao teste".
Novo - Retorne ao teste.
Como o testador deve validar se o defeito foi realmente um defeito inválido?
Este é o cenário em que um documento de requisitos preciso ajuda todos na equipe a chegarem à conclusão se o defeito registrado for inválido ou válido. A referência aos documentos de requisitos ajuda o testador e o desenvolvedor a chegar à mesma conclusão e realmente facilita o processo de discussão.
Existem cenários em que a exatidão dos documentos de design e requisitos é questionada enquanto os documentos são consultados em momentos de discussões de defeitos; nesses momentos, o retorno ao Business Analyst é considerado a melhor opção para esclarecer as consultas.
Como prática recomendada, os documentos de requisitos e design devem estar sempre atualizados para encaminhá-los sem ambiguidades.
No status “Aberto”, a equipe de desenvolvimento trabalha na correção do defeito, uma vez corrigido, o status muda para “Pronto para implantação”.
Aberto - Pronto para implantação
Implantação é o processo no qual as alterações são carregadas no servidor para que a equipe de teste possa trabalhar na versão fixa do código. Normalmente, cada projeto possui uma equipe de implantação separada para esta tarefa.
Portanto, em alto nível, uma equipe de software consiste principalmente desses 3 grupos -
- Desenvolvimento
- Ciclo de vida de defeitos em testes
- Implantação (ou algumas vezes chamada como equipe de criação)
Depois que a compilação é implantada e o defeito está novamente disponível para novo teste, ele é designado a um testador apropriado para a tarefa de novo teste.
Defeito atribuído a - condutor de teste.
Test Lead - Testador Individual.
Defeito atribuído - testador individual.
Em alguns locais de trabalho, o defeito é atribuído primeiro ao líder de teste e, por sua vez, o atribui ao testador individual; no entanto, em alguns locais, o defeito é atribuído diretamente ao testador que o testaria ou àquele que causou o defeito.
O status aqui muda de Pronto para implantação - Teste SIT pronto.
Agora o defeito está no prato do testador. A equipe de teste validará o defeito e há duas possibilidades: a correção funcionaria corretamente ou o mesmo problema será encontrado novamente. Dependendo do resultado, o defeito pode passar para os seguintes status -
Teste SIT Pronto - Fechado
Teste SIT pronto - Reabrir
Nos dois cenários acima, o testador é necessário para adicionar os comentários dos testes realizados. Isso inclui mencionar os cenários testados e os dados usados. Se o defeito for reaberto, o testador deve fornecer as etapas exatas executadas que novamente levaram ao erro.
O status de reabertura é igual ao status de defeito "Novo".
Depois que o defeito for reaberto, ele seguirá o mesmo ciclo novamente.
Desafios do ciclo de vida dos defeitos
- Decidir sobre a gravidade dos defeitos - este é um dos tópicos comuns de discussão (geralmente brigas) entre testadores e desenvolvedores.
- O defeito não é reproduzível no sistema do desenvolvedor.
- Defeito levantado no cenário que não é mencionado nos requisitos e nos documentos de design.
- O defeito é encontrado, mas o mesmo não pode ser levantado, pois a ocorrência do cenário no ambiente de produção não é viável.
Como um testador deve superar os desafios acima?
- A gravidade é diretamente proporcional ao impacto que o defeito está causando no aplicativo; se o testador não puder prosseguir devido ao defeito, ele certamente será marcado com a gravidade mais alta.
- Se existir uma solução alternativa para continuar o teste, ela deverá ser marcada como gravidade média. Além de considerar o impacto de mais testes de ciclo de vida de defeitos, a gravidade também pode ser decidida considerando a situação em que um módulo inteiro está falhando, nesse caso, mesmo que o teste de outro módulo possa ser realizado, mas a gravidade do módulo atual seja alta. portanto, o defeito deve ser marcado com a maior gravidade.
- Se um defeito não for reproduzível no sistema do desenvolvedor, há chances de o ambiente de desenvolvimento e teste não estar sincronizado. Um defeito reproduzível no sistema de teste é sempre considerado como um defeito válido.
- Existem situações em que um defeito é registrado considerando o cenário geral de negócios, mas o cenário direto não é mencionado nos requisitos ou no documento de design. Sempre é uma prática recomendada considerar os cenários de negócios reais, em vez de apenas seguir as etapas do teste. A comunicação com analistas de negócios e outras partes interessadas do produto desempenha um papel importante para registrar esses defeitos.
- Existem cenários em que um testador descobre uma lacuna na lógica de negócios durante a fase de teste. Encontrar essas lacunas é novamente considerado uma grande vantagem para um testador. As falhas de design geralmente são tratadas por meio de aprimoramentos.
- Aprimoramento - Se um comportamento precisar ser alterado durante a fase de teste do ciclo de vida do software, é criado um aprimoramento que pode ser obtido no release atual ou no próximo, considerando os cronogramas e a largura de banda das equipes de desenvolvimento e teste.
- Existem alguns cenários que um testador pode testar durante testes ad-hoc que podem ser de fato inválidos, considerando a possibilidade de sua ocorrência na produção.
Quem é o melhor amigo do testador?
Para onde um testador deve ir em caso de ambiguidade? A resposta depende do tipo de consulta. Se uma consulta estiver relacionada a requisitos, é aconselhável discutir primeiro dentro da equipe para corrigir o entendimento do sistema, consultando membros seniores. O próximo ponto de contato deve ser analistas de negócios.
Se a consulta estiver relacionada ao processo de teste, é recomendável entrar em contato com o líder ou gerente de teste.
Se a consulta estiver relacionada à compreensão dos aspectos técnicos do aplicativo, o membro da equipe de desenvolvimento pode ser a pessoa certa a quem procurar.
Como o teste é um processo que requer uma compreensão geral do sistema, a comunicação ajuda o testador a obter respostas rápidas às perguntas, depende apenas de fazer as perguntas certas para as pessoas certas. Evitar fazer perguntas no momento certo pode levar a um defeito no vazamento para o ambiente de produção.
Qual a importância do papel de um testador na empresa hoje?
Existem projetos em que a equipe de teste é igualmente importante como a equipe de desenvolvimento e, em alguns cenários, há mais dependência da equipe de teste do que da equipe de desenvolvimento. O cenário posterior é raro, mas existe em alguns locais de trabalho. Isso aconteceu ao longo do tempo e pode ser por algum período específico em que a equipe de desenvolvimento não tem muita experiência em comparação com a equipe de teste. Existem pessoas que entendem melhor o fluxo e a funcionalidade geral do que a maioria dos outros membros da equipe. Esse indivíduo pode fazer parte da equipe de teste / desenvolvimento. Esse é um dos fatores que decide a dependência de uma equipe / indivíduo para o projeto específico.
Qual é o plano de carreira de um testador?
Um indivíduo pode levar algum tempo para entender o processo geral de teste, o domínio e outras tarefas nas quais se espera que ele trabalhe no dia-a-dia. Com base nesse entendimento, é aconselhável tomar uma decisão para explorar outras áreas que um testador possa ocupar. Sempre existem oportunidades no processo de automatizar vários fluxos. Criar pequenos utilitários também pode ajudar a equipe em grande estilo. Se um testador é bom em programação, ele é considerado uma grande vantagem. Isso abre oportunidades para funções de automação. O teste de desempenho também é uma das trilhas da carreira dos testadores. Analista de negócios é outra opção. Bons conhecimentos de domínio, com boas habilidades de comunicação, são os conjuntos de habilidades necessárias para ser um analista de negócios. O teste abre muitas oportunidades para os testadores trabalharem em vários domínios, ferramentas, processos e assim por diante. Depende apenas de um indivíduo para captar e começar a se aprofundar em uma das principais áreas de teste. Existem muitas certificações específicas para várias ferramentas para se especializar em uma das áreas de teste. Ter a certificação do fornecedor padrão é uma vantagem para impulsionar a carreira, mas o certificado por si só não pode ajudá-lo a longo prazo se não for combinado com a experiência de trabalho correta.
Artigos recomendados
Aqui estão alguns artigos que ajudarão você a obter mais detalhes sobre o Teste de Software. Basta acessar o link.
- 6 perguntas mais surpreendentes da entrevista sobre testes de software
- Carreiras em Teste de Software
- Como obter um melhor crescimento na carreira no trabalho do Software Tester