기획은 재밌는데 테스트는 하기 싫다
기획자에게 테스트의 과정이 가져다주는 것들
입사 후 나에게 주어진 임무는 '테스트'였다.
아무리 작은 기획개발 건이라고 해도 문제없이 돌아가기 위해서는 예상되는 모든 상황이 기획의도대로 작동하는지 보기 위한 절차가 필요하고, 그게 바로 테스트다.
물리적 건축 설계나 제조업과 비교하면, 웹과 앱이 살아가는 소프트웨어의 가장 큰 장점은 유연성이다. 바로 이 시뮬레이션이 가능하고 쉽게 수정할 수 있기 때문에 가능한 일이다. 물론 기획자가 되기 전에는 상상조차 하지 못했던 귀찮은 영역이긴 하지만 말이다.
수많은 초보 기획자에게 용기와 절망을 동시에 주는 테스트에 대해 이야기해보려고 한다.
테스트해서 생각지 못한 오류를
발견했을 때 희열을 느껴요:)
얼마 전 코 멘토에서 멘토링을 하다가 기획자가 되고 싶은 이유에 대해서 이렇게 쓰인 자소서를 봤다. 묘한 동질감과 이질감이 동시에 들었다.
신입시절의 나는 테스트에서 찾아내는 오류에 희열을 느꼈다. 상식과 기획 사이 어딘가에서 발견한 오류를 개발자에게 던져줄 때 묘한 승리감도 있었다. 신입시절 참여한 한 프로젝트에서 한 개발자는 나에게 농담 삼아 '악의적 테스트'를 한다며 그만 좀 오류 등록을 하라고 한 적이 있다.
그런 말을 들으면서 나는 은연중에 '나는 정말 훌륭한 기획자야'라고 느끼며 우쭐댔다.
하지만, 나는 처음에 몰랐다. 테스트는 오류를 발견해내는 것이 끝이 아니었다. 테스트의 목적은 오류를 찾아내는 것이 아니라, 오류를 해결하는 것이다. 그리고 이렇게 오류를 말끔하게 해결하기 위해서는 두 가지 절차가 필요하다.
오류가 발생하는 케이스가 재현이 가능하도록 정확하게 개발자에게 공유하기
오류 상황에 대한 원인을 함께 이해하고 적절한 아웃풋 정의하거나 만약 한계가 있을 경우 대안을 빠르게 제공하기
프로젝트 방법론에 따르면 테스트란 엄연히 QC(Quality control)의 몫이지만, 기획자의 머리 속에 있는 모든 내용을 개발자와 QC에게 전달할 수도 없고 기획자가 모든 것을 미리 예지 할 수도 없다. 그래서 기획자도 결국은 테스트에 참여하게 된다. 하지만 단순히 테스트만 할 수도 없다. 개발 과정 내내 예상치 못한 대응이 기획자를 기다린다.
기획자가 기획자답게 테스트에 참여하기 위해서는 오류를 수정할 수 있도록 위의 두 가지 절차를 보여줘야 되는 것뿐만 아니라, 중간중간 예상치 못했던 부분들에 대해서는 기획을 추가하거나 제외하거나 하면서 전체적인 품질 관리를 해줘야 한다.
그리고 바로 이런 부분을 보고 배우라는 의도에서 대부분의 신입 기획자들은 테스트에 동원된다. ( 단지 일손이 부족해서 테스트시키는 건 아니다)
그러나 어렸던 나를 포함해서 대부분의 신입들은 이런 의도를 깨닫지 못하고, 오류 찾기에 쾌감을 느낀다. 개발자에 대한 '지적질'에 머물러 버린다. 어쩌면 예전 그 개발자분의 말처럼 '악의적인 테스트'의 수준이었던 건 아니었을까. 이런 것을 타고난 기획 소질이라고 말할 수 있을까?
이젠 테스트가 하기 싫어요
신입 기획자가 느끼는 신선함이 슬슬 만료될 쯤이 되면 천직 같던 테스트도 점점 지겨워진다. 산더미 같은 테스트 케이스만 봐도 천덕꾸러기 같고 답답하다. 그때쯤 깨닫게 된다. 왜 프로젝트 과정 중 가장 지루하고 가장 몸도 마음도 힘든 때가 테스트 시점이라고 하는지 말이다. (물론 오픈하고 나면 시원섭섭하지만 그 직전이라 더더더더욱 힘들게 느껴진다)
'기획자'라는 직업의 소위 '종특'은 새로움을 창조하는 과정이 훨씬 재밌다는 점이다. 어서 오픈시켜버리고 다시 설레는 새로운 기획이 하고 싶어 지는 것도 당연한 일이기도 하다. 이 밖에도 몇 가지 이유로 테스트가 끔찍하게 보일 뿐이다.
다른 기획이 빨리 하고 싶다
테스트했을 때 항상 모래밭에서 열쇠 찾기처럼 잔잔한 오류만 나온다
테스트했을 때 항상 기획을 다 바꿀 만큼 심각한 오류만 나온다
테스트하느라 한 개 화면을 너무 많이 봐서 오류도 안 보일 지경이고, 게슈탈트 붕괴로 다 이상해 보인다
테스트를 너무 많이 했더니 벌써 개선 전의 UI가 기억이 안 나고 익숙해져 버렸다.
이유를 나열해도 끝이 없지만 사실은 그냥 테스트 너무 귀찮고 싫다. 그래서 때로는 '나는 기획자야!!'라고 외치며 테스트는 개발자나 QA, QC들에게 다 미뤄버리고 싶어 지는 것도 사실이다. 꽤 오랜 기간 일해온 나 역시 테스트 기간이 눈에 보이기 시작하면 숨이 막힌다.
그러나 테스트는 위대하다. 신입 기획자 시절에는 테스트 기간을 전략적으로 잘 이겨내야 하는 확실한 이유는 '기획력'에 있다.
테스트와 테스트 케이스로 키워지는 기획력
수많은 주니어들이 무엇을 하면 기획력이 키워지냐고 묻는다. 학문적인 대답이 아닌 경험적인 대답을 해본다면, 자는 단연코 '고민하며 테스트를 할 때'라고 이야기한다.
초창기 웹 기획 관련 서적을 보다 보면 기획자의 중요한 역할로 2가지를 중요시했다.
확장성에 대한 고려
대부분의 케이스에 대한 고려
그리고 UX라는 개념이 대중화되면서 한 가지가 더 늘어났다.
고객의 디바이스 환경과 콘텍스트를 고려한 UX에 대한 기준과 목표
처음의 두 가지는 기존 시스템이나 새로 만들 시스템에 대한 이해가 제일 중요하다. 시스템은 정책서로만 이해하기 어렵다. 시스템을 파악하기 위해서는 결국은 많이 사용해볼 수밖에 없는데, 이용자로서의 사용은 아무래도 사용 방식의 다양성이 제한된다. 게다가 정상적인 서비스의 이용 패턴을 넘어선 이용도 불가능하다. 때문에 테스트는 인위적이지만 시스템을 사용하는 기간을 늘려 시스템에 대한 월등한 이해도를 높여준다. 더불어 상상만 했던 신규 서비스에 대한 테스트도 신규 시스템에 대해 누구보다도 잘 이해할 수 있도록 도와주게 되어있다.
또한 UX와 함께 강조된 후자의 역할에 의해 테스트는 더더욱 세분화될 수밖에 없게 됐고, 그 경험은 더더욱 중요해졌다. 디바이스의 종류와 해상도의 종류, OS 의 다양한 버전뿐 아니라 어쩌면 이용자의 수만큼 다양화되고 파편화된 이용 환경은 테스트로만 확인할 수 있다. 그리고 바로 그런 고려가 '자연스러운 인터렉션'을 만들어 주기 때문이다. 때문에 다양한 테스트 경험은 인터렉션에 대한 직접적인 고려가 된다. (새로운 아이폰과 안드로이드폰이 나올 때마다 전 세계의 기획자와 개발자는 기쁘면서도 슬프다ㅜㅜ)
많은 후배들이 '척하면 척'하고 프로세스를 짜고 기획일 하면서 이슈를 미리 예측하고 기획할 수 있게 되는 시점을 묻는다. 그리고 선배들의 고도화된 스토리보드 디스크립션을 보며 감탄한다.
그 많은 예외사항과 제약 상황은 사실 선배들의 산출물을 아무리 본다고 해도 체화하기 어렵다. 가장 좋은 기획 학습은 스토리보드 연습이 아니라 테스트 케이스를 모두 이해하고 하나하나 해보는 쪽이다. 하나하나 신경을 집중하고 테스트를 한다면 어떤 교육보다도 훨씬 빠르게 배울 수 있다.
예를 들어 주문서를 테스트한다고 생각해보자.
주문서에 진입한다고 했을 때 '나'자신을 기준으로만 기획한다면 '일반회원'에 '임직원 회원'기준으로만 생각해볼 수 있게 된다. 하지만 테스트 케이스적 사고관에서는 일반회원 외에 '청소년 회원' '외국인 회원' '본인인증 없이 가입한 간편 가입회원' 등 내가 접하지 못했던 케이스를 떠올리고 인위적으로라도 체험해 볼 수 있다.
게다가 동일 주문서를 안드로이드폰과 IOS폰으로 접속했을 때와 웹으로 접속 시와 앱으로 접속 시에도 나눌 수 있다. 여기에 폰의 OS 버전별 제약사항도 떠올릴 수 있다.
이런 식으로 테스트 케이스는 의도한 동작을 여러 조건에 따라서 어떻게 동작하는지 세세하게 정의된 것들을 확인하는 작업이 되고, 만약 부족하면 추가로 디테일을 추가하는 기획 작업이 되기도 한다.
그리고 이 경험이 쌓인다면 테스트를 하기 전부터 디테일을 챙길 수 있는 능력이 커지는 것이다.
아무리 잘해도 빠지는 부분은 있다
이런 아주 중요한 의미가 있음에도 여전히 귀찮은 존재가 바로 테스트다. 한두 번 해보고 나면은 테스트 기간이 얼마나 고되고 바쁠지 알기에, 다음 테스트가 더 귀찮게만 느껴질 수 있다.
하지만 반대로 엄청나게 고된 테스트를 만날 때 기획자가 느끼는 또 다른 감정은 자괴감이다. 배울 것들이 너무 많다는 것을 체감할 때 스스로 작게만 느껴지기 쉽기 때문이다. 특히나 내가 직접 기획한 것이라면 케이스에 대해서 고려하고 빠진 것들을 발견할 때마다 더더욱 자괴감은 커지기 마련이다.
그렇다면 초보 기획자에게 최대한 스트레스 안 받는 테스트가 되려면 어떤 마음가짐을 가지는 것이 좋을까?
첫째, 테스트가 기획을 보강할 기회임을 인정하되, 오픈에 대한 최소한의 기준을 정의한다.
아무리 완벽주의적인 태도로 기획을 한다고 해도 빠지는 것은 있을 수 있고, 구현 도중 생각도 못한 오류를 만날 수도 있다. 테스트를 통해 완벽해지기만 바라보면 스트레스가 더 쌓인다. 완벽한 테스트 결과를 위해 오픈을 무한정 미룰 수는 없으니까 일정 시점을 기준으로 꼭 필수적으로 처리해야 하는 것을 필터링해줄 수 있어야 한다.
만약 해결 불가능한 경우, 개발자에게 의사결정 피드백을 빨리 내줄 수 있는 '기획 우선순위'에 대한 기준을 미리 마련해둔다면 모든 오류건에 스트레스받을 필요는 없다.
그리고 항상 모든 개발 건에는 '오픈 후 잔존 결함 처리'의 기간이 있기 마련이다.
둘째. 유사한 개발 건의 테스트 케이스들을 묶어서 저장해 두고, 다음번의 기획 시에 참고자료로 사용하기 위한 '지식 저장'의 과정이라고 생각하자
'마이크로 기획'을 위해서는 '단위 테스트 케이스'를 모으고 처음 사용부터 이탈까지 시나리오를 익히고 싶다면 다람쥐가 도토리를 모으듯 프로젝트들의 '통합 테스트 케이스'를 모아 보면 된다. 스스로 기획하는 것보다 더 다양하고 넓게 모아서 분석해볼 수 있다. 어쩌면 선배가 거창하게 내밀어준 SB에 적힌 함축적 의미의 디스크립션보다도 생생한 시스템에 대한 지식을 얻을 수 있을 것이다.
그리고 꼼꼼하게 처리한 선배들의 노하우도 흡수할 수 있다. 만약 내가 다시 신입이 된다면 내 시간을 털어서라도 소위 '큰 건'의 테스트를 돕고 시험족보를 외우듯 선배들의 테스트 케이스를 씹어먹으려 할 것이다.
다시 말하지만, 테스트는 지겹다
그런데 지루하게 길다는 건 그만큼 공부할 게 많다는 뜻이다
씹어먹자, 테스트!
