# QA > Use quando a tarefa pede plano de teste, casos de teste, sessão de teste exploratório, regressão ou relato de bug — cobre o que testar, como escrever caso de teste reutilizável, como conduzir exploração com charter e como relar bug que o desenvolvedor consegue reproduzir na primeira tentativa. - Skill: `sergio-balecho/qa` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add sergio-balecho/qa` - Raw SKILL.md: https://api.skillmd.com/api/skills/sergio-balecho/qa/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: sergio-balecho (https://skillmd.com/u/sergio-balecho) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/sergio-balecho/qa --- # QA Teste de software com objetivo declarado. O entregável de QA não é "testei e funciona": é evidência do que foi coberto, do que ficou de fora, e bugs descritos de forma que a primeira tentativa de reprodução bata. ## Método 1. **Defina o escopo antes de testar.** O que entra (features, telas, endpoints, fluxos), o que fica de fora e por quê. Liste os riscos em ordem: o que quebra o negócio se quebrar? Autenticação, pagamento, perda de dados, migração — primeiro. Cosmético — por último. Se a tarefa não delimita, proponha o escopo no relatório antes de começar. 2. **Escreva os casos a partir do comportamento, não da implementação.** Um caso: nome ("Login recusa senha incorreta"), pré-condição, passos numerados, resultado esperado verificável. "Funciona bem" não é resultado esperado; "mostra 'Senha incorreta', não revela se o e-mail existe, não trava o formulário" é. Use `references/template-caso-de-teste.md` para cada caso. Cubra por feature: caminho feliz, cada regra de validação, cada estado de erro, autorização (usuário A não vê dados do usuário B), limite (0, 1, muitos), e o que acontece com conexão lenta ou interrompida. 3. **Rode os casos e registre evidência.** Resultado real, ambiente (build, navegador, conta, dados), data. Passou com ressalva é falha com nota — não "passou". Caso não executável hoje entra na lista de bloqueados com o motivo. 4. **Teste exploratório com charter.** Sessão de 60–90 minutos com destino declarado: "Explorar o fluxo de checkout com cupom expirado, buscando cobrança incorreta". Durante a sessão, anote: o que testou, o que observou, bugs, perguntas. Charter dá direção; a sessão segue o interesse quando ele serve ao destino. Um charter por sessão; ao fim, 5 minutos de relatório antes de a memória esfriar. 5. **Relate bug que reproduz na primeira tentativa.** Cada campo importa: título com comportamento observado, passos numerados partindo do estado mais simples possível, resultado esperado, resultado real, evidência (screenshot, vídeo, log), severidade e ambiente. Antes de relar, reproduza mais uma vez do zero seguindo só os seus passos — se você precisou de um passo que não escreveu, o relato está incompleto. Use `references/template-relato-de-bug.md`. 6. **Severidade e prioridade são coisas diferentes.** Severidade é o dano técnico (bloqueia tudo / funcionalidade principal com contorno / menor / cosmético); prioridade é a pressão de negócio para consertar. Crash de upload em prod pode ser severidade alta e prioridade média se há fluxo alternativo. Declare as duas e o motivo. 7. **Regressão antes de encerrar.** Da suíte, rode: casos que tocam o que a mudança altera, casos que tocam o que a mudança toca por dependência, e os casos que já quebraram antes nessa área. Bugs corrigidos voltam; teste de bug corrigido é candidato permanente à regressão. 8. **Feche com veredito, não com lista.** O relatório responde: pode sair? Quais os riscos conhecidos do que ficou sem teste? Quais os bugs abertos por severidade? Evidência resumida, não diário de bordo. ## Como explorar bem - **Varie uma coisa por vez:** dado inválido em cada campo, ação repetida duas vezes, dois usuários no mesmo recurso, rede caindo no meio de uma ação, timeout, voltar com o botão do navegador no meio do fluxo, sessão expirada em tela aberta. - **Fronteiras numéricas:** o mínimo, o mínimo menos 1, o máximo, o máximo mais 1, zero, negativo, string enorme, emoji, acento, SQL no campo de texto. - **Estado residual:** recarregue no meio de um fluxo, feche o modal e reabra, duplique a aba, volte depois de um dia. - **Não confunda certeza com cobertura:** "não achei bug" vale só para o que você efetivamente exercitou e registrou. ## Regras - Nunca teste só o caminho feliz e declare cobertura. - Nunca relate bug sem reproduzir seguindo exatamente os passos escritos. - Nunca marque "passou" o que não executou; bloqueado é estado honesto. - Nunca edite o código para "consertar" durante a sessão de teste: bug vai para o relato; consertar é tarefa de dev, separada. - Não relar opinião de design como bug ("o botão devia ser azul"): é observação, vai em seção própria. - Não abra dez bugs para uma mesma causa-raiz: um relato, lista de sintomas. - Dados de teste: nunca use conta, dado ou credencial real de cliente. ## Recuse - Assinar "testado e aprovado" sem lista do que ficou de fora. - Cobrir toda a aplicação num plano: proposta de escopo com risco justificado vence lista infinita. - Automação sem antes ter o caso manual estável: primeiro o comportamento conhecido, depois o script. - Bug sem passos de reprodução ("o sistema está estranho"): investigue ou pergunte, mas não relate no vazio. ## Modelos - `references/template-caso-de-teste.md` — para cada caso do plano. - `references/template-relato-de-bug.md` — para cada defeito encontrado.