Teste de fumaça versus teste de sanidade: diferença com exemplos

smoke testing vs sanity testing

Explore as diferenças entre o teste de fumaça e o teste de sanidade em detalhes com exemplos:

Neste tutorial, aprenderemos o que é Sanity Testing e Smoke Testing in Software Testing. Também aprenderemos as principais diferenças entre os testes de Sanidade e Fumaça com exemplos simples.

Na maioria das vezes, ficamos confusos entre o significado de Teste de Sanidade e Teste de Fumaça. Em primeiro lugar, esses dois testes são muito “ diferente ”E são realizados durante diferentes estágios de um ciclo de teste.

O que você aprenderá:

• Teste de Sanidade
• Minha experiência
• Teste de Sanidade vs. Teste de Regressão
• Estratégia para teste de aplicativos móveis
• Medidas de precaução
• Teste de Fumaça
• Exemplos de teste de fumaça
  • # 1) Teste de Aceitação
  • # 2) Teste de integração
  • # 3) Teste de sistema
• Importância na metodologia SCRUM
• Teste de fumaça vs. teste de aceitação de construção
• Ciclo de Teste de Fumaça
• Quem deve realizar o teste de fumaça?
• Por que devemos automatizar os testes de fumaça?
• Vantagens e desvantagens
• Diferença entre testes de fumaça e sanidade
  • TESTE DE FUMO
  • TESTE DE SANIDADE
• Leitura recomendada

Teste de Sanidade

O teste de sanidade é feito quando, como um QA, não temos tempo suficiente para executar todos os casos de teste, seja Teste funcional , IU, SO ou teste de navegador.

Portanto, eu definiria,

“O Teste de Sanidade como uma execução de teste que é feita para tocar cada implementação e seu impacto, mas não completamente ou em profundidade, pode incluir testes funcionais, de IU, de versão etc., dependendo da implementação e seu impacto.”

Todos nós não caímos em uma situação em que temos que assinar em um ou dois dias, mas a compilação para teste ainda não foi lançada?

ferramentas para testar serviços da web repousantes

Sim, aposto que você também deve ter enfrentado essa situação pelo menos uma vez em sua experiência de teste de software. Bem, eu enfrentei muito isso porque meu (s) projeto (s) eram em sua maioria ágeis e às vezes éramos solicitados a entregá-los no mesmo dia. Ops, como posso testar e liberar a compilação em algumas horas?

Eu costumava enlouquecer às vezes porque, mesmo que fosse uma pequena funcionalidade, a implicação poderia ser tremenda. E, como cereja no topo do bolo, os clientes às vezes simplesmente se recusam a dar tempo extra. Como eu poderia concluir todo o teste em algumas horas, verificar todas as funcionalidades, Insetos e liberar?

A resposta para todos esses problemas era muito simples, ou seja, nada além de usar Estratégia de teste de sanidade.

Quando fazemos este teste para um módulo ou funcionalidade ou um sistema completo, o Casos de teste para execução são selecionados de modo que tocarão todos os bits e peças importantes do mesmo, ou seja, testes amplos, mas superficiais.

Às vezes, o teste é feito até aleatoriamente, sem casos de teste. Mas lembre-se, O teste de sanidade deve ser feito apenas quando você estiver com pouco tempo, nunca use isso para seus lançamentos regulares. Teoricamente, este teste é um subconjunto de Teste de Regressão .

Minha experiência

Dos meus mais de 8 anos de carreira em Teste de Software, por 3 anos trabalhei em Metodologia ágil Sim, e essa foi a época em que usei principalmente um teste de sanidade.

Todos os grandes lançamentos foram planejados e executados de forma sistemática, mas às vezes, pequenos lançamentos foram solicitados a serem entregues o mais rápido possível. Não tivemos muito tempo para documentar os casos de teste, executar, fazer a documentação do bug, fazer a regressão e acompanhar todo o processo.

Portanto, a seguir estão alguns dos principais indicadores que costumava seguir nessas situações:

