QA, 잘 알아야 잘 쓴다 (2)
QA 조직을 구축하기 전에, 혹은 잘 활용하거나 협업하고 싶은 사람들에게
QA 활동, 어떤 것이 있는가? - 각종 리뷰 활동 편
1. 각종 리뷰 활동
2. Test 과정이 포함된 (일반적으로 알려진) QA 활동
3. QA 활동 자체에 대한 분석 활동
.
.
4. 기술적 (데이터 분석, 코드, 개발 지식 및 수행력을 활용한) QA
5. 회사마다 요구하는 집중 단위에 특화된 QA 활동
.
.
4, 5번은 다른 전문가 분들께서 설명해주실 수 있을 거 같고
제가 경험한 1, 2, 3번 중 1번부터 설명해보려고 합니다.
제 개인 경험 및 다른 QA 분들이 어떤 활동을 하고 있는 지 인지하고 있는 만큼만 작성되었으며 이보다 더 다양한 활동을 하는 분들이 계시는 점을 인지해주시면 좋겠습니다.
QA의 형태는 목적 달성을 위해 다양한 형태로 진행되기 때문입니다!
개요
0. 각종 리뷰 활동
- 리뷰 활동의 목적
1. 역량이 된다면, 어떤 것들을 리뷰할 수 있을까?
- 기획 및 컨텐츠 리뷰
- 디자인 리뷰
- 코드 리뷰
- IP 가이드 리뷰
- 밸런스 리뷰
- 프로세스 리뷰
2. 리뷰는 월권인가?
- 품질 보증 활동은 QA만 하지 않는다
- 품질 보증 전문가의 입장
- 중립적 시야의 중요성
3. 신뢰도를 쌓자
4. 리뷰 활동에 대해
- 품질 보증 업무에 대해 전문가로써 인정할 것
- 리뷰에 뛰어난 QA를 만난다면
- 리뷰는 불만을 토해내는 것이 목적이 아니다
- 감정이 아닌 데이터에 근거한 의견을 제시할 것
5. 마치며
각종 리뷰 활동
왜 리뷰 활동이 테스트 활동 못지 않게 중요한 비중을 차지할까?
리뷰 활동을 통해 이중 리소스 방지 활동을 할 수 있기 때문입니다!
즉, 작업할 예정인 항목들을 사전에 리뷰함으로써 작업 후 재작업하는 것을 방지하거나,
작업하여 나왔으나 고객에게 도달되기 전에 확인하여 서비스 이후 발생될 리스크를 사전 방지하는 것을 의미합니다.
그럼, 어떤 것들을 리뷰할 수 있을까요?
두뇌 풀가동QA 보유 역량에 따라 아래의 활동들이 가능합니다.
리뷰 활동 대부분은 개선안이 같이 따라오는 게 좋고, 불가능하다면 이렇게 진행할 경우 발생할 수 있는 리스크를 알리며 고민할 수 있는 여지를 주는 게 중요합니다.
역량도 없이 산출물에 대한 불만만 말하는 건 애기도 할 수 있습니다 그거슨 그냥 꼰대
기획 및 컨텐츠 리뷰
논리적 오류나 유저에게 잘못 이해될 수 있는 부분, 오자 등을 사전에 캐치하여 이중 리소스 방지 및 개선될 수 있는 방향성에 대해 건의하는 과정이라고 보시면 좋겠습니다.
1. 각 의도에 맞는 기대 효과를 가져올 수 있는 부분인지 (운영/사업/매출/향후 서비스의 사이클 등) 체크
- 기대 의도 대비 예상 효과가 미미하다면 개선이 필요하기 때문입니다.
2. 법률(보안성 포함)이나 브랜드 이미지 상 문제가 될 수 있는 지 리뷰
3. 업데이트나 신규 개발 이전에 타사에서 개발한 유사한 서비스가 있다면 타사 대비 자사에서 진행되는 서비스가 독창성이나 다른 유저 풀을 가져올 수 있는 메리트가 있는 지 등등을 분석
- 이미 타사에서 너무 잘 하고 있고, 지금 진행하려는 업데이트가 시장에서 메리트가 없다면?
- 다른 방향을 찾아야 할지, 아니면 시간을 두고 점진적으로 영향력을 넓혀갈 지 선택해야 합니다
- 리소스는 제한적이고, 타이밍(시간)은 지나가면 되돌아오지 않기 때문입니다. 선택과 집중!
밸런스 리뷰
1. 재화 촉진 및 소비 / 컨텐츠 소비 및 컨텐츠 종점 예상 도달 시간 등 대해 적용 예상 그래프와 현재 그래프를 비교. 혹은 기존 다른 게임의 레퍼런스 그래프와 비교.
2. 비교 그래프를 통해 체감도 차이 및 실질적인 소모 사이클, 고비점 등을 비교하고 우려되는 부분을 미리 리뷰를 통해 의견을 전달합니다.
- 물론 밸런스 검증 단계는 리뷰 만으로 끝나지는 않고 실질적으로 이전 데이터와 비교해서 테스트를 통해 체감 후기를 작성합니다. 한 사람만의 의견이 아니라 여러 사람의 의견을 비교해가며 협의점을 찾아가는 과정이 후에 진행된다고 보시면 되겠습니다.
3. 사용자들의 반발은 없을 지, 특정 유저에게만 제공되어 형평성에 어긋나지는 않는 지 확인
- 이벤트, 보상, 컨텐츠 소비 속도 등....밸런스에 영향을 미치는 부분들이 형평성에 어긋난다면 ...
- 유저 이탈 시 객단가를 계산해보면... ^q^...
- 그럼에도 불구하고 강행해야 할 때에는 충분한 대비책을 마련하도록 대책안을 제시해야 하겠죠!
디자인 리뷰
1. 색감, 구도, 톤, 레이아웃 등 심미적 요소에서 불편함이 초래되지는 않는 지 확인
2. 유저 입장에서 제작자의 의도가 잘 전달되게끔 디자인 되었는 지 확인
- 중요한 내용은 그만큼 강조되어 표시되는지, 반대로 너무 심미성에만 치중되어 있어 주요한 정보가 알기 쉽게 배치가 안되어 있다면 예쁘기만 한 디자인이 될 수 있습니다.
코드 리뷰
1. 말 그대로 코드 리뷰. 타당성, 효율성, 적용 기술 등 기능에 대해 효율적으로, 누수 없게 코드가 작성되었는 지 확인. (사실 코드 리뷰는 이것 말고도 더 많은 활동을 하겠죠..?)
- 국내에서도 이런 역할을 하는 분들이 계시고, 해외의 경우 개발자 리더 출신 분들이 이 계열 QA로 전직하는 경우도 심심찮게 볼 수 있습니다.
IP 가이드 리뷰
1. IP 사용 계약이 체결되어 있을 경우 브랜드 IP 상 위반 사항이 없는 지 사전에 확인
예시 > "짱구는 정면 모습을 사용할 수 없다."
정면 모습을 사용한 그림 배지를 생산했는데, IP 가이드에 위반된다며 IP 소유권자가 전량 회수를 요청할 경우 계약에 의해 전량 회수해야 할 수도 있습니다.
- IP 사용을 잘못하면 소유권자에 의해 소송을 받을 수도 있고 시간, 기회, 기타 비용 등 많은 부분에서 리스크가 있을 수 있어 IP를 사용하는 서비스라면 유의 깊게 확인해야 합니다.
프로세스 리뷰
1. 업무상 진행되는 과정에서 비효율적이거나 병목 현상이 발생할 만한 구간은 없는지 혹은 누수가 발생할 만한 부분은 없는 지 리뷰를 진행하고 개선안을 제시합니다.
기타 리뷰 단계로 많이 알고 있는 Fun QA나 알파/베타 테스트 등은 설명에서 제외하였습니다.
결국은 종합적인 리뷰에 가까운 형태라..
언급한 항목 정말 다양한 분야에서 QA 분들은 여러 활동을 하고 계심을! 알아주시면 좋을 것 같고
꼭 상기의 분류를 따르지 않는다는 점도 알아주시면 좋을 것 같습니다.
근데, 이거 월권 아냐?각 파트장이 하는 업무에 가깝잖아요?
사실 품질 보증 활동은 꼭 QA만 진행하는 것은 아닙니다.
매 순간 산출물이 누군가에게 도달되기 전에 다른 부서에서도 각자의 분야에서 품질 보증 활동을 하고 계시다고 보시면 됩니다.
기획서를, 컨텐츠를, 데이터를 다듬는 일, 좀 더 효율적인 방식을 도입하는 일, 조금 더 좋은 디자인을 하려는 모든 과정이 사실 품질 보증에 해당하는 활동들입니다.
그러니 품질 보증 전문가는 주 분야인(?) 테스트만 하면 된다?
그렇지는 않습니다. 각자 전문가 분야에서 업무를 진행하고 있듯, 품질 보증 전문가 입장에서 진행될 수 있는 부분도 있음을 인정해 주시는 게 좋지 않을까 합니다.
저나 함께 일했던 분들에게 늘 말씀드리는 것은
"QA는 제작자와 사용자 사이에서 늘 중립적 입장을 유지해야 한다" 입니다.
너무 제작자 입장에서도 생각해도 안되고, 또 너무 사용자 입장에서만 생각해서도 안됩니다.
왜 중립적인 시야가 중요하냐 하면
① 제작자 입장에서만 생각했을 때 사용자를 떠나보낼 확률이 높아집니다↑
본인이 만들었을 수록 본인이 판단하기가 어렵습니다.
개발자 분들이 개발 지식이 뛰어나지만 버그를 찾기 어렵고(...
QA인 저도 제 스스로 무언가 생산했을 때 타인의 컨텐츠를 리뷰하는 것보다 훨씬 놓치는 것이 많아 후수정하는 일이 많았습니다.
전문가 분이 작성했다고, 제작했다고 해서 그것만 보고 무조건 적으로 신뢰하기 보다 충분한 검증이 필요한 이유입니다.
② 서비스의 주 고객이 회사 내 상사나 대표가 된다! (위험해!) 사용자를 떠나보낼 확률이 높아집니다↑
월급 주시거나 나의 평가를 하는 분들이니 무시하기는 어렵겠지만
실질적으로 회사 전체를 경영하는 일, 혹은 팀을 운영하는 일, 그리고 잘 제작하는 일은 각각 다 다른일입니다.
분명히 도움이 되는 의견이 되는 것도 있을 것이지만 무조건 적으로 상사니까, 대표니까 "그냥 해야지" 했다가는 계획한 것도 쉽게 틀어지고 서비스 역시 실패로 갈 확률도 높아집니다!
근거가 확실하여 도움이 되는 의견은 당연히 감사히 받되, 아닌 부분은 아니다라고 말할 용기가 필요한 것 같습니다. 힘들겠지만요.
③ 사용자의 입장에서만 생각해서 서비스에 릴리즈가 될 때 사용자의 기분은 좋지만 회사에서는 얻는게 없어서는 안되기 때문입니다. 결국 회사는 이익을 추구하는 단체이기 때문에. 가급적 양쪽을 다 만족 시킬 수 있어야 하므로, 중립적인 시야를 가지려는 노력이 필요합니다.
QA의 업무 영역에 대해 무시받는다고 생각되시는 QA 분들은 읽어주세요 ;-(
품질 보증에 있어서 QA가 왜 전문가인지, 신뢰를 쌓는 기간이 필요하기는 합니다.
QA와 업무를 진행해 본 경험이 없거나, 적을 경우 리뷰나 건의 활동에 대해 거부감이 클 확률이 높기 때문입니다. 이 부분을 잘 풀어 나가야 합니다.
반대의 입장을 생각해보면, QA 업무에 대해 잘 모르면서(.. 의견을 얘기할 때 느끼는 점 분노(... 등을 생각해보면 훨씬 이해가 수월할 것이라 예상해 봅니다.
QA 리더들은 회사의 요구를 충족하면서 QA로써의 비전에 대해 줄타기를 잘해야 한다는 말이, 이 부분입니다. 보통은 애석하게도 하고 싶다고 모든 QA 활동을 다 대조할 수는 없습니다...
상대방은 들을 생각이 없는데 내 말을 들어줘! 라고 말하는 것보다,
정말 타당한 의견을 내는 지 수십, 수백번을 검증하고, 감정이 아닌 데이터로 근거를 들며 유효한 설득을 하는 것도 QA의 능력이기 때문입니다.
우리 회사는, 혹은 협업 부서는 QA에 대해 너무 몰라줘 라는 생각이 든다면,
어떻게 하면 상대와 신뢰도를 쌓을 수 있을지부터 고민해 보는 게 어떨까요?
담당 업무에 상관없이, 이 부분은 알아주시면 좋을 거 같습니다.
첫째로,
다만 타 부서에서도 같이 일하는 QA와 상호 신뢰도가 낮다고 해서 타 부서에서
"QA인 당신이 이걸 왜 해" 라고 말할 수 있는 권리를 가지는 건 아닙니다.
품질 보증 영역에 대해 제한이 있는 건 아니니까요.
위와 같은 발언은 품질 보증 전문가인 상대방의 업무와 커리어를 철저히 무시하는 행동과 같습니다. ;-(
우리는 회사에서 각 분야의 전문가로써 만났다는 사실을 잊지 말아 주세요!
둘째로,
하지만 리뷰 활동에 뛰어난 QA를 만난다면, 반드시 그만큼 효과를 본다고 말씀드릴 수 있습니다.
믿을만한 QA를 만났다면 프로세스에 포함해서 협업을 진행해 보세요! 적극 추천드립니다.
사전에 낭비되는 리소스 방지란, 운영하는 프로젝트에 반드시 큰 도움이 될겁니다. 신뢰하시는 만큼 함께 일하는 QA 분도 반드시 성원에 보답할 것입니다.
셋째로,
협업 시 QA 활동과 리뷰의 최종 목적은 산출물에 대한 불만 제기가 아님을 다시 한 번 상기해 주시면 좋습니다.모든 것은 "사전 방지"와 "효율적 업무"가 목적입니다.
진행하시는 QA 분들도, 리뷰 활동이 "신랄하게 까는 것"이 주 목적이 아님을 꼭 알고 진행하셔야 합니다.
내가 옳으니까, 내 경험이 맞으니까 하고 까기만 했다간 반발심 크리티컬을 맞이할 수 있습니다.
넷째로,
정말 감정에 치우친 것이 아닌지 충분한 데이터 확인과 리서치를 사전에 꼭 진행하시는 게 좋습니다.
그리고 이 리뷰 활동이 공격이 아니며 객관적인 사실에 근거한 의견을 내밀고자 한다는 의사를 표현해주시는 것도 필요합니다.
리뷰 활동은 각종 리스크 방지를 위한 여러가지 수단 중 하나일 뿐이며
이 때 커뮤니케이션 트러블이 발생하는 것도 전부 리스크입니다.
(언젠가 한 번은 필요한 리스크일 수도 있습니다만...)
즉, 리뷰 전달 시 신중해야 된다는 이야기입니다.
다섯째로,
QA 분들은 모든 리뷰나 건의가 받아들여질 것이라는 기대감을 조금 버리는 게 좋습니다.
인력 때문에, 일정 때문에, 사업 방향성 때문에, 혹은 시기 때문에, 그 외 기타 여러 상황 때문에 리뷰나 건의는 적용되기 어려울 수도 있고 내비친 의견이 실상은 효용성이 없거나 적은 의견일 수도 있습니다.
다만 적용되지 않을 때에는 적용될 수 없는 이유에 대해서 충분한 설명을 해주시는 게 좋습니다. QA이기 때문에 설명해야 하는 게 아니고 '같이 일하는 동료에게 충분한 설명을 하는 것'은 오해도 없애고(건의 맨날 안받아줘!), 충분한 데이터를 전달되어 다음에는 더욱 질적으로 향상한 리뷰가 가능해지기 때문입니다!
마치며
대략적으로 타 부서와 협업을 하면서 의견차가 발생했던 부분, 오해하고 있는 부분을 위주로 간단하게 2탄을 작성해보았습니다.
리뷰 활동, Test가 포함된 QA 활동, QA 분석 활동에 대해서 한 글에 적었었는데
너무 많은 정보가 있어서 잘 읽히지 않는다는 피드백에 따라 (...
나머지 활동은 좀 더 정리해서 빠른 시일 내에 기고해 보도록 하겠습니다.
이 시리즈를 쓰면서 감히 바라는 기대 효과는 함께 일하는 QA와 그들의 업무에 대해 다시 한 번 생각해 볼 수 있는 시간이 되었으면 좋겠습니다.
같이 일하는 부서에서 QA에 대해 몰라줘요! 라고 슬퍼하시는 QA 분들께도 이 글이 작게나마 도움이 되었으면 좋겠습니다.
다음 편 QA, 잘 알아야 잘 쓴다 (3) 에서는
Test가 포함된 QA 활동은 어떤식으로 진행되는 지 적어보겠습니다.
모쪼록 유익한 시간이 되셨길 바라며, 피드백은 항상 감사히 받겠습니다.
