기획자의 QA

이번 글의 주제는 QA(Quality Assurance)다.

사실 QA도 IT, 제조업 등등 여러 곳에서 사용되는 용어인데, 이 글에서는 ‘QA 직무’에 대한 글이 아닌 ‘기획자의 QA’에 초점을 맞춰 이야기하려 한다.(내 블로그에서 ‘기획자’라는 직무명은 비단 ‘기획자’만을 가리키는 것은 아니다. PM/PO/기획자 등 기획을 주된 업무로 하는 직무를 뜻한다.)

 

나는 ‘QA’라는 업무가 기획자의 fit한 task는 아니라고 생각하지만, 프로덕트 생애 주기에서 QA라는 것이 굉장히 중요한 task임은 확실하기에 기획자가 책임지고 꼼꼼히 확인해야 할 것은 맞다고 생각한다.

 

왜? 왜 테스팅이 중요할까? 나는 크게 2가지 관점에서 QA 과정이 중요하다고 생각한다.

1. 고객이 사용하는 제품의 질을 안정화시키고 향상시킬 수 있는 과정이기 때문이다. 기획만 했다고, 디자인만 했다고, 개발만 했다고 해서 ‘잘 돌아가는’ 서비스는 없다. 심지어 기획, 디자인, 개발을 하는 것은 ‘사람’이다. 사람은 실수를 할 수 있으며 더불어 개개인의 창의성도 발휘한다. 때문에 초기 기획이, 초기 디자인이 개발 과정을 통해 잘 구현이 되었는지, 안정적으로 서비스를 사용할 수 있는지 등을 꼭 체크해야 한다.
2. 서비스 메이커들의 입장에서 서비스를 잘 이해하는 데 도움이 되기 때문이다. QA를 통해 서비스의 첫 시작부터 끝까지 꼼꼼히 살피고 사용해봄으로써 자연스럽게 서비스에 대한 이해도가 올라갈 수 있다.

 

그럼, QA는 무엇을 뜻하는 말일까? QA와 더불어 언급되는 QC, QM, TC 용어도 같이 짚고 넘어가면 좋을 것 같다.

 

QA, QC, QM

QA : Quality Assurance. 품질 보증. 프로덕트 런칭 전, 프로덕트의 품질을 검토하는 단계다.

출시 전일 수도 있고, 2차 혹은 n차 릴리즈를 준비할 때. 즉, 버전 업데이트 전 품질을 검토하는 업무라고 생각하면 된다.(학생 때 시험을 보면, 답지 제출 전 검토를 하고 제출하는 것처럼 내가 알고 있는 ‘정답’이 맞는지 + 답안이 잘 입력되어 있는지 등을 확인하는 식이다.)

 

QC : Quality Control. 품질 관리. 테스트를 통해 제품의 품질을 일정 수준 이상으로 관리하는 업무.

 

IT 업계에서는(물론 내가 IT 업계에 오래 있어본 사람은 아니지만) QC 보다 QA라는 용어를 자주 사용하는 것 같다.

그 이유를 조금이나마 추측하자면, 제품(물질적)은 재질, 안전성, 환경/인체에 미치는 영향 등등 폭넓은 테스트 항목들이 각 제품마다 다르고 규정화되지 않은 수많은 공장에서 생산되지만 IT 제품(비물질적)은 비교적 표준화되어 있는 항목들이 많기 때문이지 않을까 싶긴 하다.(앱 출시를 위해 스토어의 심사를 넣는 것이 어떻게 보면 QC를 받고 있는 과정이라고 할 수도 있겠다.)

 

QM : Quality Management. 품질 경영. QM은 QA, QC 등의 테스트를 통해 전략을 수립하고 실행하도록 하는 방법론이다. 품질 계획, 품질 보증, 품질 관리, 품질 개선 등의 큼지막한 구성요소가 있다고 한다.

 

QA 프로세스

