Como escrever casos de teste: o guia definitivo com exemplos

how write test cases

Neste tutorial prático aprofundado sobre como escrever casos de teste, cobri os detalhes do que é um caso de teste, sua definição padrão e técnicas de design de caso de teste.

O que é um caso de teste?

Um caso de teste possui componentes que descrevem a entrada, a ação e uma resposta esperada, a fim de determinar se um recurso de um aplicativo está funcionando corretamente.

Um caso de teste é um conjunto de instruções sobre “COMO” para validar um determinado objetivo / alvo de teste, que quando seguido nos dirá se o comportamento esperado do sistema é satisfeito ou não.

Lista de tutoriais abrangidos nesta série de escrita de casos de teste:

Como escrever:

Tutorial nº 1: O que é um caso de teste e como escrever casos de teste (este tutorial)
Tutorial # 2: Modelo de caso de teste de amostra com exemplos (download) (leitura obrigatória)
Tutorial nº 3: Escrevendo Casos de Teste do Documento SRS
Tutorial nº 4: Como escrever casos de teste para um determinado cenário
Tutorial # 5: Como se preparar para escrever casos de teste
Tutorial # 6: Como escrever casos de teste negativos

Exemplos:

Tutorial nº 7: Mais de 180 casos de teste de amostra para aplicativos da Web e de desktop
Tutorial # 8: Mais de 100 cenários de teste prontos para execução (lista de verificação)

Técnicas de escrita:

Tutorial # 9: Gráfico de causa e efeito - Técnica de escrita dinâmica de casos de teste
Tutorial # 10: Técnica de teste de transição de estado
Tutorial nº 11: Técnica de teste de matriz ortogonal
Tutorial # 12: Técnica de Adivinhação de Erros
Tutorial # 13: Tabela de validação de campo (FVT) Técnica de design de teste

Caso de teste versus cenários de teste:

Tutorial # 14: Casos de teste x cenários de teste
Tutorial # 15: Diferença entre plano de teste, estratégia de teste e caso de teste

Automação:

Tutorial # 16: Como selecionar casos de teste corretos para testes de automação
Tutorial # 17: Como traduzir casos de teste manuais em scripts de automação

Ferramentas de gerenciamento de teste:

Tutorial # 18: Melhores ferramentas de gerenciamento de teste
Tutorial # 19: TestLink para gerenciamento de casos de teste
Tutorial # 20: Criação e gerenciamento de casos de teste usando o HP Quality Center
Tutorial # 21: Executando Casos de Teste Usando ALM / QC

Casos específicos de domínio:

Tutorial # 22: Casos de teste para aplicativo ERP
Tutorial # 23: Casos de teste de aplicativos JAVA
Tutorial nº 24: Análise de valor limite e particionamento de equivalência

Vamos continuar com o primeiro tutorial desta série.

Ferramentas recomendadas:

Antes de continuar com o processo de escrita do caso de teste, recomendamos o download desta ferramenta de gerenciamento de caso de teste. Isso facilitará o processo de escrita de casos de teste mencionado neste tutorial:

# 1) TestRail

=> Baixe a ferramenta de gerenciamento de caso de teste TestRail

# 2) TestMonitor

Gerenciamento de teste online de nível superior. Revolucionário fácil.

TestMonitor é uma ferramenta de gerenciamento de teste ponta a ponta para cada organização. Uma abordagem simples e intuitiva para testes. Esteja você implementando um software corporativo, precise de controle de qualidade, construindo um aplicativo de qualidade ou apenas precise de uma ajuda em seu projeto de teste, o TestMonitor tem o que você precisa.

=> Visite o site do TestMonitor

O que você aprenderá:

• O que é um caso de teste e como escrever casos de teste?
  • Por que escrevemos testes?
  • Como escrever casos de teste?
  • Formato básico de declaração de caso de teste
• Dicas para escrever testes
  • • # 1) Mantenha-o simples, mas não muito simples; torne-o complexo, mas não muito complexo:
    • # 2) Depois de documentar os casos de teste, revise uma vez como Testador:
    • # 3) Limite e facilite os testadores:
    • # 4) Seja um contribuidor:
    • # 5) Nunca se esqueça do usuário final:
• Como obter excelência na documentação de casos de teste
  • Dicas e truques úteis
    • # 1) Seu documento de teste está em boas condições?
    • # 2) Não se esqueça de cobrir os casos negativos
    • # 3) Ter etapas de teste atômico
    • # 4) Priorizar os testes
    • # 5) Sequência é importante
    • # 6) Adicionar carimbo de data / hora e o nome do testador aos comentários
    • # 7) Incluir detalhes do navegador
    • # 8) Mantenha duas folhas separadas - ‘Bugs’ e ‘Resumo’ no Documento
• Como NÃO escrever testes
  • 3 problemas mais comuns em casos de teste
    • # 1) Etapas compostas
    • # 2) O comportamento do aplicativo é considerado o comportamento esperado
    • # 3) Condições múltiplas em um caso
• Como melhorar a eficiência do caso de teste
  • Coleção de documentos para escrita de teste
  • Exemplo real
  • Documento de Caso de Teste
  • Coleta de dados de teste
• Importância da padronização dos casos de teste
  • Razões para reutilizar casos de teste
  • O que é um teste padrão em testes da Web?
  • Conclusão
  • Leitura recomendada

