Teste de Software: UI, API, Manual e Automatizado

Base — guia "Qualidade Decide Tudo: Guia Completo de Teste de Software" (Roman Surkov). Tudo que está marcado como [fora do livro] veio de outras fontes (lista no final) ou da prática geral. Apresente isso como complemento, não como posição do autor.

Quando usar

"Teste esta funcionalidade / tela / aplicativo / API", "crie um checklist / casos de teste", "registre um bug".
Revisão de especificações, layout Figma ou Swagger antes do desenvolvimento (shift-left).
Decidir o que e como automatizar; cenário de carga; relatório de prontidão para release.
Para videogames, use o skill qa-game-testing e daqui a base geral (design de testes, artefatos).

Passo 0. Defina o modo de trabalho

Solicitação	O que fornecer
Há especificação / layout, código ainda não existe	Revisão de requisitos (passo 1) + checklist escrito previamente
"Teste isso" sem detalhes	Decomposição usando "BLUGID com PC" (passo 2) → checklist → casos de teste para o complexo
Site / aplicativo ao vivo disponíveis	Execução de verificações, relatórios de bug, TRR final
API / Swagger / cURL	BINMEN + POISED (passo 6), coleção de requisições
"O que automatizar?", flaky tests, Playwright	Plano baseado na pirâmide e regras de testes automatizados (passo 8)
Verificação de segurança de API	Matriz OWASP API Top 10 (passo 6)
Funcionalidade com LLM (chatbot, geração)	Camadas de verificação e conjunto de referência (passo 9)
Teste exploratório de nova funcionalidade	Cartas de sessão SBTM + SFDIPOT (passo 2)

Primeiro os testes positivos (caminho feliz), depois os negativos. Nos positivos, as verificações podem ser combinadas, nos negativos — um parâmetro inválido por verificação.

Passo 1. Teste de requisitos (shift-left)

O erro fica mais caro pela regra 1–10–100: correção na especificação custa 1, no código — 3–8x mais, encontrado pelo QA — 20–80x, em produção — 100x+. Por isso, comece pelo documento.

Critérios de um bom requisito (para cada violação, um comentário no documento): completeza (casos extremos e erros descritos), consistência (texto não conflita com layout), clareza, correção, testabilidade ("como vou verificar isso?"), atomicidade (uma ideia por vez).

Palavras-lixo — "rápido", "conveniente", "intuitivo", "flexível", "adequado", "quando necessário". Reescreva de forma mensurável: "busca rápida" → "resultado em ≤ 1,5 s com 1000 requisições simultâneas".

Se não houver especificação, o resultado esperado é obtido de: layouts e protótipos → concorrentes → leis e regulamentações (GDPR, PSD2) → melhores práticas e senso comum (validação de email, rate-limit, máscara de telefone) → conversa com o desenvolvedor ou analista.

Como "fritar" os requisitos: perguntas sobre limites (tamanho máximo, caracteres proibidos, queda de conexão, dois usuários clicando ao mesmo tempo); diagrama de blocos ou mapa mental do fluxo (uma seta para o vazio é um cenário não descrito); casos de teste durante a leitura (não consegue escrever um caso? Encontrou um bug na especificação).

Oráculos FEW HICCUPPS [fora do livro, M. Bolton e J. Bach] — como provar que o comportamento é problemático se não há especificação ou ela está incompleta. O produto deve ser consistente com: Familiar problems (não repete tipos de bugs conhecidos), Explainability (comportamento pode ser explicado), World (não contradiz a realidade), History (versões anteriores), Image (imagem da empresa), Comparable products (produtos similares), Claims (declarações: especificação, propaganda, ajuda), User desires (desejos razoáveis do usuário), Product (consigo mesmo: mesma ação, mesmo comportamento em todos os lugares), Purpose (propósito), Statutes and standards (leis e normas). No relatório de bug, mencione o oráculo: "contradiz a versão anterior", "contradiz a ajuda" — isso torna mais difícil argumentar que "não é um bug".

Funcionalidade Ausente: se a função não existe e não está na especificação, não é um Bug, e sim uma Melhoria / Solicitação de Funcionalidade. Disputas são resolvidas pela matriz de funcionalidade: Web — existe, iOS — existe, Android — não existe.

Passo 2. Decomposição da tarefa "Teste isso"

Teste funcional responde à pergunta "O QUE faz", teste não funcional — "COMO". Os vetores não funcionais são percorridos usando o mnemônico "BLUGID com PC":

