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."