Quality Scientist
Quality Scientist & Quality Design(er)
Quality Assurance > Quality Scientist and Quality Design(er)
제1장 - 변화되는 테스트
우리는 매일 테스트를 합니다.
프로덕트의 론칭과 서비스를 목표로 개발을 진행하고 빌드를 만들면 팀 내부에 배포가 진행됩니다. 이제 QA는 이 빌드를 기획서 기반으로 작성한 테스트 케이스를 수행하여 테스트를 진행합니다. 진행 중 발생 이슈는 버그 추적 시스템에 등록 후 관리되며, 이후 수정과 재 빌드 반복 후 최종 잔여 이슈를 확인하고 라이브 배포합니다.
이 일련의 과정은 글로 쓰는 자체가 너무 어색할 만큼 매우 자연스러운 QA의 업무입니다.
테스트는 QA의 주 업무로 변함이 없습니다. 이렇게 우리는 매일 테스트를 합니다.
그렇다면 우리는 매일 똑같은 업무를 매일 반복하는 걸까요?
마치 QA의 기본 소양처럼 여겨지는 ‘반복되는 업무에도 지치지 않는’ 사람들처럼?
테스트라는 기본 업무의 핵심은 동일할 수 있지만 테스트 환경과 상황은 매일 변합니다.
아니 매일 변해 왔습니다.
개발 방법론은 폭포수에서 V 모델, 애자일과 데브옵스 등 많은 방법론과 개념을 도입하여 활용하고 있습니다. 제품 서비스를 제공하는 단말 환경은 PC에서 모바일, 웹, 콘솔 등으로 다양해졌고 플랫폼 또한 애플, 구글, 원스토어, 스팀 등으로 다양해졌습니다.
특히 모바일 단말의 폭발적인 보급으로 사용자는 시간과 장소에 구애받지 않고 우리의 제품을 사용할 수 있게 되었습니다. 이는 자연스럽게 빠른 콘텐츠 소비 속도로 연결되었으며, 이에 비례하여 개발 및 업데이트 스케줄은 몇 달에서 몇 주로 단축되었습니다.
이러한 변화에 대응하면서 동일한 품질을 보장하기 위해 QA의 테스트 방법, 프로세스, 판단 기준과 같은 부분에 크고 작은 변화가 생겼습니다. 그렇게 우리는 변함없이 이전과 동일하게 매일 테스트를 하고 있지만 상세히 본다면 사뭇 다른 테스트를 하고 있습니다. 마치 우리의 책상 위 테스트 디바이스가 모니터와 키보드에서 모바일 단말기로 바뀐 후 다시 모니터와 키보드로 바뀐 것처럼 말입니다.
우리의 책상 위 테스트 디바이스가 모바일 단말기로 변화된 초기.
QA는 과거의 프로세스와 동일하게 빌드와 기획서 배포를 기다리고 테스트 케이스 작성 후 테스트를 진행하였습니다. 하지만 짧아진 업데이트 주기, 테스트 진행 중 이슈 발생 시 재 빌드에 소모되는 많은 리소스, 새로운 플랫폼 정책 등 다수의 변화에 적응이 필요했습니다. 이에 QA는 새로운 개발 방법론, 기술, 축적된 노하우와 함께 오랜 기간 시도했던 테스팅 이론을 실무에 적용합니다.
잠시 기존과 변화된 프로세스를 한번 간략하게 되짚어 보도록 하겠습니다.
1. 기획 테스트
ISTQB의 이론을 바탕으로 개발 초기 단계부터 QA의 참여가 필요하다는 주장은 단순히 프로덕트의 이해도 상승을 넘어서 기획 리뷰를 기반으로 기획 테스트를 진행합니다. 이를 통해 빌드 배포 전 발생할 수 있는 기획적 이슈를 사전에 차단하고 단위 테스트의 수행에 필요한 테스트 케이스를 생산합니다.
2. 단위 테스트
PC 단말 테스트 환경 경험을 기반으로 애자일 방법론, 단위 테스트, 개발 엔진 활용을 병합하여 이제는 개발 QA에게 매우 익숙한 엔진 테스트가 도입되었습니다. 이는 현재 QA의 기본 테스팅 기법이 되었으며, 빌드 발행 전 대다수의 기능 이슈를 제거하여 빌드 재 발생으로 인한 리소스 낭비를 해결하고 있습니다.
3. 통합 테스트
모바일 환경에서 필수로 진행되는 플랫폼 테스트 단계에 통합 테스트를 결합하고 리소스/리비전/빌드 매니징을 강화하여 빌드 리턴을 최소화합니다. 여기에는 기능 만을 다루던 기존의 인수 테스팅을 새롭게 강화하여 비중을 높이고, 세너티 테스트와 시스템 테스트 기법 또한 활용하고 있습니다.
4. 이슈 관리/빌드 배포
이슈의 중요도 분리 및 빌드의 배포 결정은 데브옵스와 데이터 주도형 운영 시뮬레이션 테스트를 기반으로 재 정의되었습니다.
이 외에도 크고 작은 많은 부분에서 기존 방식에 변화가 생겼습니다. 프로젝트의 마지막을 담당하던 QA는 이제 마지막뿐만 아니라 프로덕트의 시작과 진행, 출시와 이후 운영 전반에 걸쳐 깊게 활동합니다.
이 글을 읽는 많은 QA는 ‘무슨 당연하고 다 아는 뻔한 이야기를 이렇게 장황하게 작성하였는가?’라는 생각이 듭니다. 맞습니다. 지금부터 하는 이야기는 너무나도 뻔하고 당연한 이야기입니다.
우리 모두가 너무나 자연스럽게 적응하고 변화해 왔던 이야기를 다음의 단어로 정의해보려 합니다.
Quality Scientist and Quality Design(er)
우선 우리를 지칭하는 단어인 QA(Quality Assurance)에서 ‘assurance’를 찾아보았습니다.
as·sur·ance
1. 확언, 장담, 확약
2. 자신감
3. (보장성) 보험
퀄리티를 장담/보장한다는 내용으로 해석이 가능할 듯합니다.
사전적 의미와 함께 우리에게는 Tester, Test Leader, Quality Engineer, Quality Manager와 같은 단어도 익숙합니다.
그렇다면 퀄리티 사이언티스트, 퀄리티 디자인은 어떠한 의미일까요?
퀄리티 사이언티스트는 프로덕트의 기능과 환경을 분석하고 이를 바탕으로 해당 프로덕트에 필요한 테스트 전략을 수립하여 프로덕트와 테스트를 연결하는 역할을 합니다. 또한 프로덕트의 목표 퀄리티를 계획하고 해당 목표에 도달할 수 있도록 테스트를 기획하고 테스트를 수행합니다.
앞서 반복했던 내용처럼 우리가 테스트하는 프로덕트의 상황은 매우 빠르게 변화합니다. 이러한 변화에 대응하여 해당 프로덕트의 목표와 현재 상황을 분석하여 수행이 되어야 하는 테스트를 선별하고 테스트 전략을 수립합니다. 또한 해당 프로덕트에서 구현 가능한 목표 퀄리티를 설정하고 해당 목표에 도달할 수 있도록 개발을 요청하거나 테스트를 기획합니다.
이를 좀 더 상세하게 들여다보겠습니다.
제2장 - 지금 우리의 테스트
1. 프로덕트의 목표
테스트 목표를 찾기 위해 일반적으로 익숙한 ‘프로젝트’라는 단어보다 프로덕트라는 단어를 사용해 보겠습니다. 그렇다면 프로젝트와 프로덕트의 목표는 서로 차이점이 있을까요?
아닙니다. 두 단어의 최종 목표는 같습니다. 단지 프로덕트가 조금 더 세분화된 목표라고 할 수 있습니다.
게임 프로젝트의 목표는 무엇일까요?
프로젝트마다 차이점이 있겠지만 일반적으로 명세서 기반 기능 구현, 균형 잡힌 밸런스, 기획 요소, 고객 경험 , 정시 출시 등의 다양한 요소가 게임 프로젝트의 목표라고 할 수 있습니다.
그렇다면 프로젝트의 결과물인 프로덕트의 목표는 무엇일까요?
프로덕트의 목표의 기본은 프로젝트를 상속하지만 가변적으로 상황에 따라 달라집니다.
마치 클래스와 유사한 느낌일까요?
예를 들어 여기에 이벤트 콘텐츠에서 고객 경험을 기존보다 더욱 긍정적인 방향으로 강화하기 위한 A/B 테스트를 준비하고 있는 프로덕트가 있다고 가정해 보겠습니다.
(이후 테스트라는 단어 반복에서 오는 혼란을 방지하기 위하여 'A/B 테스트'를 'A/B'로 표기합니다.)
이 경우 프로덕트의 목표는 프로젝트의 일반적 목표인 기능 구현과 재미 요소, 고객 경험을 상속함과 동시에 정확한 기능 구현과 데이터 수집이라는 새로운 목표를 가지게 됩니다. 물론 프로젝트의 모든 목표를 상속하여 포함할 수 있다면 좋겠지만 우선순위가 높은 목표는 현재 프로덕트의 목표입니다.
프로덕트의 목표가 파악되었다면 이제 QA의 테스트 목표는 정확한 데이터의 수집 가능 여부와 함께 데이터 수집에 영향을 줄 수 있는 기능적, 환경적 이슈를 찾는 테스트 목표를 가지게 됩니다.
클라이언트에서 이벤트 진행 시 기능이 정상 작동하여 관련 데이터가 수집이 되는지 확인합니다. 이후에는 수집한 데이터가 해석 가능하도록 제공되는 환경 구성을 테스트합니다.
이렇게 프로덕트의 목표 달성이 테스트의 목표 달성이 됩니다.
2. 프로덕트의 환경
목표와 함께 프로덕트에 QA를 연결하기 위해 퀄리티 사이언티스트는 프로덕트의 환경을 상세하게 파악합니다. 그리고 클라이언트와 서버, DB, 데이터(테이블) 구조와 같이 게임의 전체적인 구조를 파악합니다. 또한 운영 툴 및 통계 툴과 기타 다양한 서드 파티 툴에 대한 부분도 포함됩니다.
여기에서 '왜 QA가 테스트 영역 외 이런 것까지 알아야 하는가?'라는 생각이 들기도 합니다.
사실 게임의 기능 테스트만을 목표로 한다면 이러한 정보는 불필요합니다. 하지만 개발 전반에 걸쳐 테스트의 영역이 확장되고 기존과 다른 테스트를 진행하기 위해서는 프로덕트의 다양한 정보가 필요합니다.
클라이언트와 서버의 구조 정보 기반으로 이슈 발생 시 재 빌드와 패치를 결정할 수 있습니다. 추가적으로 이를 통해 QA는 이슈의 우선순위와 재 빌드의 시점의 파악이 가능합니다. 또한, 네트워크 테스트에도 이를 적용하여 더욱 명확한 테스트를 할 수 있습니다. 테이블 구조에 대한 이해를 기반으로 게임의 수치와 관련된 테스트와 함께 휴먼 에러를 방지하고, 데브옵스 개발 방법론 안에서 운영 툴과 로그는 프로덕트에서 기능 이상으로 중요한 환경이기도 합니다.
최근에는 프로덕트의 주 고객층과 같은 기능이 아닌 외부 환경 또한 매우 중요한 요소입니다.
데브옵스 개발 방법론에서 이러한 외부 환경 요소는 기능적 오류보다 리소스와 같은 디자인적 요소 이슈의 중요성이 더욱 강조되기도 하며, QA가 페르소나 테스트를 진행 시 해당 부분을 고려하여 진행할 수 있습니다.
이처럼 퀄리티 사이언티스트는 단순히 게임의 기능과 함께 더욱 광범위한 부분에서 프로덕트를 파악하고 이를 테스트에 활용합니다.
3. 퀄리티 디자인
프로덕트의 목표와 환경을 기반으로 테스트 목표를 설정한 퀄리티 사이언티스트는 퀄리티 디자이너의 역할을 수행합니다.
퀄리티 디자인은 퀄리티 목표, 테스트 스토리, 테스트 환경과 같은 항목을 고려하여 진행합니다.
우선 퀄리티 목표를 설정합니다. A/B에서 퀄리티의 목표는 수집되어야 하는 데이터 세트가 빠짐없이 수집되고 기록이 되는 게 목표라고 할 수 있습니다.
다음으로 해당 목표를 달성하기 위한 과정. 즉 테스트 스토리를 작성합니다.
퀄리티 디자이너는 A/B의 테스트 기본 스토리를 아래와 같이 작성합니다.
QA는 기존에 서비스하고 있는 이벤트 기능에 A/B가 추가된 빌드를 수령합니다. 이후 해당 빌드에서 이벤트 진행 시 관련 데이터가 예약된 툴 또는 공간에 수집될 것이고 이후 수집된 데이터가 가공되어 해석 및 판단이 가능하도록 제공이 되는 스토리를 예상합니다.
테스트 스토리는 바로 테스트 진행 과정을 미리 시뮬레이션해 보는 과정입니다.
여기에 퀄리티 디자이너는 스토리를 추가합니다. 기본 스토리 이후 확장판과 같은 개념이라고 할 수 있습니다.
아래와 같은 스토리를 추가해 보겠습니다.
해당 테스트 이후 동일한 테스트 진행 가능성을 파악하고 재 활용 가능한 테스트(또는 테스트를 하지 않아도 이슈가 없도록 테스트)를 설계한다.
수집된 데이터를 기반으로 의사 결정된 항목을 적용하는 프로세스를 파악한다.
해당 테스트 진행에 필요한 역량과 이후 팀이 보유할 수 있는 역량을 측정한다.
이제 기본 스토리와 추가 스토리가 완료되었으니 테스트 스토리 진행에 필요한 환경을 파악해 보겠습니다.
테스트 디자이너는 기본 스토리와 관련된 A/B 요청자, 콘텐츠 디자이너, 데이터 사이언티스트와 함께 A/B 기획, 이벤트 콘텐츠 변경 사항, 데이터 적재 및 분석 과정에 대한 정보를 기반으로 테스트 케이스 또는 체크리스트를 제작합니다. 추가적으로 테스트에 필요한 실 데이터 또는 더미 데이터, 검증 대상으로 수집되어야 하는 데이터 시트 등을 요청하며 기본 스토리를 완성합니다.
또한, 추가 스토리를 위해 테스트 이후 추가적인 A/B 진행 예약을 확인하여 재 활용 가능하도록 기능 설계에 대한 요청과 결정된 A/B를 라이브에 적용하는 시나리오를 요청합니다.
테스트 진행에 QA가 활용해야 하는 데이터 관련 툴에 대한 트레이닝 필요 여부도 파악하고, 트레이닝이 진행되어 팀의 역량으로 전환이 된다면 향후 다른 테스트에 해당 툴의 사용 가능 여부도 고려해서 확장 스토리를 완성합니다.
이후 완성된 스토리를 기반으로 테스트를 진행하고 이 스토리가 해피 엔딩으로 끝나길 바랍니다.
하지만 재미있는 스토리에는 언제나 크고 작은 이벤트가 발생합니다.
하나의 예시로 출시 전 라이브 환경의 오픈 적합성 테스트의 진행과 범위에 대한 논의를 해 보겠습니다.
출시 전 라이브 환경 구축 후 해당 환경에서 QA가 풀 테스트를 진행한다면 우리는 당연히 높은 안정성과 품질을 보장할 수 있습니다.
하지만 해당 게임이 최대 한 달 주기의 콘텐츠를 제공한다면 어떠한 상황이 발생할까요?
주기 진행을 위해 한 달을 사용하고 이후 데이터를 초기화하고 정상 진행 확인을 위해 다시금 한 달을 사용하여 출시 전 최소 두 달이 추가적으로 소모되어야 합니다.
물론 사전에 일정을 확보하고 변경 및 지연이 없다면 해당 테스트는 무난하고 만족스럽게 진행될 것입니다.
하지만 안정성과 함께 속도는 QA에게는 항상 고민이 되는 항목이며, 모바일 환경에서 이 고민은 더욱 부각됩니다.
이러한 고민을 해결하기 위해 프로덕트가 개발 서버에서 QA 서버, 스테이지 서버로 이동하는 과정에서 빌드 매니징을 강화하고 환경적인 발생 이슈를 파악하여 최종적으로 라이브 환경으로 이동 시 발생할 수 있는 이슈를 차단하는 과정을 거칩니다.
이 과정에서 별다른 이슈가 없다면 스토리는 해피 엔딩으로 끝이 나겠지만 크고 작은 이벤트가 발생한다면 우리의 테스트 스토리는 대대적인 수정이 진행될 것입니다.
퀄리티 디자인에 대한 다른 예시도 한번 살펴볼까 합니다. 이번에도 데이터와 관련된 이야기입니다.
과거에 테스트 및 최종 이슈 확인까지 완료된 후 데이터(밸런스)가 변경되는 경우 ‘밸런스는 원래 출시 전 마지막 순간까지 바뀌는 거야!’라는 말로 위로하던 때가 있었습니다.
A/B 테스트, 고객과의 적극적 소통, 데이터 기반 운영이 보편화된 현재는 출시 전 마지막 순간이 아닌 출시 후 아니 지금 이 순간에도 바뀌고 있습니다. 이제는 확정된 데이터(밸런스)를 기반으로 진행하는 테스트보다 데이터의 원활한 변경 가능 여부 테스트의 중요도가 높아졌습니다. 이를 기반으로 현재 서비스 중인 환경에 중단 없이 데이터 배포 또는 교체 방법 테스트가 필수가 되었습니다
이를 위해 퀄리티 디자이너는 프로덕트의 변경 가능한 데이터 분류, 범위, 주기 등을 파악하고 퀄리티가 확보된 데이터를 적용하기 위한 방법(점검, 롤링 업데이트, 테이블 교체 등) 또한 파악합니다. 이후 파악한 자료 기반 테스트 진행에 필요한 기획서, 데이터 구조도, 테스트용 더미 데이터, 업데이트 시나리오 등 을 요청하고 이를 사용하여 목표로 설계한 퀄리티를 확보하기 위한 테스트를 진행합니다.
이 과정에서 타 부서에 목표 퀄리티를 확보할 수 있도록 데이터 구조 변경 요청과 같은 최선의 선택지를 제공하기도 합니다.
4. 퀄리티 전략
이제 대망의 마지막 순간! 확인된 퀄리티를 라이브에 배포하는 과정입니다.
완료된 빌드의 배포가 가능한 순간은 언제일까요?
아니. 빌드가 최종 완료된 시점은 언제로 봐야 할까요?
해피 엔딩을 상상한다면 당연히 모든 항목의 테스트를 진행하고 발생한 모든 이슈를 수정한 다음 수정 영향 범위의 테스트까지 완료한 다음일 겁니다. 하지만 QA는 이 일이 불가능하다는 사실을 누구보다도 잘 알고 있습니다. 완벽한 테스트는 없다는 사실은 그 누구보다 QA가 더 잘 알고 있습니다.
또한 현재의 프로세스와 환경은 라이브 배포 시점이 매우 중요하기 때문에 충분한 시간이 주어지지 않는 경우도 많습니다.
이러한 환경에서 퀄리티 사이언티스트는 배포를 결정해야 합니다.
잔여 이슈 파악, 영향 범위, 수정 범위 등 익숙한 이 과정에서 주요점은 무엇일까요? 그것은 바로 판단 기준이라고 할 수 있습니다.
여기에서 다시 프로덕트의 목표를 생각해 봅니다. 익숙한 과정의 각 항목들이 프로덕트의 목표 달성에 주는 영향을 파악합니다. 수집된 A/B 데이터를 기반으로 이벤트의 방향성을 결정하는데 이슈의 영향 여부가 판단의 기준이 될 수 있습니다. 그 외의 다른 이슈는 가능하다면 모두 프로덕트의 전체 퀄리티에 좋을 수 있지만 불가피한 경우 예정된 차회 클라이언트 빌드 일정, 클라이언트 제외 수정 영역과 같은 전략 또한 판단 기준이 됩니다.
이렇게 잔여 이슈 기준 점수제와 같은 기존의 방식보다 더 많은 항목을 고려하여 전략적인 배포를 결정합니다.
제3장 - 앞으로 우리는
이렇게 현재 우리의 테스트는 크고 작은 많은 부분에서 바뀌어 가고 있습니다.
버그라는 단어보다 이슈라는 단어의 사용이 익숙해졌으며, 이슈 관리 도구 또한 버그 추적 시스템에서 프로젝트 관리 시스템으로 전환되는 추세입니다. 이는 단위 테스트를 진행하게 되면서부터 개발 작업 일감의 하위에 버그를 등록하며, 버그 또한 하나의 일감으로 관리하기 시작한 결과로 볼 수 있습니다.
이렇게 QA의 영역과 테스트에 대한 개념이 이전보다 더 확장되고 세분화되고 있습니다. 기존에는 없었던 새로운 항목과 새로운 방식의 테스트를 진행하는 상황도 많아졌습니다.
위에 작성된 많은 이야기들이 어쩌면 프로덕트에 적용이 불가능할 수도 있고, 이미 뛰어넘은 단계일 수도 있습니다. 사용하는 용어와 프로세스 모두 다를 수도 있습니다.
퀄리티 사이언티스트와 퀄리티 디자인 - 단어와 의미는 중요하지 않다고 생각합니다.
아직 완성도 정리도 되지 않은
우리의 미래 일수도 아니면 잠시 지나쳐가는 과거가 될 수도 있습니다.
멋있어 보이기 위한 단어 일 수도 있고 또 다른 개념이 등장할 수도 있습니다.
그렇지만 우리는 매일 어제와는 다른 테스트를 하려고 노력하는 사람들입니다.
감사합니다.
