Aceitação de QA

Escreva critérios de aceitação que um revisor possa executar no aplicativo em execução e decidir aprovar ou reprovar sem perguntar ao autor. Os critérios são o contrato — testes automatizados cobrem a correção, QA cobre o comportamento em nível de recurso.

Quando usar

• Uma alteração de recurso está indo para QA e precisa de um plano de validação escrito.
• Um revisor é solicitado a verificar um PR que afeta o comportamento visível ao usuário.
• Um postmortem de incidente requer uma verificação de regressão antes da prevenção de reabertura.
• Um candidato a lançamento precisa de uma passagem de "smoke test" pré-corte.

Quando não usar

• A alteração é apenas para testes unitários (refatoração de utilitários, renomeação interna). Critérios de aceitação são um trabalho desnecessário.
• Você é solicitado a escrever testes para contratos de API. Use testes de contrato, não QA de recursos.

Formato dos critérios de aceitação

Cada critério é uma declaração única e verificável independentemente:

- **Given** <starting state>, **when** <action>, **then** <observable outcome>.

Exemplo:

- **Given** a CSV export with 0 rows, **when** the user clicks Export, **then** the file downloads with only the header row and the UI shows "Exported 0 rows".

Evite critérios que combinem múltiplos whens ou thens. Divida-os.

O que todo plano deve cobrir

1. Caminho dourado. O fluxo de sucesso mais comum, de ponta a ponta.
2. Estados vazios e mínimos. Zero itens, um item, entradas opcionais ausentes.
3. Entradas de limite. Strings de comprimento máximo, valores numéricos máximos, Unicode, texto RTL onde aplicável.
4. Estados de erro. Falha de rede, permissão negada, falhas de validação, conflito (409), não encontrado (404).
5. Concorrência e ordenação. Dois usuários agindo ao mesmo tempo, corrida contra trabalhos em segundo plano, atualização durante mutação.
6. Envelope de desempenho. A maior entrada realista que a alteração deve lidar sem travamentos de UI ou timeouts.
7. Compatibilidade com versões anteriores. Dados existentes, URLs existentes, preferências de usuário persistidas continuam funcionando.
8. Telemetria e auditoria. Eventos, logs ou entradas de atividade que a alteração deve emitir.

Se uma seção for genuinamente inaplicável, escreva "N/A: <motivo>" — não omita silenciosamente.

Evidências

Cada critério precisa de evidências da passagem da verificação:

• Captura de tela ou clipe curto para comportamento de UI.
• Saída de console/rede copiada para comportamento de API.
• Trecho de log ou linha de atividade para telemetria.
• Medição de tempo para critérios de desempenho.

"Parece bom para mim" sem evidência não é uma aprovação.

Quarentena e acompanhamento

• Um critério reprovado bloqueia a aceitação, a menos que seja explicitamente dispensado pelo proprietário com um problema de acompanhamento rastreado.
• "Problema conhecido" sem um acompanhamento vinculado não é uma dispensa.
• Se você adicionar um novo critério no meio da passagem, reinicie a passagem — cobertura parcial esconde regressões.

Devolução para o autor

Retorne o plano de validação com três seções:

• Aprovado. Critérios que passaram, com resumos de evidências de uma linha.
• Reprovado. Critérios que falharam, com a reprodução exata.
• Bloqueado. Critérios que você não pôde executar, com o motivo.

O autor é responsável por transformar falhas em correções ou adiamentos aceitos.

Antí-padrões

• Aceitação formulada como plano de teste ("escreva um teste Cypress para X"). A aceitação é o que é verdadeiro após o envio da alteração; os testes são como você verifica.
• Critérios que dependem da inspeção de detalhes de implementação (seletores, planos de consulta). Mantenha-se observável.
• Listas de verificação longas sem prioridade. Marque os critérios "deve passar" distintamente dos "bom ter".
• Relatórios de validação que dizem "aprovado" sem evidências. Revisores não podem auditar esses relatórios.