QA 프로세스는 해당 QA를 하는 목적과 프로덕트 유형에 따라 천차만별이겠지만, 런칭을 앞둔 소규모 팀에서 기획자가 할 수 있는/해야 하는 정도로만 보면, 프로세스는 다음과 같지 않을까 싶다.(여러 자료를 참고하고 내 개인의 경험에서 봤을 때 이렇다는 것이다. 으레 그렇듯 뇌피셜.)

출처 : 내 뇌피셜(with 인터넷 지식)

개발자들이 개발 막바지 단계에 돌입했다면, 기획자는 QA 준비를 해야 한다.

 

QA 준비

QA 시트를 작성하는 tool에 대해 먼저 언급하자면, 나는 구글 스프레드 시트를 애용한다. 테이블 형태이기에 편리하고, 명확하고, 실시간 공유가 되는 툴이기 때문이다. 언젠가 읽었던 아티클에서, QA를 전문적으로 하는 분의 추천 tool list를 본 적이 있는데, 사실상 소규모 팀에 자원도 시간도 돈도 없다면 무료 툴인 구글 스프레드 시트를 사용하는 것을 추천한다.

 

우리는 'QA를 어떻게 하면 더 잘할까’를 고민하기 앞서, ‘어떻게 소규모 팀원들과 의견 차이 없이 명확한 공유를 할 수 있을까’를 우선적으로 생각해야 한다. 이때 의견 차이 방지가 중요한 이유는 첫째 나 혼자 QA를 하는 것이 아니기 때문이고(나 혼자 하더라도 공유는 다 같이 이루어지는 경우가 많음), 둘째 그렇기에 팀 내 모두가 같은 것을 생각해야 하기 때문이다.

 

같은 프로젝트를 하는 팀원 내에서도 ‘같은 단어에 대한 다른 생각’을 가진 채 협업하는 경우가 있다. 나 역시 그랬던 경험이 있었다. 대학교 학부생 당시 팀플에서 UT를 진행했을 때는 측정 단위에 대한 것이었고, IT 벤처 창업 동아리 SOPT의 장기 해커톤에서는 서비스 내 ‘기능 명칭’에 대한 것이었다. 나는 내 장점 중 하나로 ‘팀원 모두가 같은 방향을 바라보도록 목표에 대한 얼라인을 맞추고 동기부여를 하는 것’을 말하는데, 실례로 나는 용어에 대해 모호한 의견이 나뉘어지는 것을 발견하는 즉시 작은 회의를 열어 용어와 명확한 정의에 대한 팀원 간 얼라인을 맞추는 작업을 진행한다. 이렇게 하지 않았을 때 발생하는, 사소한 디테일에서 출발한 큰 의견 충돌의 무서움을 알기 때문이다.

 

새로 투입된 인력이 아닌, 내가 내 손과 머리로 검증하고 정의한 서비스라면 QA 시트는 비교적 어렵지 않다.(”비교적.”) QA를 작성할 때, 보통 고객 시나리오를 생각하며 TC(Test Case)를 작성하게 되는데 거기서 그치지 말고 본인 혹은 기획 팀에서 작성한 ‘기능명세서’(or 화면 설계서)를 꼭 참고하길 바란다. 기획자도 사람인지라 내가 정의한 기능의 디테일을 놓치는 경우가 있다.(예를 들어, 상단 100px은 고정되고 나머지 부분이 스크롤 영역이었는지, 전체가 스크롤 영역이었는지 등의 우선순위가 낮은 항목들이 그러하다.)

 

나도 초짜지만, 두어 번 QA를 작성해본 나름의 경험자로서 QA 내용에 대해서는 크게 세 가지 관점에서 항목을 작성하면 꼼꼼하게 작성할 수 있었다.

