두 가지 사고력
같은 직군으로 일하더라도 사람마다 업무를 처리하는 방식은 다르다. QA라고 다르지 않다. QA 대상 일감을 대하면서 명세에 충실하게 기본 위주로 확인하는 사람이 있는가 하면 확장하여 테스트를 진행하는 경우도 있다. 각자가 장단점이 있고 무엇이 옳고 그르다고 할 수는 없다. 다만 이건 남이 정해진 기준에 따라 움직이는 것이 아닌 각자의 기준이 확고할 때 해당된다.
문제를 찾아내는 사고력
지금까지 다뤄왔듯, 버그는 특정 스펙에 기획된 내용 범위를 넘어설 때 더 많이 발생한다. 생각하지 않으면 발견도 없는 셈이다. 이것은 직감으로 알 수도 있고 가설을 세우고 대비하여 알 수도 있다. 테스트 케이스를 작성해도 그 안에 없는 것들이 있기 마련이다. 이럴 때는 매뉴얼대로 하면 이상이 없지만 마음 한편에서 ‘뭔가 잘못됐다’는 신호가 온다. 그 작은 의심이 버그를 발견하게 만들고, 때로는 프로젝트의 흐름을 바꾼다. 생각해 보면 QA란 정답을 맞히는 사람이 아니라 질문을 발견하는 사람이다. “왜 이렇게 동작하지?”, “이게 정말 사용자가 원하는 경험일까?”
그 물음이 곧 ‘생각해 내는 힘’의 시작이다.
스스로 사고하고 판단하는 능력
테스트 케이스는 거의 모든 QA 업무의 시작이다. 이걸 작성하고 고치고 수행하고 완료하는 게 일반적인 루틴이다. 다만 그것이 끝나는 순간 모든 QA가 끝인가? 이렇게 생각하면 그 처리가 쉽지 않다. 꼭 필요한 것이지만 역으로 이 테스트 케이스가 사고를 제한할 때가 있다. 테스트 케이스라는 규칙 안에 갇히면 스스로 생각하는 힘은 약해진다.
이건 게임도 마찬가지다. 길이 표시된 맵에서는 모험이 사라진다. 물론 자동 이동은 게임의 피로도를 낮춰주는 이점도 있다. 그런데 QA의 일은 그 ‘길’을 의심하는 일이다. “이 설계가 진짜 사용자에게 합리적인가?”,
“이 버그가 아닌 것처럼 보이지만, 정말 문제없을까?” 생각을 멈추지 않는 사람만이 문제의 이면을 본다.
시스템은 효율을 원하지만, 창의는 언제나 비효율에서 태어난다.
질문으로 일한다
QA는 평소에도 기획자, 개발자, PM 등 다른 팀에 "이것이 의도인가요?", "괜찮을까요?"와 같은 질문을 수없이 던진다. 때론 질문을 발견하는 일을 하는 것이 아닌가라는 생각도 든다. 우리는 버그를 찾는 직업을 가졌지만 사실은 질문을 발견하는 일을 하고 있던 것이다. 버그란 시스템과 콘텐츠의 결함이 아니라 사람이 ‘멈춰 생각할 이유’이기 때문이다.
그래서 나는 오늘도 묻는다. “이건 정말 정상인가?” 그 한 문장이 다시 생각하게 한다. 그리고 그게 바로 스스로 생각해 내는 힘의 시작이다.