B — segurança (XSS, injeções SQL, direitos de acesso)
L — localização
U — usabilidade
G — interface gráfica (GUI)
I — instalação (apenas o que é instalado: desktop, mobile, consoles)
D — acessibilidade (a11y)
P — desempenho (cliente e servidor)
C — configuração e compatibilidade

Adicione os tours exploratórios de Whittaker para busca livre: guia turístico (funcionalidades principais), becos (configurações raras), entregador (um objeto por todos os status), dinheiro (carrinho e pagamento), notívago (tarefas em segundo plano), lixeiro ("Cancelar", "Redefinir"), insistente (100 repetições de uma ação), bairro ruim (módulos historicamente problemáticos), museu (código antigo, não modificado há muito tempo).

O que existe no produto — SFDIPOT [fora do livro, HTSM de J. Bach]: Structure (do que é composto: arquivos, módulos, builds), Function (o que faz), Data (o que é inserido, armazenado, exibido; vazio, enorme, corrompido), Interfaces (UI, API, importação/exportação, integrações), Platform (SO, navegador, hardware, serviços externos), Operations (como é realmente usado: cenários frequentes, usuário inexperiente e malicioso), Time (timeouts, paralelismo, ordem de eventos, fusos horários, operação prolongada). Percorra as sete palavras — você terá um mapa de cobertura que o BLUGID não fornece.

Teste exploratório por sessões (SBTM) [fora do livro, J. e J. Bach]. Sessão de 60–90 minutos sem distrações, com uma carta: "Explorar <área> usando <ferramentas, técnicas, dados> para descobrir ". No final, uma lista da sessão: o que foi coberto, bugs encontrados, perguntas, riscos, proporção de tempo gasto em teste / registro de bugs / configuração do ambiente, e uma breve discussão com o líder. Assim, o teste livre se torna reportável: fica claro o que foi verificado e o que resta.

Passo 3. Técnicas de design de testes

Ordem: primeiro a estrutura com EP + BVA + tabelas de decisão, depois o reforço com Error Guessing.

Classes de equivalência (EP): um valor de cada classe válida e inválida.
Valores de limite — apenas 3BVA: em cada limite, pegar min-1, min, min+1 (e o mesmo para max). 2BVA perde um erro de digitação do operador X == 10 em vez de X >= 10: os pontos 9 e 10 passam, e 11 quebra. Exemplo: acesso de 18–100 anos → -1, 0, 1, 16, 17, 18, 99, 100, 101. Para dinheiro, o passo é a unidade mínima (0,01 BRL).
Combinatória: 1-wise (≈50% dos bugs, expresso), pairwise — padrão (70–90%), 3-wise para fintech (≈95%), cobertura total apenas para sistemas críticos. Nunca monte uma matriz pairwise mentalmente: gere-a com uma ferramenta (PICT, se instalado, senão pip install allpairspy --break-system-packages) e verifique com um script se todos os pares estão cobertos. Onde aplicar: filtros de catálogo, calculadoras, pagamento × entrega, exportação (formato × codificação × delimitador). Para compatibilidade entre navegadores, não use pairwise (veja passo 5).
Tabelas de decisão: quando a especificação tem muitos "se / e / ou / exceto", 2–5 condições binárias. Elimine combinações impossíveis e combine regras com o mesmo resultado em um único caso. Locais típicos: descontos e cupons, matriz de papéis, campos de formulário dependentes (pessoa jurídica → CNPJ e IE obrigatórios), status de pedido.
Estados e transições: tudo que tem um ciclo de vida e timeouts. Verifique transições inválidas, expiração de timeout (reserva sem pagamento volta para "Disponível"), uso único de tokens (redefinição de senha com link antigo), falha em cada etapa.
Error Guessing — catálogo de armadilhas:
- entrada suja: apenas espaços, espaços nas bordas do email, U+200B, emojis, aspas, caracteres chineses, 10.000 caracteres do buffer;
- repetições e corridas: clique triplo em "Pagar", "Voltar" após transação, último item comprado por dois usuários;
- interrupções: queda de rede em 99%, fechamento de guia durante a aquisição;
- datas e números: 29/02 em ano não bissexto, data de nascimento no futuro, 00.00.0000, quantidade −1, 0, 999.999;
- ambiente: sessão expirou após 3 horas de inatividade, .exe com extensão .jpg, arquivo de 500 MB.

Passo 4. Artefatos

Checklist (ID, verificação, status) — por padrão. Caso de teste — para lógica complexa, onboarding e entrega para automação.

