No contexto geral, heurística é um procedimento mental simples que ajuda a encontrar respostas adequadas, embora várias vezes imperfeitas, para perguntas difíceis. A capacidade heurística é uma característica humana que, do lado positivo, pode ser descrita como a arte de descobrir e inventar ou resolver problemas mediante a experiência (própria ou observada), somada à criatividade e ao pensamento lateral ou pensamento divergente. Seja de forma deliberada ou não, heurísticas são procedimentos utilizados quando um problema a ser encarado é por demais complexo ou traz informações incompletas.
Neste artigo, abordaremos heurísticas no processo de teste de software. Explicaremos algumas das principais heurísticas utilizadas, como por exemplo, CHIQUE e CRUD. Por fim, mostraremos um exemplo prático que você pode aplicar no seu dia a dia!
Na área de testes de software, de acordo com este artigo, “as heurísticas são utilizadas em sessões de testes exploratórios, onde funcionam como um guia que auxiliam o testador a não esquecer de pontos-chave que precisam ser exercitados.” Assim, heurísticas são atalhos mentais ou dicas úteis que ajudam testadores a identificar possíveis problemas de forma eficiente, mesmo que não garantam 100% de cobertura ou precisão.
Por que heurísticas são importantes?
- Ajudam a tomar decisões rápidas sob incerteza;
- Suportam a exploração criativa do sistema;
- São úteis quando requisitos são incompletos ou vagos;
- Permitem que testadores juntem conhecimento empírico à prática diária.
Segue alguns exemplos de heurísticas:
CHIQUE (Júlio de Lima) :
- Campos obrigatórios;
- Habilitar/Desabilitar formulários;
- Interrupção da ação;
- Quebra de fluxos;
- Usabilidade dos menus;
- Estouro de campos.
CRUD (Create, Read, Update, Delete): Verifique se a aplicação permite Criar, Ler, Atualizar e Apagar dados corretamente.
Heurística do tour: Faça um “passeio” pelo sistema como se fosse um novo usuário, explorando diferentes caminhos para identificar falhas.
Heurística de consistência: O sistema deve ser consistente com padrões de design, com ele mesmo, com outros sistemas e com as expectativas do usuário.
Ordem zero, um, muitos: Teste um campo ou componente com nenhum dado, um único dado e muitos dados.
Golden rules de Nielsen (em usabilidade): Use heurísticas como visibilidade do status do sistema, controle do usuário e consistência.
Para finalizar, segue uma aplicação prática em um software. Neste caso, usamos a heurística SFDPOT, de James Bach.
| Letra | Heurística | O que observar/testar |
|---|---|---|
| S | Structure (Estrutura) | A arquitetura, componentes, módulos, banco de dados, APIs. Como o sistema é construído? |
| F | Function (Função) | O que o sistema faz? Verifique funcionalidades principais, secundárias, cálculos, regras de negócio. |
| D | Data (Dados) | Tipos de dados aceitos, validações, volume, persistência. O sistema lida bem com os dados? |
| P | Platform (Plataforma) | Onde o sistema roda? Teste em diferentes navegadores, sistemas operacionais, dispositivos, redes etc. |
| O | Operations (Operações) | Como o sistema é usado no dia a dia? Pense em cenários reais, manutenção, atualizações, logs, backups. |
| T | Time (Tempo) | Comportamento ao longo do tempo: desempenho, sessões, tempo de resposta, expirando, agendamento. |
Sistema: Aplicativo web de agendamento de consultas médicas.
- S (Estrutura): Verifico se há integração com sistemas externos (ex: banco de dados de clínicas).
- F (Função): Testo se é possível criar, editar e cancelar agendamentos.
- D (Dados): Tento agendar com dados inválidos (CPF incorreto, datas passadas, campos vazios).
- P (Plataforma): Testo no Chrome, Firefox, mobile e conexão 5G.
- O (Operações): Simulo uso diário por secretárias: múltiplos agendamentos, alterações rápidas.
- T (Tempo): Deixo o sistema inativo por 30 minutos. O agendamento ainda é salvo? Sessão expira?