O que é um caso de teste e como escrever casos de teste?

Escrever casos eficazes é uma habilidade. E você pode aprender com a experiência e o conhecimento do aplicativo em teste.

Para obter instruções básicas sobre como escrever testes, verifique o seguinte vídeo:

Os recursos acima devem nos fornecer os fundamentos do processo de escrita do teste.

Níveis do processo de escrita do teste:

• Nível 1: Neste nível, você escreverá o casos básicos da especificação disponível e documentação do usuário.
• Nível 2: Isto é o estágio prático em que os casos de gravação dependem do fluxo funcional e do sistema real do aplicativo.
• Nível 3: Esta é a fase em que você agrupará alguns casos e escreva um procedimento de teste . O procedimento de teste nada mais é do que um grupo de pequenos casos, talvez um máximo de 10.
• Nível 4: Automação do projeto. Isso irá minimizar a interação humana com o sistema e, portanto, o QA pode se concentrar nas funcionalidades atualmente atualizadas para testar, em vez de permanecer ocupado com os testes de regressão.

Por que escrevemos testes?

O objetivo básico de escrever casos é para validar a cobertura de teste de um aplicativo.

Se você estiver trabalhando em qualquer organização CMMi, os padrões de teste são seguidos mais de perto. Escrever casos traz algum tipo de padronização e minimiza a abordagem ad-hoc nos testes.

Como escrever casos de teste?

Campos:

• ID de caso de teste
• Unidade para testar: O que deve ser verificado?
• Premissas
• Dados de teste: Variáveis ​​e seus valores
• Passos a serem executados
• resultado esperado
• Resultado atual
• Aprovado / Reprovado
• Comentários

Formato básico de declaração de caso de teste

Verificar
Usando (nome da ferramenta, nome da tag, diálogo, etc)
Com (condições)
Para (o que é retornado, mostrado, demonstrado)

Verificar: Usado como a primeira palavra da declaração de teste.
Usando: Para identificar o que está sendo testado. Você pode usar ‘inserir’ ou ‘selecionar’ aqui em vez de usar, dependendo da situação.

Para qualquer aplicação, você precisa cobrir todos os tipos de testes como:

• Casos Funcionais
• Casos negativos
• Casos de valor limite

Ao escrever estes todos os seus Os TCs devem ser simples e fáceis de entender .

*************************************************

Dicas para escrever testes

Uma das atividades mais frequentes e principais de um Testador de Software (pessoa SQA / SQC) é escrever cenários e casos de teste.

Existem alguns fatores importantes e críticos relacionados a essa atividade principal. Vamos ter uma visão panorâmica desses fatores primeiro.

Fatores importantes envolvidos no processo de escrita:

a) Os TCs estão sujeitos a revisões e atualizações regulares:

Vivemos em um mundo em constante mudança e o mesmo vale para o software. As mudanças nos requisitos de software impactam diretamente os casos. Sempre que os requisitos são alterados, os TCs precisam ser atualizados.

No entanto, não é apenas a mudança no requisito que pode causar a revisão e atualização dos TCs. Durante a execução de TCs, muitas ideias surgem na mente e muitas subcondições de um único TC podem ser identificadas. Tudo isso causa uma atualização de TCs e, às vezes, leva até a adição de novos TCs.

Além disso, durante o teste de regressão, várias correções e / ou ondulações exigem TCs revisados ​​ou novos.

b) TCs são propensos a distribuição entre os testadores que irão executar estes:

Claro, dificilmente existe uma situação em que um único testador executa todos os TCs. Normalmente, existem vários testadores que testam diferentes módulos de um único aplicativo. Portanto, os TCs são divididos entre os testadores de acordo com suas áreas de propriedade do aplicativo em teste.

Alguns TCs relacionados à integração de aplicativos podem ser executados por vários testadores, enquanto os outros TCs podem ser executados apenas por um único testador.

c) TCs são propensos a agrupamento e lotes:

É normal e comum que TCs pertencentes a um único cenário de teste geralmente exijam sua execução em alguma sequência específica ou na forma de um grupo. Pode haver certos pré-requisitos de um TC que exijam a execução de outros TCs antes de operar a si mesmo.

Da mesma forma, de acordo com a lógica de negócios do AUT, um único TC pode contribuir para várias condições de teste e uma única condição de teste pode consistir em vários TCs.

d) Os TCs têm tendência à interdependência:

Esse também é um comportamento interessante e importante das CTs, denotando que podem ser interdependentes umas das outras. De aplicações de médio a grande porte com lógica de negócios complexa, essa tendência é mais visível.

A área mais clara de qualquer aplicação onde este comportamento pode definitivamente ser observado é a interoperabilidade entre diferentes módulos da mesma aplicação ou até mesmo diferentes. Em termos simples, onde quer que os diferentes módulos de um único aplicativo ou de vários aplicativos sejam interdependentes, o mesmo comportamento também se reflete nos TCs.

e) TCs são propensos a distribuição entre os desenvolvedores (especialmente em ambiente de desenvolvimento orientado a testes):

