개념
이 모듈의 모든 레슨이 이 순간을 위해 있었다 — 계획(레슨 1)을 세우고, 리스크(레슨 2)를 근거로 우선순위를 정하고, 규모(레슨 3)에 맞게 커버리지를 조정하고, 종료 조건(레슨 4)을 합의했다면, 이제 그 결과를 가지고 **"릴리즈해도 되는가"**를 판단할 차례다.
Go/No-Go는 QA 혼자 내리는 결정이 아니다
QA의 역할은 "결정권자"가 아니라 **"근거를 명확히 제시하는 사람"**에 가깝다. 최종 결정은 보통 PM, 개발 리드, 때로는 경영진까지 포함한 교차 기능적 판단이다. QA가 할 일은 리스크를 숨기지 않고 명확히 드러내는 것이지, 혼자 "안 된다"고 막는 게 아니다.
무엇을 가지고 논의 테이블에 앉는가
Go/No-Go 논의에서 QA가 제시해야 할 정보는 이렇게 정리된다.
| 항목 | 내용 |
|---|---|
| 종료 조건 충족 현황 | 레슨 4에서 정한 조건 중 몇 개가 충족됐는가 |
| 미해결 결함 | 심각도별로 몇 건이 남아있는가 |
| 남은 리스크 | 시간 부족으로 못 본 영역이 있다면 무엇이고, 얼마나 위험한가 |
| 권고 의견 | Go / 조건부 Go / No-Go 중 무엇을 권하는가, 왜 |
답은 둘 중 하나가 아니다
Go와 No-Go 사이에 조건부 Go라는 실용적인 중간 지점이 있다.
"핵심 결제 흐름의 종료 조건은 모두 충족됐습니다. 다만 다국어 설정 화면은 리스크가 낮다고 판단해 얕게만 봤고, 배포 후 관련 문의가 있는지 첫 24시간 모니터링을 권장합니다. 조건부로 Go를 권합니다."
이렇게 리스크를 명시하고 대응 방안(모니터링, 빠른 롤백 준비 등)까지 함께 제시하면, 단순히 "됩니다/안 됩니다"보다 훨씬 설득력 있고 신뢰받는 의견이 된다.
모듈 1(레슨 5)로 돌아가서
이 모듈을 시작하기 전, 모듈 1 레슨 5에서 "버그 없음을 보장해달라"는 요청에 어떻게 답할지 연습했었다. 그때는 일반적인 답변 스크립트를 만드는 수준이었다면, 이제는 실제 종료 조건 충족 현황과 리스크 매트릭스라는 구체적인 데이터를 가지고 그 질문에 답할 수 있다. "버그가 없다고는 말씀드릴 수 없지만, 핵심 흐름의 종료 조건은 100% 충족했고, 남은 리스크는 이 정도이며, 이렇게 대응할 계획입니다"라고.
실무에서 왜 필요한가
Go/No-Go 순간은 QA가 조직에서 신뢰와 영향력을 얻는(혹은 잃는) 결정적 순간이다. 근거 없이 "괜찮은 것 같아요"라고 말하는 QA와, 종료 조건·결함 현황·리스크를 근거로 명확한 권고를 제시하는 QA는 완전히 다른 신뢰를 받는다. 이건 모듈 1(레슨 6)에서 다룬 QA의 조직 내 영향력과도 직결된다 — 이 순간을 잘 다루는 QA가 "테스트나 하는 사람"이 아니라 "의사결정에 필요한 사람"으로 인식된다.
실습 과제
과제 1 — Go/No-Go 메모 작성하기 (15분)
다음 가상 데이터를 가지고 Go/No-Go 권고 메모를 작성한다 (요약, 종료 조건 현황, 미해결 결함, 남은 리스크, 권고 순으로).
계획된 테스트 케이스의 97% 실행 완료. 심각도 "높음" 결함 0건. 심각도 "중간" 결함 2건 남아있음(둘 다 자주 안 쓰는 관리자 화면 관련). 리스크가 낮다고 판단해 얕게 본 "엑셀 내보내기" 기능이 하나 있음.
과제 2 — 압박 상황 대응하기 (10분)
"릴리즈 날짜는 무조건 고정입니다"라고 경영진이 말하는 상황에서, 종료 조건이 아직 충족되지 않았다면 QA로서 어떻게 대응할지 2~3문장으로 적는다. (힌트: 결정 자체를 막을 순 없어도, 리스크 정보를 명확히 전달하는 것은 QA의 역할이다.)
자가 체크리스트
- Go/No-Go가 QA 단독 결정이 아니라 교차 기능적 판단이라는 것을 설명할 수 있다
- Go/No-Go 논의에 QA가 제시해야 할 네 가지 정보를 나열할 수 있다
- "조건부 Go"가 실용적인 중간 선택지임을 설명할 수 있다
- 종료 조건과 리스크 데이터를 근거로 실제 권고 메모를 작성할 수 있다
흔한 실수
- QA가 결정을 혼자 내리려 하거나, 반대로 의견 자체를 안 낸다. 둘 다 QA의 역할을 오해한 것이다 — 근거를 명확히 제시하고 권고하되, 최종 결정은 교차 기능적으로 이뤄진다.
- Go/No-Go를 이분법으로만 생각한다. 조건부 Go 같은 중간 선택지가 실무에서 가장 자주, 그리고 가장 유용하게 쓰인다.
- 감(느낌)으로 의견을 낸다. "왠지 불안해요"보다 "종료 조건 3번이 미충족 상태입니다"가 훨씬 설득력 있고, 나중에 문제가 생겨도 판단 근거를 추적할 수 있다.
참고 자료
- ISTQB Foundation Level Syllabus — Test Completion — 테스트 완료 보고와 릴리즈 판단의 공식 절차
- Rex Black, Managing the Testing Process — Go/No-Go 의사결정 프레임워크를 다룬 실무서