티스토리 뷰

목차



    반응형

    9. 디버깅은 PO가 하게 돼요

    💬 “테스트는 QA가 한다고 했잖아요…”

    (그런데 왜 또 내가 다 보고 있지?)

     


    📍 상황 예시

    PO 데이븐은 “사용자 맞춤 알림 설정” 기능을 출시했다.

    기획도 잘 되었고, 디자인도 깔끔했고,

    개발팀도 일정 맞춰 작업을 끝냈다.

     

    QA팀은 테스트를 마쳤다고 했고,

    릴리즈도 무사히 진행됐다.

     

    그런데 다음날부터 사용자 피드백이 쏟아졌다:

    • “푸시 설정했는데 알림이 안 와요”
    • “초기 설정값이 이상해요”
    • “이벤트 알림은 되는데 나머진 안 돼요”

    결국 데이브는 직접 디버깅에 돌입한다.

    테스트 기기를 바꿔가며

    시나리오를 수십 번씩 돌려보는 자신을 보며 문득 생각했다:

    “QA는 뭐 했지? 왜 또 내가 다 하고 있지?”

     


    🔍 왜 이런 문제가 생길까?

    디버깅은 PO의 일이 아니지만,

    현실에선 자주 PO가 맡게 된다.

    문제 설명
    QA와 PO 역할 경계 모호 범위가 명확하지 않음
    실제 사용자 흐름 미반영 테스트 시나리오 부족
    예외/경계 케이스 누락 사용자 상황 다양성 간과
    QA 인력 부족 PO가 대신 책임지는 구조

    🧠 이렇게 풀 수 있어요

    ✅ 1. QA는 기능을, PO는 ’경험’을 본다

    QA는 명세 기반 체크,

    PO는 사용자 관점 흐름 확인.

    • QA: “작동 여부 확인”
    • PO: “전체 맥락에서의 경험 확인”

    ✅ 2. PO 디버깅은 ’설계의 연장선’이다

    디버깅은

    “문제를 잡는 과정”이 아니라

    “내가 의도한 흐름이 실제로 구현됐는지 검증하는 과정”

    → 기획자의 책임이자 마지막 점검이다

    ✅ 3. 테스트 시나리오를 PO가 정리하자

    시나리오 예상 동작 확인 결과
    앱 설치 후 알림 설정 전체 OFF
    특정 알림 ON 후 앱 재실행 설정 유지 ⚠︎
    이벤트 알림만 ON 알림 수신됨

     

    ✅ 4. 문제를 ’현상’이 아닌 ’경로’로 전달하자

    • “알림이 안 와요” ❌
    • “설정 ON → 로그아웃 → 재로그인 후 테스트 → 미수신” ✅

    → 이렇게 전달하면 개발자 디버깅도 빨라진다

    ✅ 5. PO의 테스트 시간도 일정에 포함되야 한다

    PO가 QA 역할까지 한다면

    그 시간은 기획 일정의 일부로 반영해야 한다.

    • “릴리즈 전 PO 검수 필요 1일”
    • “시나리오 기반 확인 포함 일정 명시”

    💬 PO의 말 한마디

    “PO가 디버깅까지 하는 이유는
    내가 기획을 더 잘 이해하기 위해서입니다.

    하지만 그 일이 반복되면,

    기획은 자꾸 뒤로 밀리게 돼요.

    그래서 우리는 그 구조부터 개선해야 해요.”

     

    반응형