본문으로 바로가기

저희 UX팀에서는 최근 '우리펜션 모바일 리뉴얼 기획'을 마무리하고, 곧 있을 서비스 오픈을 위해 검수 시나리오(테스트 시나리오)를 작성 중에 있습니다. 검수 시나리오는 검수 항목을 사전에 계획하여 시나리오 형태로 만든 것으로 서비스를 보다 정확하게 검수하기 위해 작성하는 문서입니다.


일부 기업에서는 검수 시나리오 없이 무작위 테스트를 진행하기도 하는데요. 이 경우 다양한 케이스에 대한 검수를 진행할 수 있지만 꼭 필요한 주요 테스트를 놓칠 우려가 있고, 검수자가 의욕 없이 테스트에 임하는 경우 검사의 정확도가 떨어질 수 있습니다. 

따라서, 서비스 오픈 전 검수 시나리오를 꼼꼼히 작성하고 시나리오에 따른 검수를 진행하는 것을 권장합니다. 검수 시나리오 작성방법은 간단합니다. 엑셀 or 구글 스프레드시트를 이용해 '좌측에는 서비스에서 발생 가능한 모든 시나리오'를 나열하고 '우측에는 우리가 최적화하려는 환경'을 기록합니다.

위에서 언급한 환경에 대한 설명을 덧붙이면 다음과 같습니다.

  • 웹 브라우저 환경 : Explorer 8~11, Chrome, Firefox, Safari 등
  • 모바일 환경 : 아이폰 시리즈, 갤럭시 시리즈 등

보다 정확한 검수를 위해서는 OS에 대한 버전도 명시하는 것이 좋습니다.

검수 시나리오 샘플 보기

그렇다면 검수 시나리오는 누가 작성해야 할까요? 전문 QC팀을 보유한 기업에서는 QC팀에서 모든 검수를 총괄하지만, 스타트업과 같은 중소규모의 기업에서는 기획자 또는 개발자가 검수 시나리오를 작성합니다. 이 경우 기획자와 개발자 사이에서도 역할분담이 명확하지 않은데요. 제 개인적인 생각은 전체 검수 시나리오는 기획자가 작성하는 것이 옳다고 생각합니다.

이유는 검수 시나리오의 정교함과 세밀함이 서비스 품질에 즉각 영향을 미치는데, 기획자는 서비스 설계 과정에서 메뉴 구조, 화면 UI, 플로차트 등의 작성을 통해 서비스에 대한 모든 케이스를 이해하고 있기 때문입니다. 따라서, 기획자가 전반적인 시나리오를 작성하고 개발자가 요구하는 기능적인 시나리오를 덧붙이면 보다 완벽한 검수 시나리오를 만들 수 있습니다.

검수 시나리오가 완성되면, 검수자 선정 후 시나리오에 따른 테스트를 진행합니다. 검수를 진행하는 과정에서 시나리오 상의 오류 및 예측하지 못했던 다양한 이슈를 발견할 수 있으며, 보다 나은 아이디어를 얻을 수도 있습니다. 이렇게 발견된 오류 및 아이디어는 수정요청 Sheet에 별도 기재하고, 개발자는 수정요청 Sheet를 기준으로 수정사항을 개선합니다. 

이러한 과정을 2~3회 반복하면 대부분의 수정 요청사항은 모두 해결되고, 보다 완성도 있는 서비스를 오픈할 수 있습니다. 서비스 검수자는 많으면 많을수록 좋으며, 중소규모의 기업이라면 모든 직원이 참여하기를 권장합니다.

마치며.

정말 잘 기획된 서비스임에도 사소한 오류로 인해 고객 이탈이 발생하는 서비스를 심심치 않게 볼 수 있습니다. 이는 곧 매출 감소로 이어질 수도 있는데요. 서비스 오픈 전 꼼꼼한 검수를 통해 모든 오류를 사전 차단하시길 바랍니다. ^^ 