# 1) Sente-se com o gerente e a equipe de desenvolvimento quando eles estiverem discutindo a implementação porque eles têm que trabalhar rápido e, portanto, não podemos esperar que eles nos expliquem separadamente.

Isso também ajudaria você a ter uma ideia sobre o que eles vão implementar, qual área isso afetará, etc., isso é uma coisa muito importante a fazer porque às vezes simplesmente não percebemos as implicações e se existe alguma funcionalidade existente vai ser dificultado (na pior das hipóteses).

#dois) Como você está com pouco tempo, quando a equipe de desenvolvimento estiver trabalhando na implementação, você pode anotar os casos de teste em ferramentas como o Evernote, etc. Mas certifique-se de escrevê-los em algum lugar para que possa adicioná-los mais tarde a ferramenta de caso de teste.

# 3) Mantenha seu testbed pronto de acordo com a implementação e se você sentir que há sinais de alerta, como a criação de alguns dados específicos, se um testbed demorar (e é um teste importante para o lançamento), aumente esses sinalizadores imediatamente e informe seu gerente ou PO sobre o obstáculo.

Só porque o cliente quer o mais rápido possível, não significa que um controle de qualidade será lançado, mesmo que seja testado pela metade.

# 4) Faça um acordo com sua equipe e gerente de que devido à falta de tempo você só comunicará os bugs para a equipe de desenvolvimento e o processo formal de adição, marcando os bugs para diferentes estágios na ferramenta de rastreamento de bugs será feito posteriormente para economizar tempo .

# 5) Quando a equipe de desenvolvimento estiver testando em seu final, tente emparelhar com eles (chamado de emparelhamento dev-QA) e fazer uma rodada básica em sua configuração, isso ajudará a evitar o vaivém da construção se a implementação básica estiver falhando .

# 6) Agora que você tem a construção, teste as regras de negócios e todos os casos de uso primeiro. Você pode manter testes como validação de um campo, navegação, etc. para depois.

# 7) Quaisquer bugs que encontrar, anote todos eles e tente relatá-los juntos aos desenvolvedores, em vez de relatar individualmente, porque será fácil para eles trabalharem em um grupo.

# 8) Se você tem um requisito para o geral Teste de performance ou teste de estresse ou carga, certifique-se de ter uma estrutura de automação adequada para o mesmo. Porque é quase impossível testá-los manualmente com um teste de sanidade.

# 9) Esta é a parte mais importante e, de fato, a última etapa de sua estratégia de teste de sanidade - “Quando você redigir o e-mail de lançamento ou o documento, mencione todos os casos de teste que executou, os bugs encontrados com um marcador de status e se algo foi deixado não testado mencioná-lo com as razões ' Tente escrever uma história nítida sobre o seu teste, que transmitirá a todos sobre o que foi testado, verificado e o que não foi.

Eu segui isso religiosamente quando estava usando este teste.

Deixe-me compartilhar minha própria experiência:

# 1) Estávamos trabalhando em um site e ele costumava abrir anúncios pop-up com base nas palavras-chave. Os anunciantes costumavam fazer o lance para determinadas palavras-chave que tinham uma tela projetada para as mesmas. O valor do lance padrão costumava ser mostrado como $ 0,25, que o licitante poderia até mesmo alterar.

Havia mais um local onde esse lance padrão costumava ser exibido e poderia ser alterado para outro valor também. O cliente veio com uma solicitação para alterar o valor padrão de $ 0,25 para $ 0,5, mas ele mencionou apenas a tela óbvia.

Durante nossa discussão de brainstorming, esquecemos (?) Sobre esta outra tela porque ela não era muito usada para esse propósito. Mas durante o teste, quando executei o caso básico do lance de $ 0,5 e verifiquei de ponta a ponta, descobri que o cronjob para o mesmo estava falhando porque em um lugar estava encontrando $ 0,25.

Eu relatei isso para minha equipe e fizemos a alteração e a entregamos com sucesso no mesmo dia.

#dois) No mesmo projeto (mencionado acima), fomos solicitados a adicionar um pequeno campo de texto para notas / comentários para licitações. Foi uma implementação muito simples e nos comprometemos a entregá-la no mesmo dia.

