서비스 기획자의 테스트케이스

우리와 고객을 위한 최소한의 안전장치

현재 내가 속한 조직은 기획과 개발의 성숙도가 그리 높지 않다. 복잡하고 유기적인 기능보다는 화려하고 예쁜 단발성 페이지에 더 익숙한 조직이기 때문이다.

하지만 내가 합류한 이후로 고려해야 할 게 많은 시나리오와 기능을 개발하고 있다. 이번 배포가 그 예였다. 회원 데이터 마이그레이션, 결제와 통합 멤버십이 함께 포함되어 있기 때문이다.

민감한 배포였던 만큼 오랜만에 테스트케이스를 작성하고 검수했다. 테스트케이스를 기반으로 인수 조건을 명확히 하고, 예상 테스트 소요 시간을 산출한 후 리소스를 보충하였는데, 이 경험이 괜찮아서 여기에도 공유하고자 한다.

기획자에게 테스트케이스란?

프로덕트 팀의 모든 활동은 사용자에게 가치를 제공하고 그들의 문제를 해결하는 것에서 시작한다. 일부 서비스는 오프라인에서도 운영하고 가치를 제공하지만, 대부분 우리가 만드는 프로덕트는 온라인에서 시작하고 온라인에서 끝난다.

온라인 환경에서는 사람이 즉각적으로 개입하여 문제를 해결하기 어렵다. 프로덕트가 정확히 작동하지 않으면 사용자에게 약속한 가치를 전달할 수 없다. 그래서 우리는 기능이 기획 의도대로 정확히 구현되었는지 검증해야 한다.

하지만 기획이 복잡하고 규모가 클수록 단순히 화면을 살펴보는 것만으로는 의도대로 구현되었는지 판단하기 힘들다. 그래서 이 때는 명확한 가이드라인이 필요하다. 테스트케이스는 바로 이를 위해 작성한다.

테스트케이스 작성 방법

지라의 체크리스트처럼 체크박스 형태로 체크리스트를 만드는 방법도 있다. 하지만 일반적으로 엑셀을 사용하는 것이 보편적이다. 이 경우, 표를 활용하기 때문에 구조화가 중요한데, 잘 구조화된 테스트케이스는 테스트 과정의 효율성을 높이고, 누락과 중복을 방지하는 데 큰 도움이 된다. 나는 주로 다음과 같은 방법으로 작성한다.

1. 분류 체계 설정(구조화)

- 기능별, 모듈별, (페이지나 기능의) Depth로 구분한다.

- 예를 들어, 대분류는 "온라인 결제", 중분류는 "정기 결제", 소분류는 "월간 결제"로 세분화할 수 있다.

2. 전제 조건 명시

- 해당 케이스를 진행할 때 고려해야 하는 전제 조건을 명시한다.

- 맥락을 잘 모르는 제 3자도 이해할 수 있게 작성한다.

3. 테스트 단계 및 기대 결과 작성 

- 테스트 단계는 단계별로 번호를 매겨 순서대로 따라 하기 쉽게 작성한다.

- 기대 결과는 가능한 한 구체적으로 작성한다. 예를 들어 "결제 성공 시, 성공 메시지가 표기된다."보다 "결제 성공 시, "결제를 완료했습니다."라는 메시지가 팝업으로 표시된다."처럼 상세히 기술한다.

- 누구라도 동일한 방법으로 테스트할 수 있게 만드는 것을 목표한다.

4. 결과표(케이스 상태값) 관리

- 케이스 상태값을 관리할 수 있게 세팅한다.

- 나는 주로 아래 4개를 선호한다:

-- PASS: 테스트가 예상대로 성공한 경우

-- FAIL: 테스트가 예상과 다르게 실패한 경우

-- BLOCK: 전제 조건 미충족, 블로킹 이슈 등으로 테스트를 수행할 수 없는 경우

-- TO DO: 아직 테스트를 수행하지 않은 경우

테스트케이스 샘플

ⓒ327roy

이번에 작성한 테스트케이스를 일부 수정한 샘플이다. 

테스트케이스를 만들 때 '대분류'~'기대 결과' 컬럼의 내용을 작성하고, 테스트를 수행할 때 '실제 결과'~'테스트일자' 컬럼의 내용을 작성한다. '테스트 단계'의 세분화 정도는 작성자의 선호에 따라 달라진다. 이전에 만난 QA는 정적으로 고정된 텍스트를 확인하거나, 페이지를 이동하는 등 화면의 요소별로 케이스를 세분화했다. 나는 이전에 검증을 성공했거나, 가벼운 기능은 하나의 케이스로 합치는 걸 선호한다.

시트를 활용하는 시나리오는 아래와 같다:

1. 케이스가 성공한 경우

1) 검증 진행

2) 성공 시, 상태값을 PASS로 변경

2. 케이스가 실패한 경우

1) 검증 진행

2) 실패 시, 상태값을 FAIL로 변경
3) '실제 결과' 컬럼에 버그 현상 작성

4) 프로젝트 관리 툴에 버그 리포팅(예시: 지라, 아사나, 노션)
5) 리포팅한 티켓 번호를 시트의 '비고' 컬럼에 작성

6) 현황 추적  

본인이 속한 조직과 제품의 환경, 그리고 케이스를 활용하는 상황에 따라 더 구조화하거나 추상화할 수 있다. 이 글에서 제시하는 케이스가 고정된 정답이 아니라 상황에 맞게 변경해야 하는 하나의 프레임워크일 뿐이란 것을 기억하면 좋겠다.

샘플은 이곳에서 다운로드할 수 있다.

테스트케이스의 장단점

테스트케이스는 장단점이 명확하다.

1. 장점

- 구조화된 테스트 시트를 통해 누구나 검증할 수 있는 명확한 기준을 제공한다.

- 후임자를 서비스/제품에 온보딩시킬 때 도움이 된다.

- 버그 리포팅 시 의사소통이 원활해진다. 이미 맥락을 작성한 케이스를 공유하면 되기 때문이다.

- 기획 의도대로 개발되었는지 확인하기 쉽다.

- 프로젝트의 진행 상황을 한눈에 확인할 수 있다. (예시: 100개 케이스 중 95개 통과)

2. 단점

- 작성하는 데 시간이 많이 소요되고 번거롭다.

- 관리해야 할 항목(문서)이 늘어난다.

- 현실적으로 제품 업데이트 시마다 케이스를 유지보수하기 어렵다.

- 보통 디자인 검수와 (테스트케이스를 활용한) 기능/시나리오 검수가 별개로 진행된다. 추가적인 일정 조율이 필요하다.

테스트케이스는 제품과 서비스의 완성도를 높이는 데 활용할 수 있는 도구다. 프로젝트가 복잡하고 규모가 클수록 기능이 기획 의도대로 정확히 구현되었는지 확인하는 것이 중요하다. 이때 테스트케이스를 고려하는 것도 방법이다.

ⓒ327roy