Campos do caso de teste: ID, nome, prioridade, pré-condição (preenchida sempre), passos, dados de teste, resultado esperado; após execução — resultado real e status (Passed / Failed / Blocked / Skipped).

Regras: nos passos, apenas ações do testador; reações do sistema no resultado esperado; passos atômicos ("inserir email", "inserir senha", "clicar em Entrar" — três passos); um caso = uma verificação; casos independentes (a preparação vai para a pré-condição ou é feita via API); detalhamento razoável, sem "mover o mouse"; prioridade High — dinheiro e autenticação, Low — cosméticos, o resto (≈80%) Medium.

Suite de testes — pasta por módulo com suites aninhadas por funcionalidade; verificações comuns do módulo ficam na raiz da suite. Execução de testes — execução de um conjunto em uma build e ambiente específicos com status. Plano de teste (sob demanda): escopo (in / out), estratégia e ambiente, critérios de entrada, suspensão e saída, recursos e prazos, riscos com plano B.

Relatório de Bug

Título:      [Onde] O que acontece, sob qual condição
             exemplo: [Janela de cupom] erro 500 ao inserir cupom expirado
Ambiente:    Prod/Stage, navegador e versão, SO; para mobile, modelo e versão exata do SO; URL
Pré-condição: papel do usuário, página, dados preparados
Passos:      1. … 2. … (apenas ações, cadeia mínima)
Esperado:    específico, com referência à especificação ou layout
Real:        o que aconteceu
Severidade:  Blocker / Critical / Major (tem workaround) / Minor / Trivial — avaliação técnica, definida pelo QA
Prioridade:  High / Medium / Low — urgência para o negócio (decide PO/PM)
Reprodutibilidade: Always (10/10) ou Intermittent (exemplo: 1/10)
Workaround:  caminho alternativo, se houver
Anexos:      screenshot para estático, vídeo para dinâmico, logs do console ou HAR para backend

Regras: 1 bug = 1 ticket; antes de abrir, procure duplicatas; abra imediatamente; tom neutro; não sugira correção no ticket; escreva de forma que, depois de um mês, seja possível verificar a correção pela descrição. Severidade e Prioridade são independentes (erro de digitação no logotipo: Trivial / Immediate).

Relatório de Teste (TRR)

Mínimo de "encher lingüiça", máximo de números e recomendação clara Go / No-Go:

RELATÓRIO DE TESTE DA BUILD vX.Y
Planejados N casos: Passed a (a%) · Failed b (b%) · Blocked c (c%)
Defeitos: BUG-… — resumo (prioridade) [link] …
Bloqueado: qual bloco e devido a quais bugs
Recomendação do QA: lançamento NÃO recomendado / recomendado com condições …

Passo 5. UI: formulários, GUI, usabilidade, acessibilidade, compatibilidade, localização

Formulários e campos de entrada

Texto: valor válido; campo obrigatório vazio; exatamente max; max+1; caracteres especiais ' " < > / ; : @ # $ % ^ & * ( ) _ +; emojis (falha no utf8mb4); apenas espaços, espaços iniciais, finais e internos (espera-se trim); mistura de cirílico, latim, ideogramas e RTL; F5 salva a entrada (exceto senha e captcha); clique duplo em "Enviar" não envia duas requisições; U+200B.
Senha: mascaramento; é limpa ao recarregar e em caso de erro; verificação de senha fraca e igualdade com login ou email; colagem do buffer e gerenciador de senhas; "olhinho" alterna password ↔ text.
Seleção e upload: valores padrão razoáveis (consentimento não marcado previamente — GDPR); clique no rótulo alterna a caixa de seleção; "selecionar todos / desmarcar todos"; grupo de botões de rádio obrigatório; extensões proibidas (.exe, .php), arquivo de 0 bytes e 100 MB+, barra de progresso.
Validação UX: verificação inline no blur, o inserido não é perdido ao errar, campo destacado e com motivo e CTA; formato sugerido previamente ("DD.MM.AAAA"); um campo — um valor; tela de sucesso com número, status e próximo passo; "Voltar" em formulário de múltiplas etapas salva os dados ou é explicitamente proibido.
Mais BLUGID: Tab / Shift+Tab / Enter, Safari e mobile, traduções de erros, XSS, SQL, CSRF, rate limit.

GUI: conferência com o layout (Figma + DevTools)

