what is regression testing
O que é teste de regressão?
Teste de regressão é um tipo de teste feito para verificar se uma alteração de código no software não afeta a funcionalidade existente do produto. Isso é para garantir que o produto funcione bem com novas funcionalidades, correções de bugs ou qualquer alteração no recurso existente. Os casos de teste executados anteriormente são executados novamente para verificar o impacto da mudança.
=> Clique aqui para obter a série de tutoriais do plano de teste completo
O Teste de Regressão é um tipo de Teste de Software no qual os casos de teste são executados novamente para verificar se a funcionalidade anterior do aplicativo está funcionando bem e se as novas alterações não introduziram novos bugs.
Este teste pode ser executado em uma nova construção quando há uma mudança significativa na funcionalidade original que também ocorre em uma única correção de bug.
Regressão significa testar novamente as partes inalteradas do aplicativo.
O que você aprenderá:
- Tutoriais cobertos nesta série
- Visão geral do teste de regressão
- Quando realizar este teste?
- O teste de regressão pode ser realizado manualmente?
- Ferramentas de teste de regressão automatizada
- Por que o teste de regressão?
- Tipos de teste de regressão
- Quanta regressão é necessária?
- O que fazemos na verificação de regressão?
- Técnicas de teste de regressão
- Como selecionar um conjunto de testes de regressão?
- Como realizar o teste de regressão?
- Regressão em Agile
- Vantagens
- Desvantagens
- Regressão do aplicativo GUI
- Diferença entre regressão e novo teste
- Modelo de plano de teste de regressão (TOC)
- Conclusão
- Leitura recomendada
Tutoriais cobertos nesta série
Tutorial # 1: O que é teste de regressão (Este tutorial)
Tutorial # 2: Ferramentas de teste de regressão
Tutorial nº 3: Teste de Reteste vs. Teste de Regressão
Tutorial nº 4: Teste de regressão automatizada em Agile
Visão geral do teste de regressão
O teste de regressão é como um método de verificação. Os casos de teste são geralmente automatizados, pois os casos de teste precisam ser executados repetidamente, e executar os mesmos casos de teste manualmente é demorado e tedioso também.
Por exemplo, Considere um produto X, no qual uma das funcionalidades é acionar a confirmação, aceitação e envio de e-mails quando os botões Confirmar, Aceitar e Despachar são clicados.
Algum problema ocorre no e-mail de confirmação e para consertar o mesmo, algumas alterações de código são feitas. Nesse caso, não apenas os e-mails de confirmação precisam ser testados, mas os e-mails de aceitação e despachados também precisam ser testados para garantir que a alteração no código não os tenha afetado.
O Teste de Regressão não depende de nenhuma linguagem de programação como Java, C ++, C #, etc. É um método de teste usado para testar o produto quanto a modificações ou atualizações sendo feitas. Ele verifica se qualquer modificação em um produto não afeta os módulos existentes do produto.
Verificar se os bugs foram corrigidos e se os recursos recém-adicionados não criaram nenhum problema na versão de trabalho anterior do software.
Os testadores realizam testes funcionais quando um novo build está disponível para verificação. A intenção deste teste é verificar as alterações feitas na funcionalidade existente e também na funcionalidade recém-adicionada.
Quando esse teste é feito, o testador deve verificar se a funcionalidade existente está funcionando conforme o esperado e se as novas alterações não introduziram nenhum defeito na funcionalidade que estava funcionando antes dessa mudança.
O teste de regressão deve fazer parte do Ciclo de Liberação e deve ser considerado na estimativa do teste.
Quando realizar este teste?
O teste de regressão é geralmente executado após a verificação de alterações ou novas funcionalidades. Mas nem sempre é assim. Para a versão que está levando meses para ser concluída, os testes de regressão devem ser incorporados ao ciclo de teste diário. Para lançamentos semanais, os testes de regressão podem ser realizados quando o Teste Funcional para as alterações termina.
A verificação de regressão é uma variação do reteste (que consiste simplesmente em repetir um teste). Durante o reteste, o motivo pode ser qualquer coisa. Digamos que você estava testando um recurso específico e era o fim do dia - você não conseguiu terminar o teste e teve que interromper o processo sem decidir se o teste foi aprovado / reprovado.
No dia seguinte, ao voltar, você realiza o teste mais uma vez - isso significa que está repetindo um teste que já fez antes. O simples ato de repetir um teste é um Reteste.
O teste de regressão em sua essência é uma espécie de reteste. É apenas para uma ocasião especial que algo no aplicativo / código mudou. Pode ser código, design ou qualquer coisa que dite a estrutura geral do sistema.
Um Reteste que é conduzido nesta situação para ter certeza de que a dita mudança não teve um impacto em nada que já estava funcionando antes é chamado de Teste de Regressão. As razões mais comuns pelas quais isso pode ser realizado são porque novas versões do código foram criadas (aumento no escopo / requisito) ou bugs foram corrigidos.
O teste de regressão pode ser realizado manualmente?
Eu estava ensinando um dia desses na minha classe, e uma pergunta me veio - “A regressão pode ser feita manualmente?”
Eu respondi à pergunta e continuamos na aula. Tudo parecia bem, mas, de alguma forma, essa questão me incomodou um pouco mais tarde.
Ao longo dos muitos lotes, essa pergunta surge várias vezes de várias maneiras diferentes. Alguns deles são:
- Para realizar a execução do teste, precisamos de uma ferramenta?
- Como o teste de regressão é realizado?
- Mesmo depois de uma rodada inteira de testes - os recém-chegados acham difícil discernir o que exatamente é o teste de regressão?
E, claro, a pergunta original:
- Este teste pode ser executado manualmente?
Começar com, Execução de teste é um ato simples de usar seus casos de teste e executar essas etapas no AUT, fornecendo os dados de teste e comparando o resultado obtido no AUT com o resultado esperado mencionado em seus casos de teste.
Dependendo do resultado da comparação, definimos o status de aprovação / reprovação do caso de teste. A execução do teste é tão simples quanto isso, não existem ferramentas especiais necessárias para este processo.
Ferramentas de teste de regressão automatizada
O Teste de Regressão Automatizado é a área de teste onde podemos automatizar a maioria dos esforços de teste. Executamos todos os casos de teste executados anteriormente em uma nova construção.
Isso significa que temos um conjunto de casos de teste disponível e executar esses casos de teste manualmente é demorado. Conhecemos os resultados esperados, portanto, automatizar esses casos de teste economiza tempo e é um método de teste de regressão eficiente. A extensão da automação depende do número de casos de teste que permanecerão aplicáveis ao longo do tempo.
Se os casos de teste estão variando de tempos em tempos, o escopo do aplicativo continua aumentando e a automação do procedimento de regressão será uma perda de tempo.
A maioria das ferramentas de teste de regressão são do tipo gravação e reprodução. Você gravará os casos de teste navegando pelo AUT (aplicativo em teste) e verificará se os resultados esperados estão chegando ou não.
Ferramentas
- Selênio
- Estúdio de Catálogo
- AdventNet QEngine
- Testador de regressão
- vTest
- agua
- atiWate
- Rational Functional Tester
- SilkTest
- TimeShiftX
A maioria delas são ferramentas de teste funcional e de regressão.
Leitura Recomendada => Verifique aqui a lista das principais ferramentas de regressão
Adicionar e atualizar casos de teste de regressão em um conjunto de testes de automação é uma tarefa complicada. Ao selecionar uma ferramenta de automação para testes de regressão, você deve verificar se a ferramenta permite adicionar ou atualizar os casos de teste facilmente.
como abrir um arquivo swf no Chrome
Na maioria dos casos, precisamos atualizar os casos de teste de regressão automatizados com frequência devido a mudanças frequentes no sistema.
ASSISTA O VÍDEO
Para uma explicação mais detalhada da definição com um exemplo, verifique o seguinteVídeo de teste de regressão:
Por que o teste de regressão?
A regressão é iniciada quando um programador corrige qualquer bug ou adiciona um novo código para uma nova funcionalidade ao sistema.