Portanto, conforme mencionado acima, testei todas as regras de negócios e casos de uso em torno dele e, quando fiz alguns testes de validação, descobri que, ao inserir uma combinação de caracteres especiais como, a página travou.

Nós pensamos sobre isso e descobrimos que os proponentes reais não usarão, em nenhum caso, tais combinações. Por isso, o lançamos com uma nota bem redigida sobre o assunto. O cliente aceitou isso como um bug, mas concordou em implementá-lo mais tarde, pois era um bug grave, mas não anterior.

# 3) Recentemente, estava trabalhando em um projeto de aplicativo móvel e tínhamos a necessidade de atualizar o tempo de entrega mostrado no aplicativo de acordo com o fuso horário. Não era apenas para ser testado no aplicativo, mas também para o serviço da web.

Enquanto a equipe de desenvolvimento trabalhava na implementação, criei os scripts de automação para o teste de serviço da web e os scripts de banco de dados para alterar o fuso horário do item de entrega. Isso salvou meus esforços e pudemos alcançar melhores resultados em um curto período.

Teste de Sanidade vs. Teste de Regressão

A seguir estão algumas diferenças entre os dois:

Estratégia para teste de aplicativos móveis

Você deve estar se perguntando por que estou mencionando especificamente sobre aplicativos móveis aqui?

A razão é que o sistema operacional e a versão do navegador para aplicativos da web ou desktop não variam muito e, especialmente, os tamanhos de tela são padrão. Mas com aplicativos móveis, o tamanho da tela, a rede móvel, as versões do sistema operacional, etc. afetam a estabilidade, a aparência e, em suma, o sucesso de seu aplicativo móvel.

Portanto, uma formulação de estratégia torna-se crítica quando você está realizando este teste em um aplicativo móvel, porque uma falha pode colocar você em grandes problemas. O teste deve ser feito de forma inteligente e com cautela também.

A seguir estão algumas dicas para ajudá-lo a realizar este teste com sucesso em um 'aplicativo móvel':

# 1) Em primeiro lugar, analise o impacto da versão do SO na implementação com sua equipe.

Tente encontrar respostas para perguntas como, o comportamento será diferente entre as versões? A implementação funcionará na versão mais baixa com suporte ou não? Haverá problemas de desempenho para a implementação de versões? Existe algum recurso específico do sistema operacional que pode afetar o comportamento da implementação? etc.

#dois) Na observação acima, analise os modelos de telefone também, ou seja, há algum recurso do telefone que terá impacto na implementação? A implementação de mudança de comportamento com GPS? O comportamento de implementação está mudando com a câmera do telefone? etc. Se você achar que não há impacto, evite testar em diferentes modelos de telefone.

# 3) A menos que haja alguma mudança de IU para a implementação, eu recomendaria manter o teste de IU com a menor prioridade, você pode informar a equipe (se quiser) que a IU não será testada.

# 4) Para economizar seu tempo, evite testar em redes boas porque é óbvio que a implementação funcionará conforme o esperado em uma rede forte. Eu recomendaria começar com testes em uma rede 4G ou 3G.

# 5) Este teste deve ser feito em menos tempo, mas certifique-se de fazer pelo menos um teste de campo, a menos que seja uma mera alteração da IU.

# 6) Se você precisar testar uma matriz de sistemas operacionais diferentes e suas versões, eu sugiro que você faça isso de uma forma inteligente. Por exemplo, escolha os pares de versão de SO mais baixo, médio e mais recente para teste. Você pode mencionar no documento de lançamento que nem todas as combinações são testadas.

# 7) Em uma linha semelhante, para teste de sanidade de implementação de IU, use tamanhos de tela pequenos, médios e grandes para economizar tempo. Você também pode usar um simulador e emulador.

Medidas de precaução

O Teste de Sanidade é executado quando você está com pouco tempo e, portanto, não é possível executar todos os casos de teste e, o mais importante, você não tem tempo suficiente para planejar seus testes. Para evitar os jogos de culpas, é melhor tomar medidas de precaução.