Um fato importante sobre os TCs é que eles não devem ser utilizados apenas pelos testadores. No caso normal, quando um bug está sendo corrigido pelos desenvolvedores, eles estão indiretamente usando o TC para corrigir o problema. Da mesma forma, se o desenvolvimento orientado por teste for seguido, os TCs serão usados ​​diretamente pelos desenvolvedores para construir sua lógica e cobrir todos os cenários em seu código que são endereçados pelos TCs.

Dicas para escrever testes eficazes:

Tendo os 5 fatores acima em mente, aqui estão algumas dicas para escrever TCs eficazes.

Vamos começar!!!

# 1) Mantenha-o simples, mas não muito simples; torne-o complexo, mas não muito complexo:

Esta afirmação parece um paradoxo. Mas, eu prometo que não é assim. Mantenha todas as etapas dos TCs atômicas e precisas. Mencione as etapas com a sequência correta e mapeamento correto para os resultados esperados. O caso de teste deve ser autoexplicativo e fácil de entender. Isso é o que quero dizer para tornar as coisas simples.

Agora, torná-lo um meio complexo de torná-lo integrado ao plano de teste e outros TCs. Consulte os outros TCs, artefatos relevantes, GUIs etc. onde e quando necessário. Mas, faça isso de forma equilibrada. Não faça um testador se mover para frente e para trás na pilha de documentos para completar um único cenário de teste.

Por outro lado, não deixe nem mesmo o testador documentar esses TCs de maneira muito compacta. Ao escrever TCs, lembre-se sempre de que você ou outra pessoa terá que revisá-los e atualizá-los.

# 2) Depois de documentar os casos de teste, revise uma vez como Testador:

Nunca pense que o trabalho está concluído depois de escrever o último TC do cenário de teste. Vá para o início e analise todos os TCs uma vez, mas não com a mentalidade de um redator de TC ou planejador de teste. Analise todos os TCs com a mente de um testador. Pense racionalmente e tente testar seus TCs.

Avalie todas as etapas e veja se você as mencionou de forma clara e compreensível e se os resultados esperados estão em harmonia com essas etapas.

Certifique-se de que o dados de teste especificado em TCs é viável não apenas para testadores reais, mas também está de acordo com o ambiente em tempo real. Certifique-se de que não haja conflito de dependência entre TCs e verifique se todas as referências a outros TCs / artefatos / GUIs são precisas. Caso contrário, os testadores podem ter grandes problemas.

# 3) Limite e facilite os testadores:

Não deixe os dados de teste nos testadores. Dê-lhes uma gama de entradas, especialmente onde os cálculos devem ser realizados ou o comportamento do aplicativo depende das entradas. Você pode deixá-los decidir os valores dos itens de dados de teste, mas nunca dar a eles a liberdade de escolher os próprios itens de dados de teste.

Porque, intencionalmente ou não, eles podem usar os mesmos dados de teste repetidamente e alguns dados de teste importantes podem ser ignorados durante a execução de TCs.

Mantenha os testadores à vontade organizando os TCs de acordo com as categorias de teste e as áreas relacionadas de um aplicativo. Claramente, instrua e mencione quais TCs são interdependentes e / ou em lote. Da mesma forma, indique explicitamente quais TCs são independentes e isolados para que o testador possa gerenciar sua atividade geral de acordo.

Neste ponto, você pode estar interessado em ler sobre a análise do valor limite, que é uma estratégia de design de caso de teste usada em testes de caixa preta. Clique aqui para saber mais sobre isso.

# 4) Seja um contribuidor:

Nunca aceite o FS ou o Documento de Design como eles são. Seu trabalho não é apenas percorrer o FS e identificar os cenários de teste. Por ser um recurso de QA, nunca hesite em contribuir com os negócios e dar sugestões se achar que algo pode ser melhorado no aplicativo.

Sugira aos desenvolvedores também, especialmente no ambiente de desenvolvimento orientado a TC. Sugira listas suspensas, controles de calendário, lista de seleção, botões de opção de grupo, mensagens mais significativas, avisos, avisos, melhorias relacionadas à usabilidade, etc.

Sendo um QA, não apenas teste, mas faça a diferença!

# 5) Nunca se esqueça do usuário final:

A parte interessada mais importante é o ‘Usuário final’ que finalmente usará o aplicativo. Portanto, nunca se esqueça dele em qualquer estágio da redação de TCs. Na verdade, o Usuário Final não deve ser ignorado em nenhum estágio do SDLC. No entanto, minha ênfase até agora está apenas relacionada ao meu tópico.

Portanto, durante a identificação de cenários de teste, nunca ignore aqueles casos que serão mais utilizados pelo usuário ou os casos que são críticos para o negócio mesmo que sejam usados ​​com menos frequência. Mantenha-se no lugar do usuário final, passe por todos os TCs e julgue o valor prático de executar todos os seus TCs documentados.

*************************************************

Como obter excelência na documentação de casos de teste

Sendo um testador de software, você certamente concordará comigo que criar um Documento de Teste perfeito é realmente uma tarefa desafiadora.

Sempre deixamos algum espaço para melhorias em nosso Documentação de caso de teste . Às vezes, não podemos fornecer 100% de cobertura de teste por meio dos TCs e, às vezes, o modelo de teste não está à altura ou não fornecemos boa legibilidade e clareza aos nossos testes.

Como um testador, sempre que você for solicitado a escrever a documentação do teste, não comece simplesmente de maneira ad-hoc. É muito importante entender o propósito de escrever casos de teste bem antes de trabalhar no processo de documentação.

