Testar com dez pessoas
não é testar
O sistema que funciona na demonstração é o mesmo que trava às nove da manhã. A diferença está no que o teste não simulou.
Teste de funcionalidade não é teste de operação
A validação típica confirma que cada função existe e responde: cadastrar funciona, ler QR Code funciona, imprimir funciona. Nada disso testa o cenário real, que é dezenas de operações simultâneas, com gente apressada, rede oscilando e casos que ninguém previu.
O objetivo do teste não é confirmar que funciona. É descobrir onde quebra, enquanto ainda dá tempo de mudar.
Os quatro testes que valem por todos os outros
- Volume
- Simular o pico: várias estações operando ao mesmo tempo, com o volume da primeira hora.
- Exceção
- Cadastro duplicado, nome com acento e hífen, acompanhante, credencial perdida, homônimo.
- Queda
- Desligar a rede no meio de uma operação e ver o que acontece com o registro.
- Troca de turno
- Um operador que não participou do treinamento assume a estação e tenta operar.
Roteiro do ensaio
- Use a base real de inscritos, não dados fictícios, os problemas moram nos nomes reais
- Monte o mesmo número de estações previsto para o dia, na mesma configuração
- Cronometre atendimentos e compare com o tempo usado no dimensionamento
- Rode as exceções de propósito, uma a uma, e registre o que o operador fez
- Derrube a rede sem avisar e verifique se algum registro se perdeu
- Peça a alguém de fora da equipe para operar sem treinamento prévio
- Anote tudo que exigiu decisão de alguém: cada decisão é um procedimento faltando
O teste de queda é o mais revelador
Tirar a rede no meio do fluxo responde a pergunta mais importante da operação: o sistema perde dado, trava ou continua funcionando localmente e sincroniza depois? A resposta muda completamente o plano de contingência do dia.
Se o sistema depende de conexão para cada operação, a rede deixa de ser conforto e vira parte crítica da produção, com redundância, prioridade de tráfego e equipe presente.
O que fazer com o resultado
Todo achado do ensaio vira uma de três coisas: um ajuste no sistema, um procedimento escrito para a equipe ou uma decisão consciente de aceitar o risco. O que não pode acontecer é virar conhecimento informal na cabeça de uma pessoa.
Um documento de uma página com as exceções e o que fazer em cada uma vale mais, no dia do evento, que qualquer manual completo do sistema.
Relacionado
Vamos ensaiar o seu sistema?
Conte o volume esperado e a gente monta o roteiro de teste com a base real.
Falar sobre um evento