Quando parar de testar (critérios de saída em teste de software)

when stop testing

Critérios de saída em teste:

“Bem começado fica pela metade” - Aplica-se em qualquer lugar, até mesmo em testes de software.

Freqüentemente, vemos testadores de software muito entusiasmados no início do projeto. Nós criamos documentos de teste como Estratégia de Teste, Plano de Teste ou Casos de Teste com entusiasmo e entusiasmo.

Então chegamos ao teste de software com um BANG! Isso só é ampliado pelos defeitos interessantes que encontramos no início do projeto. Resolvê-los apenas aumentará nossa realização.

Conforme encontramos muitos defeitos e concluímos a primeira execução, passamos para a próxima fase. Quando chegamos à segunda corrida, meio que relaxamos e como é a tendência humana geral de ficando entediado em testar a mesma coisa na segunda corrida.

aplicação suporte entrevista perguntas e respostas pdf

Muitos testadores acham que se torna trabalho monótono em execuções posteriores e começa a perder o interesse em testar o mesmo software repetidamente. Quando chegamos a, talvez a terceira execução, uma pergunta começa a nos assombrar: “Quando parar de testar o software?”

Aposto que você deve ter se sentido da mesma maneira e perguntado, “Quando parar de testar?”, Pelo menos uma vez. Eu diria que a questão é “Quando, onde e como parar o teste?” :)

Conceitualmente, lemos e muitos testadores acreditam que não pode haver uma condição ou equação específica para decidir 'Quando parar de testar?' Há uma série de fatores a serem considerados antes de concluirmos essa questão.

No artigo de hoje, gostaria de compartilhar meus pensamentos sobre como concluir as atividades de teste quando chegarmos a um ponto em nosso ciclo de teste onde podemos dizer que esse teste é o suficiente. Faremos isso com a ajuda de alguns exemplos da vida real em um ciclo de teste típico.

O que você aprenderá:

• Quando é o teste suficiente?
• Parando quando todos os defeitos forem encontrados: É possível?
• Decisão de interromper o teste: critérios de saída
• O que são critérios de conclusão ou saída?
• O que deve estar presente nos critérios de saída?
• O teste pode ser interrompido quando:
• Conclusão:
• Leitura recomendada

Quando é o teste suficiente?

Quando podemos dizer que tantos testes são suficientes? O teste pode ser concluído?

Para responder a essas perguntas, teremos que analisar as atividades de teste do início ao fim. Por favor, observe que - vou definir essas atividades em termos leigos - não de uma forma técnica sofisticada.

Vamos considerar que você está iniciando o teste de um novo projeto.

Atividades iniciais:

• A equipe de teste recebe os requisitos.
• A equipe de teste começa planejamento e projetando.
• Os documentos de teste iniciais estão prontos e revisados.

Execução de teste nº 1)

• A equipe de teste inicia a execução do teste assim que receberem o produto desenvolvido.
• Durante a fase de teste, eles executam vários cenários para quebrar o software e encontrar muitos defeitos. (Além disso, a taxa de defeitos aqui é maior porque o aplicativo é novo e está sendo avaliado pela primeira vez.)
• Os defeitos são corrigidos pelos desenvolvedores e devolvidos à equipe de teste para um novo teste.
• A equipe de teste realiza o reteste dos defeitos e executa a regressão.
• Depois que a maioria dos defeitos de alta gravidade são resolvidos e o software parece estável, a equipe de desenvolvimento lança a próxima versão.

Execução de teste nº 2)

• A equipe de teste inicia a segunda execução de teste e atividades semelhantes são executadas como Execução 1.
• Nesse processo, durante a segunda execução de teste, mais alguns defeitos são detectados.
• Os defeitos são corrigidos pelos desenvolvedores e devolvidos à equipe de teste para um novo teste.
• A equipe de teste testa novamente os defeitos e executa regressão .

Isso pode continuar para sempre. Execute 3, execute 4 em diante até que todos os defeitos no software sejam encontrados e o software fique livre de erros.

Se quisermos desenhar um fluxograma para essas atividades, será mais ou menos assim:

A partir do fluxograma acima, podemos concluir claramente que o teste pode continuar até que todos os defeitos no software sejam encontrados.

Mas a questão é - é possível encontrar todos os defeitos do software? Vamos tentar encontrar a resposta para esta pergunta de um milhão de dólares :).

Parando quando todos os defeitos forem encontrados: É possível?

A maioria dos softwares é complexa e tem um escopo de teste enorme. Não é impossível encontrar todos os defeitos do software, mas isso vai demorar uma eternidade.

Mesmo depois de encontrar muitos bugs no software, ninguém pode realmente garantir que o software está livre de defeitos agora. Não pode haver uma situação em que possamos dizer com segurança que concluímos os testes, encontramos todos os defeitos no software e ele não tem mais bugs.

Além disso, o objetivo do teste não é encontrar todos os defeitos do software. A intenção do teste de software é provar que o software funciona conforme planejado, quebrando-o ou encontrando desvio entre seu comportamento atual e o comportamento esperado.

