17Start Acceptance criteria / Artifact Scenario + risk log / Loop Backfeed
QA & Operations Methods
수용 기준, 실패/예외 케이스, 보안/권한 리스크, 운영 피드백을 기획과 개발 산출물로 되돌리는 방식.
완료 기준을 먼저 문서화
QA 시나리오와 릴리즈 리스크
운영 피드백을 다음 버전 입력으로 환류
Method / QA / Operations릴리즈 기준선
method v1.0 · portfolio draft
01작업 요약
수용 기준, 실패/예외 케이스, 보안/권한 리스크, 운영 피드백을 기획과 개발 산출물로 되돌립니다.
QA와 운영 기준이 마지막 체크리스트로 밀리면 API 불일치, 권한 누락, 성능 미검증, 운영 이슈가 릴리즈 직전에 드러납니다.
02입력 의존성
- REQ / acceptance criteriaready
완료 판단 기준
- Role / permission matrixready
허용/차단 행동
- Security checklistwatch
인증, 인가, XSS/CSRF
- Operations feedbackwatch
릴리즈 후 drift backfeed
03리스크 신호
| Signal | Severity | Meaning | First response |
|---|---|---|---|
happy_path_only | high | 성공 시나리오만 존재 | 실패/예외/권한 케이스 추가 |
permission_gap | high | 역할별 차단 조건 누락 | 권한 매트릭스와 보안 리뷰 연결 |
spec_api_drift | medium | 명세와 실제 응답 불일치 | Mock/real API 비교 절차 추가 |
ops_feedback_lost | medium | 운영 이슈가 다음 기획으로 돌아오지 않음 | Backfeed queue로 승격 |
04반복 절차
QA 시나리오 뼈대 생성
개발 시작 전기획 단계에서 성공, 실패, 예외, 권한 케이스를 30~40% 수준으로 먼저 깔아 둡니다.
Scenario IDPreconditionTest stepsExpected result권한과 보안 리뷰
인증/인가/민감 데이터가 있는 경우역할별 행동, 데이터 민감도, 토큰 저장, OWASP 기준을 표로 먼저 확인합니다.
Permission matrixSecurity checklistRisk owner운영 backfeed
릴리즈 후 이슈가 발생했을 때버그와 운영 피드백을 다음 기획 버전의 요구사항, 화면 상태, QA 시나리오로 되돌립니다.
Issue queuePlan diffRegression case05역할 분담
| Role | Primary work | Handoff |
|---|---|---|
| QA | 시나리오와 수용 기준 | QA scenario draft |
| Security | 인증/인가와 민감 데이터 | Security risk notes |
| Developer | 명세와 구현 일치 | Fix / API diff |
| Operations | 릴리즈 후 피드백 | Backfeed queue |
06완료 체크리스트
완료 기준이 테스트 가능
수용 기준은 모호한 문장이 아니라 실행 가능한 기대 결과여야 합니다.
권한 실패 케이스 포함
다른 역할, 다른 반/조직, 삭제/수정 권한 같은 실패 경로가 있어야 합니다.
실제 API와 비교
Mock 기준으로 통과한 화면도 실제 응답과 에러 코드를 다시 확인해야 합니다.
운영 이슈가 회수됨
릴리즈 후 반복되는 이슈는 다음 기획과 하네스 규칙 후보로 돌아와야 합니다.