← todos os posts
Tutorial 5 min de leitura

Você testa o botão. O teste que importava era outro.

Cadastrei, entrei, paguei — e publiquei. Esse é o caminho que você imaginou. Aqui estão as seis entradas maldosas que faltam, pra você rodar hoje.

"Quem nunca estudou isso não sabe o que não sabe."

Essa frase é de um brasileiro num fórum, falando de segurança. Mas ela descreve ainda melhor o que acontece na hora de testar.

Porque a sua lista de teste hoje é essa:

Cadastrei? Sim.
Entrei?    Sim.
Paguei?    Sim.

E aí você publica.

Isso não é descuido. Você testou o caminho que imaginou quando pediu o app: tudo preenchido certo, na ordem certa, por alguém que sabe a ordem certa. Esse caminho tem nome — caminho feliz — e um problema estrutural: quem sabe a ordem é você, a única pessoa que nunca vai usar o app como um estranho.

Seu cliente vai chegar com pressa, no celular, com uma mão só, no meio de outra coisa. E ele não leu o roteiro.

A palavra que faltava: caso de borda

Caso de borda (em inglês, edge case) é o que acontece quando o usuário faz o que você não esperou. Não é o sujeito mal-intencionado tentando invadir. É a pessoa normal fazendo algo normal que você não previu — apertar duas vezes, colar um texto enorme, voltar a tela.

E aqui vai a prova de que nem quem programa confia na própria imaginação pra isso.

O Android tem, na documentação oficial do Google, uma ferramenta chamada Monkey — macaco. A descrição é literal: um programa que "gera fluxos pseudoaleatórios de eventos de usuário, como cliques, toques ou gestos", pra estressar o aplicativo. Existe uma ferramenta oficial cujo trabalho é apertar botão a esmo — porque a indústria já admitiu que ninguém, sozinho, adivinha o que o usuário vai fazer.

Você não precisa do macaco. Precisa de seis minutos e da lista abaixo.

As seis entradas maldosas

Rode agora, na tela mais importante do seu app — a que cria o item principal: o pedido, o cliente, o agendamento. Anote o resultado de cada uma.

1. Campo vazio. Deixe tudo em branco e mande enviar. Deveria: dizer, em português, qual campo falta. Costuma: página branca, "Erro 500", ou — pior — salvar o registro vazio e sujar a sua base pra sempre.

2. Texto gigante. Cole umas 2 mil letras no campo de nome. Copie uma frase e cole vinte vezes. Deveria: recusar, dizendo o limite. Costuma: aceitar e estourar o layout de toda tela que mostra esse nome.

3. Acento e emoji. Cadastre "Ana Conceição 🎉". Deveria: aparecer igual na tela, no e-mail e no PDF. Costuma: virar "Ana Concei��o" numa das três — em geral no e-mail, que é justamente a que você não vê, porque quem recebe é o cliente.

4. Número negativo e zero. Quantidade −1. Valor 0. Se for agendamento, data do ano passado. Deveria: recusar. Costuma: aceitar. E se o app tem desconto ou frete, é aqui que nasce o pedido de total negativo.

5. Clique duplo. No botão que mais importa — enviar, pagar, confirmar —, clique duas vezes rápido, como quem achou que não pegou. Deveria: criar um registro só. Costuma: criar dois.

6. Voltar do navegador. Depois de concluir, aperte a seta de voltar e tente de novo. E recarregue a tela de confirmação com F5. Deveria: levar pra uma tela sensata, sem repetir a operação. Costuma: repetir o pedido inteiro.

O clique duplo merece parágrafo próprio

É o mais barato de testar e o mais caro de ignorar.

O cliente não clica duas vezes por burrice. Clica porque a tela não deu sinal nenhum de que estava processando. A causa é uma falha de interface sua; a consequência é uma cobrança dupla no cartão dele.

Você precisa de duas defesas, não de uma:

Na tela. Desabilitar o botão no primeiro clique e mostrar "processando…". Isso resolve o dedo apressado.

No servidor. Uma trava que reconheça que a segunda chamada é a mesma operação. Em pagamento isso é padrão da casa: a Stripe documenta a chave de idempotência — um código único que você manda junto com a cobrança; se o mesmo código chegar de novo, ela devolve o resultado da primeira chamada em vez de criar uma segunda cobrança. Guarda esse código por 24 horas.

A defesa da tela sozinha não basta, e esse é o detalhe que engana: uma internet oscilando reenvia a requisição sem clique nenhum. Se o seu app cobra, a mesma família de problema aparece do outro lado, no aviso que o banco manda — escrevi sobre isso aqui.

Como pedir a correção

Uma de cada vez, e sempre dizendo onde a checagem tem que acontecer:

"Na tela de novo pedido: recuse o envio quando um campo obrigatório estiver vazio e mostre a mensagem no próprio campo, em português. Limite o nome a 120 caracteres. Recuse quantidade menor ou igual a zero. Essas três checagens têm que acontecer também no servidor, não só na tela. Depois me diga como eu confiro cada uma."

A frase "também no servidor" não é firula. Checagem que só existe no navegador é sugestão: qualquer requisição que não venha da sua tela passa por cima dela.

O que esta lista não cobre

Ela é sobre entrada inesperada. Não é sobre permissão: "o cliente B consegue abrir o pedido do cliente A" é outra lista, e é esta aqui. E também não substitui a bateria fixa que você roda depois de toda mudança, que está neste post.

São três listas diferentes, com propósitos diferentes. Reparou? A sensação de "eu não sei o que deveria testar" é honesta — ninguém nunca te contou que eram três, muito menos em que ordem elas entram.

Hoje dá pra fechar uma. Seis entradas, seis minutos, na sua tela principal. O que aparecer ali já estava no seu app antes de você começar a ler — a única diferença é que agora quem encontrou foi você, e não um cliente.

Fontes