Existem defeitos ilimitados no software e, portanto, é impraticável testá-lo até que todos os defeitos sejam encontrados, pois nunca podemos saber qual defeito é o último. A verdade é que não podemos depender de encontrar todos os defeitos no software para concluir nossos testes.

Falando honestamente, o teste é infinito e os ciclos de teste continuarão até que seja tomada uma decisão quando e onde parar. Agora fica ainda mais complicado chegar a uma decisão de interromper o teste. Se “parar quando todos os defeitos forem encontrados” não for o critério para interromper o teste, então em que base isso deve ser decidido?

Decisão de parar o teste: Critério de saída

Agora vamos tentar entender - Quais são os fatores mais importantes a serem considerados ao concluir as atividades de teste? Acho que a decisão de parar de testar depende principalmente de Tempo, orçamento e extensão do teste.

A abordagem mais comum é parar quando o Tempo / Orçamento se esgota ou todos os cenários de teste são executados. No entanto, com essa abordagem, estaremos comprometendo a qualidade dos testes e isso não nos dará confiança suficiente sobre o software; Como?

Vamos ver com umexemplo.

Cenário de teste:

Suponha que você esteja testando um módulo de software. Você recebeu um certo orçamento para cobrir isso. Os cronogramas do projeto são de um mês. O total de cenários de teste é de 200. Você é o único testando este módulo.

Cenário 1)

Semana 1: Você encontra o defeito showstopper / severity 1 no dia 1 e todo o teste é bloqueado por 3 dias. Portanto, você não pode executar nenhum dos cenários até que o defeito da Severidade 1 seja resolvido. Após perder 3 dias, o bloqueador é resolvido e você continua com sua execução.

No final da semana, você completa 20 cenários com alguns mais importantes defeitos prioritários .

Semana 2: Você começa a testar o software colocando mais foco na localização de defeitos. Você abre mais alguns defeitos de Severidade 1, Severidade 2 e Severidade 3 durante a segunda semana e, no final da semana, é capaz de cobrir 70 cenários.

Semana 3: No início do 3^rdsemana você obtém todos os defeitos de alta prioridade resolvidos, portanto, junto com a execução de cenários pendentes, agora você tem que testar novamente todos os defeitos que chegaram ao depósito de teste. Continuando com o bom andamento, você cobrirá 120 cenários com defeitos adicionais.

A essa altura, todos os defeitos de alta prioridade já foram encontrados e relatados. Então, agora você tem apenas defeitos de Severidade 3 restantes para serem encontrados.

Semana 4: Na semana 4, você precisa testar novamente a maioria dos defeitos abertos e os 80 cenários restantes. Com isso, ao final da semana 4, você será capaz de concluir até 180 cenários com todos os defeitos de prioridade alta e média corrigidos e testados novamente.

Colocando essas informações em forma tabular:

Você deveria parar aqui?

A razão de você ter esgotado Tempo de teste completamente e relataram e corrigiram a maioria dos defeitos de alta prioridade. Parar neste ponto lhe dará confiança sobre o software? Na verdade, não devido aos motivos abaixo:

• Os cenários não são executados completamente.
• Poucos fluxos não são testados nem uma vez.
• Todos os cenários cobertos são executados apenas uma vez.
• O software ainda tem defeitos.
• A regressão não é coberta.

Cenário # 2)

Semana 1: Você encontra defeito de Severidade 1 no dia 1 e o teste completo é bloqueado por 3 dias. Portanto, você não pode executar nenhum dos cenários até que o Defeito de Gravidade 1 seja resolvido. Após perder 3 dias o bloqueador é resolvido e você continua com sua execução.

No final da semana, você completa 20 cenários com mais alguns defeitos. Esta semana continua igual ao Cenário 1.

Semana 2: Você abre mais alguns defeitos de Severidade 1, Severidade 2 e Severidade 3 durante a segunda semana, mas o foco é cobrir mais cenários para cobrir o backlog da semana 1. No final da semana, você é capaz de cobrir 120 cenários.

Semana 3: No início do 3^rdsemana você tem todos os defeitos abertos resolvidos, portanto, junto com a execução de cenários pendentes, agora você tem que testar novamente todos os defeitos que foram colocados em um balde de teste. Ainda continuando com bom progresso no final, o número de cenários concluídos torna-se 200 com defeitos adicionais.

Agora você só pode relatar defeitos de Severidade 2 e Severidade 3.

Colocando essas informações em forma tabular:

Você deveria parar aqui?

Você tem cobriu todos os cenários de teste completamente uma vez e abriram alguns defeitos importantes. Parar neste ponto lhe dará confiança sobre o software?

Na verdade, não devido aos motivos abaixo:

• Todos os cenários são executados apenas uma vez.
• O software ainda tem muitos defeitos importantes.
• A regressão não é coberta.

