07화 테스트 전략을 수립하라,리스크 완화를 위해

Risk Based Testing

리스크 분석이 끝났다면 리스크 완화를 위해 전략 수립이 필요하다. 이를 리스크 계획이라 칭하고 이를 테스트 계획에 반영하게 된다. 테스트 계획은 꼭 문서화가 필요한 작업은 아니다. 나 같은 경우 실무를 혼자서 총괄하다 보니 모든 것을 기록하고 관리하는 것은 수행 중심 테스트 활동에 큰 영향을 끼쳤다. 따라서 테스트 산출물의 공개 범위를 협의했고, 모든 부서로 공개되는 문서가 아닌 경우 간소화하거나 직감 및 머릿속으로 그려가며 필요한 문서만 남겼다. 방법은 여러 가지다. 어느 기업에서, 누구는 그렇게 한다고 해서, 모든 걸 따라 할 필요는 없다. 조직 상황과 팀 상황을 고려해서 유연하게 대처하면 된다.

테스트 우선순위

리스크 분석을 통해 각 영역의 테스트 대상이 도출되었다. 하위 레벨 테스트인 단위와 통합 테스트에서는 기술적 리스크를 우선적으로 완화시켜야 하므로 아래 순서로 선정했다.

1. STA

2. ITA Tech

3. ITA Biz

4. FTA

반대로 상위 레벨 테스트인 시스템과 인수 테스트에선 사업적 리스크를 우선 완화시켜야 하므로 아래 순서로 선정했다.

1. STA

2. ITA Biz

3. ITA Tech

4. FTA

당시 상위 레벨 테스트만 관여했기에 위 순서로 진행했다. 최종적으로 작성했던 리스크 기반 테스트 전략은 아래와 같다.

STA

경곗값과 동등 분할 및 페어 와이즈를 할당했다. 네거티브 TC라고도 불리는 예외 케이스를 설계 당시 정상(Positive) 케이스와 비슷한 수준으로 작성했다. 몇 % 작성해야 한다는 가중치는 설정하지 않았고, 시스템 기획자와 논의하며 발생할 수 있는 경우의 수에 대해서는 명확한 테스트 결과를 위해 테스트 케이스 형식으로 작성했다. 또한 버그 발생 시 재 빌드 횟수마다 이전 빌드에서 QA 확인이 끝난 버그여도 재 빌드 횟수당 1회로 검증했다. 리그레션은 기본적으로 모든 테스트 케이스를 수행했고, 업데이트 내역은 QA 빌드에 적용된 시점을 기준으로 최초 검증 후 앱 심사 빌드가 배포되기 전 QA 마지막 차수에서 더블 체크했다. 테스트 종료 조건은 기본적으로 STA 영역에 속한 버그라면 수정 및 QA 확인 완료 상태로 오픈하는 방향을 택했고, 리그레션과 업데이트 내역은 테스트 준비 당시 작성한 TC라면 잔근과 야근을 진행해서라도 모든 케이스 100% 수행 목표로 진행했다. 당시 중요하게 생각하여 설계한 것이므로 설계했다면 모두 수행한다는 원칙을 지키고자 했다.

ITA Tech, Biz

예외 TC는 작성하지 않았다. 예를 들어 보상받기를 100번 진행해야 하는 상황에서 서로 다른 테스트 조건의 인풋과 아웃풋을 모두 확인하기엔 리소스가 부족하기 때문이다. STA 영역에 집중하기 위해 공인된 테스트 기법을 활용하여 공식적인 방법으로 테스트 커버리지를 줄이고자 노력했던 영역이다. TC보단 체크리스트 형식으로 빠른 실행 중심으로 진행했다.

FTA

별도의 테스트 준비는 진행하지 않았지만 필요하다면 체크리스트 형태로 간단히 작성했다. 기본적으로 Ad-hoc 수행 방식을 택했다.

여기까지가 리스크 기반 테스트 전략의 실무 과정이다. 예시로 작성한 산출물들을 토대로 테스트 준비부터 마감 활동을 진행하게 된다. 리스크 기반 테스트 전략의 전과 후를 간단히 비교하자면 테스트 우선순위를 공식적인 방법으로 선정했다는 점과, 모든 팀과 협업하며 품질 목표를 정했다는 점이다. QA팀은 테스트 수행 기간 동안 집중해야 할 영역과 그렇지 않은 영역을 구분하여 선택과 집중을 할 수 있다. 테스트 수행만이 품질 보증 활동의 전부가 아니고 품질은 QA팀만의 책임과 영역이 아니란 점을 리스크 기반 테스트 전략을 통해서도 다시 한번 깨닫게 되었다.