Nesses casos, a falta de comunicação escrita, documentação de teste e omissões são bastante comuns.

Para garantir que você não seja vítima disso, certifique-se de que:

• Nunca aceite uma construção para teste até que você não receba um requisito por escrito compartilhado pelo cliente. Acontece que os clientes comunicam mudanças ou novas implementações verbalmente ou em chat ou uma linha simples em um e-mail e esperam que tratemos isso como um requisito. Obrigue seu cliente a fornecer alguns pontos de funcionalidade básicos e critérios de aceitação.
• Sempre faça anotações grosseiras de seus casos de teste e bugs, se você não tiver tempo suficiente para escrevê-los de forma organizada. Nunca deixe esses sem documentos. Se houver algum tempo, compartilhe com seu líder ou equipe para que, se algo estiver faltando, eles possam apontar facilmente.
• Se você e sua equipe têm pouco tempo, certifique-se de que os bugs sejam marcados no estado apropriado em um e-mail. Você pode enviar por e-mail a lista completa de bugs para a equipe e fazer os desenvolvedores marcá-los de forma adequada. Sempre mantenha a bola no campo do outro.
• Se você tem Estrutura de automação pronto, use isso e evite fazer Teste Manual , assim em menos tempo você pode cobrir mais.
• Evite o cenário de “lançamento em 1 hora” a menos que você tenha 100% de certeza de que será capaz de entregar.
• Por último, mas não menos importante, como mencionado acima, redija um e-mail de lançamento detalhado comunicando o que foi testado, o que foi deixado de fora, razões, riscos, quais bugs foram resolvidos, o que foi ‘Posteriormente’ etc.

Como um QA, você deve julgar qual é a parte mais importante da implementação que precisa ser testada e quais são as partes que podem ser deixadas de fora ou testadas de forma básica.

Mesmo em um curto espaço de tempo, planeje uma estratégia sobre como você deseja fazer e será capaz de alcançar o melhor no prazo determinado.

Teste de Fumaça

O Smoke Testing não é um teste exaustivo, mas é um grupo de testes que são executados para verificar se as funcionalidades básicas de uma determinada construção estão funcionando bem como o esperado ou não. Este é e deve ser sempre o primeiro teste a ser feito em qualquer 'nova' construção.

Quando a equipe de desenvolvimento libera um build para o QA para teste, obviamente não é possível testar o build inteiro e verificar imediatamente se alguma das implementações está apresentando bugs ou se alguma funcionalidade de trabalho está quebrada.

Diante disso, como um controle de qualidade se certifica de que as funcionalidades básicas estão funcionando bem?

A resposta para isso será realizar um Teste de Fumaça .

Uma vez que os testes são marcados como testes de fumaça (no conjunto de testes) aprovados, somente então a construção é aceita pelo QA para testes aprofundados e / ou regressão. Se algum dos testes de fumaça falhar, o build é rejeitado e a equipe de desenvolvimento precisa corrigir o problema e lançar um novo build para teste.

Teoricamente, o teste de fumaça é definido como um teste de nível de superfície para certificar que o build fornecido pela equipe de desenvolvimento para a equipe de QA está pronto para testes adicionais. Este teste também é executado pela equipe de desenvolvimento antes de liberar a compilação para a equipe de QA.

Este teste é normalmente usado em Teste de Integração, Teste de Sistema e Teste de Nível de Aceitação. Nunca trate isso como um substituto para o teste completo de ponta a ponta real . Inclui testes positivos e negativos, dependendo da implementação do build.

Exemplos de teste de fumaça

Este teste é normalmente usado para integração, aceitação e Teste de Sistema .

Em minha carreira como QA, sempre aceitei uma construção somente depois de realizar um teste de fumaça. Então, vamos entender o que é um teste de fumaça da perspectiva de todos esses três testes, com alguns exemplos.

# 1) Teste de Aceitação

Sempre que uma versão é lançada para o controle de qualidade, teste de fumaça na forma de um Teste de aceitação Deve ser feito.

