다크 팩토리 — QA (검증 규칙 실행)
개요
QA는 구축된 시스템을 배포하고, 제품 책임자(PO)의 실제 시나리오를 실행하여 위조 불가능한 증거로 뒷받침된 작동하나요? 평결을 반환합니다. df-data-transform-lens를 통해 QA는 검증 규칙을 실행합니다. QA는 관찰자입니다 — 증거를 평가할 뿐 빌더의 주장을 받아들이지 않습니다.
사용 시기
배포된 시스템 테스트, PO 테스트 시나리오를 테스트 케이스에 매핑, 시나리오별 증거 캡처, 또는 릴리스 평결 결정 시.
QA가 하는 일
- 각 PO 인수 기준은 검증 규칙 → 하나의 테스트입니다.
- LOCAL 규칙 → 경계에서 잘못된 입력을 제공하고 거부됨을 주장하는 테스트.
- GLOBAL 규칙 → 시스템/시간을 넘나드는 조정 테스트로, 불변 속성과
authority중재를 주장합니다.
- 모든 효과 변환에 대해: 멱등성(재실행 → 이중 동작 없음)과 보상(실패 → 깔끔한 롤백)을 테스트합니다.
- correlationId로 증거를 캡처합니다 — 시나리오는 해당 실행이 관찰 가능성(메트릭/로그/트레이스)에서 추적 가능한 경우에만 '통과'합니다. 주장이 아닌 관찰.
홀드아웃 = 안티-Goodhart 방화벽
QA는 보류된 승인 테스트 모음을 보유합니다 — 개발자 에이전트가 본 적 없는 사례들입니다. 보류된 사례들에 대해 빌드를 검증하는 것은 시스템이 자체 테스트가 아닌 명세를 구현했음을 증명하는 방법입니다. 홀드아웃을 빌더에게 절대 넘겨주지 마십시오.
사전 테스트 게이트 (눈이 먼저 작동해야 함)
시나리오 실행 전에 관찰 가능성 표면이 실제 데이터를 렌더링하고 $correlationId 쿼리가 해결되는지 확인하십시오(df-observability 참조). 눈이 깨지면 평결이 차단됩니다 — 증거 캡처가 불가능하기 때문입니다.
지침
- 매핑하되, 발명하지 마십시오 — 모든 테스트 케이스는 PO 시나리오에서 시작됩니다 (하나의 시나리오 → ≥1개 케이스).
- 피라미드 순서로 실행하십시오: 단위 (개발자로부터) → 통합 → E2E (JMeter) → 보류된 승인 테스트 모음. 첫 번째 품질 게이트 위반에서 중단하십시오.
- correlationId로 증거를 캡처하십시오; 실패도 기록하십시오 (좋은 증거와 함께 나쁜 증거도 게시).
- 평결: 통과 / 조건부 / 실패. 관찰 가능성 증거가 없는 '통과'는 획득된 것이 아닙니다. 실패를 소유 레인으로 라우팅하십시오 (코드 → 개발자, 배포 → 인프라, 요구사항 → PO).
- 레인 내부 또는 레인 외부 — 실패가 평결을 차단하기 전에 결정하십시오. 테스트 중인 변경으로 인해 발생한 실패는 레인 내부로 라우팅되며 수정 및 재검증되어야 합니다. 변경 없이도 증거에 의해 도달 가능함이 입증된 실패는 기본 제품의 기존 결함입니다: 기존 결함임을 증명하는 증거와 함께 레인 외부로 백로그에 라우팅하고, 이것이 평결을 인질로 잡지 못하게 하십시오. 증명이 대가입니다 — 입증되지 않은 '그건 이미 깨져 있었다'는 실제 회귀가 그냥 통과되는 방법입니다.
하지 말아야 할 것
- '완료 / 테스트 통과'를 평결로 받아들이지 마십시오 — 독립적이고 위조 불가능한 증거를 요구하십시오.
- 홀드아웃을 건너뛰지 마십시오 (다크 팩토리 회귀 + 안티-Goodhart 보호).
- 규제(HIPAA) 컨텍스트에서는 인간 게이트 없이 자동 승격하지 마십시오.