Os testes devem ser sempre claros e lúcidos. Eles devem ser escritos de uma forma que ofereça ao testador facilidade para conduzir o teste completo, seguindo as etapas definidas em cada um dos testes.

Além disso, o documento do caso de teste deve conter quantos casos forem necessários para fornecer cobertura de teste . Por exemplo , você deve tentar cobrir o teste para todos os cenários possíveis que podem ocorrer em seu aplicativo de software.

Mantendo os pontos acima em mente, deixe-me levá-lo agora por um tour sobre Como Obter Excelência na Documentação de Teste.

Dicas e truques úteis

Aqui, vou fornecer algumas orientações úteis que podem ajudá-lo a se diferenciar dos outros em sua documentação de teste.

# 1) Seu documento de teste está em boas condições?

A maneira melhor e simples de organizar seu documento de teste é dividi-lo em várias seções úteis. Divida todo o teste em vários cenários de teste. Em seguida, divida cada cenário em vários testes. Finalmente, divida cada caso em várias etapas de teste.

Se você estiver usando o Excel, documente cada caso de teste em uma folha separada da pasta de trabalho, em que cada caso de teste descreve um fluxo de teste completo.

# 2) Não se esqueça de cobrir os casos negativos

Como um testador de software, você precisa pensar fora da caixa e desenhar todas as possibilidades que seu aplicativo encontra. Nós, como testadores, temos que verificar se qualquer tentativa não autêntica de entrar no software ou qualquer fluxo de dados inválidos no aplicativo deve ser interrompido e relatado.

Portanto, um caso negativo é tão importante quanto um caso positivo. Certifique-se de que para cada cenário que você tem dois casos de teste - um positivo e um negativo . O positivo deve cobrir o fluxo pretendido ou normal e o negativo deve cobrir o fluxo não intencional ou excepcional.

# 3) Ter etapas de teste atômico

Cada etapa do teste deve ser atômica. Não deve haver mais subetapas. Quanto mais simples e clara for uma etapa de teste, mais fácil será prosseguir com o teste.

# 4) Priorizar os testes

Freqüentemente, temos cronogramas rigorosos para terminar o teste de um aplicativo. Nesse caso, podemos deixar de testar algumas das funcionalidades e aspectos importantes do software. Para evitar isso, você deve marcar uma prioridade em cada teste ao documentá-lo.

Você pode usar qualquer codificação para definir a prioridade de um teste. Geralmente é melhor usar qualquer um dos 3 níveis, alto, médio e baixo , ou 1, 50 e 100. Portanto, quando você tem um cronograma estrito, deve primeiro concluir todos os testes de alta prioridade e depois passar para os testes de média e baixa prioridade.

Por exemplo - para um site de compras, verificar a negação de acesso para uma tentativa inválida de fazer login no aplicativo pode ser um caso de alta prioridade, verificar a exibição de produtos relevantes na tela do usuário pode ser um caso de prioridade média e verificar a cor do texto exibido em os botões da tela podem ser um teste de baixa prioridade.

# 5) Sequência é importante

Confirme se a sequência de etapas do teste está absolutamente correta. Uma sequência errada de etapas pode levar à confusão. De preferência, as etapas também devem definir toda a sequência, desde a entrada no aplicativo até a saída do aplicativo para um determinado cenário que está sendo testado.

# 6) Adicionar carimbo de data / hora e o nome do testador aos comentários

Pode haver um caso em que você está testando um aplicativo, alguém está fazendo modificações em paralelo no mesmo aplicativo ou alguém pode atualizar o aplicativo após a conclusão do teste. Isso leva a uma situação em que os resultados do teste podem variar com o tempo.

Portanto, é sempre melhor adicionar um carimbo de data / hora com o nome do testador nos comentários de teste para que um resultado de teste (aprovado ou reprovado) possa ser atribuído ao estado de um aplicativo naquele momento específico. Alternativamente, você pode ter um Data de Execução 'Coluna adicionada separadamente ao caso de teste que identificará explicitamente o carimbo de data / hora do teste.

# 7) Incluir detalhes do navegador

Como você sabe, se for um aplicativo da web, os resultados do teste podem ser diferentes com base no navegador em que o teste é executado. Para a facilidade de outros testadores, desenvolvedores ou quem está revisando o documento de teste, você deve adicionar o nome do navegador e a versão ao caso para que o defeito possa ser replicado facilmente.

# 8) Mantenha duas folhas separadas - ‘Bugs’ e ‘Resumo’ no Documento

Se você estiver documentando em um Excel, as duas primeiras planilhas da pasta de trabalho devem ser Resumo e Erros. A folha de resumo deve resumir o cenário de teste e a folha de Bugs deve listar todos os problemas encontrados durante o teste. A importância de adicionar essas duas folhas é que isso dará uma compreensão clara do teste para o leitor / usuário do documento.

Portanto, quando o tempo é restrito, essas duas folhas podem ser muito úteis para fornecer uma visão geral do teste.

O documento de teste deve fornecer a melhor cobertura de teste possível, excelente legibilidade e deve seguir um formato padrão.