Neste teste, o primeiro e mais importante teste de fumaça é verificar a funcionalidade básica esperada da implementação. Assim, você deve verificar todas as implementações para aquele build específico.

Vamos tomar os seguintes exemplos como implementações feitas em uma construção para entender os testes de fumaça para aqueles:

• Implementada a funcionalidade de login para permitir que os drivers registrados façam login com êxito.
• Implementada a funcionalidade do painel para mostrar as rotas que um motorista deve executar hoje.
• Implementada a funcionalidade para mostrar uma mensagem apropriada se nenhuma rota existir para um determinado dia.

Na construção acima, no nível de aceitação, o teste de fumaça significará verificar se as três implementações básicas estão funcionando bem. Se algum desses três estiver quebrado, o controle de qualidade deve rejeitar a compilação.

# 2) Teste de integração

Esse teste geralmente é feito quando os módulos individuais são implementados e testados. No Teste de integração nível, este teste é executado para garantir que toda a integração básica e funcionalidades ponta a ponta estão funcionando bem como esperado.

Pode ser a integração de dois módulos ou todos os módulos juntos, portanto, a complexidade do teste de fumaça irá variar dependendo do nível de integração.

Vamos considerar os seguintes exemplos de implementação de integração para este teste:

• Implementou a integração dos módulos de rota e paradas.
• Implementada a integração de atualização do status de chegada e refletir o mesmo na tela de paradas.
• Implementou a integração de pick up completo até os módulos de funcionalidade de entrega.

Nesta compilação, o teste de fumaça não apenas verificará essas três implementações básicas, mas para a terceira implementação, alguns casos verificarão a integração completa também. Ajuda muito descobrir os problemas que são introduzidos na integração e aqueles que passaram despercebidos pela equipe de desenvolvimento.

# 3) Teste de sistema

Como o próprio nome sugere, para o nível do sistema, o teste de fumaça inclui testes para os fluxos de trabalho mais importantes e comumente usados ​​do sistema. Isso é feito somente depois que o sistema completo está pronto e testado, e este teste para o nível do sistema pode ser referido como teste de fumaça antes do teste de regressão também.

Antes de iniciar a regressão do sistema completo, os recursos básicos de ponta a ponta são testados como parte do teste de fumaça. O conjunto de testes de fumaça para o sistema completo compreende casos de teste de ponta a ponta que os usuários finais usarão com muita frequência.

Isso geralmente é feito com a ajuda de ferramentas de automação.

Importância na metodologia SCRUM

Hoje em dia, os projetos dificilmente seguem a metodologia em cascata na implementação de projetos, principalmente todos os projetos seguem Agile e SCRUM só. Comparado ao método tradicional em cascata, o Smoke Testing tem grande consideração em SCRUM e Agile.

Trabalhei 4 anos no SCRUM . E como sabemos que no SCRUM, os sprints são de menor duração e por isso é de extrema importância fazer este teste, para que as compilações com falha possam ser imediatamente relatadas à equipe de desenvolvimento e corrigidas também.

A seguir estão alguns remover sobre a importância deste teste no SCRUM:

• Fora do sprint de quinze dias, o intervalo é alocado para o QA, mas às vezes as compilações para o QA são atrasadas.
• Em sprints, é melhor para a equipe que os problemas sejam relatados em um estágio inicial.
• Cada história tem um conjunto de critérios de aceitação, portanto, testar os primeiros 2-3 critérios de aceitação é igual a testar essa funcionalidade. Os clientes rejeitam a entrega se um único critério estiver falhando.
• Imaginem o que acontecerá se em 2 dias a equipe de desenvolvimento entregou a você a compilação e apenas 3 dias restantes para a demonstração e você se deparar com uma falha de funcionalidade básica.
• Em média, um sprint tem histórias que variam de 5 a 10, portanto, quando a construção é fornecida, é importante certificar-se de que cada história seja implementada conforme o esperado antes de aceitar a construção no teste.
• Quando o sistema completo deve ser testado e regredido, um sprint é dedicado à atividade. Quinze dias talvez um pouco menos para testar todo o sistema, por isso é muito importante verificar as funcionalidades mais básicas antes de iniciar a regressão.

