서비스 분석 및 문서화를 위한 테스트
문제가 터질 거면 테스트할 때 터지는 게 맞다.
사진: Unsplash의Giorgio Trovato내부 시스템 구조를 뜯어서 확인하지 않는 이상 어떤 서비스를 분석하고 어떻게 만들어진 건지 알기 위해선 여러 가지 테스트를 거칠 수밖에 없습니다. 특히, 문서화를 위해서는 서비스를 다각도로 만져보면서 어떻게 동작하는지 충분히 이해하는 연습이 필요한 것 같습니다. 저는 서비스를 테스트할 때 3가지를 생각합니다.
1. 정석이 있으면 그 반대에는 야매도 있다.
서비스와 기능을 이용자가 항상 정상적인 시나리오로 이용했으면 좋겠지만 그렇지 않은 경우도 있습니다. 귀찮아서 그럴 수도 있지만, 잘 몰라서 그럴 수도 있기에 어떻게 써야 하는지 정답 시나리오를 먼저 찾아내고, 이용자가 목표까지 도달할 수 있도록 안내해야 합니다. 혹시나 중요하고 필요한 절차를 무시하고 넘어갈 수 있는지 비정상적인 시나리오로도 테스트해 보면 문서화할 때 중요한 테스트 지점을 발견할 수 있습니다.
2. 다른 사람의 비정상적인 행동도 계산한다.
게임을 플레이하는 유저들이 기발한 버그를 찾아내듯 테스트할 때 이상한 짓이란 이상한 짓은 다해봅니다. 예를 들어 입력 필드가 있다면 다양한 값을 넣어봅니다. 글자수 1,000자도 넣어보고 숫자를 입력하는 공간에 몇천억을 넣기도 합니다. 값을 지우거나 논리적으로 맞지 않는 값을 넣다 보면 어느 정도의 제약이 있고 어떻게 둬야 하는지 등에 대한 정보를 알아낼 수 있습니다.
3. 서비스는 나에게 분명 숨기고 싶은 게 있다.
가끔씩은 약간 의심병 환자처럼 테스트합니다. 특히, 계정이나 권한에 따라서 특정 기능이 숨김 처리 되어 있다거나 다르게 동작하는 경우도 있기 때문에 상상력을 발휘하면 서비스의 모르는 모습을 발견할 수 있습니다. 시간대별로 또는 디바이스/채널별로 등 항상 다양하게 이용해 보고 테스트하면 차이점이나 취약점을 조기에 발견하고 개선할 수 있습니다.
분명 서비스를 잘 알고 있다고 생각하다가 꼼꼼하게 테스트를 하다 보면 서비스의 모르는 모습을 발견하고 당황하거나 신기해할 때가 종종 있습니다. 이용자의 만족도와 서비스 품질과 직결하는 부분이기에 무엇보다 정상 시나리오만 검증하지 말고 고단하더라도 반복적이고 다양한 테스트가 필수라 생각합니다.