Podemos ver que a qualidade está comprometida em ambos os cenários acima. A melhor abordagem será encontrar um ponto onde todos os fatores do cenário 1 e do cenário 2 sejam cobertos e a qualidade também não seja comprometida. Para conseguir isso, teremos que definir certos critérios no início do teste.

Esses critérios são denominados como Critérios de Conclusão ou Saída. É a resposta à nossa pergunta - “Quando parar o teste?”.

O que são critérios de conclusão ou saída?

Os critérios de saída são avaliados no final do ciclo de teste e são definidos no Plano de Teste. É o conjunto de condições ou atividades que devem ser cumpridas para a conclusão dos testes.

Os critérios de saída definem quanto teste é suficiente e quando as atividades de teste podem ser declaradas concluídas. Cobertura e os critérios de conclusão são combinados para definir os critérios de saída para teste.

O que deve estar presente nos critérios de saída?

Idealmente, os critérios de saída ou parada são definidos pela combinação de vários fatores e, portanto, são únicos em todos os projetos. Depende do requisito do projeto e, portanto, deve ser definido durante o planejamento de teste; no início do projeto. Os parâmetros definidos nele devem ser quantificados tanto quanto possível.

Abaixo estão algumas dicas a serem consideradas ao definir os critérios de saída no caso de teste funcional ou de sistema. Você pode combinar alguns ou todos os fatores abaixo ao decidir onde interromper o teste de acordo com as necessidades do projeto.

O teste pode ser interrompido quando:

Requisitos:

• 100% de cobertura dos requisitos é alcançada.

Defeitos:

• A contagem de defeitos definidos / desejados foi atingida.
• Todos os defeitos ou bloqueadores do Show Stopper são corrigidos e nenhum defeito conhecido como Crítico / Severidade 1 está no Status Aberto.
• Todos os defeitos de alta prioridade são identificados e corrigidos.
• A taxa de defeitos cai abaixo da taxa aceitável definida.
• Muito poucos defeitos de prioridade média estão abertos e têm uma solução alternativa em vigor.
• Muito poucos defeitos abertos de baixa prioridade que não afetam o uso do software.
• Todos os defeitos de alta prioridade são testados novamente e fechados e os cenários de regressão correspondentes são executados com êxito.

Cobertura de teste:

• A cobertura do teste deve ser alcançada em 95%.
• A taxa de aprovação do caso de teste deve ser 95%. Isso pode ser calculado por fórmula
  • (Número total de TCs aprovados / número total de TCs) * 100.
• Todos os casos de teste críticos são aprovados.
• 5% Os casos de teste podem falhar, mas os casos de teste com falha são de baixa prioridade.
• A cobertura funcional completa é alcançada.
• Todos os principais fluxos funcionais / de negócios são executados com sucesso com várias entradas e estão funcionando bem.

Prazos:

• Prazo do projeto ou prazo de término do teste foi atingido.

Documentos de teste:

• Todos os documentos / resultados de teste (exemplo - Relatório de resumo de teste ) são preparados, revisados ​​e publicados.

Orçamento:

• O orçamento de teste completo está esgotado.

Reuniões “Vai / Não Vai”:

• ' Go / No Go ' encontro foi conduzido com as partes interessadas e é decidido se o projeto deve ir para a produção ou não.

Conclusão:

Vamos simplificar no final.

Responda às perguntas com um simples Sim ou Não.

Se obtiver a maioria das respostas sim, isso significa que você pode parar o teste neste momento. Se a maioria das respostas for Não, isso significa que você deve verificar o que está faltando no teste e isso pode ajudá-lo a encontrar um defeito de produção escapando :)

• Todos os casos de teste são executados pelo menos uma vez?
• A taxa de aprovação do caso de teste está definida?
• A cobertura completa do teste foi alcançada?
• Todos os fluxos funcionais / de negócios são executados pelo menos uma vez?
• A contagem de defeitos decidida foi atingida?
• Todos os defeitos principais de alta prioridade foram corrigidos e encerrados?
• Todos os defeitos foram retestados e fechados?
• A regressão foi feita para todos os defeitos abertos?
• Você esgotou o orçamento de teste?
• A hora de término do teste chegou?
• Todos os resultados de teste são revisados ​​e publicados?

Sobre o autor: Este é um artigo convidado de Renuka K. Ela tem mais de 11 anos de experiência em testes de software.

como abrir um arquivo dat no windows

Espero que este artigo tenha sido útil para você. Eu também gostaria de ouvir sua opinião / comentários sobre o assunto.

Bons testes!

Leitura recomendada

• Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
• Trabalho de assistente de controle de qualidade de teste de software
• Programa do curso de teste de software - Plano de treinamento detalhado do curso online
• Curso de Teste de Software: Qual Instituto de Teste de Software devo ingressar?
• Escolhendo o teste de software como sua carreira
• Trabalho de freelancer de redator de conteúdo técnico de teste de software
• Algumas perguntas interessantes da entrevista de teste de software
• Comentários e análises do curso de teste de software