05화 식별하라, 리스크를

Risk Based Testing

리스크 기반 테스트 전략을 활용하려면 우선 리스크 아이템을 식별해야 한다. 테스트 대상의 기능 또는 모듈과 요구사항 등을 리스크 아이템으로 식별하는 단계이다. 즉 분석 필요 대상을 의미하기에 식별 방법에는 다양한 방법이 존재할 수 있다. 난 일반적으로 많이 사용하는 방법을 택했다.

개발 프로세스와 테스트 준비 및 수행 방식

개발에 필요한 산출물 배포 및 유지보수가 진행되는 형태였다. 따라서 명세 기반 기법 활용도가 높은 조직이었다. 유관부서 간의 신규 기능 및 개선 논의 후 확정된 시스템에 대해서 구체적인 기획서 작성 및 배포가 진행되었다. 아트, 클라이언트, 서버 프로그래머 및 QA 부서는 이를 확인하고 릴리즈까지 각자 맡은 역할을 수행한다.

기획서 배포 시점에서 QA팀은 테스트 준비 활동을 시작했다. 테스트 진행에 필요한 신규 QA툴 기능 또는 전사 테스트 필요 여부 및 명확하지 않은 기대 결과에 대해 시스템 기획자와 커뮤니케이션을 진행했다. 기획서 리뷰는 철저히 QA 관점(=최종 사용자)에서 진행하였고, 납득가지 않은 기능에 대해서는 시스템 기획자뿐 아니라 담당 PD의 피드백도 확인했다. 담당 QA가 기획 및 구현 방향을 명확히 알지 못하면 무슨 테스트를 하는지 모르는 것과 같다. 그러므로 테스트 준비 기간에는 끊임없이 묻고 왜라는 질문을 많이 해야 하는 시기이다.

개발 일정이 표로 정리되어 있어 클라이언트, 서버 및 아트 직군의 마감 일정을 한눈에 파악할 수 있었다. 테스트 수행 일정은 이에 맞춰 유동적으로 조정했지만, 준비 활동의 마감 일정은 주요 업데이트 내역이 QA 빌드에 적용된 시점을 기준으로 정했다. 4차 QA, 5차 QA 기간에 뒤늦게 적용된 내역에 대해 테스트하는 경우가 많았다. 따라서 신규 빌드 배포 시 추가된 사항으로 인한 기본 기능 영향도 범위 체크가 필요했고, 리그레션 범위를 산정했다.

아웃소싱 QA 환경에서 빈번하게 겪었던 일들인지라 크게 거부감은 없었다. 또한 테스트 진행 상황 공유 및 의사결정에 필요한 수치들을 모두 시각화시켰고, 모든 팀에서 진행상황 추적이 가능한 상태로 공유했기 때문에 어려운 점은 없었다.

식별하자 리스크를, 개발 산출물 활용

테스트 준비 기간 개발 산출물로 나타나는 대표적인 것이 요구사항 명세서인데, 준비가 잘 갖춰진 조직이었다. 기획 의도부터 클라이언트 및 서버 구현 방향 등의 개발과정에서 필요한 대부분의 산출물을 직접 확인할 수 있고 분석 가능한 환경이었다.

요구사항 명세서를 참고하여 중요시 여기는 항목을 이해관계자와의 커뮤니케이션을 통해 파악했고, 우선순위가 낮은 항목과 높은 항목을 파악했다. 만약 테스트 일정이 충분치 않다면 간소화시켜야 하는 테스트 대상이 있을지도 협의하에 하나씩 식별하였다.

식별 단계에서 중요시 여겼던 부분은 우선순위 조정이 필요한 테스트 대상을 함께 선정하는 것이다. QA팀만의 판단이 아닌 이해관계자의 판단과 협의하에 서로가 우려되는 부분을 공유하고 조정하였다. QA팀 입장에서는 A라는 이유로 복잡한 테스트 및 설계가 진행될 수 있는데, 높은 리소스 투입만큼 중요한 기능인지 크로스 체크했다.

업데이트 확정된 시스템들은 몇 가지 원칙이 있었는데, 사용자가 고통받는 시스템인 경우가 많았다. 이에 대한 논의가 끝난 상태로 업데이트 스펙이 확정되었기에 테스트 원리 중 오류 부재의 궤변#1 관점으로 바라볼 필요성은 없었다. 따라서 업데이트가 필요한, 개선이 필요한 기능인가로 식별하지 않고, 우리 서비스에 필요한 기능이지만 그럼에도 불구하고 서비스에 덜 중요한 기능은 무엇인지 확인하는 과정이기도 했다.

결국 정해진 테스트 일정에서 테스트 강도의 차이일 뿐 모든 테스트는 진행되어야 한다. 또한 신규 기능 추가는 수정한 코드로 인해 소프트웨어의 다른 부분에 영향을 미치는지 검증하는 리그레션 관점에서도 중요하기 때문이다.