테스트 케이스(TC)로 QA 하기
어드민 기획자의 예시로 보는 기능 테스트
고객과 직접 소통을 하는 프런트 기획을 할 경우, 작은 오류 하나가 굉장히 치명적일 수 있다. 제 아무리 꼼꼼하게 기획한 문서로 꼼꼼한 개발자가 기능을 구현한다 하더라도 예외상황에서 발생하는 오류까지 잡아내서 처음부터 완벽하게 구현할 수는 없다.
만약 제대로 테스트를 하지 않고 배포한다면?
예를 들어, 결제가 완료되었는데 시스템의 오류로 인해 결제가 되지 않았다고 서버에서 인식하여 '결제가 완료되지 않았습니다.'라는 메시지가 떠서 고객이 이중 결제를 했다고 치자. 분명히 결제 여부를 인식하는 로직에서 문제가 발생한 것이기 때문에, 그 로직을 수정하지 않는 한 동일한 문제를 겪는 고객이 계속 생긴다. 그러면 결제 서버를 잠시 닫아놓아야 하고, 결제가 안 되는 것을 고객에게 이해시키기 위해 적절한 공지를 띄워야 하며, 짧게는 몇 분, 길게는 몇 시간 동안 수많은 고객이 이탈하며 영업 손실이 생긴다. 이중 결제를 한 고객을 일일이 찾아내 cs보상을 하며 죄송하다는 전화를 돌려야 한다. 대외적으로는 기사에 'ㅇㅇ, 중복 결제로 소비자 피해 몇십억...'이라는 제목으로 글이 올라와 모든 소비자가 분노한다. 경쟁사는 이 때다 싶어 '결제시스템의 중요성'으로 기술 블로그에 글을 올린다. 영원히 그 회사의 결제시스템은 Worst case로 개발자, 기획자들에게 케이스 스터디의 주제가 된다.
정말이지 아찔하다. 기획자가 굳이 수많은 테스트 케이스를 만들어서 테스트를 해야 하는 이유를 조금만 생각해보아도 충분히 알 수 있다. 프런트 쪽이 아닌 백엔드 쪽 서비스를 구현할 때에는 위의 예시와 같이 고객에게 보이지 않다 보니 상대적으로 그 리스크가 크지는 않을 때가 만다. 그러다 보니 테스트에 대한 강박이 프런트 기획자와 같이 크지 않아서 테스트를 꼼꼼히 하지 않는 경우가 발생하고, 나중에 결산이나 월 마감을 할 때가 되어서야(실무자가 기능을 사용할 때가 되어서야) 수면 위로 문제가 드러나 수습을 하느라 애먹는 경우가 종종 있다. 나 또한 테스트를 꼼꼼히 해야 하는 이유를 몰라서 여러 실무자와 팀원들을 힘들게 한 적이 있다.^^;
어드민 기획자라서 놓칠 수 있는 부분
얼마 전까지만 해도 나는 '사내에서 사용하는 서비스인데, 작은 오류는 중요하지 않을 거야'라는 생각 때문에 그동안 QA를 할 때 TC(Test Case)를 따로 작성하지 않고 테스트를 진행했었다. 그래서 충분히 시간을 가지고 다양한 시나리오로 기능을 사용하지 않은 채로 배포를 했었다. 그리고는 배포 후에 오류가 발생할 때마다 개발자에게 작업 요청을 해야 해서 귀찮은 작업이 늘어났다. 나중에 오류 수정을 요청하면, 담당자들은 다시 그 프로젝트 작업 내용을 들여다봐야 하기 때문에 학습 시간이 들어가 두 배 이상 오래 걸린다. 이런 시행착오 끝에야 나는 내가 작성한 PRD를 참고하여 테스트 케이스를 작성하고 수많은 시나리오로 테스트를 거친 후에 운영단에 배포할 수 있게 되었다.
시나리오는 구체적으로 쪼갤수록 끝도 없는 것이 사실이다. 그래서 적당히 그 depth를 조절해서 작성하면 좋다. 테스트 케이스에서 발견되지 못하는 시나리오에서의 오류를 발견하려면 '빌런'이 되어 별 괴상망측한 테스트 데이터를 마구 넣어보는 것도 방법이다. 그러나 아직도 배포를 한 후에 상상도 못 한(ㄴㅇㄱ) 시점에서 오류가 나오는 것을 보니 아직 덜 빌런인가 보다. 가짓수를 최대한 많이 상상하며 테스트를 할 수 있는 것도 기획자의 능력인 것 같다.
테스트 케이스(TC)를 작성하는 방법
테스트 케이스는 오류를 잡아내고, 기획 의도에 대한 이해가 모두 동일한 지를 보기 위함이다. 그렇기 때문에 나뿐만 아니라 나와 협업을 한 모두가 이해할 수 있도록 보기 편하게 작성하는 센스가 필요하다. 아래에 간단하게 테스트 시나리오를 정리한 문서의 일부를 작성해 보았다. 문서에 상위 매니저의 승인이 필요한 경우, 승인 요청과 승인을 할 수 있는 어드민 메뉴가 있다고 해보자. 이 메뉴는 비서가 대표에게 OK 사인을 받는 것과 같이, 문서가 '통과'되었다는 것을 본인이 아닌 '제 3자'에게 검증받는 것이 목표이다. 이러한 목표 하의 가정은 아래와 같다.
1. 각 문서에는 '요청 전', '승인 중', '승인 완료', '반려'로 4개의 상태 값이 있다. --- 문서가 통과되었는가?
2. 요청자와 승인자는 동일할 수 없다. --- 제 3자에게 검증받는가?
3. 개인은 요청 권한과 승인(반려) 권한을 동시에 가질 수 있다. --- 내가 누군가의 문서를 통과시킬 제 3자가 될 수 있는가?
테스트 케이스 예시상황과 기대 결과는 모호한 표현은 피하고 최대한 구체적인 행동 단위로 작성해야 보기가 좋다. 나는 최근 테스트를 진행할 때 개발이 모두 끝내고 나서야 작성하긴 했지만, 다른 프로젝트를 시작해야 했기 때문에 시간이 촉박하다고 느꼈다. 그래서 개발 리뷰를 마치고 개발이 진행될 즈음, 이 프로젝트에 대한 기억이 생생할 때 작성해두면 더 효율적으로 일을 할 수 있을 것 같다.
테스트 결과 전달하기
각 케이스 별로 테스트 결과가 '성공'이어야 하는지, '실패'이어야 하는지와, 이에 따라 기대되는 결괏값을 적어본다. 그리고 테스트 결과 PASS, FAIL(의도와 다름), N/A(결과가 없음), BLOCK(FAIL이나 N/A에 영향을 받음) 중 어떤 결과가 나오는 지를 표시하고, PASS가 아닌 경우 비고란에 어떤 조치를 원하는 지를 적어둔다. 수정 요청을 하나하나 티켓을 따서 요청하는 것이 대부분이지만, FAIL이 난 항목과 그 이유를 따로 적어두어야 하는 이유는, 시간이 지나서 2차 테스트를 하거나, 시스템 로직을 외부에서 점검할 때 참고할 수 있기 때문이다.(회사 내부 정보를 다루는 어드민은 정기적으로 외부에서 감사를 받기도 한다.)
<테스트 결괏값>
1. PASS
2. FAIL(의도와 다름)
3. N/A(결과가 없음)
4. BLOCK(FAIL이나 N/A에 영향을 받음)
테스트 경우의 수 생각하기
가장 기본적으로 경우의 수를 생각하는 방법은 변수와, 변수 각각의 상태 값이 몇 개인지를 알면 된다. 가령 변수가 2개이고, 각 변수에서 가능한 경우의 수가 3개씩 있다고 하자. 그러면 가장 기본적으로 생각할 수 있는 시나리오는 3*3 = 9개이다. 상의에 검정, 노랑 상의가 있고 & 하의에 바지, 치마가 있을 경우 총 4가지의 경우의 수가 나오는 거라고 생각하면 쉽니다.
그러나 이 변수가 회원가입 시 비밀번호 인증단계와 같이 무수한 경우의 수가 나올 수 있으며 중요한 단계라면 테스트 케이스로 다 정리하지 못하는 특이한 시나리오로 최대한 많이 테스트를 시도해보면 좋다. 반대로 하나의 변수에 대한 유효성 검사가 끝난 뒤 → 오류가 없을 경우에만 두 번째 변수의 유효성 검사가 시작된다면 3*3 = 9가 아닌 3+3 = 6개의 시나리오로 테스트해도 충분하기도 하다.
공장에서 물건을 만들어도 항상 검수는 사람이 눈으로 확인해야 한다. 사람이 시작해서 사람 손을 거쳐 완성되는 기능이 완벽하게 오류가 없을 거라고 믿지 말자. 언제나 완벽한 기획, 완벽한 개발은 없다. 상황에 따라 메뉴/기능이 제대로 구현되지 않는 경우가 너무나 많으니 여러 상황이 있을 거라는 점을 인지하고 대비하는 것이 최선의 방법인 것 같다.
<메뉴/기능이 제대로 구현되지 않는 이유>
- 실무자의 요구사항을 기획자가 잘못 이해한 경우
- 기획자가 이해를 못 한 채로 기획하는 경우
- 기획서가 명확하고 구체적이지 않은 경우
- 기획 의도를 개발자가 잘못 이해한 경우
- 중간에 변경된 내용을 기획자가 개발자에게 전달하지 않은 경우
- 개발자가 기획서의 일부분을 누락한 경우
- 기술적인 한계
