STLC - Execução de Teste
A execução do teste é o processo de executar o código e comparar os resultados esperados e reais. Os seguintes fatores precisam ser considerados para um processo de execução de teste -
- Com base em um risco, selecione um subconjunto do conjunto de testes a ser executado neste ciclo.
- Atribua os casos de teste em cada suíte de teste aos testadores para execução.
- Execute testes, relate bugs e capture o status do teste continuamente.
- Resolva os problemas de bloqueio à medida que surgem.
- Relate o status, ajuste as atribuições e reconsidere planos e prioridades diariamente.
- Relate as descobertas e o status do ciclo de teste.
Os pontos a seguir precisam ser considerados para a execução do teste.
Nesta fase, a equipe de QA realiza a validação real do AUT com base nos casos de teste preparados e compara o resultado passo a passo com o resultado esperado.
O critério de entrada nesta fase é a conclusão do Plano de Teste e a fase de Desenvolvimento de Casos de Teste, os dados de teste também devem estar prontos.
A validação da configuração do Ambiente de Teste é sempre recomendada por meio de testes de fumaça antes de entrar oficialmente na execução do teste.
O critério de saída requer a validação bem-sucedida de todos os casos de teste; Os defeitos devem ser fechados ou diferidos; a execução do caso de teste e o relatório de resumo de defeitos devem estar prontos.
Atividades para execução de teste
O objetivo desta fase é a validação em tempo real do AUT antes de passar para a produção / lançamento. Para encerrar essa fase, a equipe de QA realiza diferentes tipos de testes para garantir a qualidade do produto. Junto com esse defeito, relatar e retestar também é uma atividade crucial nesta fase. A seguir estão as atividades importantes desta fase -
Teste de integração do sistema
A validação real do produto / AUT começa aqui. O Teste de Integração de Sistema (SIT) é uma técnica de teste de caixa preta que avalia a conformidade do sistema em relação aos requisitos especificados / casos de teste preparados.
O Teste de Integração do Sistema geralmente é executado no subconjunto do sistema. O SIT pode ser executado com o uso mínimo de ferramentas de teste, verificado para as interações trocadas e o comportamento de cada campo de dados dentro da camada individual também é investigado. Após a integração, existem três estados principais de fluxo de dados -
- Estado dos dados dentro da camada de integração
- Estado dos dados dentro da camada do banco de dados
- Estado dos dados na camada de aplicativo
Note- Nos testes SIT, a equipe de QA tenta encontrar o máximo de defeitos possível para garantir a qualidade. O objetivo principal aqui é encontrar o maior número de bugs possível.
Relatório de Defeito
Um bug de software surge quando o resultado esperado não corresponde ao resultado real. Pode ser um erro, falha, falha ou falha em um programa de computador. A maioria dos bugs surge de erros e erros cometidos por desenvolvedores ou arquitetos.
Ao realizar o teste SIT, a equipe de QA encontra esses tipos de defeitos e eles precisam ser relatados aos membros da equipe em questão. Os membros realizam ações adicionais e corrigem os defeitos. Outra vantagem dos relatórios é que facilita o rastreamento do status dos defeitos. Existem muitas ferramentas populares como ALM, QC, JIRA, Version One, Bugzilla que oferecem suporte a relatórios e rastreamento de defeitos.
Relatório de defeitos é um processo de localização de defeitos no aplicativo ou produto em teste, testando ou registrando feedback dos clientes e criando novas versões do produto que corrigem os defeitos com base no feedback do cliente.
O rastreamento de defeitos também é um processo importante na engenharia de software, visto que sistemas complexos e críticos para os negócios têm centenas de defeitos. Um dos fatores mais desafiadores é gerenciar, avaliar e priorizar esses defeitos. O número de defeitos é multiplicado ao longo de um período de tempo e para gerenciá-los de forma eficaz, o sistema de rastreamento de defeitos é usado para tornar o trabalho mais fácil.
Mapeamento de Defeito
Depois que o defeito é relatado e registrado, ele deve ser mapeado com os casos de teste com falha / bloqueio em questão e os requisitos correspondentes na Matriz de Rastreabilidade de Requisitos. Esse mapeamento é feito pelo Defect Reporter. Isso ajuda a fazer um relatório de defeito adequado e analisar a travessura no produto. Depois que os casos de teste e os requisitos são mapeados com o defeito, as partes interessadas podem analisar e tomar uma decisão sobre se devem corrigir / adiar o defeito com base na prioridade e gravidade.
Testando novamente
O novo teste é a execução de um teste previamente falhado no AUT para verificar se o problema foi resolvido. Após a correção de um defeito, um novo teste é executado para verificar o cenário nas mesmas condições ambientais.
Durante o novo teste, os testadores procuram por detalhes granulares na área alterada de funcionalidade, enquanto o teste de regressão cobre todas as funções principais para garantir que nenhuma funcionalidade seja interrompida devido a essa alteração.
Teste de Regressão
Uma vez que todos os defeitos estão em status fechado, adiado ou rejeitado e nenhum dos casos de teste está em andamento / falha / status sem execução, pode-se dizer que o teste de integração de sistema é completamente baseado em casos de teste e requisitos. No entanto, uma rodada de testes rápidos é necessária para garantir que nenhuma funcionalidade seja interrompida devido a alterações de código / correções de defeitos.
O teste de regressão é uma técnica de teste de caixa preta que consiste em reexecutar aqueles testes que tiveram um impacto devido a alterações no código. Esses testes devem ser executados com a maior freqüência possível ao longo do ciclo de vida de desenvolvimento do software.
Tipos de testes de regressão
Final Regression Tests- Um "teste de regressão final" é executado para validar a construção que não passou por uma alteração por um período de tempo. Esta construção é implantada ou enviada aos clientes.
Regression Tests - Um teste de regressão normal é realizado para verificar se a construção NÃO quebrou nenhuma outra parte do aplicativo pelas mudanças recentes do código para correção de defeitos ou aprimoramento.
Diagrama de blocos de atividades
O diagrama de blocos a seguir mostra as atividades importantes realizadas nesta fase; também mostra a dependência das fases anteriores -
