좋은 테스트가 좋은 프로젝트를 만든다
중요한 줄 알면서 소홀이 하는 것
테스트가 중요하다는 것에 이견을 다는 사람은 없다. 그런데, 테스트에 소홀한 사람은 엄청 많다. 즐거움으로 가득한 창작에 비해, 그것이 제대로 만들어졌는지, 의도한 대로 동작하는지 확인하는 과정은 별로 재미가 없을 것이다. 그래서 꼭 필요한 줄은 알지만 많이 소홀히 한다. 그리고, 그 대가를 나중에 치르게 된다.
테스트는 절대로 선택할 수 있는 게 아니다. 무조건 해야 하고, 완벽히 해야 한다. 어떤 면에서는 창작보다 평가가 더 중요하다. 좋은 평가 과정이 좋은 결과물을 만들어 주기 때문이다. 제대로 된 평가 과정이 없다면 무엇이 제대로 되었고 무엇이 잘못되었는지 알 수가 없다. 기껏 공들여 만든 훌륭한 작품에 오히려 흠집을 내게 될 수도 있다. 그러니, 창작에 들인 공만큼 테스트에도 공을 들이자.
일단은 빠짐없이 확인하는 것이 중요하다
테스트에서 가장 중요한 덕목은 꼼꼼함이다. 확인해야 할 것을 하나도 빠짐없이 확인해야 한다. 빠뜨린 하나가 제품과 서비스에 치명적인 결함으로 연결될 수도 있기 때문이다. 테스트를 통해 결함을 완벽히 파악하기는 어렵다. 하지만, 테스트를 꼼꼼히 진행한다면 결함의 개수와 결함이 서비스에 미치는 영향은 줄일 수 있을 것이다.
테스트를 꼼꼼히 진행하려면 먼저 무엇을 확인할지 확실히 알아야 한다. 그래서 보통, 테스트 과정의 앞부분에는 체크리스트를 작성하는 과정이 포함되어 있다. 이 부분은 전체 테스트 과정에서 가장 지루하면서 동시에 가장 중요한 부분이 된다. 체크리스트에 포함되지 않은 부분은 테스트 자체가 진행되지 않기 때문이다.
체크리스트는 테스터 혼자서 작성할 수 없다. 기획자 혼자서도 작성할 수 없다. 제품의 내용과 테스트 과정을 모두 이해해야 완전한 체크리스트를 구성할 수 있다. 그래서 협업이 필요하다. 초안을 잡고, 그것을 함께 검토하면서 보완하고 수정하여 완전한 체크리스트를 구성하게 된다.
앞에서도 말했듯이 지루하고 재미없는 작업이지만, 체크리스트를 만드는 것이 테스트의 대부분이라고 생각해도 지나치지 않다. 모든 계획이 여기서 완료되고 나머지는 실행하기만 하면 되는 것이기 때문이다. 따라서, 최선을 다해 작업하고 몇 번이고 다시 확인할 필요가 있다.
자동화할 수 있는 것은 꼭 하자
일본에서 마작 게임을 개발할 때였다. 마작은 4명의 플레이어가 있어야 게임이 진행되기 때문에, 테스트할 때마다 4명의 테스터가 필요했다. 그러다가, 간단한 AI가 대신 플레이할 수 있는 기능을 추가했다. 이후 마작 테스트는 한 명의 테스터로도 가능하게 되었다. 당연히 테스트 효율이 올라가고, 테스트 횟수도 많아졌다.
조커를 사용하는 포커를 개발할 때는 기존의 로직으로 해결이 어려워 새로운 로직을 개발했다. 그런데, 새로운 로직이 완전한지를 사람이 검증하기 어려웠다. 그래서, 같은 카드 조합에 대해 기존의 로직과 새로운 로직을 같이 돌려서 다른 결과가 나오는 것들을 검출하도록 했다. 검출된 결과를 바탕으로 새 로직의 오류를 수정했고, 한 번은 기존 로직에서 몇 년 동안 발견되지 않았던 오류도 발견하여 수정하게 되었다.
테스트는 같은 작업을 많이 반복해야 하는 성격의 작업이다. 따라서, 자동화를 통해 효율을 높일 여지가 많다. 그러니, 어느 부분을 자동화할 수 있는지 찾아보고, 자동화할 수 있는 것은 최대한 자동화하는 것이 좋다. 그러면, 더 적은 비용으로 더 많은 테스트를 할 수 있고, 테스트의 정확도도 올라갈 것이다.
테스트는 개발자로부터 시작된다
창작을 하는 사람이 테스트까지 진행하는 것은 굉장히 자연스러운 일이다. 자신의 결과물이 온전한지 살펴보고 부족한 부분은 보완한 다음, 다른 사람에게 보여주거나 전달하는 것이 당연하다. 그런데 게임을 개발할 때는 자신이 개발한 프로그램에 대해 테스트를 해보지 않은 채로 테스트 팀에게 넘기는 프로그래머를 가끔씩 만나게 된다.
개발자가 충분한 테스트를 할 만큼의 여유를 조직에서 주지 않는 경우도 많고, 테스트를 잘하는 좋은 테스트팀이 많기 때문에, 개발이 완료되었다 싶을 때 빨리 테스트팀에 넘기는 것을 어느 정도는 이해할 수 있다. 하지만, 제대로 구동되지도 않는 프로그램을 테스트팀에 넘기는 것은 분명 문제가 있다. 실제로, 테스트를 진행할 수 없을 만큼 엉성한 상태로 테스트를 의뢰하는 프로그래머들이 있다.
프로그램에 대해 완벽한 검증까지 요구하지는 않는다. 하지만, 기본적인 동작은 확인한 상태로 테스트팀에 넘겨야 한다. 그리고, 프로그램이 동작하는 방식을 프로그래머가 가장 잘 이해하기 때문에, 프로그래머가 테스트하는 것이 좋은 부분도 있다. 그러니, 테스트는 테스트팀에서 하는 것이라고 생각하지 말고, 프로그래머가 미처 확인하지 못한 부분을 테스트팀에서 찾아준다는 생각으로, 프로그래머가 먼저 충분히 테스트하는 습관을 가질 필요가 있다.
꼭 필요한 최종 사용자 테스트
오류가 있는지 테스트하는 것은 전문 테스터들이 테스트하면 된다. 하지만, 제품에 대한 고객의 만족도나 편의성을 예측하는 것은 전문 테스터들만으로 충분하지 않다. 아무래도 일반 고객과는 다른 성향을 가졌기 때문에 전문 테스터에 의한 테스트에 왜곡이 포함될 수 있다. 그래서, 최종 사용자에 의한 테스트가 반드시 필요하다. 말하자면, 고객이 될 사람들을 대상으로 테스트를 진행하는 것이다.
UX 테스트만 하더라도, 일반 사용자를 대상으로 테스트를 진행하면 놀라운 사실을 여러 가지 발견하게 된다. 분명히 눈에 잘 띄는 곳에 큰 버튼을 배치했는데도, 심지어 버튼이 깜빡거리는데도 버튼을 찾지 못하는 유저들이 있다. 그리고, 같은 버튼을 계속 연타하는 등, 개발할 때는 생각지도 못했던 행동을 하는 고객들도 있다. 이런 행동들은 제품에 대해 충분히 이해하고 있는 전문 테스터들에게서는 발견하기 쉽지 않은 행동들이다.
이런 생각지 못한 발견들이 있기 때문에, 사용자 테스트에는 개발팀 인원을 꼭 참관하게 하는 것이 좋다. 직접 눈으로 보지 않으면, 누군가 설명을 해줘도 잘 받아들이지 않는 상황들이 있기 때문이다. 실제로, 최종 사용자 테스트를 참관한 프로그래머는, 기획자의 수정 요청에 훨씬 적극적으로 대응해 줄 때가 많다.
좋은 테스트 과정은 안전감을 준다
게임을 개발할 때 정말 좋은 테스트팀과 일했던 적이 있다. 지금까지도 내가 겪어본 테스트팀 중 최고라고 할 수 있고, 일에 대한 자부심과 책임감이 투철했던 팀이다. 그 팀과 일할 때는, 내가 개발한 프로그램이 발매되어 고객을 만나더라도 전혀 걱정되거나 불안한 것이 없었다. 그 팀에서 확인하고 승인한 프로그램은 신뢰할 수 있었기 때문이다.
물론, 나도 충분한 테스트를 하고 테스트팀에 넘겼다. 하지만, 개발자가 아무리 열심히 테스트를 해도 발견하지 못한 오류가 있기 마련이다. 그런데, 그 팀의 테스트를 거치면 프로그램은 거의 완벽해졌다. 물론, 그 팀도 오류를 완전히 잡아내지는 못했다. 하지만, 서비스에 크게 영향을 미치는 오류는 그 팀의 테스트를 피하지 못했다.
좋은 테스트는 좋은 제품을 만들어 주기도 하지만, 그전에 개발팀에게 굉장한 안전감을 준다. 그래서, 프로젝트 초기부터 좋은 테스트 과정을 확보하는 것이 중요하다. 위험을 감지할 때마다 신호음으로 알려주는 장치가 수많은 운전자를 주차 과정의 불안감으로부터 지켜주고 있는 것을 생각해 보면 될 것이다.
1. 빠짐없이 확인하는 것이 중요하다.
테스트 과정에 허점이 없을수록 서비스를 위협하는 결함의 개수와 위력을 줄일 수 있다.
무엇을 확인할지 확실히 알아야 완전한 테스트가 가능하다.
제품을 만드는 팀과 테스트하는 팀이 협업하여 완전한 목록을 만들어내야 한다.
2. 최대한 자동화하자.
테스트는 반복적인 작업이 많은 일이다.
자동화되는 부분이 많을수록 적은 비용으로 많은 테스트를 할 수 있고, 정확도도 올릴 수 있다.
3. 개발자에 의한 테스트를 소홀히 하지 말자.
프로그램에 대해 가장 잘 아는 것은 개발자이다.
개발자가 확인할 수 있는 것들은 확인한 후에 테스트팀에 넘겨야 한다.
4. 최종 사용자 테스트는 꼭 해보자.
제품에 대한 만족도와 제품의 편의성은 최종 사용자를 통해 테스트해야 정확히 판단할 수 있다.
개발 과정에서 생각하지 못했던 사용자의 행동을 확인할 수 있다.
