Cada formulário do seu app é um lugar onde o usuário pode perder o trabalho ou desistir. Rode esta lista em cada formulário (cadastro, perfil, checkout, feedback). Use um aparelho real e o teclado real.
O checklist
- Envio vazio. - Por quê: é o erro mais comum. - Como testar: toque em enviar com todos os campos vazios. Cada campo obrigatório mostra uma mensagem clara; nada trava.
- Obrigatório vs. opcional está marcado. - Por quê: o usuário não deveria descobrir isso errando. - Como testar: leia o formulário antes de digitar. Fica claro quais campos são obrigatórios?
- Entrada muito longa. - Por quê: texto longo pode quebrar layouts, bater em limites do servidor ou ser cortado sem aviso. - Como testar: cole vários milhares de caracteres em cada campo de texto. O app mostra um limite ou trata o texto, e o layout se mantém.
- Só espaços, e espaços no início e no fim. - Por quê: " " passa em verificações de "não vazio", e um espaço no fim quebra a comparação de e-mail ou nome de usuário. - Como testar: digite só espaços, depois um valor válido com espaços em volta. Ele é recusado ou os espaços são removidos.
- Caracteres especiais e unicode. - Por quê: nomes com acentos, apóstrofos, escritas não latinas e emojis são entradas normais. - Como testar: tente nomes como O'Brien, Zoë, 李雷, uma string com direções mistas e um emoji. Eles são aceitos, salvos e exibidos sem alteração.
- Texto colado. - Por quê: texto colado costuma trazer espaços escondidos, quebras de linha ou outro formato. - Como testar: cole um e-mail com quebra de linha no fim, um telefone com espaços ou traços, uma senha de um gerenciador. O formulário lida com isso ou diz exatamente o que está errado.
- Regras de formato batem com dados reais. - Por quê: regras de e-mail, telefone ou CEP rígidas demais rejeitam usuários válidos. - Como testar: tente um endereço com "+" (nome+tag@example.com), um TLD longo, um telefone internacional e um CEP de outro país, se você oferecer suporte.
- Números e datas. - Por quê: vírgula decimal vs. ponto, valores negativos e datas impossíveis geram dados errados. - Como testar: digite 1,5 e 1.5, 0, -1, um número muito grande e 31 de fevereiro. Troque a região do aparelho e repita.
- Erros aparecem ao lado do campo. - Por quê: um único erro no topo obriga o usuário a procurar. - Como testar: envie dados inválidos; cada mensagem fica no seu campo, o primeiro erro rola para a tela e o teclado não o esconde.
- Mensagens dizem como corrigir.
- Por quê: "Entrada inválida" não dá nada para agir.
- Como testar: leia cada mensagem. Ela nomeia o problema e o formato esperado.
- A entrada é mantida após um erro.
- Por quê: limpar um formulário longo ao dar erro faz o usuário desistir.
- Como testar: faça a validação ou a rede falhar uma vez. Todas as entradas válidas continuam lá, exceto as sensíveis, como senhas, se você as limpar de propósito.
- O momento da validação faz sentido.
- Por quê: erros enquanto o usuário ainda está digitando incomodam.
- Como testar: digite um e-mail válido devagar. Nenhum erro aparece antes de sair do campo ou enviar.
- Envio duplo é bloqueado.
- Por quê: dois toques podem criar dois registros ou duas cobranças.
- Como testar: toque em enviar várias vezes rapidamente, também com conexão lenta. Só uma requisição passa.
- Teclado e preenchimento automático combinam com o campo.
- Por quê: o tipo de teclado errado dificulta a digitação, e o preenchimento automático economiza tempo.
- Como testar: o campo de e-mail mostra teclado de e-mail, o campo numérico mostra teclado numérico, os botões próximo/concluir movem o foco, e o gerenciador de senhas preenche.
- Rejeição do servidor é tratada.
- Por quê: o servidor pode rejeitar o que o app aceitou.
- Como testar: se possível, faça o backend devolver um erro de validação. O app mostra o erro no campo certo.
- O leitor de tela lê os erros.
- Por quê: senão, usuários cegos não ficam sabendo o que falhou.
- Como testar: ative o leitor de tela e envie dados inválidos; o erro é anunciado. Veja teste de leitor de tela em 10 minutos.
Relacionados
Voltar a todos os checklists · Checklist de estados de erro · Checklist de estados vazios
Olhos novos encontram o formulário que rejeita um nome perfeitamente válido. Comece grátis: feedback privado e estruturado, 1 feedback = 1 crédito.