안녕하세요. 크몽에서 QA를 담당하고 있는 제임스입니다.
이번 세션에는 ‘테스트 케이스’ 잘 작성하는 법 혹은 쉬우면서도 관리하기 좋은 테스트 케이스란 무엇인지에 대해서 말씀드리려 합니다. 그리고 평소에 잘 알면서도 하기 어려웠던 ‘테스트 케이스 리뷰’를 크몽에서는 어떻게 하고 있을까요?
우선 많이 사용하지만, 의미가 다른 테스트 관련 용어의 정의부터 간단하게 알아볼까요?
- 테스트(Test)란 한 개 이상의 테스트 케이스의 집합을 의미합니다.
- 테스트 케이스(Test Case)란? 「프로그램의 특정 경로를 실험」해 보거나 혹은 「프로그램이 특정 요구 사항을 준수하는지를 확인」하기 위한 목적으로 사용. 이때, 「특정 목적」 또는 「테스트 조건의 확인」을 위해 개발된 「입력값, 실행 사전 조건, 예상 결과 및 실행 사후 조건」 등을 포함한 내용의 집합.
- 테스트 시나리오(Test Scenario)란? 테스트 실행을 위한 일련의 활동을 구체적으로 기술해둔 문서. 테스트 시나리오는 「테스트 스크립트」라고 불리기도 하며, 혹은 「수동 테스트 스크립트」
실무에서는 혼용해서 사용하는 경우가 대부분입니다. 테스트 케이스를 테스트 시나리오라고 하는 경우도 있고, QA라는 용어를 테스트라고 의미하는 경우도 있습니다.
조직 내에서 약속만 된다면 용어의 의미는 크게 중요하지 않습니다.
하지만 아래의 내용을 이해하기 위해서는 테스트(Test)라는 용어와 테스트 케이스(Test Case)라는 용어가 다르다는 것을 이해하고, 테스트 케이스(Test Case)라는 용어와 테스트 시나리오(Test Scenario)라는 용어도 다르다는 것을 명확하게 이해하고 읽어야 실무에 도움이 되실 거라 생각됩니다.
테스트 케이스를 체계적으로 작성하고 관리하기 위한 바이블!
- 엑셀은 이제 그만! : 시스템 도구 활용하기
- 누구나 쉽게 이해하고 수행할 수 있는 테스트 케이스 작성하기
- 테스트 케이스 리뷰하기
- OKR(Objectives와 Key Results) 활용하기
- 마무리
엑셀은 이제 그만!
시스템 도구 활용하기
처음 테스트 케이스를 작성하게 되면 대부분 엑셀에 작성을 하게 됩니다. 누가 시키지 않아도 엑셀에 작성하거나 기존에 작업자도 엑셀에 작성을 해둔 것을 자주 보셨을 겁니다.
엑셀에 테스트 케이스를 작성함으로써의 장점은 수행의 편리함과 수정이 쉽고 한눈에 볼 수 있는 장점이 있습니다.
예를 들면, Pass/Fail 등 결과를 입력하기 편하다는 말입니다. 또한, 설계만 잘한다면 비즈니스 흐름이나 예상 시나리오로 기능의 흐름에 따라 작성되어서 끊김이 없이 한 번에 수행할 수도 있습니다.
장점이자 단점으로 동시에 수행이 어렵고(엑셀 특징상 공유하게 되면 매우 느려짐) 수정하더라도 언제 무슨 이유로 수정하게 되었는지 이력을 찾기 어렵습니다. 물론 이점을 조금 보완한 구글 시트를 활용하기도 하지만 마찬가지로 이력을 확인하기는 어렵습니다.
가장 문제는 이슈 트래킹이 원활하지 않다는 점입니다. 엑셀의 Fail 케이스에 대한 이슈를 별도의 시스템에 등록하거나 시트를 분리해서 이슈를 작성하게 되는데 이슈의 상태나 이력을 테스트 케이스와 싱크를 맞추기가 매우 어렵습니다.
그래서 우리는 엑셀을 과감히 포기하고 시스템 도구(테스트 관리 도구)를 활용해야 합니다. 테스트 관리 도구는 매우 많지만 제가 사용해 보고 추천해 드리는 도구는 Zephyr와 Xray라는 도구 입니다. 둘 다 Jira와 연동되는 플러그인으로 유료 도구인 점 참고 부탁 드립니다.
Zephyr와 Xray는 테스트 목적에 따라 활용하면 되는 데 메뉴얼 테스트가 많은 도메인의 경우 Zephyr가 유리할 수 있고, 테스트 자동화를 계획하고 있는 도메인의 경우 Xray를 활용하는 것이 좋습니다.
두 가지 도구 모두 활용법이나 사용법이 비슷하고, 심지어 UI도 비슷합니다. 비용은 Zephyr가 조금 비싸지만 그만큼 기능이 좀 더 많습니다. 도구 선택 시에는 기능을 잘 살펴보고 활용할 수 있는 기능인지 검토 후 선택하시길 바랍니다.
도구가 선택되었다면 기존 엑셀 데이터를 가공하여 시스템에 임포트 할 수 있습니다. 임포트 방법은 해당 도구 가이드에 잘 설명되어 있으니 확인해 보시고 방식은 동일하며 보통은 .csv 파일의 컬럼과 Jira의 필드를 매칭시켜 업로드하는 방식입니다. .json도 지원하고 있습니다.
테스트 케이스를 시스템 도구에 업로드하고 수행/관리하려는 가장 큰 이유는 요구사항 = 개발 아이템 = 테스트 케이스 = 이슈에 대한 요구 추적이 가장 큰 이유 중의 하나입니다. 이슈로 인해 요구 사항이 변경될 수도 있고, 개발 아이템의 변경으로 테스트 케이스 및 이슈의 내용이 수정될 수도 있습니다.
물론 현실적으로 모든 내용을 현행화하기는 매우 어려운 일입니다. 하지만 중요한 것은 테스트 관리를 시스템 도구를 통해 할 수 있다는 것이 요구 추적이 가능한 환경이 구축되었다는 것이고 이점이 매우 중요한 포인트입니다.
테스트 케이스 검색에 대한 이점도 있습니다. 엑셀 파일을 열어야만 확인할 수 있는 내용을 시스템 도구에서는 바로 검색할 수 있으며, 현재 테스트 케이스가 사용되고 있는지 사용되지 않는지에 대한 정보도 관리하기 편리합니다.
결론적으로 장기적으로 봤을 땐 테스트 케이스를 관리하기 위해 시스템 도구를 활용하는 것은 선택 아닌 필수 사항으로 생각해 주세요.
테스트 케이스 작성하기
시스템 도구에 테스트 케이스 등록하기
엑셀의 작성했던 테스트 케이스를 그대로 시스템 도구에 입력한다고 가정해 봅시다.
엑셀에 작성한 테스트 케이스
- 컬럼 : TC ID | Req. ID | 구분 | 대/중/소 | 우선순위 | 스텝 | 기대 결과 | 확인자 | 확인 일자 | 결과 | 비고 등
아마도 엑셀에는 위와 같은 컬럼으로 테스트 케이스가 작성되어 있을 것입니다. 우선 여기서 시스템에 임포트 했을 때 자동으로 설정되는 부분은 아래와 같습니다.
- 시스템 도구 자동 설정 필드 : TD ID | 우선순위 | 스텝 | 기대 결과
- 테스트 수행 시 자동 설정 : 확인자 | 확인 일자 | 결과
그리고 우리가 가장 중요하게 설정해야 하는 부분은 바로 Req. ID와 구분 관련된 대/중/소입니다.
엑셀은 이 부분이 매우 쉽게 보이기도 하고, 매우 유용하게 사용되는 부분이기도 합니다. 그래서 시스템 도구에서도 구분 관련된 부분을 쉽게 보일 수 있도록 설정해야 합니다.
시스템 도구의 경우 테스트 케이스를 등록할 때 이슈 등록과 동일한 방법으로 작성하게 됩니다. 내부적인 포맷(이슈 상세)이 다르지만, 등록하는 방법은 일반적인 이슈 등록과 동일합니다.
대부분 시스템 도구에 테스트 케이스를 작성하게 되면
- 요약(제목) : 로그인하기, 로그아웃하기 등등
위와 같이 구분 없이 작성합니다. 갑자기 어디서 나온 시나리오 성 문구일까요?
일반적으로 이슈를 등록할 때 습관? 같이 테스트 케이스의 요약(제목)을 작성했던 것입니다. 하지만 도구만 엑셀에서 시스템으로 바뀌었을 뿐 테스트 케이스의 베이스는 변함이 없기 때문에 위와 같이 작성하게 되면 보기도 어려워지고 관리도 어렵게 됩니다.
위와 같이 요약(제목)을 작성하게 되면 스텝에 메뉴의 위치 혹은 기능의 위치 정보를 모두 작성해야 하고 하나의 케이스에 여러 케이스를 작성해야 하는 상황이 발생할 수 있습니다.
시스템 도구에서도 누구나 쉽게 테스트 케이스를 보고 이해하기 위해서는 요약(제목)에 메뉴의 위치나 기능의 위치 정보를 작성해 주는 것이 좋습니다.
예를 들면,
- 로그인 버튼의 경우 : [로그인] 홈 > Navigation bar : 로그인 > 로그인하기
위치 정보를 작성하고 마지막에는 기능명이나 컴포넌트 명, 혹은 모듈명을 작성해 주는 것이 좋고, 특수문자를 이용해서 구분해 주면 매우 좋습니다.
- 시스템 도구 등록 요약(제목) : [구분] 대분류 > 중분류 > 소분류 : 기능명
Req.ID의 경우 라벨링이나 시스템 도구에서 활용 가능한 사용자 지정 필드를 이용해서 구분자를 넣어주면 향후 요구 추적 시 매우 유용한 정보로 활용할 수 있습니다. 또한, 테스트 케이스를 수정하기 위해 정보를 찾는 용도로도 활용하게 됩니다.
- Tip : Jira의 Figma/Zeplin 등 플러그인을 통해 바로 요구 문서에 연결 가능하도록 설정하거나 컨플런스 문서를 링크해 놓고 있습니다.
시스템 도구로 테스트 케이스를 관리하기 위해서는 빠르게 찾아서 수정이 가능해야 하며 빠르게 찾기 위한 정보를 구분자로 입력을 해두어야 합니다. 엑셀에서 구분이나 대분류를 입력했듯이 시스템 도구에도 테스트 케이스를 구분할 수 있는 명확한 구분자를 입력해야 합니다.
- Tip : 요약(제목)의 [구분] 값을 라벨링이나 컴포넌트 구분자에 넣습니다.
[번외] 테스트 시나리오의 활용
시스템 도구에 테스트 케이스 등록 시 습관과 같이 제목(요약)을 시나리오 성으로 작성하는 것은 테스트의 다른 방법의 하나입니다.
- 예시) 로그인하기, 로그아웃하기 등등
이것은 명확하게 테스트 케이스는 아니고, 시나리오 혹은 테스트 스위트(Suite)로 구분하여 별도의 테스트 커버리지를 높일 수 있는 항목으로 구분되어야 합니다.
Zephyr와 Xray 모두 Suite로 구성할 수 있는 기능을 제공하고 있습니다.
Suite로 구성된 시나리오는 향후 테스트 자동화 시나리오로도 활용할 수 있습니다.
누구나 쉽게 이해하고 수행할 수 있는 테스트 케이스
시스템 도구를 활용했을 때 테스트 케이스를 누구나 쉽게 이해하고 수행하려면 다음 3가지를 꼭 기억하시길 바랍니다.
- 기능의 위치를 명확히 보여주기 : 요약(제목) 활용
- 요구 추적이 가능하도록 작성하기 : 링크 활용
- 유지 보수가 원활할 수 있도록 작성하기 : 구분자 활용
테스트 케이스 리뷰하기
테스트 케이스 리뷰해 보셨나요? 개발자들이 코드 리뷰를 하듯이 QA나 테스트 엔지니어, 그리니까 테스트 케이스를 작성하는 직군은 테스트 케이스 리뷰를 한다는 이야기는 한 번쯤 들어 보셨을 거라 생각합니다.
하지만 일이 많아서? 바빠서? 라는 이유로 하지 못했던 게 현실이었을 거라 생각됩니다. 업무와 연계하여 테스트 케이스 리뷰를 하나의 업무로 가져가는 방법을 공유해 드리고자 합니다.
우선 스터디를 하나 만들었습니다. 스터디의 제목은 아주 유치하게 “테스트 케이스 작성 달인 되기”로 결정하였습니다. QA 위클리 미팅 시간에 스터디의 목적과 목표를 설정하고 스터디를 진행하기로 했습니다.
회사에서 스터디를 한다고 하면 “업무 시간에 스터디를 한다고?” 윗분들께 눈치 보이고 그러셨을 텐데요. 회의 시간의 10분만 투자하면 충분합니다.
테스트 케이스 리뷰 절차
- 프로젝트의 수행 시 요구 문서를 기준으로 테스트 케이스 작성
- 테스트 케이스 작성 완료 시 리뷰(혹은 중간중간 일정 간격을 두고 리뷰)
- 프로젝트 종료 후 리뷰 내용 반영
- 다음 프로젝트에 리뷰 내용을 반영한 테스트 케이스 작성
- 1~4번 반복
프로젝트를 수행하게 되면 요구 문서에 대한 검증을 위해 테스트 케이스를 작성합니다. 테스트 케이스 리뷰의 내용은 컨플런스(스터디 스페이스)에 정리를 하였습니다.
바로 적용할 수 있는 것은 바로바로 적용하였고, 많은 부분을 수정해야 하는 경우에는 프로젝트 종료 후 반영하는 방법을 택했습니다. 리뷰 내용을 모두 반영하면 스터디의 프로젝트를 종료로 업데이트했습니다.
리뷰어는 별도의 시간을 투자해서 리뷰 내용을 정리해야 하는 것은 사실입니다. 많은 시간이 필요한 것은 아니기 때문에 그동안의 노하우를 후배에게 알려준다는 마음으로 접근하면 즐겁게 리뷰 내용을 정리할 수 있을 거라 생각합니다.
OKR(Objectives 와 Key Results) 활용하기
테스트 케이스를 작성해서 수행하는 가장 중요한 이유는 ‘품질률’을 측정하기 위한 모수로 활용되기 때문입니다. ‘품질률’은 단순한 단어이지만 많은 내용을 담고 있기 때문에 다음 세션에 자세히 다뤄 보도록 하겠습니다.
테스트 케이스를 OKR로 설정하기 위해서는 로드맵이 나와야 합니다. 운영 중인 서비스를 분석해서 테스트 케이스 작성이 필요한 영역을 전체 모수로 설정해서 진척을 관리해야 합니다.
테스트 케이스의 진척 관리는 [작성 완료 항목 / 전체 항목]으로 진척률을 측정합니다.
OKR의 목표는 분기별 혹은 반기별로 목표를 설정하고, 명확한 수치로 작성하는 것이 좋습니다.
예외적인 상황으로 테스트 케이스의 모수는 명확히 정해져 있는 것이 아니고 중간에 모수가 늘어나거나 줄어들 수 있기 때문에 Objectivs 변경 시에는 명확한 사유와 함께 공유될 수 있도록 해야 합니다.
가장 좋은 방법은 최초 계획된 OKR과 변경된 OKR을 비교해서 측정하는 것도 좋은 방법입니다.
테스트 케이스를 설계하고 작성하고 수행하는 것은 하나의 주요 업무로써 회사의 품질 목표와 싱크를 맞추고 함께 움직일 수 있도록 해야 합니다.
마무리
테스트 케이스를 누구나 이해하기 쉽게 작성하기는 사실 매우 어려운 작업입니다. 내 기준에는 쉽다고 생각했지만, 다른 사람이 보았을 땐 어렵게 느껴질 수 있기 때문입니다.
그래서 테스트 케이스 리뷰를 통해 수정하고, 보완해 나가는 작업이 꼭 필요합니다. 지금은 스터디로 테스트 케이스를 리뷰하고 있지만 하나의 업무 프로세스로 자리 잡아야 할 만큼 매우 중요한 활동이라는 것을 다시 한번 말씀드립니다.
테스트 케이스를 어렵게 작성한다고 해서 누가 뭐랄 사람은 없습니다. 내가 작성한 테스트 케이스가 나도 이해하기 어려우면 테스트 케이스를 가장 많이 사용하는 내 자신부터 힘들어질 거라는 것을 알고 최대한 쉽게 작성될 수 있도록 고민해 보시길 바랍니다.
다음 세션은 ‘품질률’에 대해서 이야기해 볼까 합니다.
긴 글 읽어 주셔서 감사합니다.
