답변.

릴리스 단계에서 수동 테스트를 조직하는 것은 배포할 준비가 된 제품 버전에서 결함을 빠르고 효과적으로 찾기 위한 일련의 조치로, 가장 중요하고 자주 사용되는 기능에 중점을 둡니다.

질문 배경: 과거에 릴리스는 종종 "야근 대작전"과 함께 진행되었습니다: 테스터는 모든 것을 급하게 확인하느라 테스트 품질이 저하되고, 버그가 프로덕션으로 넘어가며, 자원이 비효율적으로 소모되었습니다. 점차적으로 명확한 우선순위 시스템을 통해 더 적은 시간 안에 더 많은 결과를 달성할 수 있음을 깨달았습니다.

문제: 릴리스 전에 테스트할 수 있는 시간이 제한되어 있어 모든 것을 확인할 수 없으며, 사람의 피로, 서두름, 스트레스와 같은 인간적인 요소가 증가합니다. 종종 치명적인 버그는 배포 후에만 드러나며, 제품의 명성을 훼손하고 팀에 혼란을 야기합니다.

해결책:

비즈니스, 분석가, 개발팀과 협력하여 중요하고 비즈니스에 중요한 시나리오를 평가합니다.
가장 자주 사용되거나 위험한 시나리오로 '컷팅' 시나리오라고 하는 릴리스 체크리스트를 작성합니다.
시스템 시작, 로그인 프로세스, 주문 처리, 결제 등을 수동으로 확인하여 최종 스모크 및 샌리티 테스트를 실시합니다.
테스트 데이터, 발견된 결함에 대한 보고서, 개발팀과의 커뮤니케이션에 대한 책임을 명확히 구분합니다.

주요 특징:

버그 우선순위 설정: 가장 중요한 것을 먼저 찾아서 에스컬레이트합니다.
간단하고 신속하게 실행할 수 있는 테스트 케이스 및 체크리스트 사용.
개발팀과의 빠른 커뮤니케이션으로 신속한 수정.

함정 질문들.

릴리스 전 모든 애플리케이션을 "과잉 검증"할 수 있을까요?

아니요, 일반적으로 전체 수동 테스트를 위한 시간이 없으며, 핵심 시나리오에 집중하는 균형 잡힌 접근 방식이 더 좋은 결과를 제공합니다.

릴리스 전에 "사소한" 버그를 보고하여 팀이 미리 알 수 있도록 하는 것이 좋을까요?

아니요, 릴리스 모드에서는 치명적이고 차단적인 결함만 에스컬레이트해야 하며, 덜 중요한 것은 알려진 문제로 처리하여 배포 후에 작업합니다.

릴리스 단계에서 상세한 테스트 케이스를 수동으로 작성하는 것이 필수인가요?

아니요, 종종 체크리스트나 테스트 케이스에서 가져온 미니 스크립트로 작업하는 것이 더 쉽고 빠르며, 관련 시나리오를 신속하게 검토할 수 있습니다.

일반적인 실수 및 안티패턴

마지막 순간까지 테스트를 미루는 것 — 이로 인해 모든 것이 서두르며 품질이 저하됩니다.
핵심 시나리오를 희생하면서 드물게 사용되거나 덜 중요한 시나리오를 확인합니다.
릴리스 직전 최종 스모크/샌리티 테스트가 없습니다.

사례 연구

부정적 사례

릴리스 테스트가 밤에 진행되고, 문서를 대충 확인하며, 결제의 중요 흐름을 잊어버립니다. 다음 날 사용자들이 대량으로 주문 결제를 할 수 없습니다.

장점:

높은 검사 속도.

단점:

치명적인 버그가 발견되지 않음.
야간 스트레스와 커뮤니케이션 누락의 위험.

긍정적 사례

릴리스 전에 오직 중요한 시나리오(로그인, 결제, 주문 저장, 파트너와의 통합)에만 집중합니다. 체크리스트를 통해 결과를 진행하며 버그를 즉시 에스컬레이트합니다.