Pode haver muitas dependências na funcionalidade recém-adicionada e existente.
É uma medida de qualidade para verificar se o novo código está em conformidade com o código antigo para que o código não modificado não seja afetado. Na maioria das vezes, a equipe de teste tem a tarefa de verificar as alterações de última hora no sistema.
Em tal situação, testar apenas a área de aplicação afetada é necessário para concluir o processo de teste a tempo, cobrindo todos os principais aspectos do sistema.
Este teste é muito importante quando há uma mudança / melhoria contínua adicionada ao aplicativo. A nova funcionalidade não deve afetar negativamente o código testado existente.
A regressão é necessária para localizar os bugs que ocorreram devido a uma alteração no código. Se esse teste não for feito, o produto pode ter problemas críticos no ambiente ao vivo e isso pode levar o cliente a problemas.
Ao testar qualquer site online, um testador relata um problema de que o Preço do Produto não é mostrado corretamente, ou seja, mostra um preço inferior ao preço real do Produto e precisa ser corrigido em breve.
Depois que o desenvolvedor corrige o problema, ele precisa ser testado novamente e o teste de regressão também é necessário, pois a verificação do preço na página relatada teria sido corrigida, mas pode estar mostrando um preço incorreto na página de resumo, onde o total é mostrado junto com as outras cobranças ou a correspondência enviada ao cliente ainda tem o preço incorreto.
Agora, neste caso, o cliente terá que arcar com a perda se este teste não for realizado, pois o site calcula o custo total com o preço incorreto e o mesmo preço vai para o cliente por e-mail. Uma vez que o cliente aceita, o Produto é vendido online a um preço mais baixo, isso será um prejuízo para o cliente.
Portanto, esse teste desempenha um grande papel e é muito necessário e importante também.
Tipos de teste de regressão
A seguir estão os vários tipos de regressão:
- Regressão de Unidade
- Regressão Parcial
- Regressão Completa
# 1) Regressão da Unidade
A regressão da unidade é feita durante o Teste de Unidade fase e código são testados isoladamente, ou seja, quaisquer dependências na unidade a ser testada são bloqueadas para que a unidade possa ser testada individualmente sem qualquer discrepância.
# 2) Regressão parcial
A regressão parcial é feita para verificar se o código funciona bem, mesmo quando as alterações foram feitas no código e que a unidade está integrada com o código inalterado ou já existente.
# 3) Regressão completa
A regressão completa é feita quando uma mudança no código é feita em vários módulos e também se o impacto da mudança de uma mudança em qualquer outro módulo for incerto. O produto como um todo é regredido para verificar quaisquer alterações por causa do código alterado.
Quanta regressão é necessária?
Isso depende do escopo dos recursos recém-adicionados.
Se o escopo de uma correção ou recurso for muito grande, a área do aplicativo que está sendo afetada também é muito grande e o teste deve ser executado completamente, incluindo todos os casos de teste do aplicativo. Mas isso pode ser decidido de forma eficaz quando o testador obtém informações de um desenvolvedor sobre o escopo, a natureza e a quantidade de mudança.
Como esses são testes repetitivos, os casos de teste podem ser automatizados para que um conjunto de casos de teste sozinho possa ser executado facilmente em uma nova construção.
Os casos de teste de regressão precisam ser selecionados com muito cuidado para que a funcionalidade máxima seja coberta em um conjunto mínimo de casos de teste. Esse conjunto de casos de teste precisa de melhorias contínuas para a funcionalidade recém-adicionada.
Torna-se muito difícil quando o escopo do aplicativo é muito grande e há incrementos ou patches contínuos no sistema. Nesses casos, testes seletivos precisam ser executados para economizar tempo e custo de teste. Esses casos de teste seletivos são escolhidos com base nas melhorias feitas no sistema e nas partes em que isso pode afetar mais.
O que fazemos na verificação de regressão?
- Execute novamente os testes conduzidos anteriormente
- Compare os resultados atuais com os resultados do teste executado anteriormente
Este é um processo contínuo executado em vários estágios ao longo do ciclo de vida do teste de software.
Uma prática recomendada é conduzir um teste de regressão após o Teste de Sanidade ou Fumaça e no final do teste funcional para uma versão curta.
A fim de realizar testes eficazes, a regressão Plano de teste deve ser criado. Este plano deve delinear a estratégia de teste de regressão e os critérios de saída. O Teste de Desempenho também faz parte desse teste para garantir que o desempenho do sistema não seja afetado devido às alterações feitas nos componentes do sistema.
Melhores Práticas : Execute casos de teste automatizados todos os dias à noite para que quaisquer efeitos colaterais de regressão possam ser corrigidos na compilação do dia seguinte. Dessa forma, ele reduz o risco de lançamento, cobrindo quase todos os defeitos de regressão em um estágio inicial, em vez de localizar e corrigir no final do ciclo de lançamento.
Técnicas de teste de regressão
A seguir estão as várias técnicas.
- Teste novamente tudo
- Seleção de teste de regressão
- Priorização de caso de teste
- Híbrido

