QA, 잘 알아야 잘 쓴다 (1)
QA 조직을 구축하고 싶은, 혹은 잘 활용하고 싶은 사람들에게
QA(Quality Assurance)란 무엇인가?
소프트웨어 업계에 있으면서 예전만큼 QA란 직업이 생소하지는 않음에도 불구하고
아직도 'QA랑은 일을 처음 해봅니다'라는 말을 심심치 않게 듣곤 합니다.
함께 일하는 QA의 이미지는 어떤 느낌일까요, 이런 느낌일까요? ㅎㅎㅎㅎ회사에 있는 QA, 혹은 QA 조직은 어떤 사람들인가?
임원진은 QA 조직에 대해 명확한 이해를 하고 있는가?
QA 리더들은 회사와 조직에 대한 비전의 균형을 맞추고 있는가?
많은 의문들이 들면서 그간 생각해왔던 것들을 끄적여보려고 합니다.
먼저, 체크를 한 번 해볼까요?
다음 중 QA의 일이라고 생각되는 일을 한 번 체크해 봅시다.
1. 테스트를 통한 결함 도출 및 보고/관리
2. 기획/논리적 오류 사전 검증 및 대안 제시
3. 사업 운영에 대한 타당성 검증
4. 개발 과정 및 협업 과정에 대한 프로세스 개선 제시 활동
5. 디자인 리뷰
6. 보안성 검수
7. 신규 컨텐츠에 대한 타당성 검수
이 중 얼마나 체크하셨나요?
QA의 능력이 허락하는 한 (또한 협업 부서에서 그러한 이해가 있다는 전제하에)
모든 것이 정답입니다.
필자는 그렇게 배워왔고, 위 모든 상황에 대한 경험을 해보았습니다.
"그건 QA가 할 일이 아닌데요. / QA가 판단할 일은 아닌 것 같은데요."
라는 말을 한 적을 봤을 수도, 혹은 했을 수도, 혹은 그런 생각이 들 수도 있습니다.
왜 정답인지는 이어서 QA 업무 개념과 목적을 설명하려고 합니다.
목적을 알고 난 후에는 이 글을 읽으시는 분의 생각이 조금 달라지셨으면 좋겠습니다.
QA (Quality Assurance) ＝ Test 이다?
정답부터 말하면 그렇지 않습니다.
QA와 Test는 동의어가 아닙니다.
대체 뭐가 달라요? 라고 묻는다면 개념적으로 간단히 설명드리겠습니다.
"테스트를 통해 품질 보증 활동을 하는 것"과, "품질 보증 활동을 테스트로만 하는 것"은
명백한 차이가 있습니다.
굳이 따지면 테스트는 이런 느낌이죠품질을 보증할 수 있는 수 많은 수단들 중에, 테스트가 유독 다른 부서 눈에 띄는 업무라
QA=Test와 같은 인식이 잡힌 것이라고 볼 수 있습니다.
"결함(Defect, Bug, Error)"이라는 단어로 커뮤니케이션이 도달하는 것과
"의견", "건의" 이라는 단어로 커뮤니케이션이 도달되는 것은 인상부터가 차이가 크니까요 :)
실상은 "의견", "건의"와 같은 QA 수단으로 QA 활동이 추구하는 목적에 도달하기 더 쉬울수도 있는데
유독 이 부분에 관해서는 커뮤니케이션이 약하게 받아들여지거나 우선순위가 낮아지는 현상들을 볼 수 있습니다.
국내 QA 조직들이 해결해야하는 오랜 숙원같은 것이기도 합니다. 이 부분도 기회가 되면 언젠가 정리를 해 보겠습니다.
그럼 어떤 활동들을 하는 지 궁금하실텐데, 자세히 어떤 활동들을 해서 품질 보증 활동을 하는지는 다음편 글에서 상세하게 서술해보겠습니다.
이번 글에서는 간단하게 개념만 설명하고, 바로 이어서 목적에 대해 설명하겠습니다.
QA의 진짜 목적
QA의 진짜 목적이 무엇일까요?
버그를 모두 없애서 안정적인 서비스 하기?
효율적인 QA 프로세스를 도입하여 릴리즈 일정 완수하기?
때깔 좋은 서비스를 만드는데 조력하기?
밑도 끝도 없이 버그를 찾고 안된다고 외쳐서 개발팀 괴롭히기? 이건 오해입니다
이런 것은 진짜 최종 목적으로 가기 위한 과정, 수단일 뿐입니다.
QA의 진짜 목적은 "예산 감소를 통한 자산 축적"입니다.
잘 먹고 잘 살자
의외이신가요?
모든 활동이 결론 적으로는 예산을 감소시키고, 그를 통한 회사의 자산 축적이 목적이라는 것을요.
제가 경험해 본(아주 극히 일부) 예시를 들어보겠습니다.
목적에 맞게 빠르게 개발했는데, 의도대로 개발했는 지 맞냐고 물어봐요.
별 것도 없는데 너무 비효율적이고 보수적인 거 같아요.
그냥 간단하게 설정만 수정한건데, 사이드 이펙트 여부를 자꾸 확인하네요.
이전 빌드 리소스 없긴한데, 환경상 마지막 빌드로 확인해도 문제 없어요.
간단한 옵션만 만졌다고 분명히 말했고, 기능에 영향 없다니까요.
ㅎㅎㅎㅎㅎ
하나하나 사례를 통해 목적과 연결지어 보겠습니다.
Case 1. 이중 리소스 방지
목적에 맞게 빠르게 개발했는데, 의도대로 개발했는 지 맞냐고 물어봐요.
별 것도 아닌데 너무 비효율적이고 보수적인 거 같아요.
왜 목적에 맞게 수정했는 지, 더 이상 개선 여부는 없는 지
기획자 분까지 불러서 2차, 3차로 확인하고 도장까지 찍을까요?
이유는 "이중으로 리소스가 낭비되는 것을 방지하기 위함입니다."
지금부터 말하는 모든 리소스 (인적, 시간 등)는 말 그대로 작은 개념으로는 양 팀에서 사용하는 "비용",
크게는 회사에서 사용하는 "비용"이 됩니다.
A 기능이 있습니다. [(메인 등에서) 추천 영역 선택 시 상세 화면으로 이동한다] 로 서술되어 있을 때
Android 개발자는 섬네일은 포함하지 않고 텍스트 정보 영역만 터치 영역으로 잡았습니다.
iOS 개발자는 섬네일을 포함하여 텍스트 정보 영역까지 전부 터치 영역을 잡았습니다.
기획자가 명확히 터치 영역을 가이드라인을 삼아준 건 아니지만 대략적 뉘앙스와 유저 경험으로 미루어보았을 때, iOS 개발자가 의도에 부합하게 개발했을 수 있습니다. 특별한 경우가 아니라면요.
말장난이기는 하지만 어쨌든 추천 영역으로는 이동했으니 "오류는 아니다"라고 생각할 수 있습니다.
다만, "개선은 해야한다"라고 QA는 그 자리에서 판단했을 것입니다.
현재 설명으로는 작은 기능이지만 OS 별로 특화된 사례를 제외하고는, 유저가 다른 경험을 겪는 것은 좋은 사례는 아니니까요.
시간이 걸려도 기획자까지 불러서 의도를 확인하고 수정 여부를 진행하게끔 커뮤니케이션을 유도하는 이유는
① 의도에 맞게 개발된 건 어느 쪽인지
② 혹은 의도에 맞지는 않았지만 (알고보니 텍스트 영역만 터치 가능 영역으로 기획자도 생각했다!) 개발자가 개발한 내용이 좀 더 유저 사용성에 좋을 것 같지는 않은 지
③ 혹은 둘 다 잘못 이해하여 둘 다 개선해야 하는 상황은 아닌 지 등
한 번 수정하더라도 여러번 결정을 번복하는 상황을 없애기 위해 확인하고 진행하게 되는 것입니다.
이미 각자 다르게 이해함으로 개선을 위한 리소스는 들어가야 하는 상태입니다. (이미 이중 비용 발생)
① 다만 커뮤니케이션 미스로 같은 기능을 두 번, 세 번 수정하여 리소스를 낭비해야 하는 일은 없어야 하기에
② 지금 기획자의 코멘트를 기다려서 수정하는 것이, 같은 기능을 두 번 세 번 수정하는 것보다는 비용이 적게 들 것이라고 판단했기 때문입니다.
Case 2. "괜찮을 거야"가 불러온 재앙
그냥 간단하게 설정만 수정한건데, 사이드 이펙트 여부를 자꾸 확인하네요.
이전 빌드 리소스 없긴한데, 환경상 마지막 빌드로 확인해도 문제 없어요.
간단한 옵션만 만졌다고 분명히 말했고, 기능에 영향 없다니까요.
글쎄, 간단한 옵션만 만졌다니까. 지금 빨리 출시하자고 하는데 그냥 나가면 안되나요?
기능에는 분명 문제없다고 장담하던 개발자, 그냥 넘어간 QA가 맞게 될 운명은...
제가 새싹 QA일 때 소규모 게임 개발사에서 QA 아르바이트를 하던 시절의 이야기입니다.
소규모 개발사이고, 유저 피드백도 빠르고, 운 좋게 반응이 좋고 매출도 괜찮았기에 빠른 개발 및 배포를 가열차게 하던 개발사였습니다. (빠르게 개발되는 만큼 중간 정리할 시간이 없었어요.)
IP도 묶여 난이도가 꽤 높은 프로젝트였는데, 업데이트 QA 마지막즈음 개발자 분이 그러더군요.
D : (1) 용량 때문에 유니티 옵션을 좀 만졌는데, (2) 기능에는 문제 없어요.
Q : (마감 직전이라 대수롭지 않게 여기고) 정말 영향이 없나요?
D : 네. 없어요.
Q : D님, 업데이트 테스트를 해야 하는데 이전 빌드에서 업데이트 테스트를 해야해요. 빌드 좀 뽑아주세요.
D : 지금 이전 빌드 리소스 없어요. 그냥 마지막 빌드로 봐도 문제 없어요.
Q : 그럼 업데이트 테스트를 못하는데... 안 봐도 괜찮을까요?
D : (3) 네. 전혀 영향 없어요. 바꾼 게 없어요.
Q : 어.. (4) 그럼 어쩔 수 없으니까 안 볼게요. QA 종료하고 라이브 모니터링 대기하겠습니다.
~업데이트 후~
그날 발생한 장애, 문제, 리스크를 정리 해보겠습니다.
개발자가 건드렸다던 그 옵션, 하필이면 저장소에 영향이 가는 옵션이라 유저가 게임 실행을 위해 서버에서 받았던 파일 중 일부만 업데이트를 받은 게 아니라 이중으로 다시 다운받게 됨
① 유저 피드백이 빠른 게임인 만큼 거의 전체 유저가 게임 실행 파일을 재다운로드하게 되어 CDN 비용이 엄청나게 발생함
② 상황 확인하여 다운로드를 막기 위해 서버 닫음. 해결될 때 까지 유저 불만 증가(이건 뭐 업데이트 하자마자 점검이야!!) + 매출 생성 불가 등 연계 이슈 발생
③ 유저 피드백이 빠르다고 말씀 드렸죠? 이미 다운로드를 받은 유저들은 갑자기 불어난 용량에 용량이 많으니 지워야겠다며 커뮤니티에 글을 올리기 시작. 삭제 인증글이 간간히 보이며 유저 이탈 보임
PD님의 분노는 차라리 나은 상황처럼 느껴질 정도로 감당하기 어려운 문제들이 발생하더군요. ㅎㅎㅎㅎㅎㅎㅎ
(1)번 대화에서 QA가 좀 더 경각심을 가졌다면
(2), (3)에서 함부로 영향도를 장담하지 않았다면
(4) 영향도를 장담했다고 해서 QA가 넘어가지 않았다면
이 무시무시한 사태들은 반드시 예방될 수 있었고, 불필요한 예산이 낭비되지 않았을 것입니다.
불필요한 CDN 비용, 유저 불만 해소를 위한 비용, 매출을 생성 못한 시간에 대한 비용, 유저 이탈을 막고 다시 불러오기 위해 사용하게 되는 비용, 이 문제를 해결하기 위해 들게 된 내부 인적 리소스... 모든 것이 불필요한 추가 비용이었고 피해가 막심했습니다.
간단한 작업이었고 조금 더 노력하면 환경을 구축하여 테스트할 수 있었던 상황이었는데
빨리 업데이트를 해야 한다는 노파심에 대수롭지 않게 여긴 것이 큰 패인이었습니다.
담당 개발자 분은 업계에서 실력이 좋기로 어느 정도 소문이 난 분이었고, 실제 일처리도 빠르고 시야도 넓으며 프로젝트에 대한 애정도도 높았던 분입니다.
그럼에도 불구하고 업데이트에서 팀이 실패한 원인은, 그 누구도 충분한 검증 없이는 서비스에 영향도를 장담할 수 없다는 것을 몰랐기 때문입니다. 어떤 훌륭한 개발자나 관리자라도 경험에 의해 실패 확률이 줄을 뿐이지, 100% 보장은 할 수 없는 것이지요.
또 반대로 , QA도 능력있는 개발자가 장담했다고 QA가 그냥 넘어가서도 안되는 것이지요.
어떠신가요?
현재는 발생 후에 대한 예산 감소 (비용 발생 방지)에 대한 사례 위주로 작성했으나
발생 전에 대한 예산 감소 활동에 대한 사례도 많답니다.
이 부분은 QA는 어떤 활동을 하는가? 에서 더 자세히 다뤄보겠습니다.
마치며
왜 우리 조직 QA는 이렇게나 보수적이고, 항상 걱정이 많고, 의심이 많을까? 에 대해 조금은 이해할 수 있는 시간이 되었으면 좋겠습니다.
QA 조직의 목적은 버그를 찾아내서 개발팀을 괴롭히는 것이 아닙니다. 혹은 득세하는 것도 아닙니다.
좋은 서비스를 만들고, 리소스 절약에 대해 늘 고민하고 생각하는 조직입니다.
가령, 돌아가는 길을 선택했을 경우에는 돌아가는 것이 결국 절약하는 길이다 라고 판단했기 때문일 확률이 높습니다.
좋은 의견이 있다면 개선 의견을 제시하며 건강한 커뮤니케이션으로 QA 조직과 협업하시게 되길 바라봅니다.
다음 편 QA, 잘 알아야 잘 쓴다 (2) 에서는
QA는 어떤 활동을 하는 지 대략적으로 설명해보도록 하겠습니다.
모쪼록 유익한 시간이 되셨길 바라며, 피드백은 항상 감사히 받겠습니다.
