들어가며
안녕하세요, 코인원 QA셀의 CO를 맡고 있는 구자현입니다. QA는 과연 어떤 역할을 하고 있을까요? 여러 개발 직군에 몸담고 계신 분들이 저에게 QA(Quality Assurance)와 관련해 반문하는 경우가 적지 않습니다. 대부분 QA팀을 테스트 역할만 하는 팀으로 인식하는 경우가 많습니다.
오늘은 기술블로그에 이러한 현실을 조금이나마 정리해서 말씀드리려고 합니다. 제가 작성하는 글은 전문적인 기술요소가 아닌 개념설명에 초점을 맞추고 있습니다. 개인적인 의견이 주가 됩니다. 다른 QA 직군 종사자분과 의견이 다를 수 있으니 참고해주시기 바랍니다. 그럼 이제 시작하겠습니다!
‘어느날 코인원 아이유(a.k.a 기술블로그 담당자)님의 DM이 도착했습니다.’
아 이렇게 기술블로그 여정이 시작되었습니다. 이 때 대답을 하는게 아니었다 (…)
과연 QA에 대해 어떤 내용을 작성해야 여러분의 궁금증을 아주 일부라도 시원하게 긁어드릴 수 있을지 고민했습니다. “조금은 무거운 기술 내용을 담고 있는 기술 블로그에 뭔가 맛깔 난 글을 쓸 수는 없을까?” 하고 말이죠. 그래서 아주 단순하지만 많은 분이 착각(?)하고 있는 내용을 다룰까 합니다. 많은 분이 저에게 QA는 무엇인지에 대해 질문을 하곤 합니다. (Q&A 아닙니다…?) 문득 한가지 생각이 들었습니다. 과연 나는 QA 절차를 잘 지켜 일하는지, 코인원은 이상적인 QA 활동을 하고 있는지, 2017년 12월 입사하고 나서 다짐했던 것들을 잘 이행하고 있는지!
잘 이행하긴…(feat. 라이언)
“QA 해주세요!” 코인원에 있으면서 가장 많이 들었던 말 중 하나입니다. 사실 여기서 우리는 큰 오류를 범하고 있습니다. 단지 ‘QA = TESTer’ 라고 생각하고 요청을 하셨다는 생각이 듭니다. QA는 매우 어렵고 전문적인 활동입니다. 프로덕트 QA를 위한 하나의 방법으로 ‘테스트’가 있고, QA 활동의 극히 일부의 영역입니다. 테스트는 품질을 향상하기 위한 행위 중 하나입니다. 테스트만 잘된다고 해서 프로덕트의 품질이 높아질 수는 없습니다. 때때로 발견된 결함도 상황에 따라 수정 없이 넘어가는 경우도 많습니다. 먼저 품질 목표를 설정하고 그에 따른 효율적인 개발 방안을 설정하는 것이 소프트웨어 품질 향상에 도움이 됩니다. 테스트에 몰두하는 것이 능사는 아니라 생각합니다.
자, 여러분은 테스트가 무엇이라 생각하시나요?
테스트는 개발 완료 단계에서 기능의 정상 동작이나 확인하는 그런 단순한 업무를 의미하는 것이 아닙니다. 테스트는 전반적인 개발 단계에 걸쳐 수행되어야 합니다. 기획/요구사항 분석 및 리뷰, 기술 명세 리뷰, 리스크 분석, 테스트 아키텍처, 테스트 환경 구축, 테스트 설계 및 수행, 테스트 스크립트 작성, 성능 테스트 등 많은 작업이 테스트 활동에 포함되어 있습니다. (자세한 설명을 하기에는 광범위하여 다음에 다루도록 하겠습니다)
그럼 코인원의 QA셀은 왜 QA를 할 수 없을까요?
대부분 QA 부서라고 하면 가장 먼저 개발이 완료되고 난 후, 완료된 프로그램을 다양한 환경에서 테스트를 수행하고 고객에게 전달하는 부서로 생각합니다.
아니라고…!!!! (feat. 나는 자연인이다)
지금까지 ISTQB Syllabus에 QA와 테스팅에 대한 이야기가 없었는데 2018년 버전에 추가되었습니다. 1.2.2 Quality Assurance and Testing을 참고하시면 됩니다. 하지만 여러분은 뭔가 부족함을 느끼실 거라 생각됩니다. (링크: https://www.istqb.org/downloads/send/51-ctfl2018/208-ctfl-2018-syllabus.html)
QA는 ‘Quality Assurance’의 약자로 제품이 일정 수준의 품질을 가질 수 있도록 제품의 기획부터 개발 그리고 릴리즈까지 모든 과정에서 함께합니다. 고객에게 최고의 품질을 서비스 할 수 있도록 최선의 노력을 합니다. 하지만 쉽지가 않죠. 가장 큰 이유 중 하나는 짧은 스프린트로 돌아가는 코인원의 목적조직에는 어울리지 않기 때문입니다.
스프린트 안에 발생하는 명세에 대한 분석 및 설계가 정상적인 범위에 수행되었다 해도 테스트 단계에서 이슈라는 벽에 부딪히기 마련입니다. 리그레션 테스트의 무한루프(테스트 > 결함수정 > 사이드이펙트 > 테스트)에 빠지는 경우가 발생할 수 있기 때문입니다. 다행스럽게도 코인원 QA의 힘은 강합니다. (네 정말 다행입니다. 저는 이것만으로 QA의 목적의 70%는 달성했다고 봅니다.) 아닌걸 아니라고 할 수 있으니 말이죠. (너무 당연한건데…)
매주 스프린트에 대한 배포 프로세스
코인원은 변화무쌍한 암호화폐 시장의 요구사항을 모두 충족시키기 위해 노력합니다. 그러다보니 어쩔수없는 D-Day(배포일정이 미리 확정된)가 있어 많은 제약사항이 발생할 수 밖에 없는 환경입니다. 그렇기 때문에 우리가 바라는 이상적인 QA활동을 하기 힘들 수 있습니다. 하지만 우리는 강합니다. 코인원 QA 셀은 각 상황에 따른 대응 매뉴얼을 만들고 수행하며, 각 상황별 QA플랜을 명시하고, 크루 개개인의 R&R을 확실하게 정/부로 나누어 운영하여 중간에 새로운 업무가 발생해도 바로 백업이 가능하도록 준비되어 있습니다.
물론 이것이 답은 아닐 수 있습니다…!
하지만 다른 회사의 프로세스가 아무리 잘 운영이 되고 있다고 해도 코인원에 맞는 운영법은 따로 있다고 생각합니다. 가장 좋은 예시로 많은 회사에서 도입하다 실패하는 `애자일`의 예를 듭니다. 그래서 코인원만의 프로세스를 만든것이죠.
출처 : https://wifflegif.com
간단히 코인원의 QA 활동을 나열해 볼까 합니다.
코인원의 QA는 정의된 요구사항에 누락 및 중복된 것이 없는지 검증하는 과정을 거칩니다. 모호한 요구사항은 담당자와 협의하여 정의하는 단계를 거쳐 요구사항을 테스트 관점에서 재정의하여 케이스를 도출합니다. 이렇게 정의된 요구사항은 추후 변경에 대하여 반영하고 이력을 관리합니다. 테스트에 대한 요구사항은 설계자 및 담당자에게 공유하고 검증하며 개발 단계별로 테스트 프로시저 및 테스트 케이스 도출에 대해 담당자와 협의를 합니다. 보통 V모델을 기준으로 진행하며 각 분석, 설계단계 별로 테스트케이스 및 프로시저를 준비할 수 있습니다.
품질 목표를 세우고 품질 목표에 기반하는 테스트계획을 세우고 분석 결과를 토대로 케이스를 작성하며 테스트 케이스는 ISO/IEC 25010 품질 특성을 기반으로 작성하려 노력합니다. 때로는 자원과 시간이 부족할 수 있습니다. 그럴 경우 리스크분석을 하는 것이 좋습니다.
코인원은 테스트케이스 수행을 최소화하고 있습니다. 추가된 신규기능에 대한 테스트케이스를 수행하며 그 외의 기능은 기본기능(필수) 체크리스트 및 API 테스트케이스(스크립트)를 수행함으로써 테스트 시간을 단축합니다. (메이저 버전의 업데이트에 한하여 전체 테스트케이스를 수행하며 일정에 따라 전사 배포를 프리징 시키기도 합니다)
자동화가 필요한 영역(자주 사용되고 UI의 변화가 없는)은 자동화를 진행 중이며 변경 사항에 대한 성능 테스트도 진행합니다. 성능에 영향을 줄 수 있는 api 또는 websocket과 같은 변경사항은 변경 전과 변경 후의 성능 측정 결과를 비교합니다.
테스트 환경은 Dev — QA — Stage — Real로 구성이 되어있으며 dev는 개발자의 영역이며 QA 환경부터 테스트가 진행됩니다. (QA 테스트 완료 > Stage 테스트 완료 > 배포 > Real 테스트)
코인원은 자신이 개발한 내역을 배포 전 한번더 확인을 위해 Dev환경에서 개발자 테스트 수행을 필수로 하고 있습니다. 테스트 내용과 테스트 결과를 jira에 명시하도록 되어 있으며 Dev 환경에서 Pass가 되지 않은 내역은 QA환경에서 테스트 진행을 하지 않습니다.
이렇게 완료된 테스트 결과를 기준으로 리뷰하고 내부 정의한 이슈 심각도 기준에 따라 배포 가능 여부를 결정합니다. 기준을 충족하면 배포를 진행하며 배포가 완료되면 리얼환경에서 추가 테스트 진행과 모니터링을 진행합니다. (오늘도 무사히🙏)
코인원의 QA 셀은 항상 이야기합니다. 완벽한 테스트는 불가능하며, 테스트는 결함이 없다는 것을 밝히는 활동이 아닌 결함의 존재를 증명하는 행위라고 말합니다. 또한 테스트로 인해 발생할 수 있는 기업의 이익에 대하여 말합니다. 초기에 발견된 결함이 수정에도 용이하며 추후 발생하는 문제점 대응에도 수월해 집니다. 늦을수록 들어가는 금액과 결함발견 및 수정에도 많은 시간이 소요되며, 성급한 테스트와 부족한 시간은 좋은 소프트웨어의 품질을 보장하기 쉽지 않기 때문에 각 상황에 맞는 리소스 분배를 진행합니다.
가끔 새벽 점검배포도…
지금까지 코인원의 QA 셀이 QA를 할 수 없는 이유와 그것을 해결하기 위한 행동을 알아봤습니다.
QA와 테스트는 전혀 다른 활동입니다. 같은 활동으로 착각하지 않으셨으면 좋겠습니다. 두 활동은 목적과 목표가 전혀 다릅니다. 테스터는 제품이 고객에게 전달되었을 때 결함이 발생할 확률을 낮추기 위한 행동을 합니다. 그러나 QA는 그 제품을 사용자가 감탄을 자아내게 하는 행동을 하기 위해 노력합니다. 가장 좋은 그림은 QA 조직과 테스트 조직을 분리하여 고객에게 결함이 적고 감동을 줄 수 있는 서비스를 유지하는 것입니다. 아직 코인원의 QA가 가야 할 길은 멉니다. 현재 진행 중인 테스트 자동화 및 케이스 고도화 등 해야 할 일이 많죠.
언제나 그랬듯이 우리는 삽질을 할 것이고, 삽질 끝에 결과를 만들어 낼것입니다. 코인원 QA셀 화이팅입니다!
바쁘다고 일정 픽스하고 던지기 있기? 없기?
기준통과 못하면 안된다…!!!! (출처 : SBS 스페셜 ‘학교의 눈물’)
다음 편에서는 개발 전반에 숨어있는 QA 활동(테스트)은 어떤 것이 있을지 알아보는 시간을 가질 예정입니다. 감사합니다!
구자현, Release Manager & QA
가입하기