# 1) Teste novamente tudo
Como o próprio nome sugere, todos os casos de teste no conjunto de testes são executados novamente para garantir que nenhum bug tenha ocorrido por causa de uma mudança no código. Este é um método caro, pois requer mais tempo e recursos quando comparado às outras técnicas.
# 2) Seleção de teste de regressão
Neste método, os casos de teste são selecionados do conjunto de testes para serem executados novamente. Nem todo o pacote é executado novamente. A seleção dos casos de teste é feita com base na alteração do código no módulo.
Os casos de teste são divididos em duas categorias, uma é casos de teste reutilizáveis e outra é casos de teste obsoletos. Os casos de teste reutilizáveis podem ser usados em ciclos de regressão futuros, enquanto os obsoletos não são usados nos próximos ciclos de regressão.
# 3) Priorização de caso de teste
Os casos de teste com prioridade alta são executados primeiro do que aqueles com prioridade média e baixa. A prioridade do caso de teste depende de sua criticidade e seu impacto no produto e também na funcionalidade do produto que é usado com mais frequência.
# 4) Híbrido
A técnica híbrida é uma combinação de seleção de teste de regressão e priorização de caso de teste. Em vez de selecionar todo o conjunto de testes, selecione apenas os casos de teste que são executados novamente, dependendo de sua prioridade.
Como selecionar um conjunto de testes de regressão?
A maioria dos bugs encontrados no ambiente de produção ocorre devido às mudanças ou bugs corrigidos na décima primeira hora, ou seja, as mudanças feitas em um estágio posterior. A correção de bug no último estágio pode criar outros problemas / bugs no Produto. É por isso que a verificação de regressão é muito importante antes de lançar um produto.
Abaixo está uma lista de casos de teste que podem ser usados durante a realização deste teste:
- Funcionalidades frequentemente utilizadas.
- Casos de teste que cobrem o módulo onde as alterações foram feitas.
- Casos de teste complexos.
- Casos de teste de integração que incluem todos os componentes principais.
- Casos de teste para a funcionalidade ou recurso principal do Produto.
- Os casos de teste de Prioridade 1 e Prioridade 2 devem ser incluídos.
- Casos de teste que freqüentemente falham ou defeitos de teste recentes foram encontrados no mesmo.
Como realizar o teste de regressão?
Agora que estabelecemos o que significa regressão, é aparente que ela também está testando - simplesmente se repetindo em uma situação específica por um motivo específico. Portanto, podemos deduzir com segurança que o mesmo método se aplica ao teste em primeiro lugar pode ser aplicado a isso também.
Portanto, se o teste pode ser feito manualmente, o Teste de Regressão também pode ser. O uso de ferramenta não é necessário. No entanto, conforme o tempo passa, os aplicativos são empilhados com mais e mais funcionalidades, o que continua aumentando o escopo da regressão. Para aproveitar ao máximo o tempo, este teste é mais frequentemente automatizado .
A seguir, estão as várias etapas envolvidas na realização deste Teste
- Prepare um conjunto de testes para regressão considerando os pontos mencionados em “Como selecionar o conjunto de testes de regressão”?
- Automatize todos os casos de teste do conjunto de testes.
- Atualize o pacote de regressão sempre que for necessário, como se algum novo defeito não coberto no caso de teste for encontrado, e um caso de teste para o mesmo deve ser atualizado no pacote de teste para que o teste não seja perdido na próxima vez . O conjunto de testes de regressão deve ser gerenciado adequadamente, atualizando continuamente os casos de teste.
- Execute os casos de teste de regressão sempre que houver alguma alteração no código, o bug for corrigido, uma nova funcionalidade for adicionada, um aprimoramento da funcionalidade existente for feito, etc.
- Crie um relatório de execução de teste que inclui o status Aprovado / Falha dos casos de teste executados.
Por exemplo:
Deixe-me explicar isso com um exemplo. Examine a situação abaixo:
| Estatísticas da versão 1 | |
|---|---|
| Nº de testadores | 3 |
| Nome da Aplicação | XYZ |
| Número da versão / lançamento | 1 |
| Nº de requisitos (escopo) | 10 |
| Nº de casos de teste / testes | 100 |
| Número de dias que leva para desenvolver | 5 |
| Número de dias que leva para testar | 5 |
| Estatísticas da versão 2 | |
|---|---|
| Nº de testadores | 3 |
| Nome da Aplicação | XYZ |
| Número da versão / lançamento | dois |
| Nº de requisitos (escopo) | 10+ 5 novos requisitos |
| Nº de casos de teste / testes | 100+ 50 novos |
| Número de dias que leva para desenvolver | 2,5 (já que esta metade da quantidade de trabalho do que antes) |
| Número de dias que leva para testar | 5 (para os 100 TCs existentes) + 2,5 (para novos requisitos) |
| Estatísticas da versão 3 | |
|---|---|
| Nº de testadores | 3 |
| Nome da Aplicação | XYZ |
| Número da versão / lançamento | 3 |
| Nº de requisitos (escopo) | 10+ 5 + 5 novos requisitos |
| Nº de casos de teste / testes | 100+ 50+ 50 novos |
| Número de dias que leva para desenvolver | 2,5 (já que esta metade da quantidade de trabalho do que antes) |
| Número de dias que leva para testar | 7,5 (para os 150 TCs existentes) + 2,5 (para novos requisitos) |
A seguir estão as observações que podemos fazer a partir da situação acima:
- Conforme os lançamentos aumentam, a funcionalidade também aumenta.
- O tempo de desenvolvimento não aumenta necessariamente com os lançamentos, mas o tempo de teste aumenta
- Nenhuma empresa / sua administração estará pronta para investir mais tempo em testes e menos para desenvolvimento
- Não podemos nem mesmo reduzir o tempo que leva para testar aumentando o tamanho da equipe de teste porque mais pessoas significa mais dinheiro e novas pessoas também significam muito treinamento e talvez também um comprometimento na qualidade, pois as novas pessoas podem não estar em sintonia com o conhecimento necessário níveis imediatamente.
- A outra alternativa é claramente reduzir a quantidade de regressão. Mas isso pode ser arriscado para o produto de software.
Por todos esses motivos, o teste de regressão é um bom candidato para o teste de automação, mas não precisa ser feito apenas dessa maneira.
Etapas básicas para realizar testes de regressão
Cada vez que o software passa por uma alteração e uma nova versão / lançamento surge, a seguir estão as etapas que você pode seguir para realizar este tipo de teste:

- Entenda que tipo de mudanças foram feitas no software
- Analise e determine quais módulos / partes do software podem ser afetados - as equipes de desenvolvimento e BA podem ser fundamentais para fornecer essas informações
- Dê uma olhada em seus casos de teste e determine se você terá que fazer uma regressão completa, parcial ou unitária. Identifique aqueles que se encaixam na sua situação
- Agende o horário e teste!
Regressão em Agile
Ágil é uma abordagem adaptativa que segue um método iterativo e incremental. O produto é desenvolvido em iterações curtas chamadas sprint, que duram de 2 a 4 semanas. No ágil, há uma série de iterações, portanto, esse teste desempenha um papel significativo à medida que a nova funcionalidade ou mudança de código é feita nas iterações.
O conjunto de testes de regressão deve ser preparado desde a fase inicial e deve ser atualizado a cada sprint.
No Agile, a verificação de regressão é coberta em duas categorias:
- Regressão de nível de sprint
- Regressão de ponta a ponta
# 1) Regressão de nível de sprint
A regressão de nível de sprint é feita principalmente para a nova funcionalidade ou o aprimoramento que é feito no sprint mais recente. Os casos de teste do conjunto de testes são selecionados de acordo com a funcionalidade recém-adicionada ou o aprimoramento que é feito.
# 2) Regressão ponta a ponta
A regressão ponta a ponta inclui todos os casos de teste que devem ser reexecutados para testar o produto completo, de ponta a ponta, cobrindo todas as funcionalidades essenciais do produto.
Como o Agile tem sprints curtos e continua, é muito necessário automatizar o conjunto de testes, os casos de teste são executados novamente e isso também precisa ser concluído em um curto espaço de tempo. Automatizar os casos de teste reduz o tempo de execução e o deslizamento de defeitos.
Vantagens
Dada a seguir estão as várias vantagens do teste de regressão
- Além disso, melhora a qualidade do produto.
- Ele garante que qualquer correção de bug ou aprimoramento feito não afeta a funcionalidade existente do Produto.
- Ferramentas de automação podem ser usadas para este teste.
- Isso garante que os problemas que já foram corrigidos não ocorram novamente.
Desvantagens
Embora existam várias vantagens, também existem algumas desvantagens. Eles estão:
- Isso também deve ser feito para uma pequena mudança no código, porque até mesmo uma pequena mudança no código pode criar problemas na funcionalidade existente.
- Se, no caso, a automação não for usada no Projeto para este teste, será uma tarefa demorada e tediosa executar os casos de teste repetidamente.
Regressão do aplicativo GUI
É difícil realizar um teste de regressão GUI (Graphical User Interface) quando a estrutura da GUI é modificado. Os casos de teste escritos na GUI antiga se tornam obsoletos ou precisam ser modificados.
Reutilizar os casos de teste de regressão significa que os casos de teste da GUI são modificados de acordo com a nova GUI. Mas essa tarefa se torna complicada se você tiver um grande conjunto de casos de teste de GUI.
Diferença entre regressão e novo teste
O novo teste é feito para os casos de teste que falham durante a execução e o bug levantado para o mesmo foi corrigido, enquanto a verificação de regressão não se limita à correção do bug, pois cobre outros casos de teste também para garantir que a correção do bug não impactou qualquer outra funcionalidade do Produto.
Modelo de plano de teste de regressão (TOC)
1. Histórico do documento
2. Referências
3. Plano de teste de regressão
3.1. Introdução
3.2. Propósito
3.3. Estratégia de Teste
3.4. Recurso a ser testado
3,5. Requisito de recursos
3.5.1. Requisito de Hardware
3.5.2. Requisito de Software
3,6. Cronograma de Teste
3,7. Pedido de mudança
3,8. Critérios de entrada / saída
3.8.1. Critérios de entrada para este teste
3.8.2. Critérios de saída para este teste
3,9. Suposições / restrições
3,10. Casos de teste
3,11. Risco / Suposições
3,12. Ferramentas
4. Aprovação / Aceitação
Vamos dar uma olhada em cada um deles em detalhes.
# 1) Histórico do documento
O histórico do documento consiste em um registro do primeiro rascunho e de todos os atualizados no formato fornecido a seguir.
| Versão | Encontro | Autor | Comente |
|---|---|---|---|
| 1 | DD / MM / AA | abc | Aprovado |
| dois | DD / MM / AA | abc | Atualizado para o recurso adicionado |
# 2) Referências
A coluna Referências mantém um registro de todos os documentos de referência usados ou exigidos para o projeto ao criar um plano de teste.
| Não | Documento | Localização |
|---|---|---|
| 1 | Documento SRS | Drive compartilhado |
# 3) Plano de teste de regressão
3.1. Introdução
Este documento descreve a mudança / atualização / aprimoramento no Produto a ser testado e a abordagem usada para esse teste. Todas as alterações de código, aprimoramentos, atualizações e recursos adicionados são delineados para serem testados. Os casos de teste usados para Teste de Unidade e Teste de Integração podem ser usados para criar um conjunto de testes para Regressão.
3.2. Propósito
O objetivo do plano de teste de regressão é descrever o que exatamente e como o teste seria realizado para alcançar os resultados. A verificação de regressão é feita para garantir que nenhuma outra funcionalidade do produto seja prejudicada por causa da alteração do código.
3.3. Estratégia de Teste
A Estratégia de Teste descreve a abordagem que será usada para realizar este teste e inclui a técnica que será usada, quais serão os critérios de conclusão, quem executará qual atividade, quem escreverá os scripts de teste, qual ferramenta de regressão será usada , etapas para cobrir os riscos como escassez de recursos, atraso na produção, etc.
3.4. Recursos a serem testados
Recursos / componentes do produto a ser testado estão listados aqui. Na regressão, todos os casos de teste são executados novamente ou aqueles que afetam a funcionalidade existente são escolhidos dependendo da correção / atualização ou melhoria feita.
3,5. Requisito de recursos
3.5.1. Requisito de hardware:
O requisito de hardware é identificado aqui como computadores, laptop, modems, livro do Mac, smartphone, etc.
3.5.2. Requisito de software:
O Requisito de Software é identificado como qual sistema operacional e navegadores serão necessários.
3,6. Cronograma de Teste
O cronograma de teste define o tempo estimado para a execução das atividades de teste.
Por exemplo Quantos recursos realizarão uma atividade de teste e isso também em quanto tempo?
3,7. Pedido de mudança
Os detalhes de CR são mencionados para os quais a regressão seria realizada.
| S.Não | Descrição CR | Suíte de teste de regressão |
|---|---|---|
| 1 | ||
| dois |
3,8. Critérios de entrada / saída
3.8.1. Critérios de entrada para este teste:
Os critérios de entrada para o Produto para iniciar a verificação de regressão são definidos.
Por exemplo:
- As alterações de codificação / aprimoramento / adição de novo recurso devem ser concluídas.
- O plano de teste de regressão deve ser aprovado.
3.8.2. Critérios de saída para este teste:
Aqui os critérios de saída para regressão são definidos.
Por exemplo:
- O teste de regressão deve ser concluído.
- Quaisquer novos bugs críticos encontrados durante este teste devem ser fechados.
- O relatório de teste deve estar pronto.
3,9. Casos de teste
Os casos de teste de regressão são definidos aqui.
3,10. Risco / Suposições
Quaisquer riscos e premissas são identificados e um plano de contingência é elaborado para os mesmos.
3,11. Ferramentas
As ferramentas a serem utilizadas no Projeto são identificadas. Tal como:
- Ferramenta de automação
- Ferramenta de relatório de bugs
# 4) Aprovação / Aceitação
Os nomes e designação das pessoas estão listados aqui:
| Nome | Aprovado / Rejeitado | Assinatura | Encontro |
|---|---|---|---|
Conclusão
O teste de regressão é um dos aspectos importantes, pois ajuda a entregar um produto de qualidade, garantindo que qualquer alteração no código, seja ele pequeno ou grande, não afete a funcionalidade existente ou antiga.
Muitas ferramentas de automação estão disponíveis para automatizar os casos de teste de regressão, no entanto, uma ferramenta deve ser selecionada de acordo com os requisitos do projeto. Uma ferramenta deve ter a capacidade de atualizar o conjunto de testes, pois o conjunto de testes Regression precisa ser atualizado com freqüência.
Com isso, encerramos este tópico e esperamos que haja muito mais clareza sobre o assunto de agora em diante.
Informe-nos sobre suas perguntas e comentários relacionados à regressão. Como você abordou suas tarefas de teste de regressão?
=> Visite aqui para obter a série de tutoriais do plano de teste completo
Leitura recomendada
- Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
- As 10 ferramentas de teste de regressão mais populares em 2021
- O que é teste de confiabilidade: definição, método e ferramentas
- 11 melhores ferramentas de automação para testar aplicativos Android (Android App Testing Tools)
- Teste de regressão automatizado: desafios, processos e etapas
- Download do e-book do Testing Primer
- Diferença entre reteste e teste de regressão com exemplo
- Top 10+ Best SAP Testing Tools (SAP Automation Tools)