Teste de fumaça vs. teste de aceitação de construção

O Smoke Testing está diretamente relacionado ao Build Acceptance Testing (BAT).

No BAT, fazemos o mesmo teste - para verificar se a construção não falhou e se o sistema está funcionando bem ou não. Às vezes, acontece que, quando uma construção é criada, alguns problemas são introduzidos e, quando é entregue, a construção não funciona para o controle de qualidade.

Eu diria que o BAT é parte de uma verificação temporária porque, se o sistema estiver falhando, como você, como um QA, pode aceitar a compilação para teste? Não apenas as funcionalidades, o próprio sistema tem que funcionar antes que o controle de qualidade continue com os testes detalhados.

Ciclo de Teste de Fumaça

O fluxograma a seguir explica o Ciclo de Teste de Fumaça.

Depois que um build é implantado em um QA, o ciclo básico seguido é que, se o teste de fumaça for aprovado, o build será aceito pela equipe de QA para testes adicionais, mas se falhar, o build é rejeitado até que os problemas relatados sejam corrigidos.

Ciclo de Teste

Quem deve realizar o teste de fumaça?

Nem toda a equipe está envolvida neste tipo de teste para evitar o desperdício de tempo de todos os QAs.

O Smoke Testing é idealmente realizado pelo líder de QA, que decide com base no resultado se deve passar o build para a equipe para testes adicionais ou rejeitá-lo. Ou, na ausência do líder, os próprios QAs também podem realizar esse teste.

Às vezes, quando o projeto é de grande escala, um grupo de controle de qualidade também pode realizar esse teste para verificar se há obstáculos. Mas não é assim no caso do SCRUM porque o SCRUM é uma estrutura plana sem Leads ou Gestores e cada testador tem suas próprias responsabilidades em relação às suas histórias.

Portanto, os QAs individuais realizam esse teste para as histórias que possuem.

Por que devemos automatizar os testes de fumaça?

Este teste é o primeiro teste a ser feito em um build lançado pela (s) equipe (s) de desenvolvimento. Com base nos resultados desse teste, testes adicionais são realizados (ou a construção é rejeitada).

fig_cropper.swf como abrir

A melhor maneira de fazer esse teste é usar uma ferramenta de automação e programar o smoke suite para ser executado quando um novo build for criado. Você pode estar pensando por que eu deveria “Automatizar o conjunto de testes de fumaça”?

Vejamos o seguinte caso:

Digamos que você esteja a uma semana de seu lançamento e de um total de 500 casos de teste, sua suíte de teste de fumaça compreende de 80-90. Se você começar a executar todos esses casos de teste 80-90 manualmente, imagine quanto tempo você levará? Acho que 4-5 dias (mínimo).

Mas se você usar automação e criar scripts para executar todos esses casos de teste de 80 a 90, o ideal é que eles sejam executados em 2 a 3 horas e você terá os resultados com você instantaneamente. Isso não economizou seu precioso tempo e deu a você os resultados sobre a integração com muito menos tempo?

5 anos atrás, eu estava testando um aplicativo de projeção financeira, que pegava dados sobre seu salário, poupança, etc., e projetava seus impostos, economias, lucros dependendo das regras financeiras. Junto com isso, tivemos customização para países que dependem do país e suas regras tributárias costumavam mudar (no código).

Para este projeto, eu tinha 800 casos de teste e 250 eram casos de teste de fumaça. Com o uso de Selenium, podemos facilmente automatizar e obter os resultados desses 250 casos de teste em 3-4 horas. Isso não apenas economizou nosso tempo, mas nos mostrou o mais rápido possível sobre os obstáculos.

Portanto, a menos que seja impossível automatizar, leve a ajuda da automação para este teste.

Vantagens e desvantagens

Vejamos primeiro as vantagens, pois ele tem muito a oferecer em comparação com suas poucas desvantagens.

Vantagens:

