QA & Operations Methods

한눈에 보기

수용 기준, 실패/예외 케이스, 보안/권한 리스크, 운영 피드백을 기획과 개발 산출물로 되돌리는 방식입니다.

• Start: Acceptance criteria — 완료 기준을 먼저 문서화
• Artifact: Scenario + risk log — QA 시나리오와 릴리즈 리스크
• Loop: Backfeed — 운영 피드백을 다음 버전 입력으로 환류

QA 시나리오 뼈대

기획 단계의 QA는 100% 테스트 케이스를 완성하는 작업이 아니다. 개발이 시작되기 전 성공, 실패, 예외, 권한 케이스를 30~40% 수준으로 먼저 깔아 두는 작업이다.

• 시나리오 ID와 목적
• 사전 조건과 테스트 단계
• 기대 결과와 실패 메시지
• 개발 후 상세 보강할 TODO

권한과 보안 매트릭스

AI 생성 코드와 문서는 보안 조건이 빠지면 일반적인 패턴으로 돌아가기 쉽다. 그래서 역할별 행동, 데이터 민감도, 인증/인가, XSS/CSRF 같은 기준을 표로 먼저 둔다.

• 역할별 허용/차단 행동
• 데이터 민감도와 소유 관계
• 인증 토큰 저장 방식과 만료 정책
• OWASP 기준과 취약 컴포넌트 검토

릴리즈 리스크

QA와 운영 기준은 마지막에 붙이는 체크리스트가 아니다. 일정, 인력, 성능, API 불일치, 문서 부채 같은 리스크를 기획 초안부터 기록해야 재작업 비용이 줄어든다.

• API 명세와 실제 응답 비교
• Mock 데이터와 운영 데이터 차이
• 성능 미검증 항목
• 사람 승인 없이는 넘길 수 없는 blocker

운영 피드백 backfeed

릴리즈 후 발견된 버그와 운영 이슈는 회고에만 남기지 않는다. 다음 기획 버전의 요구사항, 화면 상태, QA 시나리오, 자동화 규칙 후보로 되돌린다.

• 반복 이슈를 REQ/QA 항목으로 승격
• 운영 로그에서 화면 상태 누락 추출
• 사람 검토 기준이 필요한 항목 분리
• 규칙화 가능한 실패는 하네스 후보로 이동

연결 문서

• Planning Generation Harness Loop — 검증 실패를 다음 기획 루프로 되돌리는 구조
• Prototype & Handoff Methods — QA가 이어받는 핸드오프 번들 기준
• Work Method Library — 직무별 방법론 허브