06화 분석하고 협의하라, 리스크를
Risk Based Testing
앞서 리스크를 식별했다. 이제 식별한 리스크를 분석하는 과정이 필요하다. 개발하기 힘들어요, 테스트하기 힘들어요가 아닌, 기준이 필요하고 기준이 존재한다. 리스크 분석은 시스템의 장애 발생 가능성(Likelihood)과 장애로 인한 영향(Impact)을 분석하여 도출된 결과로 우선순위를 정하는 활동이다. 이는 리스크를 장애 발생 가능성 X 장애로 인한 영향으로 정의한 레이놀즈의 정의에 따른다.
리스크 요소
장애 발생 가능성 중심의 기술적 리스크 요소와 장애로 인한 영향 중심의 사업적 리스크가 존재한다. 기술적 리스크는 단위 및 통합 테스팅과 같은 하위 레벨 테스팅(low level testing)과 관련되고, 사업적 리스크는 시스템 및 인수 테스팅과 같은 상위 레벨 테스팅(high level testing)에 관련된다.
실무 관점으로 해석하면 독립된 조직에서 진행하는 테스트, 즉 아웃소싱의 품질 보증 형태가 상위 레벨 테스팅이라 할 수 있다. 하위 레벨 테스팅은 개발 사이드에서 검증하는 화이트 박스 테스트부터, 정식 QA 수행 전 개발사 내부 QA가 유니티 에디터와 같은 환경 및 일부 코드만 빌드에 반영된 채 동작 여부를 살펴보는 형태의 테스트라 할 수 있다.
당시 일부 스펙들이 클라이언트와 서버 쪽 작업이 완료되면 시스템 기획자가 빌드에 접속하여 구현 여부를 파악했는데, 이러한 테스트를 하위 레벨 테스팅이라 볼 수 있다. 이 기간 때 QA가 직접적인 관여는 하지 않았고 특이사항이나 진행상황만 추적했다.
또한 모든 스펙이 하나의 빌드에 적용되고 진행하는 정식 QA와 개발 사이드에서 진행하는 테스트 목적을 다르게 구분하였다. 정식 QA는 리그레션 관점이 포함된 테스트고 신규 기능과 기존 기능의 연관성을 고려한 테스트를 위해선, 테스트 준비 활동에 리소스를 집중하는 것이 옳다고 판단했기 때문이다. 그래서 직접적인 관여는 하지 않았다.
그러므로 개발자들이 테스트하는 기간은 정식 QA 준비에 필요한 테스트 문서 작업 기간이기도 했다. 간혹 기획 리뷰 중 복잡한 테스트이거나 기획서만으로는 테스트 준비가 힘든 경우가 있었다. 그럴 땐 유니티 에디터 또는 개발자들이 테스트 중인 빌드에 접속하여 구현 여부와 동작 방식을 직접 파악해가며 테스트 케이스를 준비했다.
앞서 리스크 요소를 크게 2가지로 분류했고 세부 요소를 살펴보면 아래와 같다.
장애 발생 가능성(Likelihood)
개발팀 숙련도
사용한 기술의 난이도 및 최신성
상호 연관성
새로운 개발의 정도
복잡성
테스트 난이도
리그레션 영향도
테스트 일정
장애로 인한 영향도(Impact)
사용자의 사용 빈도
장애 발생 시 기본 기능 영향도
장애 발생 시 사용자 영향
장애 발생 시 브랜드 이미지 및 금전적 피해 정도
사용자의 기대치 및 중요도
리스크 요소 예시
위 요소를 기준으로 이해관계자들과 커뮤니케이션을 진행했고, 리스크의 높고 낮음을 구분해 변별력을 높일 수 있도록 스케일(Scale)을 사용했다.
리스크 스케일
9-심각(Critical)
5-높음(High)
3-보통(Moderate)
1-낮음(Low)
0-없음(None)
리스크 스케일 예시
이 과정에서 어려웠던 점은 리스크 세부 요소 중 특히 개발팀 숙련도와 같은 영역이 어려웠다. 기술을 다루는 인원의 업무 경력으로 구분하자니 객관적이지 않을 것 같다는 판단이었다. 개발을 해본 적은 없지만 하나의 팀으로 진행되는 업무이기에 적정 수준의 코드 리뷰와 팀워크를 통해 경험적 미숙은 극복 가능한 영역이라 판단했었다. 따라서 추상적이고 명확하지 않은 요소들은 혼선과 오해를 불러일으킬 소지가 있기에 제외시켰다. 여러 번 진행한 끝에 도출된 판단 기준은 아래와 같다.
장애 발생 가능성(Likelihood)
상호 연관성, 기술 난이도 및 최신성, 새로운 개발의 정도
3가지 요소는 개발팀의 협조를 받았다. QA 스스로 판단하기 어려운 영역이기 때문이다.
테스트 난이도
QA 기획 리뷰 및 테스트 커버리지를 참고했다. 테스트 난이도는 QA 부서에서 가장 잘 파악하고 있어야 하는 요소이다. 또한 리그레션과 BAT(=스모크 테스트) 수행에 걸리는 일반적인 테스트 수행 시간을 산출 및 관리하고 있는 조직이라면 리스크 스케일 작성 간에 큰 어려움이 없다.
리그레션 영향도
개발팀 협조 결과를 토대로 QA 부서에서 최종 판단했다. 내가 사용했던 방식은 기능 동작 플로우를 기준으로 신규 업데이트가 기본 기능과 독립된 콘텐츠인지 아닌지를 최우선으로 구분했다. 예를 들어 기본 기능 중 랭킹 정산 시스템이 있다고 가정해보자. 신규 모드가 추가되었는데 이 또한 기존 모드와 동일하게 1달 주기로 정산된다면 비슷한 로직을 사용했을 가능성이 높고 기존 시스템과 영향이 크다고 볼 수 있다. 특히 랭킹 정산 보상이 차등적으로 지급될 경우 동등 분할과 경곗값 기법을 적극 활용하여 테스트 커버리지를 보완해야 한다. 이런 식의 판단과 구분을 위해서는 서비스 이해도가 높아야 하고 QA 부서가 제품을 가장 잘 이해하는 조직이 되어야 하며, 테스트 설계 기법을 활용할 줄 알아야 한다.
테스트 일정
개발 과정에서의 어려움으로 인해 혹시나 충분치 못한 테스트로 라이브에 오픈되는 경우의 리스크를 뜻한다. 이 경우 사후 모니터링을 통해 사용자보다 먼저 장애 상황을 인지할 수 있는 노력이 필요하고, 예정된 테스트 커버리지를 완료하지 못할 경우엔 다음 차수 업데이트로 기능 오픈을 늦추는 방향도 적절하다. 실무에서는 다양한 상황과 예측 불가한 상황들이 발생하기에 어떻게 하는 것이 정답이라 할 수는 없다. 품질 보증 활동 중 테스트 활동이 어려운 이유 중 하나이다.
장애로 인한 영향도(Impact)
사용 빈도
사용자의 기능 사용 빈도를 뜻한다. 플레이는 다양한 환경에서 진행되기 때문에 어떠한 상황에서 어떤 장애가 발생할지 예상하기 어렵다. 그렇기 때문에 QA는 서비스 이해도를 높이기 위한 활동으로도 라이브 플레이를 진행하지만, 실제 사용자와 비슷한 환경과 관점에서 게임을 바라보기 위해 라이브 플레이를 진행하기도 한다. 사용자의 입장에서 게임을 플레이할 때 기능 사용 빈도의 수준도 대략적인 파악이 가능할 것이다. 예를 들어 1달에 한번 정산되는 랭킹 보상 시스템은 1달에 1번 정해진 시간에 사용자들이 이용하게 된다. 하지만 전투 입장과 같은 상시 사용하는 콘텐츠일 경우 사용 빈도가 높다고 할 수 있다. 일일 콘텐츠, 주 단위 콘텐츠, 월 단위 콘텐츠로 구분해보는 것도 좋은 방법이다.
기본 기능 영향도
장애 발생 시 메인 콘텐츠에 어느 정도 영향이 있을지 파악하는 것이다. 메인 콘텐츠가 1:1 PVP 시스템이면 A 기능 장애 발생으로 1:1 PVP 시스템이 동작하는 최소한의 루트, 즉 전투 입장 여부에 문제가 없는지를 파악하는 것이다. 중요한 것은 발생한 장애가 서비스의 중요한 기능에 어느 정도 영향이 있을지를 살펴보는 과정인 만큼, 이 또한 평소 리그레션 테스트 케이스 또는 체크리스트 유지보수를 잘 해왔다면 쉽게 파악이 가능할 것이다. 이러한 점들 때문에 TC와 체크리스트 작성은 결코 쉬운 일이 아니고 많은 노력에 따른 가치가 있는 작업이다. 체계적인 테스트 디자인이 진행되는 조직일수록 품질에 대한 중요성과 비용에 아낌없는 투자를 할 것이라 생각된다. 담당 서비스의 무엇을 테스트해야 하는지 꿰뚫고 있기 때문이다.
사용자 영향
장애 발생 시 영향받는 사용자는 누구인지에 대한 파악이다. 예를 들어 테스트에 필요한 QA 운영 툴과 같은 기능에 장애가 발생했다면 영향받는 사용자는 최종 사용자가 아닌 QA 또는 운영팀일 것이다.
기대치 및 중요도
사용자가 중요시 여기고 기대하는 정도에 대한 기준이다. 게임 커뮤니티의 여론을 살펴보는 것도 도움이 된다. 업데이트 예고성이 담긴 공지가 오픈되었을 때 사용자의 반응을 보는 것이다. 또는 평소 사용자의 불평불만 가득한 피드백을 주의 깊게 살펴보는 것도 큰 도움이 된다. 이를 완벽히 정량화할 수는 없겠지만 대략적인 분위기를 파악하는 것만으로도 판단에 있어서 도움이 된다. 앞서 언급한 라이브 플레이도 이러한 이유로 중요하다. 서비스의 실 사용자의 입장에서 꾸준히 플레이하다 보면 다가올 업데이트가 흥미로운지 아닌지를 판단할 수 있기 때문이다. 물론 게이머들의 성향은 모두 천차만별이지만 나와 비슷한 성향의 유저 또한 존재한다는 것을 감안한다면 라이브 플레이의 중요성은 더욱 높아진다.
식별과 분석 과정 정리
지금까지 과정을 정리하면 앞서 리스크 식별 단계에서 개발 산출물을 참조하여 리스크를 아이템을 식별하였다. 식별된 리스크 아이템을 장애 발생 가능성과 장애로 인한 영향도에 따른 세부 요소를 기반으로 리스크 스케일을 산정하였다. 이에 대한 예시로 아래 그림을 참고하면 좋다.
리스크 스케일 산정이 끝나면 위 형태의 그래프 확인이 가능하다. 리스크 분석 분포도에는 4가지 영역이 존재하고 각 영역별로 QA가 참고해야 할 부분은 아래와 같다.
FTA(Fundamental Test Area)
만약 QA팀 리소스가 부족하다면 테스트 제외 가능한 영역이다. 하지만 나 같은 경우 FTA 영역에 놓인 테스트 대상일지라도, 경험 기반의 Ad-hoc 테스팅을 10분에서 30분 내외로 짧게 투입하는 편이다. 가장 큰 이유는 앞서 리스크 식별과 리스크 세부 요소 분석을 토대로 산정한 리스크 스케일에 대한 불확실성 때문이다. 결국 사람이 하는 일이기 때문에 방법론에 따른 프로세스를 맹신하진 않는다. 따라서 짧게라도 집중하여 테스트하는 편이다. 또한 테스트 미진행 영역이 존재할 정도로 일정 관리가 안되었다는 것을 의미하는 상황이기도 했기에, 그에 따른 책임이었다.
ITA(Tech)-Intensive Test Area
테스트 필요 영역이다. 해당 영역에 놓인 테스트 대상은 하위 레벨의 개발 테스팅 과정에서 진행하는 편이 낫다. 장애 발생 가능성이 높은 기술적 리스크 영역이기 때문이다. 하지만 결국 리그레션 관점에서 한번 더 QA팀의 손길을 거쳐 오픈되어야 하기에 무조건적으로 개발 테스팅에서 진행 필요한 것은 아니다. 다만 해당 영역에 놓인 테스트 대상들은 정식 QA 전에 주의 깊게 살펴보면 좋다.
ITA(Biz)-Intensive Test Area
이 또한 테스트 필요한 영역이다. Tech 영역과 반대로 장애로 인한 영향이 높은 사업적 리스크에 속한다. 블랙박스 테스트 중 단순 반복이라 불리는 정형화된 패턴과 피로도가 높은 테스트의 대부분이 Biz 영역에 분류되었다. 보상 상자를 2000회 수령한다거나 모든 등급 보상을 한 번씩 받아보는 테스트가 그 예시이다. 장애 발생 가능성에 속하는 테스트 난이도는 낮은데, 장애로 인한 영향 중 하나인 사용자 중요도가 높다 보니 Biz 영역에 분류되는 것이다.
STA(Severe Test Area)
가장 강도 높게 테스트되어야 하고 반드시 테스트해야 하는 영역이다. 장애 발생 가능성과 장애로 인한 영향 모두 높은 영역에 속한다. 어떠한 것이 있을까? 예를 들어 PVP 게임의 매칭 룰과 같은 것이다. 게임의 승패를 결정짓기에 사용자에게 노출도가 높으며 중요한 부분이다. 매칭 룰을 테스트하는 건 꽤나 복잡하다. 1:1 PVP의 공정함을 유지하기 위해 다양한 조건을 통해 매칭이 진행되기 때문이다. QA는 이러한 점들을 모두 고려하여 다수의 계정과 환경을 세팅해야 하고, 테스트 기간 동안 높은 집중력이 요구된다. 결과에 대한 신뢰성을 보장하기 위한 문서 작성도 필요하다. 변수 상황을 고려한 테스트 시나리오 설계가 필요하며 어뷰징 요소 또한 체크가 필요하다. 테스트 준비와 수행 시간이 가장 오래 걸리는 영역이라 할 수 있다.
논의 필요 영역
간혹 4분면의 중간에 속해있는 경우가 있는데 특히 ITA와 STA 영역에 한 끗 차이로 속한 경우, STA 영역으로 간주하고 진행했다. 애당초 분포가 STA 영역에 근접했다는 것 자체가 꽤나 중요한 테스트로 인식할 수 있는 근거 치라 판단했고, 사실상 ITA와 STA 모두 테스트 필요한 영역이기 때문이다. 어느 영역으로 보는 게 적절한지에 대해 리스크 식별 단계부터 되돌아간다는 것은 리소스 투입 대비 효율이 낮다는 판단도 있었다.
지금까지 리스크 식별과 분석까지 알아보았다. 이제 분석한 것을 토대로 테스트 전략을 어떻게 수립할 것인지 계획해야 한다. 리스크 전략 수립 단계는 테스트 우선순위를 본격적으로 선정하고 테스트 준비를 끝마치는 시점이다.