1. 기능적 관점 : 우리(makers)가 초기 정의했던 대로, 생각했던 대로 버그 없이 기능이 잘 구현되어 동작하는지를 살펴보아야 한다.
2. UX/UI 관점 : 각종 버튼, 텍스트, 화면 레이아웃 등에 오류가 없는지 확인해야 한다.(디자이너와 함께라면, 실제 기종에서의 색감과 화면 비율도 고려해보면 좋다.)
3. 성능 관점 : 화면 로딩 속도는 괜찮은지, 콘텐츠(로티 등) 속도는 괜찮은지, 화면 안에 삽입한 motion은 어색하지 않은지, page 이동은 자연스러운지, 토스트나 팝업은 잘 나오는지 등.
4. 이것 외에도 Empty view, 콘텐츠의 정렬 등을 생각하며 시트를 작성하면 좋다.

 

그럼 QA 시트에는 어떤 내용이 들어가야 할까?(Test Case의 내용을 말하는 게 아니다. 항목, 형식을 말하는 거다.) QA 시트를 작성하며 느낀 건, 결국 이것도 크게 상관이 없다는 것이다. 물론, 꼭 들어가야 할 항목은 포함되어야겠지만 팀 상황에 따라/프로덕 상황에 따라 유연하게 만들어 작성하면 된다.

 

나의 경우, 대분류(User Flow 기반) - 중분류(View/팝업 명칭) - 소분류(View인지 팝업인지) - 운영 체제(내가 하고 있는 프로덕은 앱이라 AOS와 iOS의 구분이 필요했다.) - 테스트 항목 - 내용 - 개발 담당자 - n차 QA 담당자/기기 기종 - n차 결과 - 이슈 - 비고 이렇게 작성했다.

ex) 온보딩 - 스플래쉬 - view - 공통 - page 이동 - 고객이 처음 앱에 진입했다면 튜토리얼 view로 진입 - 최소현 - 최소현/Z플립3 - F - 로고 안 뜸 - (비고 x)

Hous-의 1차 QA Sheet.

 

인터넷 내의 여러 형식을 살펴보면 화면의 depth를 표시하기도 하고, TC의 조건이나 테스트 범위를 적기도 하며 내용(체크리스트)과 디스크립션을 따로 작성하기도 한다.(case by case~)

 

테스트 환경 세팅(’수정 요청’ 환경 만들기)

QA 시트를 작성했다면, QA를 진행하기 위한 환경을 세팅해야 한다. 구글 스프레드 시트 자체도 QA 환경 중 하나이지만, 우리는 QA 중 가장 중요한 부분 중 하나가 ‘협업(이슈/오류 해결)’임을 잊어서는 안 된다. 테스트 환경은 곧 ‘수정 요청을 쉽고 효율적으로 할 수 있는 환경’을 의미하는데, QA 도중 fail된 내용을 해당 view 담당자가 수정하기 쉽게 전달하는 것이다.

 

개발까지 끝마친 상태라면, 이미 팀 내부에서 활발하게 사용되고 있는 툴이 있을텐데, 가능하다면 그 툴을 사용해 환경을 세팅하길 바란다.(툴이 늘어나면 팀원들에게 툴 교육도 해야 한다~) 나의 경우, 노션/슬랙/피그마 등의 협업 툴을 사용하는데 이 중 ‘노션’ 혹은 ‘구글 스프레드 시트’를 사용해 테스트 환경을 세팅하려 한다.(글을 쓰는 시점이 ‘테스트 환경 세팅’ 전이다.)

 

노션은 담당자를 언급하고 이슈에 대한 누적 관리가 쉽다는 장점이 있지만, 구글 스프레드 시트와 번갈아 보아야 한다는 단점이 있어 이 둘 중 신중하게 선택하려 한다.(개발자의 입장에서는 개발 툴까지 같이 봐야 하니 효율성이 더 떨어질 수 있다.)

 

