스펙에 대처하는 QA의 자세

QA가 이슈를 발견하고 개발자가 이를 수정해 제품이나 서비스에 반영하는 과정은 다양한 커뮤니케이션을 통해 이루어 집니다. QA가 테스트를 수행하다가 이슈로 추정되는 증상을 발견하면 해당 증상이 이슈인지 아닌지 개발자 혹은 기획자에게 확인하는 과정을 거칩니다. 이 과정에서 QA가 개발자 혹은 기획자로부터 흔히 듣게 되는 답변 중에 아래와 같은 말이 있습니다.

“이거 스펙(Spec)입니다.”

‘아니 이게 스펙이라니. 이렇게 발견하기 힘든 이슈를 어렵게 재현해 냈는데, 이게 스펙이라니. 이 문제가 그냥 라이브에 배포되면 사용자가 많이 불편해 할텐데!'라는 속마음을 뒤로하고 QA는 터덜터덜 자리로 돌아갈 수 밖에 없습니다. 자리에 돌아와 생각해보니 마음 한 켠에는 ‘수정하기 힘든 이슈라 수정하는데 시간은 많이 걸릴 것 같고 또 이걸 이슈라고 인정하면 왠지 부끄러워서 그냥 스펙이라고 하는 거 아냐?’라는 의문이 듭니다.

하지만 어쩌겠어요. 테스트하고 있는 기능이나 콘텐츠에 대해 가장 잘 알고 있는 개발자와 기획자가 스펙이라고 하는 걸.

자, 그럼 그냥 이렇게 아쉬움을 뒤로 하고 해당 증상을 스펙이니까, 라고 그냥 정리하고 마무리하면 될까요? 스펙이라는 것이 과연 어떤 것인지, 그리고 QA 입장에서 어떻게 대처하면 좋을 지 한 번 고민해 봤습니다.

스펙의 정의

필자 역시 처음 테스트 업무를 수행했던 곳에서부터 스펙이라는 단어를 자주 접할 수 있었습니다. 우선 스펙이라는 말을 영문 위키피디아에서 한 번 검색해 봤습니다. 한글로 검색하면 전혀 다른 의미가 주로 검색됩니다.

영문 위키피디아에서 검색한 'Spec'의 정의

보시다시피 Spec은 Specification의 줄임말이며, 재료, 제품 혹은 서비스가 충족시켜야하는 일련의 명확한 요구 사항이라고 설명하고 있습니다. Specification 항목을 찾아보면 좀 더 정확한 정의를 찾을 수 있습니다. 물론 위키피디아의 단어 정의가 100% 정확한 것은 아니지만 일상적으로 큰 거부감 없이 통용되는 수준으로 볼 수 있을 것 같습니다.

'Specification'의 의미

여기서 Specificaiton은 종종 재료, 제품 혹은 서비스가 충족시켜야 하는 일련의 문서화된 요구 사항이라고 정의하고 있습니다. 이 문장을 좀 더 간단하게 표현하면 문서화된 요구사항이라고 할 수 있겠습니다. 게임 업계에서 흔히 말하는 기획서가 여기에 해당될 것 같습니다. 즉, `스펙입니다` 라고 이야기하는 것은 '기획서에 그 내용이 있습니다` 라고 이야기하는 것이라고 볼 수 있을 것 같네요.

제 개인적으로는 Spec in Close 라는 단어가 스펙을 처리하는 가장 좋은 단어가 아닐까 합니다. Spec in close는 발견한 증상이 Spec의 범위 안에 있으므로 결함으로 분류하지 않는다는 의미입니다. 여기서 Spec은 앞서 살펴본Specification, 직역하면 명세 혹은 명세서, 의역하면 기획서라고 할 수 있겠습니다. 즉, QA가 발견한 증상이 기획서에 명세되어있는 기대 결과에 포함되어 있다는 것을 뜻합니다.

여기서 중요한 것은 해당 증상이 명세되어 있다 는 것입니다. '기대 결과 안에 포함된다', 혹은 '그 예외 사항은 허용된다'와 같이 다양하게 표현할 수 있겠습니다. 이런 내용이 글이나 그림 같은 인지할 수 있는 형태로 기획서에 기록되어 있어야 한다는 것이 가장 중요합니다. 즉, 개발자 혹은 기획자가 특정 증상을 스펙으로 분류했다는 것은 기획서와 같은 문서에 기재되어 있는 내용을 근거로 해당 증상을 스펙이라고 정의 혹은 분류한다는 것을 뜻합니다. 만일 그렇지 않다면 특정 이슈를 스펙으로 분류하는 것에 대한 설득력이 떨어질 수 밖에 없습니다.