Podemos alcançar a excelência na documentação de teste apenas mantendo algumas dicas essenciais em mente como a organização do documento de caso de teste, priorizando os TCs, tendo tudo na sequência adequada, incluindo todos os detalhes obrigatórios para executar um TC e fornecendo etapas de teste claras e lúcidas, etc. conforme discutido acima.

*************************************************

Como NÃO escrever testes

Passamos a maior parte do nosso tempo escrevendo, revisando, executando ou mantendo-os. É lamentável que os testes também sejam os mais sujeitos a erros. As diferenças de compreensão, práticas de teste da organização, falta de tempo etc. são alguns dos motivos pelos quais frequentemente vemos testes que deixam muito a desejar.

Existem muitos artigos em nosso site sobre este assunto, mas aqui veremos Como NÃO escrever casos de teste - algumas dicas que serão fundamentais na criação de testes diferenciados, de qualidade e eficazes.

Vamos continuar lendo e observe que essas dicas são para testadores novos e experientes.

3 problemas mais comuns em casos de teste

1. Etapas compostas
2. O comportamento do aplicativo é considerado o comportamento esperado
3. Múltiplas condições em um caso

Esses três devem estar na minha lista dos três principais problemas comuns no processo de redação de testes.

O que é interessante é que isso acontece com testadores novos e experientes e nós continuamos seguindo os mesmos processos falhos, sem nunca perceber que algumas medidas simples podem consertar as coisas facilmente.

Vamos começar e discutir cada um em detalhes:

# 1) Etapas compostas

Em primeiro lugar, o que é uma etapa composta?

Por exemplo, você está dando instruções do ponto A ao ponto B: se você disser que 'Vá para o lugar XYZ e depois para o ABC', isso não fará muito sentido, porque aqui nos encontramos pensando - 'Como faço chegar a XYZ em primeiro lugar ”- em vez de começar com“ Vire à esquerda daqui e siga 1 milha, depois vire à direita na Road. não 11 para chegar a XYZ ”pode obter melhores resultados.

As mesmas regras se aplicam aos testes e suas etapas também.

Por exemplo Estou escrevendo um teste para a Amazon.com - faça um pedido de qualquer produto.

A seguir estão as etapas do meu teste (Observação: estou apenas escrevendo as etapas e não todas as outras partes do teste como o resultado esperado, etc.)

para . Abra Amazon.com
b . Pesquise um produto inserindo a palavra-chave / nome do produto no campo “Pesquisar” na parte superior da tela.
c . Dos resultados da pesquisa exibidos, escolha o primeiro.
d . Clique em Adicionar ao carrinho na página de detalhes do produto.
é . Check-out e pagamento.
f . Verifique a página de confirmação do pedido.

Agora, você pode identificar qual delas é uma etapa composta? Right- Step (e)

Lembre-se de que os testes são sempre sobre “Como” testar, por isso é importante escrever as etapas exatas de “Como fazer check-out e pagar” em seu teste.

Portanto, o caso acima é mais eficaz quando escrito como abaixo:

para . Abra Amazon.com
b . Pesquise um produto inserindo a palavra-chave / nome do produto no campo “Pesquisar” na parte superior da tela.
c . Dos resultados da pesquisa exibidos, escolha o primeiro.
d . Clique em Adicionar ao carrinho na página de detalhes do produto.
é . Clique em Checkout na página do carrinho de compras.
f . Insira as informações de CC, envio e cobrança.
g . Clique em Checkout.
h . Verifique a página de confirmação do pedido.

Portanto, uma etapa composta é aquela que pode ser dividida em várias etapas individuais. Da próxima vez, quando escrevermos testes, vamos todos prestar atenção a esta parte e tenho certeza que você vai concordar comigo que fazemos isso com mais frequência do que imaginamos.

# 2) O comportamento do aplicativo é considerado o comportamento esperado

Mais e mais projetos precisam lidar com essa situação atualmente.

Falta de documentação, programação extrema, ciclos de desenvolvimento rápidos são alguns motivos que nos obrigam a confiar no aplicativo (uma versão mais antiga ou mais) para escrever os testes ou para basear o teste em si. Como sempre, esta é uma prática comprovadamente ruim - nem sempre realmente.

É inofensivo, desde que você mantenha a mente aberta e mantenha a expectativa de que o - “AUT pode ter falhas”. Só quando você pensa que não é, as coisas funcionam mal. Como sempre, vamos deixar os exemplos falarem.

Se a página a seguir for a que você está escrevendo / projetando as etapas de teste:

melhor site conversor de youtube para mp3

Caso 1:

Se as etapas do meu caso de teste forem as seguintes:

1. Lance o site de compras.
2. Clique em Envio e devolução - Resultado esperado: A página de envio e devolução é exibida com “Coloque sua informação aqui” e um botão “Continuar”.

Então, isso está incorreto.

Caso 2:

1. Lance o site de compras.
2. Clique em Envio e devolução.
3. Na caixa de texto ‘Digite o número do pedido’ presente nesta tela, digite o número do pedido
4. Clique em Continuar- Resultado esperado: Os detalhes do pedido relacionados ao envio e devoluções são exibidos.

O caso 2 é um caso de teste melhor porque, embora o aplicativo de referência se comporte incorretamente, nós o consideramos apenas como uma diretriz, fazemos pesquisas adicionais e escrevemos o comportamento esperado de acordo com a funcionalidade correta antecipada.

