Ir para o conteúdo principal

Como pensar em casos de teste?

Ao receber uma nova tarefa de teste, o planejamento é o primeiro passo e o mais crucial para garantir a qualidade de uma funcionalidade. Nossa missão como QAs vai além de apenas seguir instruções; é preciso pensar proativamente no contexto e nos arredores da situação que será testada.

Muitas vezes, as solicitações de teste chegam sem todos os detalhes de implementação. Nesses casos, o papel do Analista de Qualidade é fundamental: devemos entender o objetivo da nova funcionalidade e, a partir daí, levantar dúvidas pertinentes. As respostas a essas dúvidas e o raciocínio por trás delas se tornarão parte da documentação e dos casos de teste que serão criados.

O objetivo é mapear todos os cenários de teste, tanto os explícitos quanto os implícitos, a partir das regras de negócio fornecidas.

Casos de Teste Explícitos

Os Casos Explícitos são os cenários que se referem diretamente às regras e condições que estão claramente declaradas nos requisitos ou no enunciado da tarefa. Eles representam o "caminho feliz" e as funcionalidades básicas que são descritas textualmente.

  • Exemplo: Se o requisito afirma que "o usuário deve inserir um e-mail válido para se cadastrar", um caso de teste explícito seria verificar se o sistema aceita um e-mail com o formato usuario@dominio.com.

Casos de Teste Implícitos

Os Casos Implícitos são os cenários que não estão explicitamente registrados, mas que um Analista de Qualidade deve sempre considerar e pensar proativamente. Eles são essenciais para construir um conjunto de testes abrangente e robusto, cobrindo situações que a documentação inicial pode não prever.

Eles incluem, mas não se limitam a:

  • Validações de Limite e Borda: Testar os valores mínimos e máximos permitidos para um campo.

    • Exemplo: Em um campo de idade que aceita valores de 18 a 60, testar as idades 17, 18, 59 e 60.

  • Condições de Erro: Cenários onde o usuário insere dados inválidos ou incorretos, o que deve gerar uma mensagem de erro apropriada.

    • Exemplo: Inserir um e-mail sem o "@" no campo de cadastro.

  • Caminhos Alternativos: O que acontece quando o usuário não segue o fluxo principal?

    • Exemplo: O que ocorre se o usuário cancelar uma transação no meio do processo?

  • Comportamento do Sistema: Verificar o que acontece em situações como falta de conexão, tempo de espera (timeout) ou interações com outros componentes.

  • Segurança e Permissões: Testar se um usuário com privilégios limitados consegue acessar uma funcionalidade restrita.

  • Integridade de Dados: Garantir que as informações são salvas e exibidas corretamente, sem perdas ou alterações.

Uma documentação de teste de alta qualidade é aquela que, além de validar os requisitos explícitos, demonstra uma visão ampla ao antecipar e testar cenários implícitos, garantindo a solidez e a confiabilidade do produto.

Exemplo de casos de teste em um contexto real. 

"Clientes do sistema têm enfrentado lentidão por volta das 16h devido a rotinas de backup de bases de dados grandes configuradas em horário comercial. Em resposta a essa questão, a presidência da empresa e o time de desenvolvimento definiram as seguintes novas regras para a configuração de rotinas de backup, com base no tamanho da base de dados do cliente:

  • Bases de dados menores que 20 GB: A rotina de backup deve ser obrigatória às 16h.

  • Bases de dados entre 20 GB e 50 GB (inclusive): Podem ser configuradas para backup a qualquer horário do expediente.

  • Bases de dados maiores que 50 GB e até 100 GB (inclusive): Somente podem configurar rotinas de backup a partir das 19h.

  • Bases de dados maiores que 100 GB: Somente podem configurar rotinas de backup a partir das 22h."

Conceito de Teste Aplicado (Valor Limite):

Exemplos de Cenários (Implícitos e Explícitos) dentro do contexto:

  • Para Bases de Dados Menores que 20 GB (Obrigatório às 16h):

    • Explícito: Testar se o sistema permite o backup às 16h para uma base de 15 GB.

    • Implícito: Verificar se o sistema não permite fazer backups às 15h ou às 17h para uma base de 15 GB, já que o horário obrigatório é 16h.

  • Para Bases de Dados Entre 20 GB e 50 GB (Inclusive, Qualquer Horário do Expediente):

    • Explícito: Testar se o sistema permite o backup em um horário qualquer do expediente (ex: 10h) para uma base de 30 GB.

    • Implícito: Definir um expediente padrão (ex: 8h às 18h) e verificar se o sistema permite backups dentro desse horário e não permite fora dele (ex: 7h ou 19h). Testar os limites de 20 GB e 50 GB (ex: 20 GB às 8h, 50 GB às 17h).

  • Para Bases de Dados Maiores que 50 GB e Até 100 GB (Inclusive, a Partir das 19h):

    • Explícito: Testar se o sistema permite o backup às 19h para uma base de 75 GB.

    • Implícito: Verificar se o sistema nega backups para essa faixa de tamanho dentro do horário de expediente antes das 19h (ex: 18h30). Testar os limites de 50.01 GB e 100 GB.

  • Para Bases de Dados Maiores que 100 GB (a Partir das 22h):

    • Explícito: Testar se o sistema permite o backup às 22h para uma base de 120 GB.

    • Implícito: Verificar se o sistema nega backups para essa faixa de tamanho antes das 22h (ex: 21h30). Testar o limite de 100.01 GB.