만약 QA 시트와 수정 요청 툴이 다르다면, 수정 요청 툴에서도 아래와 같은 항목이 포함되어야 할 것이다. 분류(화면 명칭), 테스트 항목, 내용, n차 QA 담당자&기기 기종, n차 결과, 이슈 + 개발 담당자 언급 등 말이다.

 

+ 테스트 환경 세팅이 끝나고 QA 진행 중에 기록용으로 적어두자면, 나는 구글 스프레드 시트와 노션을 동시에 사용하기로 했다. QA 시트 항목에 있는 수정 내용은 가능하면 전부 스프레드 시트에서, 그 외 추가적인 수정 사항(AOS, iOS 기기 Align 용 수정 사항 등)은 노션으로 별도 DB를 생성해 관리하고 있다.

 

테스트 진행

테스트 환경까지 세팅이 되었다면, 본격적으로 QA를 진행하면 된다. QA 시트를 작성하면서도 느꼈겠지만, 작은 규모의 서비스라도 QA는 굉장히 오래 걸리기 마련이다. 때문에 섹션별로 묶어 진행과 휴식기간을 나누어 진행하면 좋다.(중간에 너무 힘들어서 쉬는 것보다 각 섹션을 묶어서 내가 정한 부분에서 쉬는 게 훨 낫다. 하다 말면 다시 시작할 때 헷갈린다...)

 

테스트를 진행하며 주의할 것은 QA 시트 대로 진행하되, Edge case를 찾으려 노력해야 한다는 것이다. 한 아티클에서 재미있는 예시를 들었는데, “QA팀을 미운 4살로 생각해라.”였다. 올바른 케이스와 별개로, 미운 4살이 할 법한 뜬금없고 이상한 동작을 해보자는 것이다.

 

황당해보이지만 사실 굉장히 중요한 부분이다. 실제로 나도 QA 시트를 작성하며 최대한 많은 Edge case를 찾아보려 노력했다. 재미(?)있었던 이슈를 하나 공유하자면, 글자 제한이 40자인 프로필 수정의 text 입력 칸에 “사용자가 40자를 싹 다 엔터로 처리해서 저장하면 어떻게 돼?”라는 이슈였다. 프로필을 보여주는 view에서는 디자이너가 열심히 짠 레이아웃에서 글자 제한수에 맞게 단 2줄만 보여주도록 해뒀으니 엔터를 40번이나 쳐도 우리 서비스 view에서는 그 text를 모두 보여줄 수 없는 것이 당연했다. 이 안건으로 회의를 진행했을 당시 팀원 중 한 명이 ‘사용자는 대체 왜 이래!’ 하는 말을 했는데(ㅋㅋ) 실제 사용자가 하지 않더라도 안정적인 서비스 제공을 위해 한 번쯤은 짚고 넘어가야 하는 내용임에는 틀림없을 것이다.

 

나는 찐 소규모인 웹 QA 한 번 해보고, 그 이후 (내 기준)중간 규모의 앱 QA를 앞두고 있는데, 기종/협업하는 사람/협업 툴/서비스 규모 등에 따라 기획뿐 아니라 QA 역시 꽤 많은 것이 다르다는 것을 느낄 수 있었다.

 

+ 지금 하고 있는 Hous- 서비스의 QA를 끝낸 뒤 느낀점을 기록하러 다시 와야지.(아윌비백.ㅋ.ㅋ)

 

---

 

돌아왔따! 사실 QA가 마무리된 지는 좀 지났으나 그동안 런칭이니 학교 개강 준비니 뭐니 해서 바쁘다는 핑계로 미뤄왔다… 1월까지 이 글을 완성시키는 게 목표였으니 턱걸이인 셈이다.ㅎ

 

테스트 이후

느낀점을 가볍게 기록하자면

 

1. QA의 일정은 생각보다 더 여유를 두어야 한다.

