테스트는 누구나 할 수 있지만, QA는 준비된 자만이 할 수 있습니다.
시작하며
안녕하세요. 카카오엔터프라이즈 서비스품질파트의 테오입니다.
카카오엔터프라이즈는 카카오 워크, 카카오 i, 카카오 i 커넥트, 카카오 i 인사이트 등의 다양한 사업 영역에서 인공지능 기반 플랫폼과 솔루션 서비스들을 기획하여 출시하고 있는데요. 이러한 많은 서비스들을 시장에 성공적으로 출시하기 위해 기획, 개발, QA, 사업, 마케팅팀을 비롯하여 많은 구성원들이 각자의 자리에서 주어진 역할에 최선을 다하고 있습니다.
이 중, 여러분은 QA(Quality Assurance) 팀에 대해서 얼마나 알고 계신가요?
제가 처음 만나는 사람들에게 QA팀이라고 소개를 하면, 대부분 제조업 분야에서 기계 성능을 테스트하는 QA를 생각하는 경우가 많습니다. 대화를 이어가기 위해 카카오엔터프라이즈의 QA 파트에 대해 이야기를 시작하면, 어떤 이들은 “IT 회사인데도 QA가 있나요?”라고 되묻기도 합니다. 심지어 IT 회사에 다니는 몇몇 친구들조차 “우리 회사는 QA 없는데...:”, “우리는 개발팀에서 테스트까지 다 해서 QA는 필요 없는데..” 라는 반응을 보이기도 합니다.
사실 소프트웨어의 역사만큼이나 QA 역사는 길지 않고 실제로 QA 조직이 없는 IT 기업들도 존재하기 때문에 이들의 반응이 이해가 안 가는 것은 아니지만, “테스트는 누구나 할 수 있지만, QA는 준비된 자만이 할 수 있다”라는 사실을 우리는 절대 간과할 수 없을 것입니다.
그래서 오늘 이 자리를 빌려 카카오엔터프라이즈의 기술 플랫폼과 솔루션 전반의 품질 보증을 책임지고 있는 팀으로서 서비스품질파트가 수행하고 있는 QA 활동, 업무 방향성 및 업무 방식등을 소개하고자 합니다.
QA는 Test일까?
카카오엔터프라이즈의 스마트 스피커인 카카오 미니(Mini), 많이 사용하고 계시죠? :)
그런데 카카오 미니가 이처럼 사용자가 원하는 요구사항을 제대로 제공하지 못한다면 어떻게 될까요?
사용자 : "헤이카카오, 오늘 삼평동 날씨 알려줘."
헤이카카오 : "네, 고맙습니다."
사용자 : ??? 😭
혹시라도 이런 상황이 발생한다면 기획, 개발 및 마케팅 등에 투입되었던 많은 구성원들의 노고는 제대로 인정받지 못할 것이며, 단순한 사용자의 불편함을 넘어 전사 서비스 이미지에도 부정적인 영향을 미치게 될 것입니다. 이런 부정적인 고객 경험이 하나, 둘 모이게 되면 결국 영업 손실이라는 리스크로 이어질 수도 있는데요. 이러한 상황을 사전에 예방하기 위해 QA 활동이 필요합니다. 즉, QA는 프로젝트 목적에 대한 정확한 이해를 바탕으로 서비스 품질을 보증하여 비즈니스 리스크를 감소시키고, 사용자에게 최대의 서비스 가치를 제공하는 것을 목표로 합니다.
QA의 테스트 방법론은 여러개가 존재하지만, 그 중 ISO/IEEE 29119-2 표준의 동적 테스트 프로세스(Dynamic Test Processes)가 가장 널리 활용되고 있습니다.
| 동적 테스트 프로세스 단계 | 설명 |
| 테스트 설계 및 구현 | 테스트 베이시스(요구사항, 기획) 검토 및 리뷰, 리스크 분석, 테스트 컨디션 파악, 테스트 케이스 설계 |
| 테스트 환경 구축 및 유지보수 | 특정 테스트 환경 요구사항을 분석하고 환경 구축 및 유지보수 수행 |
| 테스트 실행 | 테스트 실행 후 보고서 작성, 완료 조건 평가 |
| 테스트 인시던트1 보고 및 마감 | 결과서 작성과 프로세스 회고 진행 |
앞서 잠깐 언급했지만, 소프트웨어 분야의 QA 역사는 제조업 분야의 QA만큼 길지 않은데요. 따라서 QA 조직을 운영 중인 회사에도 실제 QA 엔지니어들과 일을 해 본 개발자는 그렇게 많지 않습니다. 그래서 간혹 서비스 출시 3일 전에 다급하게 “3일 후에 서비스 출시인데 빠르게 테스트 해주세요"라는 요청을 (아직도) 받을 때가 있습니다. 이렇게 QA를 서비스나 상품 출시 직전에 테스트하는 업무로만 생각하시는 분들도 있을 수도 (실제로 많이) 있는데요. 이 자리를 빌려 “QA는 Test가 아니다.”라는 점을 다시 한번 강조하고 싶습니다.
즉, QA는 서비스 기획 단계부터 참여하여 개발, 테스트 그리고 출시까지의 전체 소프트웨어 라이프 사이클 전반에서 잠재적인 품질 리스크를 찾아내어 프로젝트 참여자들과 공유하며, 해당 서비스가 최종 사용자의 요구사항에 충족하는지에 대한 다양한 활동을 진행합니다. QA 업무에 있어서 테스트는 다양한 QA 활동 중에 하나라고 볼 수 있습니다.
효율적인 QA를 위해
ISO/IEC/IEEE 29119-2:2013 표준의 동적 테스트 프로세스(Dynamic Test Processes)를 기반으로 주어진 자원(일정 및 인원) 내에서 단계별 테스트 계획을 철저히 실행할 수 있다면, 적어도 이론적으로는 이상적인 QA 활동을 수행할 수 있습니다.
하지만 현실에서 이런 이상적인 QA 활동을 수행하기는 그리 쉽지 않습니다. 프로젝트 구성원으로 참여하다 보면 여러 종류의 예기치 못한 변수들이 발생하게 됩니다. 예를 들어 테스트 계획에 포함되지 않은 기능 요구사항들이 갑자기 추가되거나, 개발과 테스트 환경 구축에 예상보다 많은 시일이 소요되어 테스트 일정을 준수하지 못하게 되는 상황 등에 직면하게 됩니다. 이런 상황에 대처하기 위해 저희는 조직 레벨에서의 테스트 전략과 그에 부합하는 테스트 계획을 최대한 상세하게 수립하는 동시에 프로젝트 단위별로 변경점이 발생할 때마다 테스트 계획을 유연하게 수정하는 전략을 취하고 있습니다. 이러한 전략의 일환으로 QA 구성원 모두가 Quality Accelerator의 역할을 수행하며, Test Case 설계 및 수행 등의 단순한 ‘테스트 활동’ 보다는 효율적이고 이상적인 ‘테스트 방법’을 끊임없이 탐색하고 고도화시키는 전략을 취하고 있습니다.
이런 전략은 한정된 자원을 효율적으로 활용하여 시간과 인적 자원 등을 절감하는 고효율 테스트를 수행하는데 목적이 있는데요. 이런 전략의 방법론으로서 저희는 ‘리스크 기반 테스팅’, ‘RST(Rapid Software Testing) 방법론’, 그리고 테스트 자동화 등을 프로젝트에 유연하게 적용하고 있습니다.
#리스크 기반 테스팅
리스크 기반 테스팅(Risk-based Testing)은 리스트 척도 평가를 통해 높은 아이템과 낮은 아이템에 따라 자원을 효율적으로 활용하는 테스트 방식으로 크게 리스크 아이템 식별, 리스크 분석 및 테스트 전략 수립 단계로 구성됩니다.
카카오엔터프라이즈에서는 프로젝트 단위별로 자원을 분배하여 QA 활동을 하고 있는데 한정된 자원으로 모든 프로젝트를 동일한 수준으로 대응하기는 매우 힘든 상황입니다. 이런 이유로 리스크 평가 절차에 맞추어 프로젝트별 조건에 따라 과제나 기능 단위로 리스크 아이템을 식별하는 작업을 수행합니다. 그 후, 식별된 리스크 아이템들을 대상으로 사업 및 마케팅 등 다양한 내부 조건에 맞추어 중요도를 평가하고 테스트 우선순위를 부여하여 그에 맞는 테스트 전략을 수립합니다.
| 리스크 기반 테스팅 단계 | 설명 |
| 리스크 식별 | 대응하는 과제 혹은 기능 단위로 리스크 아이템을 식별합니다. |
| 리스크 분석 | 식별된 아이템을 내부 기준에 맞추어 평가하여 중요도에 따라 테스트 우선순위를 부여합니다. |
| 테스트 전략 수립 | 부여된 우선순위에 따라 테스트 전략을 수립하고, 해당 테스트의 범위와 프로세스, 산출물 등과 같이 상세한 테스트 계획을 작성합니다. |
테스트 전략을 수립할 때에는 SDLC(Software Development Life Cycle)의 전체 범위를 대상으로 한 ‘Full Cycle 프로세스’와 제한된 일정 혹은 자원에 대한 대응이 필요할 때 테스트 차터(Test Charter)2를 활용하는 ‘경량화된 프로세스’로 구분하여 업무에 활용하고 있습니다.
하지만 앞에서도 언급했듯이, 실제 업무에서는 여러 예기치 못한 변수가 발생하기 때문에 테스트 프로세스 중 하나를 선택하여 완벽히 준수하기는 쉽지 않습니다. 따라서 테스트 리드는 정의된 테스트 기법과 프로세스를 준수하되, 프로젝트별 환경(일정, 인프라, 협업 조직 구성 등)과 변수 등을 면밀히 파악하여 더욱 효율적인 방식으로 테스트 계획과 프로세스를 유동적으로 조정하며 테스트 업무를 수행하는 것을 목표로 합니다.
#RST(Rapid Software Testing)
리스크 기반 테스팅 외에도 저희는 정해진 리소스를 효율적으로 운용하는 방식을 꾸준히 연구하며 적용해보고 있는데, 그중 하나가 제임스 바흐(James Bach)가 제안한 Rapid Software Testing(이하 RST) 입니다.
RST 방법론은 제품이나 소프트웨어가 가지는 다양한 정황(Context)에 대한 이해를 바탕으로 상세하게 수립된 미션을 수행하고(Mission-Focus), 예산과 시간이 정해져 있는 상황에서 한정된 자원을 효율적으로 활용하는 것에 집중하는 접근 방식입니다. 카카오엔터프라이즈에서는 일부 프로젝트에 RST 방법론을 적용하여 테스트를 수행 중이며 프로젝트별 일정과 제한된 자원, 환경 등의 여러 정황을 고려하여 테스트 리드의 판단하에 공식화된 테스트와 탐색적인 테스트 방식을 적절히 편성하여 업무를 수행하고 있습니다. 이는 RST 방법론이 가지는 목적과 동일하며, 문서나 산출물의 유지 보수 비용을 최소화하여 절감된 자원을 통해 테스트 가치를 극대화하는 데 그 목적을 두고 있습니다.
#테스트 자동화
이 밖에도 한정된 자원을 효율적으로 활용하기 위해 반복되는 테스트 범위에 대한 커버리지를 확보할 수 있는 목적으로 테스트 자동화도 좋은 접근 방식이 될 수 있습니다. 현재 저희는 Sanity Test 용도로서 공통 범위를 대상으로 하는 UI 테스트 자동화와 카카오 i에 탑재된 다양한 도메인에 대한 발화 테스트 용도로 API 자동화 등을 적용했으며, 가능한 전체 서비스에 이런 테스트 자동화를 도입하는 것을 목표로 하고 있습니다.
UI 테스트 자동화를 조금 더 설명하자면, 저희는 웹이나 애플리케이션 영역을 대상으로 Selenium과 Appium 기반으로 스크립트를 작성하여 업무에 활용하고 있는데요. 유지 보수가 최대한 적게 발생하는 공통 영역을 선정한 후, 해당 영역에 대한 테스트 시나리오를 기반으로 스크립트를 작성하고 적용하고 있습니다. 이는 유지 보수에 드는 비용을 최대한 줄여 리소스에 대한 부담을 줄이려는 목적으로, 테스트 스크립트는 키워드 중심(Keyword-driven) 구조로 설계되며 다양한 용도에 맞추어 필요한 기능들만 수행하는 것도 가능합니다.
하지만 테스트 자동화 영역은 QA 리소스를 대체하는 용도로 접근하기보다는 QA 활동의 일부분을 대체하여 활용하는 것을 목표로 하는 것이 이상적이며, 적용 커버리지 역시 현실적인 수치를 목표로 잡는 것이 중요합니다. 또한 테스트 자동화에만 너무 집중하면 다양한 영역에서의 활동에 제약이 발생할 수 있고, 오히려 매뉴얼로 테스트하는 것보다 효율이 떨어질 수 있기 때문에 이런 점도 유의해야 합니다.
마무리하며
지금까지 QA에 대한 간략한 설명과 카카오엔터프라이즈 QA 파트에서 실제 진행하고 있는 QA 업무 이야기를 두서없이 소개해 드렸는데요. 회사마다 QA 직군이 담당하는 역할에 차이가 있기 때문에 익숙한 내용도 혹은 조금은 생소한 내용도 있을 것 같습니다.
테스트는 품질 향상을 위한 QA 역할 중 하나로 굉장히 중요한 활동이지만, 테스트를 계획한 대로 잘 수행했다고 해서 품질에 대한 확보가 동일하게 이루어졌다고 확신하기는 어렵습니다. 따라서 각 프로젝트 구성원들은 특정 프로젝트 목적에 대한 정확한 이해를 바탕으로 리스크 기반 테스팅, RST 기법, 혹은 테스트 자동화를 적절히 활용하여 테스트 커버리지를 효율적으로 확보할 수 있도록 다양한 관점에서 테스트 전략을 설계하는 것이 중요합니다. 이런 전략을 바탕으로 각 구성원들의 수행 역할이 톱니바퀴처럼 맞아 돌아갈 때, 사용자에게 최대의 서비스 가치를 제공할 수 있을 것이며 카카오엔터프라이즈 QA 파트의 존재 이유를 찾을 수 있을 것입니다.
카카오엔터프라이즈는 서비스품질 파트를 별도 조직으로 운영하며, 서비스 퀄리티에 대한 중요성과 책임을 가지며 다양한 서비스를 만들어 가고 있습니다. 앞으로 수많은 QA 활동이 녹아있는 신규 서비스들을 지켜봐주시고 응원해주시면 감사하겠습니다.
자, 그럼 도입부에 언급했던 “테스트는 누구나 할 수 있지만, QA는 준비된 자만이 할 수 있습니다.” 라는 문구를 다시 한번 되새겨 보며, 오늘 포스팅을 마치도록 하겠습니다. 본문에는 간단히 언급하고 넘어갔지만, 기회가 된다면 카카오엔터프라이즈의 QA 파트에서 진행하고 있는 테스트 자동화와 관련된 내용도 상세히 다뤄보도록 하겠습니다. 부족한 글솜씨임에도 긴 글 읽어주셔서 감사드립니다.
참고 문헌
[1] ISO/IEC/IEEE 29119-2:2013 (Test Planning Process)
[2] ISO/IEC 25010:2011 (Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models)
[3] Rapid Software Testing (https://rapid-software-testing.com/)
[4] SATISFICE (https://www.satisfice.com/)
[5] Test Charter (https://www.tmap.net/)
Teo (오태준)
새로움에 대한 도전을 좋아하고 효율적인 테스트에 관심이 많은 Quality Engineer입니다.