이렇게 수정되지 않고 라이브 환경까지 전달된 이슈를 사용자가 발견하게 된다면 어떨까요. 사용자 역시 이 증상이 정상적인 범위에 포함되는지 궁금해 하지 않을까요. 이 경우에도 스펙이라고 설명한다면 사용자가 충분히 납득할 수 있을까요. 개발 과정에 참여한 QA조차 문제인지 아닌지 의아해하는 이슈를 사용자가 봤을 때 정상적이라고 납득할 가능성이 과연 얼마나 될까요. 스펙으로 추정되는 이슈를 제대로 정리하지 않는 것은 고객에게 제품을 전달하기 전에 이슈를 찾아 개선하고 이를 통해 최고의 경험을 전달해야 하는 QA의 미션에도 어긋납니다.

Spec in Close 라는 단어에서 좀 더 눈여겨볼 만한 부분은 Close 입니다. 결함 추적 시스템을 사용하는 분들은 잘 아시겠지만 Close는 BTS에 등록된 이슈 티켓이 도달하는 최종단계 중 하나 입니다. Spec in close라는 말은 등록된 이슈가 스펙으로 처리되어 폐쇄 처리한다는 뜻입니다. 즉, 폐쇄 처리되기 위해서는 해당 이슈가 이미 BTS에 등록되어 있어야 한다는 것을 의미합니다. 이슈가 이슈로 판명되기 전에 QA가 이슈라고 의심할만한 증상도 우선은 BTS에 등록되고, 확인을 거쳐 스펙이라고 판명이 되면 Spec in close 처리가 된다는 것입니다. 이슈라고 의심되는 것 자체가 이미 BTS에 등록될 자격을 갖게 되는것입니다. 따라서 Spec in close 자체도 의미를 가지게 됩니다. Spec in close 처리되는 이슈가 많다는 것은 명세서가 제대로 정리되어 있지 않거나 명세된 내용을 QA가 제대로 파악하지 못했다는 것을 의미하게 됩니다. 반면, Spec in close 처리되는 것이 적다는 것은 명세서에 예외 처리되어야 하는 부분이 확실하게 명시 되어 있으며 명세된 내용을 QA가 확실하게 파악하고 있다는 것을 의미하게 됩니다.

자, 이제 앞의 내용을 정리해 봅시다. 이슈인지 아닌지 명확하게 판단하기 힘든 이슈의 경우 아래와 같은 절차를 따라 처리합니다.

1. 우선 결함 추적 시스템에 해당 증상으로 티켓을 생성합니다. 티켓의 상태는 'Open'을 유지합니다.

2. 해당 티켓의 증상을 개발자 혹은 기획자에게 문의합니다.

3. 개발자 혹은 기획자가 스펙으로 분류한다면, 전달받은 기획서 중 어떤 부분에 해당하는지 문의합니다.

4. 전달받은 기획서에서 해당 내용을 확인했다면 해당 티켓의 상태를 'Spec in close'로 변환합니다.

5. 만일 명세된 내용이 없다면 해당 증상을 스펙으로 분류해서 기획서에 추가할지, 이슈로 판단하여 수정할지 확인합니다.

스펙으로 추정되는 이슈가 기획서의 어느 부분에 해당하는지 확인할 때도 개발자 혹은 기획자에게 '스펙이라는 것을 증명해봐'가 아니라, 내가 어떤 부분을 추가로 확인하면 되는지 묻는 것이 중요합니다. 또한 명세되지 않은 내용이라면 QA는 이 증상을 '사용자가 봤을때 어떻게 받아들일지'를 감안해서 스펙으로 분류할지 논의하는 것이 좋습니다. 문제를 수정하는 과정은 누군가의 잘잘못을 따지는 것이 핵심이 아니라, 최대한 빠르게 원인을 파악하고 수정해 제품의 품질을 높이고 이를 통해 고객이 최고의 경험을 할 수 있게 도와주는 과정이기 때문입니다. 이런 과정을 하나하나 거치는 것이 번거롭고 비 효율적이라고 생각할 수도 있습니다. 하지만, 누군가 원칙과 품질을 고수해야 한다면 그게 바로 QA가 해야할 일이겠죠.

Happy Testing! :)