QA 테스트 계획 생성기(QA Test Plan Generator)

오늘 건너뛴 QA 계획이 내일의 P0 장애가 된다

2023년 9월, 호주 2위 통신사 Optus는 일상적인 설정 변경 하나로 고객 1천만 명을 14시간 동안 오프라인 상태로 만들었습니다. 원인은 복잡한 것이 아니었습니다. 알려진 edge case에 대해 검증되지 않은 네트워크 라우팅 업데이트였습니다. 누군가 test plan을 건너뛴 것입니다.

모든 PM은 충분한 QA 없이 무언가를 출시해본 경험이 있습니다. 때로는 운이 좋고, 때로는 그렇지 않습니다.

테스트는 엔지니어링 문제만이 아니라 제품 의사결정이다

대부분의 PM이 QA에서 틀리는 지점은 이것입니다. QA를 엔지니어링 concern으로만 본다는 점입니다. "엔지니어가 테스트를 쓰겠지." 하지만 엔지니어는 자신이 만든 것을 테스트합니다. QA test plan은 사용자가 경험하는 것을 테스트합니다. 둘은 다릅니다.

Capgemini의 2024 World Quality Report에 따르면 조직의 60%가 여전히 critical defect를 프로덕션에서 발견하고 있으며, 릴리스 후 버그를 고치는 평균 비용은 개발 중 발견할 때보다 6배 높습니다. 그런데도 일정이 빡빡해지면 가장 먼저 잘리는 것이 QA planning입니다.

PM의 역할은 test case를 직접 쓰는 것이 아니라, 사용자 관점에서 "작동한다"는 말이 무엇인지 정의하는 것입니다. 어떤 user flow가 critical한가요? 어떤 브라우저와 기기가 중요한가요? 어떤 accessibility standard를 맞춰야 하나요? API가 500을 반환하면 무슨 일이 일어나야 하나요? 이런 질문은 테스트 결정처럼 보이지만 사실은 제품 결정입니다.

이 프롬프트가 돕는 방식

이 프롬프트는 feature context를 바탕으로 구조화된 QA test plan을 생성합니다. 기능, 플랫폼, 핵심 user flow, 리스크 영역을 지정하면 functional test case, edge case scenario, regression check, cross-browser/device testing matrix, performance benchmark, accessibility check를 모두 뽑아줍니다.

특히 edge case coverage에서 강점이 큽니다. PM이 흔히 놓치는 failure mode, 예를 들어 empty state, 최대 입력 길이, 동시 사용자, 네트워크 timeout, permission boundary 같은 상황을 체계적으로 훑어줍니다.

언제 꺼내 쓸까

• 다음 주에 기능이 나가는데 아무도 test plan을 아직 쓰지 않았다는 걸 깨달았을 때
• critical flow가 바뀌어서 regression coverage를 다시 짜야 할 때
• 모바일이나 태블릿 같은 새 플랫폼으로 확장하며 device-specific test scenario가 필요할 때
• 최근 production incident가 있었고, 비슷한 문제를 앞으로는 QA에서 잡고 싶을 때
• accessibility audit을 앞두고 WCAG 기준을 선제적으로 점검해야 할 때

좋은 결과물의 모습

좋은 QA test plan은 우선순위별로 정리되어 있습니다. 매 릴리스마다 반드시 도는 P0 smoke test, 기능별 P1 test, edge case 중심의 P2 test 같은 식입니다. 각 test case는 명확한 precondition, step, expected result를 가져야 합니다. 또한 부정 경로를 반드시 포함해야 합니다. "사용자가 로그인에 성공한다"뿐 아니라 "사용자가 비밀번호를 다섯 번 틀린다"까지 들어가야 합니다. QA 엔지니어가 추가 질문 없이 바로 실행할 수 있는 문서여야 합니다.

참고 자료

• World Quality Report 2024 — Capgemini
• The Cost of Software Defects — NIST