작은 명세에서 테스트 케이스가 나오기까지
무한도전이라는 TV 프로그램을 대부분 잘 알고 있을 것이다. 국내 최고의 예능 프로그램 중 하나로 여섯명 정도의 출연진이 우리에게 큰 웃음을 준다.
그러나 우리가 잘 알지 못하는 브라운관 뒷편에는 50–60명이 넘는 대규모의 제작 팀 — 작가, 카메라 , 음향, 조명 담당자 등 많은 사람들이 최고의 프로그램을 만들기 위해 노력하고 있다.
나는 IT 회사에 다니며 내가 하는 일도 이들과 비슷하다. TV 프로 하나가 세상에 나가기 전 수많은 확인과 편집을 거치듯이, IT 회사도 software 출시를 하기전에 상당히 많은 준비작업과 프로그램 테스트를 거친다. 나는 스타트업에서 QA Engineer로 일하고 있다.
소프트웨어 하나가 탄생하거나 업데이트 버전이 출시 되고 나면 예상하지 못한 사용자의 동작에 뭇매를 맞기도 한다. 블리자드는 스타크래프트라는 게임 출시 후 다양한 엽기적 플레이와 버그를 이용한 플레이도 다양하게 나왔다. 이때 블리자드는 이렇게 생각했다.
“저희는 게임이 오류로 인해 강제 종료되지 않기 만을 빌었습니다”
BOB FITCH — Lead Programmer, Starcraft
사용자들은 회사가 원하는 대로 앱을 동작하지 않는다. 전화번호를 입력하라는 화면을 무시할 것이고, 로그인 버튼을 연타하기도 한다. 이는 보통 회사가 원하는 시나리오가 아니다. 이런 문제가 발생하지 않도록 노력 하는 것도 나의 일이다.
소프트웨어는 어떻게 탄생하고 그 시작은 어디서 부터일까? 여러분들이 매일 쓰는 모바일 폰에 설치된 수많은 앱을 생각하면 쉽다. 때때로 앱이 업데이트가 되었다며 업데이트 해달라는 요청을 받는 경우도 자주 발생할 것이다. 업데이트는 오류를 수정하거나 성능 향상을 위한 경우도 있지만 대부분 새로운 기능을 추가하는 경우가 많다. 이미 만들어진 기능에 무언가 추가되기 위해서는 어떤 아이디어 혹은 요청사항으로 부터 시작한다. IT업계에서는 정제된 필요한 새로운 기능 또는 그 무엇을 요구사항(Requirements)로 정의하고 시작한다. 이 작은 요구사항은 수많은 기획과 회의를 거치며 구체화 되고 문서화 된다. 하나의 사례를 살펴 보자.
요구사항 도출 배경 : 클래스팅은 러닝 플러스라는 학습 콘텐츠 플랫폼을 출시하였다. 스트리밍 서비스처럼 매달 구독료를 지불하면 모든 콘텐츠를 이용할 수 있는 방식을 채택하였다. 또한 결제 후 이용을 원하지 않는 사용자들에게 결제 비용을 돌려 줄 수 있는 환불에 대한 요구사항도 도출 되었다.
금전과 관련된 사항은 언제나 민감하다. 환불 기능 또한 제대로 동작하지 않아 돈이 새어 나가게 되면 손해를 끼칠 수도 있고, 사용자가 환불을 적절히 받지 못하는 경우는 비난을 감수해야 할것이며 서비스의 평판은 빠르게 나빠질 것이다.
그런 위험을 줄이기 위해서는 탄탄한 명세 검토와 테스트 설계와 수많은 테스트가 중요하다. 몇줄 안되는 명세에서 테스트 케이스(이하 TC)가 어떻게 도출되는지 하나의 사례를 소개하고자 한다.
1 ) 월간 플랜 가격
베이직 : 9,800원 /월
스탠다드 : 29,800원 /월
프리미엄 : 49,800원/월
2 ) 환불 정책
결제 후 7일 이내 : 수강권 이용한 적 없으면 전액 환불
결제 후 7일 이후 : 수강권 이용한 적 없으면 금액의 5% 위약금 차감 후 환불
이용 내역이 있다면 10% 위약금 차감 후 아래 수강 일 기준에 따라 환불
총 수강일의 1/2이 경과하기 전 : 납부한 금액에서 납부가격의 1/2에 해당하는 금액을 차감한 금액
총 수강일의 1/2이 경과한 후 : 환불 불가
주어진 명세가 적절히 도출되고 어느 정도 리뷰가 끝났다면, QA Engineer의 역할은 적절한 TC를 만드는 재미있는 작업이 시작된다.
첫 번째로 할 일은 적절한 밑그림을 그리는 것이다. 테스트 해야 할 부분을 어떻게 나눌지를 체크하는 부분에서 시작한다. 업계 용어로는 테스트 조건(Test Conditions) 도출이다. 비슷한 단어로 구분 조건이나 입력 조건 등으로 생각해 볼 수도 있다. 위 명세에서 이용내역이 없는 경우는 다음과 같은 두개의 조건이 있다.
결제 후 7일 이내 : 수강권 이용한적 없으면 전액 환불
결제 후 7일 이후 : 수강권 이용한적 없으면 금액의 5% 위약금 차감 후 환불
첫 두 줄의 명세에서 두 개의 조건을 쉽게 얻는다. 이건 뭐 첫 게임 한판 하고 1레벨업 후 받은 기본 전리품 박스라고 할까…
표로 가볍게 정리 해 보았다. 추가로 이용 내역이 있는 경우에 대해서도 경우의 수를 추가할 수 있다. 명세의 총 수강일의 1/2 이 경과하기 전과 후의 케이스를 추가하면 다음과 같다.
어떻게 보면 위의 명세를 그대로 복사하고 붙여넣기 한 것처럼 보인다. 그렇다고 해도 논리적으로 명세를 구성하고 정리하며 이해하는 것도 중요한 작업이라 간과해서는 안 된다.
여기에 추가로 위약금 항목을 추가했다. 조건에 따라 위약금이 있을 수 있고 없을 수 있다. 위약금은 5%, 10% 가 있는 두 곳의 케이스에 속해 있다.
명세서에는 위약금 100% 라는 부분은 없지만 환불불가 조항이 있으므로 이 부분을 고려하여 추가적으로 100%로 기록했다. 세 번째 이용내역이 있지만 사용 기간이 절반을 넘지 못한 경우는 일정 금액을 차감한 금액을 환불하기로 하였다. 이 부분은 용어를 명확히 하여 ‘차감액’으로 추가했다.
이렇게 쓰고 나서 보니 ‘결제일’이 올바른 표현은 아닌듯했다. 따라서 좀 더 명확한 ‘결제 후 경과일’로 변경하고 각각을 수식으로 변경해 보았다. 이용 내역은 Y/N으로, 결제 후 경과일은 D로, 총 수강일은 MaxD로, 결제 금액은 P 로 정리했다. 또한 결제한 당일은 0, 그다음날은 1 로 계산하기로 했다.
네개의 케이스에 대해서 이제 결제 금액만 넣어주면 어느 정도의 테스트가 될것이다. 결제금액은 위의 명세에 정해진 플랜중 베이직 플랜의 가격을 넣는다면 환불액을 예상 할 수 있다. TC에서의 ‘기대결과’ 가 여기에 해당한다고 볼 수 있다.
환불액도 결국에는 명세 조건에 따라서 고정되어 있으므로, 이부분도 수식으로 전환해두면 바뀌는 입력값에 따라 기대결과를 바로 변경 할 수 있을 것이다.
첫 번째의 경우 전액 환불이 가능하므로 결제 금액(P)와 동일한 금액을 환불한다.
두 번째는 5%의 위약금으로 결제금액의 95% 를 환불해주면 된다.
세 번째는 결제금액에서 10%의 위약금을 제하고 결제금의 1/2을 제하는 금액이 환불액이 된다.
네 번째는 환불불가로 실제 환불액은 0원이 된다.
위 표에 나와있는 4개의 TC가 완성되었다. 여기에 3개의 플랜이 있었으므로 해당 플랜별로 한번씩은 테스트를 해봐야 할 것 같다. 상황에 따라서는 한 번씩만 할 수도 있겠지만 이런경우는 테스트 하는 것이 좋겠다. 따라서 4 * 3 = 12개의 TC를 제작 완료 할 수 있다.
TC설계가 끝났으니 기쁜 마음으로 컴퓨터를 끄자. 그런데 PC방에서 나올때 로그아웃 안한 게임 계정이 생각난 것 처럼 밀려오는 찝찝함은 무엇일까?
그랬다. 이대로 테스트 케이스를 바로 실행하면 좋겠지만 아직 선정되지 못한 값들이 남아있었었다. 결제 후 경과일, 그리고 총 수강일을 정해야 한다. 테스트 데이터의 선정은 매우 중요한 작업중 하나다.
먼저 결제 후 경과일의 범위를 정한다. 결제후 경과일은 결제일은 D0 부터 시작해 D+1, D+2 … 으로 증가한다. 끝도 없다. 이번에는 총 수강일의 범위를 알 필요가 있다. 여기서 말하는 총 수강일이라는 것은 일반적으로 사용하는 용어가 아니다. 내부 정책에 의한 개념이므로 이 또한 구체화해야 한다. 명세의 월간 플랜은 한달 단위라서 한달의 개념이 중요하다. 간단하게 무조건 한달은 30일로 정할 수도 있다. 우리는 결제한 날이 1일이면 다음달 1일까지를 한달이자 총 수강일로 정했다. 결제일에 따라 총 수강일의 날짜는 조금 다양해진다. 일일이 확인하려면 1월 1일에 결제하는 경우 ~ 12월 31일에 결제하는 경우를 모두 세어보면 총 수강일의 모든 종류를 구할 수 있다. 1월의 경우 최대 31일, 2월의 경우 최대 28일, 3월의 경우 최대 31일, 4월의 경우 최대 30일 … 반복되는 패턴으로 결국 총 수강일은 28, 30, 31일로 끝남을 알 수 있다. 데이터를 입력하고 또 노트북을 닫으려다 재빠르게 노트북을 다시 오픈한다. 모니터에 지문은 묻었지만 환불 시스템을 살린 것 같다.
역시나 였다. 4년에 한번 온다는 예외 케이스 바로 윤년이다. 2월이 29일로 끝나는 경우도 있다. 따라서 총 수강일은 28~31 로 총 4종류로 확인했다! 기왕 여기까지 온 거 모든 경우의 조합을 따져보자.
플랜 3개 * D+???? * 총 수강일 4개 = 이미 무한대의 조합이다. 싸늘하다. 가슴에 비수가 날아와 꽂힌다. 오늘도 난 회사에 머물 것인가? 좋은 묘수가 없을까? 그렇다. 불가능은 없다. Yes I Can! 게임에 궁(궁극기)이 있다면 QA Engineer 에겐 ‘명세기반 테스트 설계 기법’ 이 있다. 설계기법 중 경곗값 분석(Boundary Value Analysis, 이하 BVA)을 사용해보자. 이 스킬은 초보자도 쉽게 쓸 수 있는 궁이며 광범위하게 적용 가능하다. 궁도 에너지가 생겨야 사용하듯 BVA도 명세에 조건을 정확히 분석하고 정리 되면 사용된다.
case1~2번은 각 D < 7, D ≥ 7 의 조건에서 True False 의 경계에 있는 값 : 6, 7을 선택한다. 좀 더 강도 높은 설계를 위해서 5, 8을 추가할 수 있다.
case3~4번은 각 D < MaxD / 2, D ≥ MaxD / 2의 조건에서 우선 MaxD는 28,29,30,31 네가지 케이스가 있음을 알고 있다. 총 수강일은 2로 나눈 값을 넘느냐 넘지 않느냐에 따라 달려 있으므로 2로 나누어보면
case3 D < MaxD / 2 = D < 14 | D < 14.5 | D< 15 | D< 15.5
case4 D ≥ MaxD / 2 = D < 14 | D < 14.5 | D< 15 | D< 15.5
위와 같이 정리 된다. 이 것을 기준으로 D를 선택해 보자. BVA를 적용하면 13, 14, 15, 16 으로 정리할 수 있다. 마찬가지로 좀 더 강도 높은 설계를 위해 12, 17을 추가할 수 있다.
최초의 4개 TC보다는 보강되었고 D가 무한대로 증가되어 범위가 적절히 도출되지 못한 부분의 절충안이 설계기법을 사용하여 다음과 같이 정리되었다.
위에 정리된 베이직 플랜의 TC 수 2 + 2 + 8 + 8 = 20개 * 3가지 플랜으로 총 60개의 TC를 정리할 수 있다. 해당 D와 MaxD값을 넣었을 때 예상대는 기대결과와 실제 값이 다르게 나온다면, 오류가 있다고 판단 가능하다. 하지만 현실은 다르다. 늘 테스트할 시간은 부족하다. 이런 경우 적절히 3, 4번 case에 대해서 일부만 테스트 해 볼 수도 있을 것이다. 이것은 단 하나의 답이 아니다. 어떤 관점에서 보느냐에 따라 다른 데이터를 선택 할 수도 있고 TC수나 조합 방법은 얼마든지 달라진다.
작은 명세에서 출발한 TC를 설계하는 길다면 길고 짧다면 짧은 여정이 지났다. 하지만 이게 끝이 아니다. 이제 실제 환경을 구성하고 테스트 하는 과정과 발견된 오류를 처리하는 과정도 있지만 그 이야기까지는 오늘 할 이야기는 아닌것 같다. 게다가 분명 아직도 명세에는 우리가 알아 채지 못하는 오류가 존재할 수 있고 명세나 세부 사항이 바뀌는 일도 종종 발생하기도 한다. 결국 하나의 명세 즉 요구사항이 소프트웨어에 담겨 출시되고 안정적으로 돌아가기까지는 이 수많은 과정들이 반복되고 많은 사람들의 노력이 담긴다는 점을 생각해 줬으면 좋겠다.
극히 일부의 명세를 TC로 만들었지만 실제로는 거의 무한대에 가까운 모든 조건을 다 테스트하는 것은 불가능에 가까운 일이다. 그렇기에 그럼에도 모든 소프트웨어의 오류는 끝도 없이 존재한다.
내가 오류 없는 좋은 품질을 위해 노력하는 이유는 단 하나다. 내 손을 거친 소프트웨어를 통해 불편함을 느끼지 않고 편하게 즐기면서 인간으로서 더 IT기술을 활용하여 더 나은 삶을 살게 하고 싶다는 마음 뿐이다.
오늘도 오류없는 좋은 품질의 소프트웨어를 출시하기 위해 노력하는 모든 분들께 존경을 표하며 이 글을 마무리 하고자 한다.