팀바팀이겠지만, 우리는 n차별 QA를 하루에 몰아서 하는 방식을 선택했다. AOS와 iOS 기기를 사용하는 나와 우리 팀 디자이너가 오프라인으로 만나 내가 작성한 TC를 보며 쭈우욱 QA를 하는 식이었다. QA가 끝나야 수정 개발이 들어가고, 우리는 시간이 여유롭지 않았기 때문이다.

 

이렇게 했음에도 QA 일정은 생각만큼 빠르게 흘러가지는 않았다. 우리 팀원들의(+나도) 종강 이슈..^^도 한몫을 거들었으나 그 이유를 차치하고서라도 QA 중 발견한 다양한 이슈들이 있었기 때문이다.

 

1차 QA 때는 분명 잘 돌아갔는데, 2차 QA 때는 오류가 발생한다던지. 클라가 가지고 있는 줄 알았던 데이터가 알고 보니 서버에서 가지고 있어 데이터의 퀄리티 검토를 했어야 한다던지.

 

2. 개발자들은 생각보다 QA에 영향을 많이 받는다.

개발자의 성향에 따라 다르겠지만, 결과에 F가 기록되면 긴장하거나 불안해하는 개발자들이 있을 수 있다. 나도 1차 QA를 진행하며 QA Sheet(TC)가 마치 개발자의 평가서같이 느껴질 수 있다는 점을 알 수 있었다.

 

음, 뭐라고 예를 들면 좋을까. 종강을 하고 학점을 받았는데 전공 수업의 학점이 F가 나온 거다. 오류가 분명하니 교수님께 이의 신청을 하면 다시 내 본 학점을 받을 수 있겠지만, F 학점을 본 순간의 심정은 참 당황스럽고 식은땀이 날 것이다. 개발자들도 F를 보았을 때, 비슷한 심정이 아닐까?

 

때문에 나는 1차 QA가 끝나고, QA Sheet를 약간 수정했다. T/F로 구분했던 결과란을 체크표시로 모두 바꾸어 놓았다. 시각적으로 보기 편하게 각 섹션별(카테고리별) 색상도 다르게 주고 선도 그었다. F가 아닌 미체크. 바뀐 건 하나뿐인데, QA에 참여하는 우리 개발자 팀원들의 마음이 좀 더 편안해졌다는 것을 느낄 수 있었다.

 

덧붙여 개발자를 위한 사소한 배려로, QA를 진행하다 당황스러운 광경이 벌어져도 가능하면 “어?” “엥?” “이게 뭐야?” 등의 리엑션은 자제하자. 기획자/디자이너보다 개발자가 더 놀란다.ㅋㅋ

 

3. 역시 구글 스프레드 시트가 최적화된 QA 툴은 아닌 것 같다.

물론, 그럼에도. '최적'은 못 되더라도. '최선'을 찾으려는 노력은 필요할 것이다. 구글 스프레드 시트에서 사용할 수 있는 것들은 최대한 이용하자.(색상, 선, text 처리 뿐 아니라 데이터 제한, 정렬, 셀 병합 등등!)

 

4. 이후 QA를 위한 인사이트.

나중에 QA Sheet를 작성할 땐 화면 기준으로 작성하는 것에 끝나지 않고 QA 실행 순서를 고려해서 정렬을 변경해 봐야겠다.

 

ex_매끄럽게 실행될 수 있도록 '다음으로/저장하기' 등의 버튼 QA를 맨 마지막에 넣는다던지.

 

 

---

 

 

P.S_ 끝내기 전에, 위 과정으로 QA를 진행하고 출시한 Hous- 앱의 미니 홍보를 해보겟다ㅎㅎ

- 서로 다른 환경에서 살아온 룸메이트들의 더 나은 공동생활을 위해, Hous-!

 

✅ 플레이 스토어 다운로드 바로가기

https://play.google.com/store/apps/details?id=hous.release.android 

 

✅ 앱 스토어 다운로드 바로가기
https://apps.apple.com/kr/app/hous-/id1659976144

✅ 공식 인스타그램
https://www.instagram.com/hous_official_/