Comece pelos Componentes Comuns — correção em um componente comum conserta dezenas de telas. Tamanhos — extensão Pixel Measurement (largura "menor que o layout" com DevTools aberto — é responsividade, não bug). Fontes e cores — Elements → Computed (font-size, background-color → HEX). Espaçamentos — Option/Alt no Figma contra Box Model. Animações — Command Palette → Show Animations, reduza para 10–25%. Sobreposição — PerfectPixel com 50% de opacidade. Diferença de 1 px não é bug (arredondamento de subpixel), a menos que o layout quebre.

Usabilidade

Verifique pelos 10 heurísticos de Nielsen: status do sistema, linguagem do usuário, controle e Undo, padrões da plataforma (HIG / Material), prevenção de erros, reconhecimento em vez de memorização, atalhos, minimalismo, erros compreensíveis, ajuda. Para público adulto: fonte não menor que 12 pt, contraste, alvos grandes. Não quebre padrões nativos: toque duplo, gestos do sistema na borda da tela. Cancelar com "Undo" por 5 segundos é melhor que o diálogo "Tem certeza?".

Acessibilidade (WCAG, POUR)

Execução rápida: Lighthouse (apenas Acessibilidade) → axe DevTools → IBM Equal Access → ANDI (ordem de Tab e nomes dos elementos) → contraste (AA ≥ 4,5:1, AAA ≥ 7:1). Texto sobre imagem ou gradiente verifique novamente com o conta-gotas do DevTools: scanners pegam a cor da tag vizinha. Manualmente: todo o trabalho sem mouse, foco visível e não sobreposto, alt em imagens informativas, nada pisca mais de 3 vezes por segundo, respeita prefers-reduced-motion, leitor de tela (NVDA / VoiceOver). Simulações — Web Disability Simulator.

Compatibilidade

Construa a matriz com base em dados: sua própria análise → estatísticas regionais → StatCounter (e relate o risco de cobertura insuficiente). Olhe para a receita por plataformas, não apenas o tráfego. Descarte a cauda < 0,5%. Agrupe por mecanismo: Chrome e Edge no Windows — um Chromium; todos os navegadores no iOS — WebKit, mas Safari no iOS teste separadamente (seus próprios bugs de layout). Distribua a regressão proporcionalmente às fatias (200 casos × fatia do grupo), não pairwise "navegador × caso" (isso seria 1400 execuções). A falta de dispositivos é compensada com emuladores/simuladores

testes manuais nos reais. Comunique os riscos de cobertura automaticamente.

Passo 6. Teste de API

Análise: BINMEN + POISED

BINMEN — decomposição funcional: Body (formato, campos obrigatórios, tipos, valores), Input (parâmetros de URL, cabeçalhos, cookies, autenticação), Negative (erros, limites, injeções), Method (GET / POST / PUT / DELETE / PATCH — semântica), Endpoint (URL correta, versão), Network (timeouts, retries, compressão).

POISED — decomposição não funcional: Performance (tempo de resposta, throughput), Overload (rate-limit, estresse), Integration (contratos, dependências externas), Security (OWASP API Top 10), Error handling (códigos HTTP, mensagens, logging, idempotência), Documentation (Swagger correto, schemas, exemplos).

Contratos de API

Verifique schemas (JSON Schema, OpenAPI, Protocol Buffers, GraphQL) — tipos, campos obrigatórios, enumerações, formatos.
Teste de contrato com schemas: validação com ferramentas (por exemplo, ajv para JSON Schema).
Verifique a documentação: Swagger corresponde ao comportamento real.

Matriz de segurança OWASP API Top 10

API1: Broken Object Level Authorization — um usuário acessa dados de outro alterando ID na URL.
API2: Broken Authentication — senha fraca, token não expirado, ausência de rate-limit no login.
API3: Excessive Data Exposure — resposta contém campos desnecessários (hash, senha).
API4: Lack of Resources & Rate Limiting — sem limite de requisições, consulta pesada sem paginação.
API5: Broken Function Level Authorization — usuário comum chama endpoint de admin.
API6: Mass Assignment — atualização de campo proibido via body da requisição.
API7: Security Misconfiguration — CORS aberto, debug habilitado, TLS fraco.
API8: Injection — SQL, NoSQL, LDAP, OS Command, XSS em parâmetros.
API9: Improper Assets Management — versões antigas da API disponíveis, documentação obsoleta.
API10: Unsafe Consumption of APIs — falta de validação de respostas de serviços externos.

Coleção de requisições e automação

Crie coleções no Postman / Insomnia / Bruno: smoke, regressão, cenários.
Variáveis de ambiente para diferentes ambientes (dev, stage, prod).
Testes de contrato e validação de esquema em cada coleção.
Integre com CI: Newman (Postman CLI) ou ferramentas similares.