• Fácil de executar.
• Reduz o risco.
• Os defeitos são identificados em um estágio muito inicial.
• Economiza esforços, tempo e dinheiro.
• É executado rapidamente se for automatizado.
• Menores riscos e problemas de integração.
• Melhora a qualidade geral do sistema.

Desvantagens:

• Este teste não é igual ou um substituto para o teste funcional completo.
• Mesmo depois que o teste de fumaça for aprovado, você poderá encontrar bugs impeditivos.
• Esse tipo de teste é mais adequado se você puder automatizar, caso contrário, muito tempo é gasto na execução manual dos casos de teste, especialmente em projetos de grande escala com cerca de 700-800 casos de teste.

O Smoke Testing deve definitivamente ser feito em cada build, pois aponta as principais falhas e obstáculos em um estágio muito inicial. Isso se aplica não só a novas funcionalidades, mas também à integração de módulos, correção de problemas e improvisação. É um processo muito simples de realizar e obter o resultado correto.

Este teste pode ser tratado como o ponto de entrada para um Teste Funcional completo de funcionalidade ou sistema (como um todo). Mas antes disso, a equipe de QA deve ser muito clara sobre quais testes devem ser feitos como testes de fumaça . Este teste pode minimizar os esforços, economizar tempo e melhorar a qualidade do sistema. Ele ocupa um lugar muito importante em sprints, pois o tempo em sprints é menor.

Este teste pode ser feito manualmente e também com a ajuda de ferramentas de automação. Mas a maneira melhor e preferida é usar ferramentas de automação para economizar tempo.

Diferença entre testes de fumaça e sanidade

Na maioria das vezes, ficamos confusos entre o significado de Teste de Sanidade e Teste de Fumaça. Em primeiro lugar, esses dois testes são muito “ diferente ”E realizado durante diferentes estágios de um ciclo de teste.

A seguir está uma representação esquemática de suas diferenças:

TESTE DE FUMO

• Este teste teve origem no hardware prática de teste de ligar uma nova peça de hardware pela primeira vez e considerá-la um sucesso se não pegar fogo e fumaça. Na indústria de software, esse teste é uma abordagem superficial e ampla, em que todas as áreas do aplicativo são testadas, sem se aprofundar muito.
• Um teste de fumaça é programado, usando um conjunto escrito de testes ou um teste automatizado
• Um teste de fumaça é projetado para tocar todas as partes do aplicativo de forma superficial. É raso e amplo.
• Esse teste é realizado para garantir se as funções mais importantes de um programa estão funcionando, mas sem se preocupar com os detalhes mais sutis. (Como verificação de compilação).
• Este teste é uma verificação de integridade normal para a construção de um aplicativo antes de levá-lo para um teste aprofundado.

TESTE DE SANIDADE

• Um teste de sanidade é um teste de regressão estreito que se concentra em uma ou algumas áreas de funcionalidade. O Teste de Sanidade é geralmente estreito e profundo.
• Este teste geralmente não tem script.
• Este teste é usado para determinar se uma pequena seção do aplicativo ainda está funcionando após uma pequena alteração.
• Este teste é um teste superficial, é realizado sempre que um teste superficial é suficiente para provar que o aplicativo está funcionando de acordo com as especificações. Este nível de teste é um subconjunto do teste de regressão.
• Isso é para verificar se os requisitos são atendidos ou não, verificando todos os recursos primeiro.

Espero que você tenha esclarecido as diferenças entre esses dois tipos de teste de software vastos e importantes. Sinta-se à vontade para compartilhar suas idéias na seção de comentários abaixo !!

Leitura recomendada

• Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
• Diferença entre Desktop, Teste de Servidor Cliente e Teste da Web
• Teste Funcional Vs Teste Não Funcional
• Download do e-book do Testing Primer
• Teste Alfa e Teste Beta (um guia completo)
• Guia de teste de portabilidade com exemplos práticos
• Tipos de teste de software: diferentes tipos de teste com detalhes
• Teste funcional versus teste de desempenho: deve ser feito simultaneamente?