본문 바로가기

QA

스펙에 대처하는 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! :)

  • BlogIcon 메로나나 2019.11.29 22:21 신고

    안녕하세요. 게임 QA로 이직 준비 중인 직장인입니다. 온오프믹스에서 지난 1월 '[특강] 게임 QA를 꿈꾸는 모든 분들께' 라는 제목으로 강연하셨던 걸 보고 찾아왔습니다(https://www.onoffmix.com/event/166218). 다름이 아니라 게임 QA로 전업을 하고자 준비 중에 있는데 혹시 강연을 다시 하실 계획이 있으신지 여쭙고자 합니다.
    저는 작은 기업에서 기획쪽으로 있는 직장인이고 내년이면 34살이 됩니다. 좀 늦은 나이지만 이직을 준비하면서 게임 QA에 대해 알게되었고, 관심을 갖고 여러모로 공부하는 중입니다. 다만 게임 QA를 전문적으로 가르치는 학원이나 수업이 없어 직접적으로 실무자님이나 강사님을 만날 기회가 없었는데, 마침 온오프믹스에서 강연하신 내역이 있어 이렇게 찾아오게 되었습니다.
    개인적으로 현업 종사자분께 질문하고자 하는 부분은 제가 만들어낸 테스트케이스나 버그케이스가 실무에서도 쓰일만한 정도인지, 아니면 유저의 리뷰 정도인지 알고싶습니다. 그리고 현재는 ISTQB 자격증을 준비중에 있는데 이 외에 추가적으로 준비하면 좋겠다 싶은 자격증이나 지식이 있는지를 알고싶습니다.

    • BlogIcon 검은왕자 2019.12.02 08:06 신고

      안녕하세요 메로나나 님, 검은왕자 입니다. 현재는 계획된 강의 일정이 없습니다. 가끔 대학 재학생을 대상으로 특강 의뢰가 들어오고는 하는데, 그밖의 일반인이나 직종 전환을 고려하고 계신 분을 대상으로 하는 강의는 상대적으로 그 기회가 드문 편입니다. 작성하신 테스트 케이스나 버그 리포트가 현업에서 사용이 가능한지 여부는 직접 보지않고는 판단이 힘들 것 같습니다. 다만 두 문서 모두 유저의 리뷰와는 성격이 판이하게 다른 것입니다. ISTQB 자격증 취득을 준비하고 계신다고 하니 아마 실라버스의 내용들이 상당히 많은 도움을 드릴 것 같습니다. 단, 게임 도메인의 경우 ISTQB의 내용을 그대로 적응하기에는 어려운 부분도 많다는 것을 알고 계시면 좋을 것 같네요. 충분히 잘 준비하셔서 게임 QA로의 이직 성공하시길 바랍니다. 감사합니다. :)

  • 지찬욱 2019.12.09 15:45

    작성하신 블로그 글들 보고 많은 생각을 하게 되고, 많은 공부가 되었습니다! 좋은 글 감사합니다. :)

  • 도라에몽 2020.03.22 19:15

    안녕하세요. 게임 업계 6년차 QA는 3년차입니다. 12월에 검은 왕자님의 글을 보고 QA 주니어인 제 예전 후임에게 알려줬더니, QA 마인드에대해서 많이 알게됐다고 고마워하더군요. 저 역시 게임 업계에 있으면서 QA를 하던 시절이 재밌었던거 같습니다. 중간에 회의감이 들어 다른길로 빠져서 일하다보니 경력은 6년차인데 연봉만 올라가있고 제 동기들과 비교했을때, 전 너무 많은 시간낭비를 했다싶었습니다. 이제라도 다시 게임 업계 QA를 준비하며 이력서를 돌리고있는데, 리딩 경험외엔 6년차 업계 사람이 QA를 하고자할때, 게임회사는 저에게 어떤 스펙을 요구할지 궁금하여 어렵사리 댓글 남깁니다. 검은 왕자님이 생각하셨을땐 6년차 그리고 3년차 QA는 어떤 스펙을 가지고 있어야 회사 입사의 기회를 얻을수 있는지 조언 부탁드립니다.

    • BlogIcon 검은왕자 2020.03.23 09:03 신고

      안녕하세요, 검은왕자 입니다. 다시 게임 QA를 시작하기 위한 준비를 하고 계시군요. QA를 하지 않으실 때 어떤 일을 하셨는지 모르겠지만, 그 일을 경험해서 어떻게 게임 QA를 더 잘 할 수 있다는 것을 어필하시는게 좋을 것 같습니다. QA에서 시작해 훌륭한 게임 기획자, PM으로 거듭나시는 분들을 많이 뵈었는데 이분들 역시 한결같이 QA할 때의 업무가 많이 도움이 되었다고들 하십니다. 그 반대로 다른 직군에서의 경험이 QA 업무에도 많은 도움이 되리라 생각합니다. 이 부분을 잘 어필하신다면 오히려 한 분야의 QA만 오래하신 분들이 가지지 못한 강점이 되리라 생각합니다. 모쪼록 원하시는대로 QA 업무 시작할 수 있기를 바라며 조금이라도 도움되었기를 바랍니다. 감사합니다. :)