Conclusão: O aplicativo como referência é um atalho rápido, mas apresenta seus próprios perigos. Desde que sejamos cuidadosos e críticos, ele produzirá resultados surpreendentes.

# 3) Condições múltiplas em um caso

Mais uma vez, vamos aprender com Exemplo .

Dê uma olhada nas etapas de teste abaixo: A seguir estão as etapas de teste em um teste para uma função de login.

uma. Insira os detalhes válidos e clique em Enviar.
b. Deixe o campo Nome de usuário vazio. Clique em Enviar.
c. Deixe o campo de senha vazio e clique em Enviar.
d. Escolha um nome de usuário / senha já conectado e clique em Enviar.

O que deveria ser 4 casos diferentes é combinado em um. Você pode estar pensando: O que há de errado nisso? Está economizando muita documentação e o que posso fazer em 4, estou fazendo em 1- não é ótimo? Bem, não exatamente. Razões?

Leia:

• E se uma das condições falhar - temos que marcar todo o teste como ‘falhou’. Se marcarmos todo o caso como 'falhou', significa que todas as 4 condições não estão funcionando, o que não é realmente verdade.
• Os testes precisam ter um fluxo. Da pré-condição à etapa 1 e em todas as etapas. Se eu seguir esse caso, na etapa (a), se for bem-sucedido, serei logado na página, onde a opção “login” não está mais disponível. Então, quando eu chegar à etapa (b) - onde o testador irá inserir o nome de usuário? Você vê, o fluxo está quebrado.

Conseqüentemente, escrever testes modulares . Parece muito trabalhoso, mas tudo o que você precisa é separar as coisas e usar nossos melhores amigos Ctrl + C e Ctrl + V para trabalhar para nós. :)

*************************************************

Como melhorar a eficiência do caso de teste

Os testadores de software devem escrever seus testes do estágio anterior do ciclo de vida de desenvolvimento de software, melhor durante a fase de requisitos de software.

O gerente de teste ou gerente de QA deve coletar e preparar o máximo possível de documentos de acordo com a lista abaixo.

Coleção de documentos para escrita de teste

# 1) Documento de Requisitos do Usuário

É um documento que lista o processo de negócios, perfis de usuário, ambiente do usuário, interação com outros sistemas, substituição de sistemas existentes, requisitos funcionais, requisitos não funcionais, requisitos de licenciamento e instalação, requisitos de desempenho, requisitos de segurança, usabilidade e requisitos concorrentes, etc. .,

# 2) Documento de caso de uso de negócios

Este documento detalha o caso de uso cenário dos requisitos funcionais do ponto de vista do negócio. Este documento cobre os atores de negócios (ou sistema), objetivos, pré-condições, pós-condições, fluxo básico, fluxo alternativo, opções, exceções de todo e qualquer fluxo de negócios do sistema sob requisitos.

# 3) Documento de Requisitos Funcionais

Este documento detalha os requisitos funcionais de cada recurso para o sistema sob requisitos.

Normalmente, o documento de requisitos funcionais serve como um repositório comum para a equipe de desenvolvimento e teste, bem como para as partes interessadas do projeto, incluindo os clientes para os requisitos comprometidos (às vezes congelados), que devem ser tratados como o documento mais importante para qualquer desenvolvimento de software.

# 4) Plano de Projeto de Software (opcional)

Um documento que descreve os detalhes do projeto, objetivos, prioridades, marcos, atividades, estrutura organizacional, estratégia, monitoramento do progresso, análise de risco, premissas, dependências, restrições, requisitos de treinamento, responsabilidades do cliente, cronograma do projeto, etc.,

# 5) Plano de controle de qualidade / teste

Este documento detalha o sistema de gestão da qualidade, padrões de documentação, mecanismo de controle de mudanças, módulos críticos e funcionalidades, sistema de gestão de configuração, planos de teste, rastreamento de defeitos, critérios de aceitação, etc.

O Plano de teste documento é usado para identificar os recursos a serem testados, recursos a não serem testados, alocações da equipe de teste e sua interface, requisitos de recursos, cronograma de teste, escrita de teste, cobertura de teste, resultados de teste, pré-requisito para execução de teste, relatório de bug e rastreamento mecanismo, teste de métricas etc.,

Exemplo real

Vamos ver como escrever casos de teste de forma eficiente para uma tela de 'Login' familiar e simples, conforme a figura abaixo. O abordagem de teste será quase igual mesmo para telas complexas com mais informações e recursos essenciais.

# 1) A primeira abordagem para qualquer processo de caso de teste será obter um protótipo de tela (ou estruturas de arame) como acima, se disponível. Isso pode não estar disponível para algumas das funcionalidades e depende da criticidade de projetar um protótipo nos estágios iniciais de desenvolvimento.

Mas, se um SRS (Especificação de Requisitos de Software) documento está disponível para o projeto, a maioria dos protótipos de tela são desenvolvidos pela equipe do projeto. Este tipo de tela simplifica o trabalho do testador e aumenta a eficiência dos testes.

#dois) A seguir, o especificações de requisitos funcionais . Depende do processo de organização, estará disponível em um pacote de vários documentos.

Então, decida o melhor documento para escrever casos, pode ser um documento de requisitos do usuário ou especificações de requisitos funcionais (ou até mesmo um documento SRS se puder ser compreendido confortavelmente pela equipe de teste), que dará um fluxo funcional completo do selecionado recurso a ser testado.