Passo 7. Testes não funcionais

Desempenho

Cliente: Lighthouse, WebPageTest, PageSpeed Insights (LCP, FID, CLS, TBT, INP). Otimizações: compressão, cache, lazy loading, redução de requests. Servidor: k6, Locust, Vegeta (para cenários e picos). Métricas: latência (p50, p95, p99), throughput, taxa de erro, utilização de CPU/memória.

Carga

Cenários: pico normal, carga sustentada, estresse, pico.
Perfis de usuário: autenticado / anônimo, diferentes papéis, diferentes dados.
Objetivos: tempo de resposta < X s, throughput > Y rps, taxa de erro < Z %.

Segurança (além do OWASP API Top 10)

XSS, SQLi, CSRF, SSRF, IDOR, LFI/RFI, clickjacking, open redirect.
Verificação de headers de segurança (CSP, HSTS, X-Frame-Options, etc.).
Teste de força bruta, fuzzing.
Análise de dependências (OWASP Dependency Check, Snyk).

Passo 8. Automação de testes

Estratégia por pirâmide

Unitários (base): Jest, Vitest, Mocha — para lógica de negócio, funções, componentes.
Integração: testes de API, contrato, banco de dados — ferramentas: Supertest, Postman/Newman, Pact.
E2E (topo): Playwright, Cypress, Selenium — UI, cenários críticos (compra, registro, login).

Regras de automação

Estabilidade: testes devem ser independentes, idempotentes e gerenciar dados de teste (setup/teardown).
Flaky tests: detectar e corrigir (retry com captura de evidências, análise de causas).
Manutenção: Page Object Model (POM) ou Component Object Model para UI; usar seletores estáveis (data-* attributes).
Cobertura: priorizar cenários de alto valor (fluxo de dinheiro, autenticação, regressão crítica).
Integração contínua: executar em CI (GitHub Actions, GitLab CI, Jenkins) após cada merge ou agendado.
Relatórios: Allure, ReportPortal, HTML reports com evidências (screenshots, videos, logs).

Playwright (foco)

Instalação: npm init playwright@latest (ou yarn create playwright).
Configuração: playwright.config.ts — projetos para diferentes navegadores, viewports, dispositivos móveis.
Fixtures e hooks: beforeEach, afterEach, test.step.
Page Object Model: classes para páginas, componentes.
Testes de API via page.request.
Geração de relatórios: npx playwright show-report.
Debug: --debug, --headed, page.pause(), trace viewer.
Execução paralela, sharding.
Integração com CI: npx playwright install --with-deps.

Passo 9. Funcionalidades LLM (chatbots, geração de conteúdo)

Camadas de verificação:

Funcionalidade básica: respostas coerentes, formato correto, sem alucinações óbvias.
Entrada: prompts inválidos, vazios, maliciosos (injeção de prompt), muito longos, ambiguidade.
Segurança: jailbreaks, conteúdo proibido, viés, privacidade (vazamento de dados pessoais).
Desempenho: latência, throughput, capacidade de lidar com múltiplas conversas simultâneas.
Consistência: mesma entrada → mesma saída (ou variação controlada), comportamento previsível.
Integração: funcionamento via API, webhook, integração com outros sistemas.
Monitoramento: logs, rastreamento de erros, métricas de uso.

Conjunto de referência:

Perguntas típicas do domínio.
Casos de borda (ambiguidades, paradoxos, perguntas impossíveis).
Exemplos de ataques (injeção de prompt, jailbreaks conhecidos).
Cenários de carga.

Passo 10. Repetição: relatório de teste (TRR) e recomendação

Resuma tudo em um documento final (TRR) com:

Resumo dos resultados (passou, falhou, bloqueado).
Lista de defeitos críticos e bloqueadores.
Riscos identificados.
Recomendação: Go / No-Go / Go com condições.

Fontes adicionais (fora do livro "Qualidade Decide Tudo"): OWASP API Security Top 10, documentação do Playwright, "Lessons Learned in Software Testing" (C. Kaner, J. Bach, B. Pettichord), "Explore It!" (Elisabeth Hendrickson), "Agile Testing" (Lisa Crispin, Janet Gregory), heurísticas de teste, SBTM, HTSM.`,

Nota: este skill é um guia integrado; as pesquisas e ferramentas mencionadas são de código aberto ou gratuitas, salvo indicação contrária.

Perguntar na sua IA favorita

Documentação