STLC - Guia Rápido
STLC significa Ciclo de Vida de Teste de Software. STLC é uma sequência de diferentes atividades realizadas pela equipe de teste para garantir a qualidade do software ou do produto.
STLC é parte integrante do Ciclo de Vida de Desenvolvimento de Software (SDLC). Mas, o STLC lida apenas com as fases de teste.
O STLC começa assim que os requisitos são definidos ou SRD (Documento de Requisito de Software) é compartilhado pelas partes interessadas.
STLC fornece um processo passo a passo para garantir software de qualidade.
No estágio inicial do STLC, enquanto o software ou produto está em desenvolvimento, o testador pode analisar e definir o escopo do teste, os critérios de entrada e saída e também os Casos de Teste. Ajuda a reduzir o tempo do ciclo de teste com melhor qualidade.
Assim que a fase de desenvolvimento termina, os testadores estão prontos com os casos de teste e começam a execução. Isso ajuda a encontrar bugs na fase inicial.
Fases STLC
STLC tem as seguintes fases diferentes, mas não é obrigatório seguir todas as fases. As fases dependem da natureza do software ou do produto, tempo e recursos alocados para o teste e o modelo de SDLC a ser seguido.
Existem 6 fases principais do STLC -
Requirement Analysis - Quando o SRD estiver pronto e compartilhado com as partes interessadas, a equipe de teste inicia uma análise de alto nível sobre o AUT (Aplicativo em Teste).
Test Planning - A equipe de teste planeja a estratégia e a abordagem.
Test Case Designing - Desenvolver os casos de teste com base no escopo e critérios.
Test Environment Setup - Quando o ambiente integrado está pronto para validar o produto.
Test Execution - Validação do produto em tempo real e localização de bugs.
Test Closure - Assim que o teste for concluído, a matriz, os relatórios e os resultados serão documentados.
Neste capítulo, entenderemos os fatores de comparação entre STLC e SDLC. Vamos considerar os seguintes pontos e, assim, comparar STLC e SDLC.
STLC faz parte do SDLC. Pode-se dizer que STLC é um subconjunto do conjunto SDLC.
STLC é limitado à fase de teste onde a qualidade do software ou produto é garantida. SDLC tem um papel vasto e vital no desenvolvimento completo de um software ou produto.
No entanto, STLC é uma fase muito importante do SDLC e o produto final ou o software não pode ser lançado sem passar pelo processo STLC.
O STLC também faz parte do ciclo de pós-lançamento / atualização, a fase de manutenção do SDLC, onde os defeitos conhecidos são corrigidos ou uma nova funcionalidade é adicionada ao software.
A tabela a seguir lista os fatores de comparação entre SDLC e STLC com base em suas fases -
| Fase | SDLC | STLC |
|---|---|---|
| Recolha de requisitos |
|
|
| Projeto |
|
|
| Desenvolvimento |
|
|
| Configuração de ambiente |
|
|
| Testando |
|
|
| Implementação / Lançamento do produto |
|
|
| Manutenção |
|
|
O objetivo comum dos testes é encontrar bugs o mais cedo possível. E, uma vez que os bugs sejam corrigidos, certifique-se de que está funcionando como esperado e não quebrando nenhuma outra funcionalidade.
Para atingir esses objetivos, sete princípios básicos são dados para teste de software -
O que mostra o teste?
Os testes podem mostrar que existem defeitos, mas não há como provar que não há defeito no produto. As fases de teste garantem que o aplicativo em teste esteja funcionando com base no requisito fornecido e ajuda a reduzir a probabilidade de defeitos não descobertos no aplicativo. Mas, mesmo que nenhum defeito seja encontrado, isso não significa que seja absolutamente correto. Podemos assumir que o AUT está de acordo com nossos critérios de saída e mantendo os requisitos de acordo com SRD.
O teste exaustivo é possível?
100% de cobertura ou teste de todas as combinações de entradas e combinações possíveis não são possíveis, exceto em casos triviais. Em vez de testes exaustivos, a análise de risco e as prioridades são usadas para definir o escopo do teste. Aqui, a maioria dos cenários em tempo real pode considerar a inclusão do cenário negativo mais provável. Isso nos ajudará a rastrear a falha.
Teste Inicial
As atividades de teste devem começar o mais rápido possível e se concentrar nos objetivos definidos na Estratégia de Teste e nos resultados esperados. O estágio inicial de teste ajuda a identificar Defeito de Requisito ou discrepâncias de nível de projeto. Se esses tipos de bugs forem capturados no estágio inicial, isso nos ajudará a economizar tempo e também será econômico. A resposta de por que o teste deve começar em um estágio inicial é muito simples - assim que o SRD for recebido, os testadores podem analisar o requisito da perspectiva do teste e podem notar uma discrepância de requisito.
Clustering de defeitos
Com base na análise de defeitos do produto anterior, pode-se dizer que a maioria dos defeitos são identificados a partir de um pequeno conjunto de módulos que são críticos para a aplicação. Esses módulos podem ser identificados com base na complexidade, interação de sistema diferente ou dependência de outros módulos diferentes. Se os testadores puderem identificar esses módulos cruciais, eles podem se concentrar mais nesses módulos para identificar todos os bugs possíveis. Em um estudo, descobriu-se que 8 em cada 10 defeitos são identificados a partir de 20% da funcionalidade do AUT.
Paradoxo de Pesticidas
O que é o paradoxo dos pesticidas - se os pesticidas são usados com frequência nas plantações, chega quando os insetos desenvolvem certo tipo de resistência e, gradualmente, os pesticidas assim pulverizados parecem ser ineficazes sobre os insetos.
O mesmo conceito também se aplica a testes. Aqui, os insetos são insetos, enquanto os pesticidas são casos de teste usados para funcionar repetidamente. Se os mesmos conjuntos de casos de teste forem executados repetidamente, esses casos de teste se tornarão ineficazes após certo período de tempo e os testadores não serão capazes de identificar nenhum novo defeito.
Para superar essas condições, os casos de teste devem ser revisados e revisados periodicamente e novos e diferentes casos de teste podem ser adicionados. Isso ajudará na identificação de novos defeitos.
O teste é dependente do contexto
Este princípio afirma que dois tipos diferentes de aplicativo não podem ser testados usando a mesma abordagem até que ambos os aplicativos sejam da mesma natureza. Por exemplo, se um testador usa a mesma abordagem para aplicativos baseados na Web e aplicativos móveis, isso está completamente errado e há alto risco de baixa qualidade de lançamento do produto. Os testadores devem usar diferentes abordagens, metodologias, técnicas e cobertura para diferentes tipos e natureza de aplicativos.
Ausência de erro - falácia
Este princípio afirma encontrar defeitos e corrigi-los até que o aplicativo ou sistema esteja estável, consome tempo e também consome recursos. Mesmo depois de consertar 99% dos defeitos, existe um alto risco de aplicação instável. O primeiro fundamental é verificar a estabilidade da aplicação e os pré-requisitos do ambiente. Se essas duas condições se cumprirem, só então podemos começar com os testes detalhados.
A Análise de Requisitos é a primeira fase do STLC e começa assim que o SRD / SRS é compartilhado com a equipe de teste. Vamos considerar os seguintes pontos para entender a Análise de Requisitos em STLC.
O critério de entrada nesta fase é o fornecimento de SRS (Software Requirement Specification); também é recomendado que a arquitetura do aplicativo seja prática.
Nesta fase, a equipe de QA analisa em um nível superior o que testar e como testar.
A equipe de QA acompanha várias partes interessadas, como analista de negócios, arquitetura de sistema, cliente, gerente de teste / líder no caso de qualquer dúvida ou esclarecimento ser necessário para entender o requisito.
Os requisitos podem ser funcionais ou não funcionais, como desempenho, segurança, usabilidade, etc. ou funcionais e não funcionais.
O critério de saída desta fase é preencher o documento RTM, relatório de viabilidade de automação e uma lista de perguntas, se aplicável, para ser mais específico sobre os requisitos.
Atividades realizadas para análise de requisitos
Existem três atividades principais que são executadas pela equipe de QA nesta fase. As atividades estão descritas a seguir.
Definindo o Escopo
A equipe de QA identifica o escopo dos testes em níveis elevados e se divide em vários módulos funcionais. A equipe também identifica os tipos de teste necessários para realizar - teste de fumaça, teste de sanidade, teste funcional, teste de regressão, etc. A equipe de QA analisa os pré-requisitos e os detalhes do ambiente onde o teste deve ser realizado. A equipe reúne detalhes sobre as prioridades de teste e concentra-se na sequência de módulos a serem validados. Ele também identifica os defeitos de requisitos se os módulos forem contraditos e a funcionalidade não for transportada com outros módulos.
Prepare RTM
O rastreamento de requisitos é um processo de documentação dos links entre os requisitos e os produtos de trabalho desenvolvidos para implementar e verificar esses requisitos. O RTM captura todos os requisitos da Análise de Requisitos junto com sua rastreabilidade em um único documento. Tudo isso é entregue na conclusão do ciclo de vida.
A Matriz é criada no início de um projeto, pois forma a base do escopo do projeto e das entregas que serão produzidas.
A Matrix é bidirecional, pois rastreia o requisito examinando a saída das entregas e vice-versa, observando o requisito de negócios que foi especificado para um determinado recurso do produto.
Análise de Automação
Na fase de requisitos, a equipe de QA analisa o escopo da automação para o teste de regressão. Se a automação for incluída no escopo, a equipe decide qual ferramenta pode ser usada, quais funcionalidades serão cobertas como automação, o prazo e a alocação de recursos envolvidos para o desenvolvimento da automação. Depois que essa análise for concluída, a equipe de QA fornecerá o Relatório de Viabilidade de Automação para diferentes partes interessadas para fornecer a aprovação.
Neste capítulo, veremos os critérios de entrada e saída em diferentes níveis do STLC. Os pontos a seguir precisam ser considerados para entender os critérios.
O ideal é que a equipe de QA não prossiga com a próxima fase até que os critérios de saída da fase atual sejam atendidos. Os critérios de entrada devem incluir a conclusão dos critérios de saída da fase anterior.
Em tempo real, não é possível esperar pela próxima fase até que os critérios de saída sejam atendidos. Agora, a próxima fase pode ser iniciada se as entregas críticas da fase anterior foram concluídas.
Em cada fase do STLC, os critérios de entrada e saída devem ser definidos.
Critério de entrada
Os critérios de entrada para as fases STLC podem ser definidos como condições específicas; ou, todos os documentos necessários para iniciar uma determinada fase de STLC devem estar presentes antes de entrar em qualquer fase de STLC.
Os critérios de entrada são um conjunto de condições que permitem que uma tarefa seja executada ou, na ausência de qualquer uma dessas condições, a tarefa não pode ser executada.
Ao definir os critérios de entrada, também é importante definir o período de tempo em que o item de critérios de entrada está disponível para iniciar o processo.
Por exemplo, para iniciar a fase de desenvolvimento de casos de teste, as seguintes condições devem ser atendidas -
- O documento de requisitos deve estar disponível.
- É necessário um entendimento completo do fluxo do aplicativo.
- O documento do plano de teste deve estar pronto.
Critério de saída
Os critérios de saída para as fases do STLC podem ser definidos como itens / documentos / ações / tarefas que devem ser concluídos antes de concluir a fase atual e passar para a próxima fase.
Os critérios de saída são um conjunto de expectativas; isso deve ser atendido antes de concluir a fase de STLC.
Por exemplo, para concluir a fase de desenvolvimento de casos de teste, as seguintes expectativas devem ser atendidas -
- Os casos de teste devem ser escritos e revisados.
- Os dados de teste devem ser identificados e prontos.
- O script de automação de teste deve estar pronto, se aplicável.
Critérios de aceitação significa o comportamento esperado de uma funcionalidade, módulo e aplicativo conforme listado nos documentos de requisitos. São estágios / pontos de verificação de verificação para determinar se o sistema de software atendeu ou não às especificações dos requisitos. O objetivo principal deste teste é avaliar a conformidade do sistema com os requisitos do negócio e verificar se ele atendeu aos critérios exigidos.
Os Critérios de Aceitação são um conjunto de declarações que mencionam claramente o resultado de aprovação / reprovação esperado. Os critérios de aceitação especificam requisitos funcionais e não funcionais. Esses requisitos representam "condições de satisfação ou comportamento esperado". Não há aceitação parcial; um critério foi atendido ou não foi atendido.
Esses critérios definem os limites e parâmetros de uma funcionalidade / módulo e determinam se a funcionalidade / módulo está concluída e funcionando conforme o esperado.
Os critérios de aceitação de alto nível são mencionados no nível do plano de teste. Os critérios de aceitação são convertidos em uma lista de pontos a serem verificados ou resultados esperados no nível dos casos de teste.
Os critérios de aceitação são definidos com base nos seguintes atributos -
- Correção Funcional e Completude
- Integridade de dados
- Conversão de dados
- Usability
- Performance
- Timeliness
- Confidencialidade e disponibilidade
- Capacidade de instalação e atualização
- Scalability
- Documentation
Um plano de teste descreve a estratégia que será usada para testar um aplicativo, os recursos que serão usados, o ambiente de teste no qual o teste será executado e as limitações do teste e o cronograma das atividades de teste. Normalmente, o líder da equipe de garantia de qualidade será responsável por escrever um plano de teste.
O que um plano de teste inclui?
Um plano de teste inclui o seguinte.
- Introdução ao documento do Plano de Teste.
- Suposições ao testar o aplicativo.
- Lista de casos de teste incluídos no teste do aplicativo.
- Lista de recursos a serem testados.
- O tipo de abordagem a ser usada durante o teste do software.
- Lista de entregas que precisam ser testadas.
- Os recursos alocados para testar o aplicativo.
- Quaisquer riscos envolvidos durante o processo de teste.
- Um cronograma de tarefas e marcos a serem alcançados.
Pontos importantes para o planejamento de teste
Os pontos a seguir devem ser considerados para o planejamento de teste em STLC.
Idealmente, o Analista de Teste (Líder) / Gerente prepara a Estratégia de Teste / Documento de Plano de Teste.
A análise é mais focada em dados / informações relacionados ao aplicativo.
É a primeira fase das tarefas de teste reais.
Esta fase responde “O QUE deve ser testado” e “QUE RECURSOS são necessários para testar”.
O critério básico de entrada desta fase é o fornecimento de Documentos de Requisitos (versão atualizada de requisitos pouco claros / ausentes / esclarecidos) junto com a Matriz de Rastreabilidade de Requisitos.
Se a automação estiver no escopo, o Relatório de Viabilidade de Automação deve ser preparado antes de entrar nesta fase.
O critério de saída desta fase é a conclusão do Documento de Estratégia de Teste / Plano de Teste e do documento de Estimativa de esforço de Teste.
Aspectos da fase de planejamento de teste
O principal objetivo desta fase é preparar um documento de Plano de Teste / Estratégia de Teste. Inclui três aspectos principais - Escopo dos produtos, estimativa de esforço e plano de recursos.
Escopo de Entregáveis
As seguintes atividades precisam ser realizadas para concluir sobre o escopo das entregas -
- Identificar engajamento adequado e modelo de entrega.
- Defina objetivos de teste, escopo de teste, fases de teste e atividades.
- Revise os requisitos de negócios e os requisitos do sistema para identificar a viabilidade do teste.
- Defina o processo de teste, tipo de teste e procedimentos.
- Definir procedimentos de gerenciamento de defeitos e gerenciamento de mudanças.
- Identifique ferramentas de teste, técnicas e práticas recomendadas.
- Defina a análise de risco.
- Defina a solução de automação e identifique candidatos adequados para automação, se aplicável.
Estimativa de Esforço
Estimativa é o processo de encontrar uma estimativa, ou aproximação, que é um valor que pode ser usado para algum propósito, mesmo que os dados de entrada possam ser incompletos, incertos ou instáveis.
A estimativa determina quanto dinheiro, esforço, recursos e tempo levará para construir um sistema ou produto específico. A estimativa é baseada em -
- Dados / experiências anteriores
- Documentos / Conhecimento Disponíveis
- Assumptions
- Riscos Identificados
As quatro etapas básicas no teste de estimativa são -
- Estimativa do tamanho do AUT (Aplicação em Teste).
- Estimativa do esforço em pessoa-mês ou pessoa-hora.
- Estimativa do cronograma em meses civis.
- Estimativa do custo do projeto na moeda acordada.
Plano de Recursos
Os planos de recursos são o elemento-chave nas fases de teste. Esses planos são inversamente proporcionais ao tempo gasto pela equipe de teste para concluir uma tarefa específica. Aumentar o número de recursos diminuirá o número de dias de conclusão para um determinado limite depois que ele ficará saturado e aumentar o recurso não terá muito impacto e pode não levar a uma diminuição nos dias de conclusão.
Um solicitante de recursos, geralmente um gerente de projeto, cria planos de recursos para solicitar recursos, rastrear esforços e custos. Um gerente de recursos pode modificar e aprovar planos de recursos antes que os planos sejam usados.
O fluxo de trabalho normal para um plano de recursos é -
- Planejamento por Gerente de Projeto
- Solicitação levantada pelo Gerente de Projeto
- Aprovar / modificar / rejeitar pelo gerente de recursos
- Concluído - Fechando a solicitação após a aprovação pelo Gerente de Recursos
Assim que o plano de teste estiver pronto, a equipe de QA inicia o desenvolvimento dos casos de teste. O principal objetivo desta fase é preparar casos de teste para uma unidade individual. Esses casos de teste funcionais e estruturais cobrem a funcionalidade, pontos de verificação e validação mencionados no Plano de Teste.
Os pontos a seguir precisam ser considerados para o Desenvolvimento do Caso de Teste em STLC.
Nesta fase, a equipe de QA escreve o caso de teste com uma abordagem gradual. O caso de teste é então assinado por um analista de negócios após a revisão ou retrabalho nos casos de teste, caso sejam necessárias modificações.
Depois que os casos de teste estão prontos, a equipe de QA prepara os dados de teste com base nas pré-condições.
O critério de entrada nesta fase é que as atividades no planejamento de teste devem ser concluídas e o plano de teste deve estar pronto.
O critério de saída desta fase é que os casos de teste devem ser assinados, os dados de teste devem estar prontos e os scripts de teste preparados se a automação estiver no escopo.
Os casos de teste devem ser mapeados com a Matriz de Rastreabilidade de Requisitos para acompanhar a cobertura dos requisitos se algo for perdido.
Atividades na fase de desenvolvimento do caso de teste
A seguir estão as três atividades que são realizadas na fase de Desenvolvimento do Caso de Teste -
Identificação de cenários de teste
Os cenários facilitam o teste e a avaliação de um sistema complexo. As seguintes estratégias ajudam na criação de bons cenários -
Enumere os possíveis usuários, suas ações e objetivos.
Avalie os usuários com a mentalidade do hacker e liste possíveis cenários de abuso do sistema.
Liste os eventos do sistema e como o sistema lida com essas solicitações.
Liste os benefícios e crie tarefas de ponta a ponta para verificá-los.
Leia sobre sistemas semelhantes e seu comportamento.
Estudo de reclamações sobre produtos do concorrente e seu antecessor.
Escrita de Casos de Teste
Um caso de teste é um documento, que inclui dados de teste, pré-condições, resultados esperados e pós-condições, desenvolvido para um cenário de teste específico a fim de verificar a conformidade com um requisito específico.
O Caso de Teste atua como o ponto de partida para a execução do teste. Depois que um conjunto de valores de entrada é aplicado; o aplicativo tem um resultado definitivo e deixa o sistema em algum ponto final, também conhecido como pós-condição de execução.
Preparação de dados de teste
Os dados de teste são usados para executar os testes no software de teste. Os dados de teste precisam ser precisos e exaustivos para descobrir os defeitos. Para cumprir esses três objetivos, é seguido por uma abordagem gradual conforme a seguir -
- Identifique recursos ou requisitos de teste
- Identifique as condições / funcionalidade a serem testadas
- Definir condições de teste de prioridade
- Selecione as condições para o teste
- Determine o resultado esperado do processamento de casos de teste
- Criar casos de teste
- Condições de teste de documento
- Realizar teste
- Verifique e corrija os casos de teste com base nas modificações
Diagrama de blocos de atividades
O diagrama a seguir mostra as diferentes atividades que fazem parte do Desenvolvimento de Caso de Teste.
O Ambiente de Teste consiste em elementos que suportam a execução de teste com software, hardware e rede configurados. A configuração do ambiente de teste deve imitar o ambiente de produção para descobrir quaisquer problemas relacionados ao ambiente / configuração.
Os pontos a seguir devem ser considerados em uma configuração de ambiente de teste.
É uma combinação de ambiente de hardware e software no qual os testes serão executados.
Inclui configuração de hardware, configurações de sistema operacional, configuração de software, terminais de teste e outros suportes para realizar o teste.
É o aspecto mais crucial do processo de teste. A indisponibilidade ou configuração de ambiente defeituosa podem arruinar todos os esforços de teste.
Praticamente, a equipe de QA não pode iniciar o trabalho real sem ter o ambiente certo para testar.
É uma atividade independente e pode ser iniciada junto com o desenvolvimento do caso de teste.
De forma mais genérica, essa atividade é realizada por desenvolvedores em aspectos técnicos, enquanto as condições de requisitos podem ser realizadas por Clientes / Analistas de Negócios.
A prontidão do ambiente de teste pode ser validada pelo teste de fumaça e realizada pela equipe de QA.
Idealmente, podemos dizer que o Critério de Entrada desta fase é o fornecimento de Plano de Teste, prontidão de casos de Teste de Fumaça e preparação de dados de teste.
O critério de saída desta fase é que o ambiente de teste deve estar pronto e o teste de fumaça deve ser realizado com sucesso com os resultados esperados.
Atividades realizadas para configuração do ambiente de teste
As seguintes atividades são realizadas nesta fase.
Ambiente de teste de design
Os seguintes fatores desempenham um papel importante para o design de um ambiente de teste.
Determine se o ambiente de teste precisa de arquivamento para fazer backups.
Verifique a configuração da rede.
Identifique o sistema operacional do servidor necessário, bancos de dados e outros componentes.
Identifique o número de licenças exigidas pela equipe de teste.
Configuração do ambiente
Analise os requisitos de configuração do ambiente e prepare uma lista de requisitos de software e hardware para a configuração. Obtenha a confirmação oficial para a configuração do ambiente de teste e configure para acessar o ambiente de teste.
Teste de Fumaça
Depois que o ambiente estiver configurado e a equipe de QA tiver acesso a ele, uma rodada rápida de testes de fumaça deve ser realizada para validação da estabilidade de construção do ambiente de teste. Se os resultados forem os esperados, a equipe de QA pode passar para a próxima fase, caso contrário, apontar as discrepâncias e aguardar a implantação após as correções.
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 -
Ciclo de vida do defeito, também conhecido como ciclo de vida do bug, é a jornada de um defeito, o ciclo pelo qual um defeito passa durante sua vida. Isso varia de organização para organização e também de projeto para projeto, pois é regido pelo processo de teste de software e também depende das ferramentas utilizadas.
Ciclo de vida do defeito - Fluxo de trabalho
O diagrama a seguir mostra o fluxo de trabalho de um Ciclo de Vida de Defeito.
Estados de um ciclo de vida de defeito
A seguir estão os diferentes estados de um Ciclo de Vida de Defeito.
New - Potencial defeito que foi levantado e ainda não foi validado.
Assigned - Atribuído contra uma equipe de desenvolvimento a ser abordado.
Active- O Defeito está sendo tratado pelo desenvolvedor e a investigação está em andamento. Nesta fase, existem dois resultados possíveis - Adiado ou Rejeitado.
Test / Fixed / Ready for Retest - O defeito está corrigido e pronto para teste.
Verified - O Defeito que é testado novamente e o teste foi verificado pelo QA.
Closed - O estado final do defeito que pode ser fechado após o novo teste de QA ou pode ser fechado se o defeito for duplicado ou considerado NÃO um defeito.
Reopened - Quando o defeito NÃO é corrigido, o controle de qualidade reabre / reativa o defeito.
Deferred - Quando um defeito não pode ser resolvido naquele ciclo específico, ele é adiado para uma versão futura.
Rejected - Um defeito pode ser rejeitado por qualquer um dos três motivos - defeito duplicado, NÃO um defeito, não reproduzível.
Os defeitos são classificados da perspectiva da equipe de QA como Priority e da perspectiva de desenvolvimento como Severity(complexidade do código para corrigi-lo). Essas são duas classificações principais que desempenham um papel importante no prazo e na quantidade de trabalho necessária para corrigir os defeitos.
O que é prioridade?
A prioridade é definida como a ordem em que os defeitos devem ser resolvidos. O status de prioridade geralmente é definido pela equipe de controle de qualidade enquanto apresenta o defeito à equipe de desenvolvimento, mencionando o prazo para consertar o defeito. O status de Prioridade é definido com base nos requisitos dos usuários finais.
Por exemplo, se o logotipo da empresa for colocado incorretamente na página da web da empresa, a prioridade é alta, mas é de baixa gravidade.
Lista de Prioridades
Uma Prioridade pode ser categorizada das seguintes maneiras -
Low - Este defeito pode ser corrigido após a correção dos defeitos críticos.
Medium - O defeito deve ser resolvido nas compilações subsequentes.
High - O defeito deve ser resolvido imediatamente porque o defeito afeta o aplicativo em uma extensão considerável e os módulos relevantes não podem ser usados até que seja corrigido.
Urgent - O defeito deve ser resolvido imediatamente porque o defeito afeta a aplicação ou o produto severamente e o produto não pode ser usado até que seja corrigido.
O que é gravidade?
A gravidade é definida como o defeito do aplicativo e a complexidade do código para corrigi-lo do ponto de vista do desenvolvimento. Itestá relacionado ao aspecto de desenvolvimento do produto. A gravidade pode ser decidida com base em quão ruim / crucial é o defeito do sistema. O status de gravidade pode dar uma ideia sobre o desvio na funcionalidade devido ao defeito.
Example - Para o site de operação de voos, o defeito na geração do número do bilhete na reserva é de alta gravidade e também de alta prioridade.
Lista de Gravidade
A gravidade pode ser categorizada das seguintes maneiras -
Critical /Severity 1- O defeito afeta a funcionalidade mais crucial do aplicativo e a equipe de QA não pode continuar com a validação do aplicativo em teste sem corrigi-lo. Por exemplo, o aplicativo / produto trava com frequência.
Major / Severity 2- O defeito impacta um módulo funcional; a equipe de QA não pode testar aquele módulo específico, mas continuar com a validação de outros módulos. Por exemplo, a reserva de voo não está funcionando.
Medium / Severity 3- O defeito apresenta problemas com tela única ou relacionado a uma única função, mas o sistema ainda está funcionando. O defeito aqui não bloqueia nenhuma funcionalidade. Por exemplo, Ticket # é uma representação que não segue caracteres alfanuméricos adequados, como os primeiros cinco caracteres e os últimos cinco como numéricos.
Low / Severity 4- Não afeta a funcionalidade. Pode ser um defeito cosmético, inconsistência da IU para um campo ou uma sugestão para melhorar a experiência do usuário final do lado da IU. Por exemplo, a cor de fundo do botão Enviar não corresponde à cor do botão Salvar.
Uma verificação em relação aos critérios de saída do teste é muito essencial para afirmar que o teste agora está completo. Antes de encerrar o processo de teste, a qualidade do produto é medida em relação aos critérios de conclusão do teste.
O critério de entrada nesta fase é que a execução do caso de teste seja concluída, os resultados do teste estejam disponíveis e o relatório de defeitos esteja pronto.
Os critérios para a conclusão do teste incluem o seguinte -
- A cobertura especificada foi alcançada.
- Não showstoppers ou defeitos críticos
- Existem muito poucos defeitos conhecidos de média ou baixa prioridade. Isso não afeta o uso do produto.
O critério de saída desta fase é o fornecimento de relatórios de encerramento de testes e preparação de matrizes que são posteriormente assinadas pelo cliente.
Vamos agora discutir o activities involved in the closure of Test Cycle.
Relatório de conclusão de teste
O relatório de conclusão de teste é um processo em que as métricas de teste são relatadas em formato resumido para atualizar as partes interessadas. Isso permite que eles tomem uma decisão informada.
O Relatório de conclusão do teste contém as seguintes informações.
- Identificador de relatório de resumo de teste
- Summary
- Variances
- Resultados Resumidos
- Evaluation
- Esforços planejados versus reais
- cancelar assinar
Um bom Relatório de Conclusão de Teste indica a qualidade, mede os riscos pendentes e identifica o nível de um software testado.
Matriz de conclusão de teste
Após a conclusão do teste, várias matrizes são coletadas para preparar os relatórios de teste. Os critérios para preparar os relatórios incluem o seguinte -
- Número de testes executados
- Número de testes aprovados
- Número de testes falhados
- Número de falhas de teste com base em cada módulo
- Número de defeitos de teste levantados durante o ciclo de execução
- Número de defeitos de teste aceitos
- Número de defeitos de teste rejeitados
- Número de defeitos de teste adiados
- Status de defeitos ativos
- Calculando o Índice de Qualidade da Construção
Resultado dos testes
Durante a execução de um caso de teste, testando novamente os defeitos e realizando o caso de teste de regressão, Test results articulate devem ser salvos e podem ser produzidos junto com os documentos de encerramento do ciclo de teste para apoiar a conclusão da execução do teste.
Os articulados podem ser capturas de tela, resultados de consulta de banco de dados, gravação, arquivos de log, etc.