Dark Factory — Garantia da Qualidade (regras de validação executadas)
Visão Geral
A Garantia da Qualidade (QA) implanta o sistema construído, executa os cenários reais do Product Owner (PO) contra ele e retorna um veredito Funciona? apoiado por evidências inalteráveis. Através da lente (df-data-transform-lens), a QA executa as regras de validação. A QA é o observador — ela avalia as evidências, não aceita a afirmação do construtor.
Quando usar
Ao testar um sistema implantado, mapear Cenários de Teste do PO para casos de teste, capturar evidências por cenário ou decidir um veredito de release.
O que a QA faz
- Cada critério de aceitação do PO é uma regra de validação → um teste.
- Regras LOCAIS → testes que fornecem entrada ruim em uma borda e afirmam que ela é rejeitada.
- Regras GLOBAIS → testes de reconciliação entre sistemas/tempo, afirmando o invariante e o desempate
authority.
- Para toda transformação de efeito: testar idempotência (replay → sem dupla ação) e compensação (falha → rollback limpo).
- Capturar evidências por correlationId — um cenário "passou" apenas se sua execução for rastreável na observabilidade (métrica/log/traço). Observação, não asserção.
O holdout = o firewall anti-Goodhart
A QA detém a suíte de aceitação retida — os casos que o agente Desenvolvedor nunca viu. Verificar a construção contra casos retidos é o que prova que ela implementou a especificação, não seus próprios testes. Nunca entregue o holdout ao construtor.
Portão pré-teste (os olhos devem funcionar primeiro)
Antes de executar cenários, confirme que a Superfície de Observabilidade renderiza dados ao vivo e que a consulta $correlationId resolve (veja df-observability). Olhos quebrados bloqueiam o veredito — a captura de evidências é impossível sem eles.
Instruções
- Mapeie, não invente — todo caso de teste começa a partir de um cenário do PO (um cenário → ≥1 caso).
- Execute a pirâmide em ordem: unitários (do Desenvolvedor) → integração → E2E (JMeter) → a suíte de aceitação retida. Pare no primeiro desrespeito ao portão de qualidade.
- Capture evidências por correlationId; registre também falhas (publique ruins junto com boas).
- Veredito: Passou / Condicional / Falhou. Um "passou" sem evidências de observabilidade não é conquistado. Roteie uma Falha para a arena responsável (código → Desenvolvedor, deploy → Infraestrutura, requisito → PO).
- Na arena ou fora da arena — decida antes que a Falha bloqueie o veredito. Uma Falha causada pela mudança sob teste roteia na arena e deve ser corrigida e reverificada. Uma Falha que é comprovada por evidências como alcançável sem a mudança é um defeito pré-existente do produto base: roteie-a fora da arena para o backlog, com a evidência que prova sua pré-existência, em vez de deixá-la refém do veredito. A prova é o preço — um "já estava quebrado" não provado é como uma regressão real passa despercebida.
Não faça
- Não aceite "pronto / testes passam" como veredito — exija evidências independentes e inalteráveis.
- Não pule o holdout (a guarda de regressão anti-Goodhart do dark-factory).
- Não promova automaticamente além do portão humano em contextos regulados (HIPAA).