신고
웹기획자 조영수
여행 카테고리 서비스 기획자. 《처음부터 다시 배우는 웹 기획》 저자. 웹기획&AXURE 강사. 웹/모바일 기획자 그룹 운영자.

댓글을 달아 주세요

  1. JINI 신고">2016.10.10 15:51 신고

    웹기획을 전혀 모르는데 웹기획자로 크기위해 채용된 신입사원입니다.
    프로젝트 산출물 중 궁금한게 있습니다..
    단위테스트 케이스/ 단위테스트 결과서 / 통합테스트 시나리오 / 통합테스트 결과서
    단위테스트와 통합테스트의 차이가 뭔지 애매모호합니다.
    테스트 케이스와 시나리오의 차이는 뭘까요...?
    그리고 제생각엔 테스트케이스를 나열하고 바로 오른쪽에 결과를 기입하는게 가독성높다고 여겨지는데.
    결과서 파일을 따로 만드는 필요성을 잘 모르겠습니다.
    시나리오도 마찬가지로 오른쪽에 오류결과, 수정사항, 처리여부 등을 쓰면 훨씬 편하고 보기좋은 문서가 될것같은데 왜 다 따로 작성하는걸까요?

    • dj 신고">2016.10.12 14:50 신고

      지도에서 위치 공유를 구현하는데 지도에서 로그인이 가능한지 로그인했을때 내가 핀해서 저장했던 위치가 나타나는지 그리고 이 위치를 공유 할 수 있는 기능이 작동되는지를 각각으로 보고 테스트 하는것이 단위테스트에 속하고
      로그인 전/후 나의 계정에 핀 값이 출력되고 공유가 되는지 등의 서로 연동되어 테스트하는것을 통합테스트라고 보시면 될것 같습니다. 하나하나의 기능에는 문제가 없으나 전체를 하나로 보고 테스트 할때는 다른 문제점들이 발생할 수 있습니다.

      프로젝트 규모와 성격에 따라 다르겠지만 위 문서는 간략한 형태의 통테 문서 인것 같습니다.. 문서에는 날짜별로 합격과 불합격 여부만 작성합니다. 그리고 보통 큰 프로젝트에서는 결과지를 따로 만들지 않고 이슈트레커(Redmine, Mantis)를 사용하여 오류나 처리 결과를 별도로 관리 합니다. 별도의 문서는 누가 어떤 일을 어떻게 처리했는지 추적이 불가능하여 사용하지 않습니다.

  2. BlogIcon 웹기획자 조영수 신고">2016.10.11 19:23 신고

    안녕하세요 Jini님 남겨주심 질문에 답변드립니다.

    먼저 단위테스트와 통합테스트의 차이는 말 그대로 테스트 범위를 의미합니다. 단위테스트의 경우 프로젝트 일부분에 집중된 테스트로 한번에 전체를 검수하기 어렵거나 프로젝트 개발이 단위별로 끝나는 경우 중간중간 진행하기도 합니다.

    또한 오른쪽에 열을 나열해서 쓰는것도 좋은 방법입니다. 다만 오른쪽에 모든 처리사항을 나열하는 경우 여러 사람이 공동으로 테스트를 진행하는 경우 테스트 결과가 꼬이는 경우가 발생합니다.

    결과서를 따로 만드는 이유는 결과를 보고할때 가공되지 않은 샘플은 중복도 많고 보기가 불편합니다. 따라서 결과내용을 보고받는 사람이 쉽게 이해할 수 있도록 따로 정리하는 절차를 가지게 됩니다.

    하지만, 위의 산출물들은 프로세스가 엄격히 정해져있거나 산출물을 제공해야 하는 위치에 있을때 모두 작성하게 되구요.

    스타트업 또는 작은 단위의 프로젝트를 진행할때는 JINI님이 말씀하신대로 약식으로 진행하기도 합니다.