# 3) Uma vez que o protótipo de tela e as especificações funcionais estão em vigor, o testador deve começar a escrever os casos com a abordagem e os critérios a seguir.

• Testes de IU :Os controles / campos que são visíveis ao usuário. Existem controles estáticos e dinâmicos disponíveis para o recurso a ser testado. Por exemplo, na tela de login acima, os textos de ‘Nome de usuário e senha’ são campos estáticos que não requerem interação do usuário, apenas para exibir apenas o texto.

• Casos Funcionais :Por outro lado, o botão Login e os Hiperlinks (Esqueceu a senha? & Registro) são campos dinâmicos que exigem a interação do usuário clicando nos controles, o que fará alguma ação posteriormente.

• Casos de banco de dados :Depois que o usuário insere o nome de usuário e a senha, os testes podem ser escritos para verificar o banco de dados relacionado, se o nome de usuário e a senha foram verificados no banco de dados e na tabela corretos e também se o usuário tem permissão para fazer login no aplicativo em teste.
  

• Testes de Processo :Isso está relacionado ao processo (não às ações associadas aos controles visíveis disponíveis na tela) associado ao recurso e à funcionalidade. Por exemplo, clicar no link Esqueci a senha na tela de exemplo acima pode enviar um e-mail ao usuário. Então, talvez um e-mail precise ser testado para o processo e confirmação adequados.

4) Finalmente, mantenha o “ BAOE mantra ', meios i) Fluxo Básico ii) Fluxo Alternativo iii) Opções e iv) Exceções para a cobertura completa do fluxo funcional e do recurso a ser testado. Cada conceito deve ser aplicado a testes positivos e negativos.

Por exemplo, vamos ver a abordagem BAOE simples para o exemplo de tela de login acima.

• Fluxo Básico: Insira o caminho da URL do Login em qualquer navegador, insira as informações necessárias e faça login no aplicativo.
• Fluxo alternativo: Instale o aplicativo em um dispositivo móvel, insira as informações necessárias e faça login no aplicativo.
• Opções: Quais são as opções disponíveis para acessar a mesma tela de login? Por exemplo, após o login no aplicativo, clicar em ‘Logout’ pode trazer a mesma tela ou se o tempo limite da sessão ou expirou, o usuário pode vir para a tela de login.
• Exceções: O que são exceções se meus testes forem negativos? Por exemplo, se credenciais incorretas forem inseridas na tela de Login, o usuário receberá uma mensagem de erro ou nenhuma ação associada.

Com todas essas informações em mãos, comecemos a escrever os TCs para a tela de login, em um formato com cobertura e rastreabilidade completa e com informações detalhadas. A sequência lógica e a numeração de identificação do ‘ ID do caso de teste ' será muito útil para um histórico de execução de identificação rápida de casos de teste.

Leia também=> Mais de 180 casos de teste prontos para uso para aplicativos da web e de desktop.

Documento de Caso de Teste

Observação : As colunas de teste não estão limitadas ao documento de teste de amostra abaixo, que pode ser mantido em uma planilha do Excel para ter quantas colunas forem necessárias para uma matriz de rastreabilidade completa, viz., Prioridade, objetivo do teste, tipo de teste, localização da captura de tela de erro etc,

Leia também=> Modelo de caso de teste de amostra com exemplos.

Para facilitar a simplicidade e a legibilidade deste documento, vamos escrever as etapas para reproduzir, o comportamento esperado e real dos testes para a tela de login em detalhes abaixo.

Observação : Adicione a coluna Comportamento real no final deste modelo.

Coleta de dados de teste

Quando o caso de teste está sendo escrito, a tarefa mais importante para qualquer testador é coletar os dados do teste. Esta atividade é ignorada e ignorada por muitos testadores com a suposição de que os casos de teste podem ser executados com alguns dados de amostra ou dados fictícios e podem ser alimentados quando os dados são realmente necessários. Esse é um equívoco crítico que alimentar dados de amostra ou dados de entrada da memória mental no momento da execução de casos de teste.

Se os dados não forem coletados e atualizados no documento de teste no momento da gravação dos testes, o testador gastará anormalmente mais tempo para coletar os dados no momento da execução do teste. Os dados de teste devem ser coletados para casos positivos e negativos de toda a perspectiva do fluxo funcional do recurso. O documento de caso de uso de negócios é muito útil nessa situação.

Encontre um documento de dados de teste de amostra para os testes escritos acima, que por sua vez será útil em quão eficazmente podemos coletar os dados que facilitarão nosso trabalho no momento da execução do teste.

*************************************************

Importância da padronização dos casos de teste

Neste mundo agitado, ninguém pode fazer coisas repetitivas dia após dia com o mesmo nível de interesse e energia. Especialmente, não sou apaixonado por fazer a mesma tarefa repetidamente no trabalho. Gosto de administrar as coisas e economizar tempo. Qualquer pessoa da área de TI deveria ser assim.

Todas as empresas de TI executam diferentes tipos de projetos. Esses projetos podem ser baseados em produtos ou serviços. Destes projetos, a maioria deles trabalha em torno de sites e teste de site . A boa notícia é que todos os sites têm muitas semelhanças. E, se os sites forem do mesmo domínio, eles também terão vários recursos em comum.

