Uma mensagem de erro genérica como "Ocorreu um erro. Tente novamente." quando o usuário tenta se registrar com um email já cadastrado é um defeito de usabilidade. Não um problema estético: o usuário fica sem saber se deve trocar o email, mudar a senha ou tentar fazer login. Detectar e reportar isso está no escopo do QA.

O que é teste de usabilidade

Teste de usabilidade é a observação estruturada de usuários reais tentando realizar tarefas reais com seu produto. Você observa o que fazem, escuta o que dizem e anota onde têm dificuldade.

O resultado não é passar/falhar. É uma informação qualitativa: onde os usuários ficam confusos, o que tentam sem sucesso, que linguagem usam e não corresponde à linguagem da UI. Também registra quanto tempo levam para fazer algo que deveria ser simples.

Os cinco componentes de usabilidade (Nielsen)

O modelo de usabilidade de Jacob Nielsen define cinco dimensões:

Aprendizabilidade: quão fácil é para usuários novatos realizar tarefas básicas? Eficiência: depois de aprender, com que rapidez usuários experientes realizam tarefas? Memorabilidade: quando os usuários voltam depois de um período sem usar o produto, com que facilidade retomam a proficiência? Erros: quantos erros os usuários cometem, qual a gravidade e com que facilidade conseguem se recuperar? Satisfação: quão agradável é a experiência?

Produtos diferentes pesam essas dimensões de forma diferente. Um fluxo de checkout para consumidores otimiza aprendizabilidade e recuperação de erros. Uma ferramenta profissional de uso diário otimiza eficiência.

Métodos: do barato ao rigoroso

Avaliação heurística (sem usuários)

Um engenheiro de QA ou especialista em UX avalia a UI contra heurísticas de usabilidade estabelecidas. As 10 heurísticas de Nielsen são o padrão:

1. Visibilidade do status do sistema: o usuário sabe o que está acontecendo?

2. Correspondência entre sistema e mundo real: a linguagem combina com as expectativas do usuário?

3. Controle e liberdade do usuário: os usuários podem desfazer ações e sair de situações?

4. Consistência e padrões: a UI segue as convenções da plataforma?

5. Prevenção de erros: o design previne erros antes que aconteçam?

6. Reconhecimento em vez de recordação: a UI minimiza a carga de memória?

7. Flexibilidade e eficiência: atalhos estão disponíveis para usuários experientes?

8. Design estético e minimalista: a UI está livre de informações irrelevantes?

9. Ajude os usuários a reconhecer, diagnosticar e corrigir erros: as mensagens de erro são específicas e úteis?

10. Ajuda e documentação: a ajuda está disponível e é fácil de encontrar?

É rápido e não requer usuários. Encontra 30 a 50% dos problemas de usabilidade em uma única sessão de revisão.

Teste de usabilidade guerrilha

Cinco minutos, qualquer usuário, qualquer lugar. Mostre um protótipo ou o produto real para alguém. Dê uma tarefa: "Você consegue encontrar onde redefinir sua senha?" Observe. Não ajude. Anote.

Cinco usuários por rodada. Os problemas mais óbvios aparecem rapidamente. Funciona com orçamento zero.

Sessões de usabilidade moderadas

Um facilitador trabalha com um participante por vez. O participante "pensa em voz alta" enquanto tenta realizar as tarefas. O facilitador sonda e aprofunda.

Testes moderados remotos (via Zoom + compartilhamento de tela) tornam isso acessível. Ferramentas como UserTesting ou Maze fornecem painéis de participantes.

Teste de usabilidade não moderado

Os participantes completam as tarefas de forma independente, gravados via captura de tela. Você revisa as gravações. É mais escalável que as sessões moderadas, porém menos detalhado: sem oportunidade de aprofundar os pontos.

O que o QA pode fazer sem um processo de UX formal

Durante os testes exploratórios: anote momentos de confusão ou frustração. "A mensagem de erro diz 'Entrada inválida' sem indicar qual campo é inválido." Isso é um defeito de usabilidade. Aplique as 10 heurísticas: percorra qualquer feature nova com a lista de Nielsen. Verifique cada item sistematicamente. Pergunte "um usuário novo consegue entender isso?": ao testar uma feature pela primeira vez (sem ler a spec), preste atenção na sua própria confusão. Você está atuando como proxy para novos usuários. Teste a recuperação de erros: o que acontece quando o usuário comete um erro comum? A mensagem de erro é útil? Há um caminho claro para corrigir? Teste no mobile: muitos problemas de usabilidade são específicos do dispositivo. Alvos de toque pequenos demais para tocar com precisão. Formulários que exigem rolar para cima e para baixo para preencher. Modais que ultrapassam os limites da tela.

Defeitos de usabilidade comuns para reportar

  • Mensagens de erro que não especificam o que deu errado nem como corrigir
  • Campos de formulário que são limpos ao dar erro (o usuário precisa redigitar tudo)
  • Campos obrigatórios não marcados como tal até depois de uma submissão com falha
  • Botões ou links que parecem clicáveis mas não são, ou que não parecem clicáveis mas deveriam ser
  • Diálogos de confirmação sem distinção clara entre confirmar e cancelar
  • Estados de carregamento que não indicam progresso nem tempo estimado de espera
  • Ações sem possibilidade de desfazer (especialmente ações destrutivas)
  • Terminologia inconsistente (mesma funcionalidade com nomes diferentes em partes diferentes da UI)
  • Paginação sem indicação do total de resultados ou posição atual

Escrevendo defeitos de usabilidade

Defeitos de usabilidade são mais difíceis de escrever do que os funcionais porque não há um resultado esperado claro na spec. Enquadre-os pelo impacto:

Ruim: "A mensagem de erro é confusa." Bom: "Quando o usuário submete o formulário de cadastro com um email já registrado, a mensagem de erro exibe 'Ocorreu um erro. Tente novamente.' Os usuários não conseguem determinar se devem trocar o email, usar uma senha diferente ou tentar fazer login. Sugestão: exibir 'Este email já está cadastrado. Tente fazer login.' com um link para a página de login."

O bug report explica o impacto no usuário e propõe uma correção específica. Isso faz com que problemas de usabilidade sejam levados a sério em vez de descartados como "opiniões de design".

→ Veja também: Testes de Acessibilidade com Playwright: Verificações a11y Automatizadas | Testes Exploratórios: A Habilidade que a IA Não Consegue Substituir | Como Escrever um Caso de Teste: Formato, Exemplos e Erros Comuns