테스트 맵을 활용한 테스트
‘테스트 케이스’는 QA 업무를 대표하는 키워드 중에 하나일 것입니다. 프로젝트 팀원들이 QA 엔지니어에게 바라는 절대적인 작업 산출물이기도 합니다. 어떤 테스트 관리툴을 쓰느냐의 차이는 있지만, 대부분 아래와 같은 형식입니다.
그리고 이 형식은 제가 처음 일을 시작했던 2005년과도 크게 다르지 않습니다.
기존 테스트 케이스 문서의 문제점
기존 형식의 테스트 케이스는 작성하는데 시간이 많이 걸리고 부피가 큽니다. 많은 시간을 들여 작성하는데도 불구하고 거의 읽히거나 검토되지 않습니다. 애자일한 개발 환경에서 이러한 문서의 구조는 빈번하게 발생하는 변경 사항에 유연하게 대응하기 어렵고, 압축된 개발 주기에서 문서화에 너무 많은 시간을 소비하게 돼 실제 테스트를 수행하는 데 할애할 수 있는 시간이 제한적이게 됩니다.
이론적인 테스트 케이스의 이점 중에 하나는 재사용성이지만, 이러한 방대한 양의 성문화된 문서 구조는 차후에 누군가에 의해 정보가 추가, 제거 또는 수정되기가 어렵습니다. 더군다나 많은 피쳐들이 생겨났다 사라지고, 대대적으로 개편되는 일이 빈번하게 발생하는 스타트업 환경에서 더 이상 쓸모없게 되는 경우도 허다합니다.
마인드맵 도구를 이용한 ‘테스트 맵’
제가 아는 대부분의 QA들은 초기 테스트 분석 단계에서 아이데이션의 도구로 마인드 맵을 이용합니다. 그렇게 모아진 정보를 바탕으로 적절히 그루핑하여 최종적으로 테스트 케이스화 합니다.
원티드랩에서는 테스트 케이스화하는 번거로운 작업을 과감히 덜어내고 마인드 맵 형식의 문서, ‘테스트 맵’을 테스트 준비/실행 단계에서 직접적으로 활용해 보기로 하였습니다.
테스트 맵을 이용한 테스트 실행은 어떻게 하나요?
처음에는 테스트 실행단계의 편리함(혹은 익숙함)을 위해 테스트 맵 정보를 자동으로 기존 형식의 문서로 변환시키는 도구 개발을 고려하였습니다. 하지만 이를 위해서는 부득이하게 테스트 맵 문서에 어느 정도 형식적 제약이 필요하고 이는 가장 중요한 아이데이션의 효과를 감소시킬 것으로 판단하여 진행하지 않기로 하였습니다.
그러던 중, 전사 디자인 협업툴로 사용 중인 Figma의 사용사례를 보고, 협업툴인 Figjam을 이용하여 테스트 맵 자체를 리뷰하고 테스트 실행에 활용해보기로 하였습니다.
선형적으로 작성된 기존 문서를 가지고 테스트를 수행하는데 익숙한 조직원들은 도입 초반 어색함이 있었지만 한 두 스프린트 후에는 익숙해졌고, 테스트 맵이 주는 생산적인 가치를 체감하기 시작했습니다.
실행 결과는 어떻게 기록하나요?
Figjam 안에서 제공되는 편리한 기능을 이용하여 테스트 맵 위에 바로 결과를 마킹하거나 to-do 리스트와 같은 위젯을 활용하여 기록합니다.
실행률은 어떻게 측정하나요?
완료여부 혹은 대략적인 진행 정도만 스탬프나 노트를 통해 남기고 구체적인 수치는 측정하지 않기로 하였습니다.
기존 테스트 관리 툴로 제퍼스케일을 사용하고 있었습니다. 제퍼스케일에서 테스트 케이스, 테스트 싸이클을 생성하고 기존 지라 티켓과 연결해 주는 번거로운 작업을 통해 전체 테스트 케이스 개수, 실행률을 프로젝트/유저스토리/테스트 환경별로 확인할 수 있는 대시보드를 제공해 왔었습니다.
문제는, 아무도 이런 수치에 주목하지 않는다는 것입니다.
QA로서 우리가 답해야 하는 궁극적인 질문은 ‘프로젝트가 정해진 일정대로 배포되는데 문제없어?’라고 생각합니다. 그것을 정확히 답할 수 있다면, 그런 수치들은 부수적일 뿐이고 아무런 가치를 창출하지 못한다면 굳이 유지할 필요가 없다 판단하였기 때문입니다.
효과
- 문서화에 상당한 시간을 절약할 수 있습니다.
- 누구나 쉽게 시작할 수 있습니다.
- 포괄적인 테스트 문서 형식을 방지하고 테스트 아이디어 생성에 집중할 수 있습니다.
- 기존 형식의 문서 대비 공유와 피드백이 효과적으로 일어나고, 팀원들(리뷰어)의 창의적인 생각을 유도합니다.
- 팀이 놓치거나 잘못 이해하고 있는 부분에 대한 파악도 원활히 일어나 버그를 예방하는 효과가 있습니다.
- 실제 테스트와 같은 정말 중요한 것에 집중할 수 있습니다.
마무리
시대의 변화에 따라 개발 프로세스는 형식보다는 긴밀하게 협업하고 변화에 유연하게 대응하는 방식으로 진화해 왔습니다. 그에 반해 테스트 활동들과 산출물들은 여전히 형식적이고 유연하지 못한 방식이 많은 것 같습니다.
test_case != Testing
많은 분들이 생각하시는 것 만큼, 테스트 케이스는 테스트 활동에서 절대적인 요소는 아니라 생각합니다. 문서 그 자체가 그 어떤 가치를 생산한다고도 생각하지 않습니다.
test_case = ‘Value’ if test_case == ‘Used Properly’
테스트 케이스는 효과적으로 사용될 때, 비로소 가치를 생산합니다.
if test_case not in [
‘공정과 도구보다 개인과 상호작용을’,
‘포괄적인 문서보다 작동하는 소프트웨어를’,
‘계약 협상보다 고객과의 협력을’,
‘계획을 따르기보다 변화에 대응하기를’
]
>> return False
오랫동안 해오던 방식을 습관처럼 따르기보다 각자의 개발 프로세스 내에서 실제로 버그를 찾고 예방하는 것에 얼마나 가치를 창출하는지 검토하고 그러지 못한 것들은 과감히 생략하거나 바꾸는 것을 고려해 보아야 할 것입니다.