A pergunta que sempre me deixa perplexo é: “Se a maioria dos aplicativos são semelhantes, por exemplo: como sites de varejo, que foram testados milhares de vezes antes,“ Por que precisamos escrever casos de teste para outro site de varejo do zero? ” Não vai economizar muito tempo retirando os scripts de teste existentes que foram usados ​​para testar um site de varejo anterior?

Claro, pode haver alguns pequenos ajustes que podemos ter que fazer, mas no geral é mais fácil, eficiente, economiza tempo e dinheiro e, portanto, sempre ajuda a manter os níveis de interesse dos testadores altos. Quem gosta de escrever, revisar e manter os mesmos casos de teste repetidamente, certo? Reutilizar os testes existentes pode resolver isso em grande medida e seus clientes também acharão isso inteligente e lógico.

Então, logicamente, comecei a puxar os scripts existentes de projetos semelhantes baseados na web, fiz alterações e fiz uma revisão rápida deles. Também usei um código de cores para mostrar as alterações feitas, de modo que o revisor só possa se concentrar na parte que foi alterada.

Razões para reutilizar casos de teste

# 1) A maioria das áreas funcionais de um site são quase - login, registro, adicionar ao carrinho, lista de desejos, check-out, opções de envio, opções de pagamento, conteúdo da página de produto, visualizado recentemente, produtos relevantes, recursos de código promocional etc.

#dois) A maioria dos projetos são apenas melhorias ou alterações na funcionalidade existente.

# 3) Os sistemas de gerenciamento de conteúdo que definem os slots para uploads de imagens com formas estáticas e dinâmicas também são comuns a todos os sites.

# 4) Sites de varejo têm CSR (Atendimento ao Cliente) também.

# 5) O sistema de back-end e o aplicativo de warehouse usando JDA também são usados ​​por todos os sites.

# 6) O conceito de cookies, tempo limite e segurança também são comuns.

# 7) Projetos baseados na Web são freqüentemente sujeitos a mudanças de requisitos.

# 8) O tipos de teste necessários são comuns como o navegador teste de compatibilidade , teste de performance , teste de segurança

Veja, há muito que é comum e semelhante.

Tendo dito que a reutilização é o caminho a percorrer, às vezes as próprias modificações podem ou não levar mais ou menos tempo. Às vezes, pode-se sentir que é melhor começar do zero do que modificar tanto.

Isso pode ser facilmente resolvido criando um conjunto de casos de teste padrão para cada funcionalidade comum.

O que é um teste padrão em testes da Web?

• Crie casos de teste completos - etapas, dados, variável, etc. Isso garantirá que os dados / variáveis ​​não semelhantes possam ser simplesmente substituídos quando um caso de teste semelhante for necessário.
• Os critérios de entrada e saída devem ser devidamente definidos.
• As etapas modificáveis ​​ou a instrução nas etapas devem ser destacadas em uma cor diferente para localização e substituição rápidas.
• A linguagem usada para a criação do caso de teste padrão deve ser genérica.
• Todos os recursos de cada site devem ser abordados nos casos de teste.
• O nome dos casos de teste deve ser o nome da funcionalidade ou do recurso que o caso de teste está cobrindo. Isso tornará a descoberta do caso de teste do conjunto muito mais fácil.
• Se houver alguma amostra básica ou padrão ou arquivo de GUI ou captura de tela do recurso, ele deve ser anexado com as etapas relevantes.

Usando as dicas acima, pode-se criar um conjunto de scripts padrão e usá-los com poucas ou necessárias modificações para diferentes sites.

Esses casos de teste padrão também podem ser automatizados, mas, mais uma vez, focar na reutilização é sempre uma vantagem. Também se automação é baseado em uma GUI, reutilizar os scripts em vários URLs ou sites é algo que pessoalmente nunca achei eficaz.

Usar um conjunto padrão de casos de teste manuais para diferentes sites com pequenas modificações é a melhor maneira de realizar um teste de site. Tudo o que precisamos é criar e manter os casos de teste com padrões e uso adequados.

Conclusão

Melhorar a eficiência do caso de teste não é um termo simplesmente definido, mas é um exercício e pode ser alcançado por meio de um processo amadurecido e prática regular.

A equipe de teste não deve se cansar de se envolver na melhoria de tais tarefas, pois é a melhor ferramenta para maiores realizações no mundo da qualidade, isso é comprovado em muitas das organizações de teste em todo o mundo em projetos de missão crítica e aplicações complexas.

Espero que você tenha adquirido imenso conhecimento sobre o conceito de Casos de Teste. Fique atento à nossa série de tutoriais para saber mais sobre os casos de teste e sinta-se à vontade para expressar sua opinião na seção de comentários abaixo!

Próximo tutorial

Leitura recomendada

• Teste Funcional Vs Teste Não Funcional
• Guia de teste de portabilidade com exemplos práticos
• Tipos de teste de software: diferentes tipos de teste com detalhes
• Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
• Teste Alfa e Teste Beta (um guia completo)
• O que é teste de sistema - um guia para iniciantes definitivo
• Exemplos de exemplos de perguntas para a certificação do teste ISTQB com respostas
• Como escrever um relatório semanal de status de teste de software