안녕하세요! 웹서비스셀에서 웹 QA를 담당하고 있는 강유경, 송선주입니다. 저희는 데브시스터즈의 웹서비스 품질을 높이는 업무 및 QA 프로세스 개선 업무 등을 진행하고 있습니다. 기존에 엑셀로 관리하던 테스트 케이스(Test Case) 작성을 탈피하고 JIRA에서 제공하는 테스트 관리 툴로 테스트 케이스를 작성부터 테스트 수행, 결과 보고서와 이슈(Issue)를 관리하는 방법에 대해 소개해 드리고자 합니다.
#엑셀로 테스트 케이스 관리가 점점 어려워져
대부분의 QA 직군은 테스트를 진행하기 전 테스트 케이스를 작성하며 관리합니다. 테스트를 수행하면서 이슈를 찾고, 어느 부분에서 이슈가 발생했는지 또 수정은 되었는지, 어떤 항목은 이번 환경에서는 제외되었는지, 발생한 이슈로 인해 더는 테스트 진행이 불가한지 등 테스트 케이스에 기록들을 남기고 다양한 활동들을 합니다. 테스트 케이스는 테스트 진행률과 이슈 발생률 등을 한눈에 볼 수 있는 자료로 활용됩니다.
저희 웹서비스셀에서도 엑셀을 사용해 테스트 케이스를 관리해왔습니다. 게임과 달리 웹서비스셀의 프로젝트는 주기적으로 관리하는 프로젝트보다는 1회성으로 개발 및 검증을 하는 프로젝트가 많습니다. 테스트 케이스 관리 툴로 엑셀을 사용하다 보니 크게 5가지의 불편함을 느낄 수 있었습니다.
1) 작성해야 하는 테스트 케이스는 많고, 테스트 기간은 너무 짧다
웹의 경우 브라우저(Browser)와 기기 별로 검증이 필요하고, 기기 별로 제공되는 브라우저가 달라 해상도까지 고려할 사항 이 많습니다.
위 이미지에서 보이는 것과 같이 PC는 OS 기준으로 크롬, 사파리, 인터넷 익스플로러 브라우저를 확인하고, 모바일의 경우는 OS 기준으로 크롬, 사파리, 삼성 인터넷, 네이버, 웹 뷰까지 확인합니다.
그러다 보니 스펙이 크거나 새로운 프로젝트의 경우 Full 테스트 케이스를 작성하게 되면 테스트 케이스가 1,000개가 넘는 경우가 많아 작성 기간도 일주일 이상 소요될 때가 있습니다. 이렇게 되면 짧은 기간 안에 많은 양의 테스트 케이스를 상세하게 쓰기 쉽지 않습니다.
QA직군에 계신 분들이라면 누구나 한 번쯤 이런 테스트 케이스를 작성하고 이를 기반으로 검증을 수행해 보셨을 거라는 생각이 듭니다. 이렇게 테스트 케이스가 길어지면 이를 확인하는데 어려움이 있습니다. 그리고 협업하는 다른 부서의 분들도 확인하는데 어렵다는 피드백을 주셨습니다. 더구나 짧은 기간 안에 브라우저별, PC/모바일별로 기획이 다른 경우라면 시간이 매우 부족한 경우가 많았습니다.
2) 기능 업데이트 시 버전 관리의 어려움이 있다
2020년 상반기까지는 in-house 제품 및 사전 예약이 업무의 대부분을 차지했지만, 2020년 하반기부터는 더욱 많은 게임 사이트와 기업 사이트에 대한 업무까지 진행하게 되었습니다. 게임 관련 웹 프로젝트의 경우 게임별, 언어별 등 다양한 케이스가 있다 보니 이걸 엑셀 시트에 추가하더라도 버전 관리가 어려웠습니다. 또한, 완료한 테스트 케이스에서 다음 버전으로 업데이트 시 테스트 케이스를 복제한 뒤 새로 만들어야 합니다. 새로 추가가 된 후 어느 부분이 이번에 새로 추가되었는지 표시까지 해줘야 합니다.
3) JIRA에 등록한 이슈를 또 엑셀에 복사/붙여넣기를 해야 한다
엑셀에 JIRA 이슈 링크를 연동할 때 보통 하나의 케이스에 여러 개 이슈를 추가하게 됩니다. 이때, 가끔 알 수 없는 이유로 최상위에 있는 이슈만 하이퍼링크(Hyperlink)가 연결되는 것을 경험하신 분들이 많으실 겁니다.
해당 이슈를 보고 싶을 때 직접 URL을 입력해서 들 어가거나 아예 JIRA 화면을 띄운 채 들어가야 하는 불편함이 있습니다.
이슈를 등록하고 하나의 JIRA 티켓 링크를 복사하고, 다시 엑셀에 붙여 넣고, 하이퍼링크는 한 개만 연결되는 이런 과정들이 계속 반복되어 피로감이 있었습니다.
또한, 별도로 이슈 관리 시트도 만들었는데 이슈가 수정되었을 경우 일일이 수정 확인 후 상태 변경이 필요했습니다. 이런 과정들이 모두 수작업으로 진행되다 보니 소요되는 시간이 상당했습니다.
4) 이전 테스트 결과를 보려면 과거 테스트 케이스를 일일이 열어봐야 한다
기능 업데이트 시 버전 관리의 어려움과 연결되는 부분인데, 이전 테스트 결과를 보려면 과거 테스트 케이스를 하나하나 열어서 확인해야 합니다. 과거부터 쌓아온 테스트 케이스이고, 히스토리 관리가 잘 되었다고 하더라도 수작업으로 진행하고 있어 많은 비효율이 발생하게 됩니다.
5) 이미지 삽입 등의 첨부 파일을 삽입 할 경우 테스트 케이스 템플릿이 한정적이기 때문에 보기 및 관리가 어렵다
아무래도 엑셀을 사용하기 때문에 이미지가 삽입되면 셀의 크기가 커지기 마련입니다. 1,000개가 넘어가는 테스트 케이스에 이미지까지 추가된다면 문서 한 페이지의 크기가 너무 커져 각각의 테스트 케이스를 확인하는 것이 아주 어려워집니다. 셀 내에 이미지를 삽입할 수 있으나 셀의 크기가 작다면 이미지의 크기도 작아져 따로 확대해서 이미지를 확인하고, 다시 줄이는 일련의 과정을 거쳐야 합니다.
위와 같은 문제들로 인해 저희는 공통으로 한 가지를 생각하게 됐습니다.
"그러면 우리 엑셀에서 벗어나 보는 건 어떨까요?"
#엑셀에서 벗어나서 어떤 테스트 관리 툴을 사용해볼까?
여러 가지 많은 테스트 관리 툴이 있지만 저희는 JIRA와 연동이 가능한 QAlity와 Zephyr Scale을 선정했습니다.
어떻게 하면 테스트 케이스를 줄이고, 테스트 수행부터 결과까지의 시간을 단축 할 수 있을까?에 대한 고민을 다른 셀의 QA직군에 계신 분과 이야기를 나누다가 QAlity를 제안받았습니다. QAlity는 쉽게 앱 설치가 가능했고, 다양한 상황에서 유동적으로 대응이 가능하다는 것에 눈길이 갔습니다.
한 가지 툴만 사용하기 보다는 다른 툴도 비교해보고 싶다는 생각이 들어 인터넷 검색을 통해 ‘상위 20개 최고의 테스트 관리 도구 목록’의 블로그 글 내용에서 Zephyr Scale을 알게 되었습니다. 사용하기 쉽고, 유연해 시작하는데 최소한의 노력만 들일 수 있다는 문구가 매력적으로 느껴졌습니다.
이 두 가지 테스트 관리 툴로 웹서비스셀의 프로세스와 얼마나 잘 맞을지 비교 검증하게 되었습니다.
1) 테스트 케이스 작성
기존과 제일 큰 차이점은 바로 Test Step(재현 방법)과 Expected Result(기대 결과)만으로 작성이 가능한 점이었습니다. 이전에는 대분류/중분류/소분류/사전 조건/재현 방법/기대 결과 이런 식으로 작성했다면, 재현 방법과 기대 결과만 작성하니 작성 시간이 굉장히 줄어들었습니다.
2) 테스트 수행
작성한 테스트 케이스를 수행하기 위해선 테스트 사이클(Test Cycle)을 설정해야 합니다. 테스트 사이클은 작성한 테스트 케이스를 실행할 수 있게 해주는 기능입니다. 테스트 케이스와 연결하고 실행하면 본격적으로 수행할 수 있는 환경이 만들어집니다.
테스트하면서 결과를 직관적으로 확인할 수 있고, 이슈와 테스트 케이스 간에 추적성이 높아졌습니다. 이런 방식으로 JIRA 티켓 복사/붙여넣기에서 해방되었습니다.
3) 테스트 결과
테스트 사이클로 테스트를 완료하면 자동으로 결과가 생성됩니다. QAlity는 테이블과 상태 그래프, 담당자 그래프 형태로 결과를 볼 수 있었습니다. Zephyr Scale의 경우는 다양하게 결과를 나타낼 수 있는데 그중에서 전체적으로 볼 수 있는 항목(Test execution results (summary))을 선택해 종합적인 결과를 확인했습니다.
사용한 경험을 토대로 이제 2가지 툴의 장/단점을 비교해보도록 하겠습니다.
QAlity의 장/단점은 아래와 같습니다.
QAlity 장점
- 오타 및 새로 변경할 사항이 있으면 바로 수정할 수 있습니다.
- 테스트 케이스 작성에 필요한 항목이 줄어들었습니다.
- 테스트 케이스에 이슈를 바로 등록/연결할 수 있습니다.
QAlity 단점
- 상태가 Not Executed, In Progress, Pass, Fail, Blocked밖에 없습니다.
- 5가지만 사용할 수 있으며, 추가 및 수정 불가합니다.
- 테스트 케이스가 새 창이 아닌 현재 페이지에서 열리고 로딩이 깁니다.
- 각 케이스 별로 찾는 시간이 많이 소요됩니다.
Zephyr Scale의 장/단점은 아래와 같습니다.
Zephyr Scale 장점
- 테스트 케이스를 작성하고, 테스트 사이클을 연결하고, 테스트 케이스를 실행하는 것까지 자연스럽게 연결되어 있어 편하게 관리할 수 있습니다.
- 테스트를 수행하는데 걸리는 시간을 기록합니다.
- 테스트 케이스에 이슈를 바로 등록/연결할 수 있습니다.
- 작성한 테스트 케이스를 엑셀이나 다른 파일로 변환할 수 있습니다.
- 상태가 Not Executed, In Progress, Pass, Fail, Blocked이 디폴트로 있고, 설정을 통해 상태를 추가할 수 있습니다.
Zephyr Scale 단점
- 오타 및 새로 변경될 사항이 있으면 테스트 케이스를 수정하고 테스트 사이클을 갱신해야 하는 추가 작업을 해야 합니다.
- 이슈 등록 시 재현 방법과 기대 결과가 반영될 줄 알았으나 직접 입력해야 하는 점이 아쉬웠습니다.
위 2가지 툴을 사용해보니 QAlity와 Zephyr Scale의 장점들을 놓치기 어려웠지만, 저희는 결국 Zephyr Scale을 채택하게 되었습니다. 그 이유는 테스트 케이스를 작성, 수행, 결과를 만들 때까지 연결되며 편하게 관리할 수 있다는 점이 가장 컸고, 무엇보다 상태를 추가할 수 있는 점이 가장 좋았습니다. Not Executed, In Progress, Pass, Fail, Blocked 외에도 N/A, N/I 항목 등 다양하게 커스텀마이징이 가능해 웹서비스셀의 QA 업무 성격과 잘 맞았습니다.
#Zephyr Scale 선택 후 이전보다 나아진 점
저희가 사용해보고 나아진 점은 아래 6가지를 나열해 보았습니다.
1) 엑셀에서 벗어나면서 테스트 케이스 작성 시간이 70% 단축되었다
앞서 위에서 언급한 것과 같이 재현 방법과 기대 결과만 작성하니 1주일 이상 걸리던 테스트 케이스 작성 시간이 1~2일 정도로 확연히 감소했습니다. 1,000개가 넘던 테스트 케이스가 이제는 25~30개로 충분히 작성할 수 있었습니다.
또한, 재현 방법이나 기대 결과를 입력하는 곳에 이미지나 다른 첨부 파일 삽입이 가능합니다. 삽입하더라도 템플릿이 일그러지거나 이미지가 작아지지 않습니다. JIRA에서 제공되는 기능이기 때문에 어렵지 않게 작성을 할 수 있습니다.
마지막으로, 테스트 케이스를 추가할 때 자동으로 순서가 지정되어 번호를 직접 부여하지 않아도 자동으로 번호가 부여됩니다. 그리고 테스트 케이스의 순서도 자유롭게 변경할 수 있어서 다른 곳에 잘못 추가했더라도 쉽게 순서 변경을 할 수 있고, 복제도 가능합니다.
2) 이슈 관리가 굉장히 단순해졌다
해당 테스트 케이스에서 이슈 발 생 시 바로 이슈를 등록할 수 있고, 등록된 이슈의 티켓 번호만 안다면 검색해서 연결할 수도 있습니다. 수동으로 복사/붙여넣기 하던 시절에는 느끼지 못한 감동이었습니다.
이슈가 수정되면 케이스에도 상태가 반영되어 이슈 확인 및 종료하는데도 수월했습니다.
3) 테스트 수행 시 시간을 측정해주는 기능이 있어서 얼마나 걸렸는지 확인할 수 있다
테스트 사이클에서 테스트 수행할 때 소요되는 시간을 측정할 수 있습니다. 대신 다른 테스트 케이스로 이동하면 시간은 멈춥니다. 이전에는 테스트 소요 시간을 체감으로만 알 수 있었고, 현재는 이 기능으로 테스트 리소스 측정을 정확하게 할 수 있어 다음 테스트를 계획하는 시간을 확보할 수 있었습니다.
4) 결과를 한눈에 볼 수 있는 툴이 제공되어 편리하다
지금까지는 복잡한 엑셀 수식을 사용해 결과 보고서를 작성했습니다. 효과적으로 작성이 되는 것 같지만 수식에 오류라도 있으면 결과는 제대로 나오지 않습니다. 하지만 Zephyr Scale에서는 결과 보고서를 보여주는 툴이 제공됩니다. 원하는 형태의 보고서를 간편하게 만들 수 있습니다.
5) 테스트 케이스를 처음 접한 사람도 쉽게 이해할 수 있다
사인 오프(Sign-off: “제품이 시장에 출시되어도 됩니다” 라고 선언)를 할 때에도 유관 부서와 함께 해당 케이스들을 내부에 공유하면서 체크를 하는데 사용했습니다. 기존 엑셀의 경우 내용이 너무 길어서 체크하면서 검증하기가 어려움이 있었으나, Zephyr Scale 의 경우 재현 방법/기대 결과/등록한 이슈가 한번에 노출되어 처음 본 사람도 알기 쉬웠습니다.
6) 기타
- 버전 관리도 쉬운데다가 프로젝트별로 폴더를 생성해 관리를 할 수 있어 좋다
- 테스트 케이스별 엑셀 시트와 같이 LNB 메뉴가 제공되고 폴더 별로 관리가 쉬워졌고 이전 테스트 케이스를 바로 확인할 수 있었습니다.
- 검증 시간이 많이 절약됐다
- 플로우에 맞게 순서에 따라 작성 및 테스트하는데 시간이 감소하고, 좀 더 엣지 케이스(Edge case) 위주의 검증을 할 수 있는 시간이 늘었습니다.
#엑셀을 대체 할 만큼 좋은가?
테스트 케이스를 작성하는 과정에서 굉장히 시간을 단축할 수 있었고, 결과 보고서 작성도 빨라졌습니다. 하지만 JIRA에서 제공되는 툴이기 때문에 JIRA를 사용하지 않는 유관부서에서 확인하기 어려워 테스트 케이스 및 결과를 Zephyr Scale에서 pdf 파일로 다운받은 후 가공해서 유관부서에 전달하고 있습니다. 결과적으로 리소스는 낭비를 줄이고 이전보다 빠르게 결과 공유가 가능했습니다.
엑셀을 대체할 만큼 좋은가? 라고 누군가 물어본다면, 네라고 답변할 수 있습니다. 테스트 케이스 작성도 편리했지만, 무엇보다 테스트 케이스 수행부터 결과 보고서 작성, 특히 이슈 관리를 유연하게 할 수 있었습니다. 이렇게 효과적으로 리소스를 관리해서, 예외 케이스가 발생했을 경우 셀 구성원들과 협업을 통해 대응할 수 있었습니다.
저희와 같은 고민을 하신 분들이 계신다면 소개해 드린 QAlity와 Zephyr Scale을 테스트 관리 툴로 사용해 보시는 건 어떨까요? 30일 무료 체험 버전이 있어서 어떤 툴이 본인의 QA 업무에 맞는지 비교해 보시고 선택하시는 걸 추천해 드립니다.
긴 글 읽어주셔서 감사드립니다.
데브시스터즈에서는 작은 불편함을 참지 않고 새로운 기술을 받아들여 개선하려는 도전적인 QA 인재를 기다리고 있습니다. 여러분과 함께 하길 기다리며 글을 끝내도록 하겠습니다. 그럼 이만!
