테스트 관리 도구: TestRail·Zephyr로 테스트 케이스 관리하기

개념

이슈 추적 도구와 테스트 관리 도구는 목적이 다르다

모듈 6(레슨 4)에서 Jira 같은 이슈 추적 도구를 다뤘다 — 결함이 발견부터 종결까지 어떤 상태를 거치는지 추적하는 도구였다. 테스트 관리 도구(TestRail, Zephyr, qTest 등)는 질문 자체가 다르다.

테스트 관리 도구의 핵심 개념

• 테스트 케이스(Test Case) — 모듈 3에서 설계한 테스트 케이스를 구조화된 형태(사전조건·절차·기대결과)로 저장하는 저장소 역할
• 테스트 스위트(Test Suite) — 관련된 테스트 케이스를 묶은 그룹 (예: "로그인 스위트", "결제 스위트")
• 테스트 실행(Test Run) — 특정 시점(예: 릴리스 직전)에 어떤 스위트를 실행했고, 각 케이스가 통과/실패/보류 중 무엇이었는지 기록
• 트레이서빌리티(Traceability) — 요구사항 → 테스트 케이스 → 실행 결과 → (실패 시) 결함으로 이어지는 연결고리. 모듈 2에서 배운 요구사항 기반 테스트 설계가 실제로 "몇 % 커버됐는지" 확인하는 근거가 된다

테스트 관리 도구와 이슈 추적 도구는 연동된다

실무에서는 테스트 관리 도구에서 테스트를 실행하다가 실패하면, 그 자리에서 바로 이슈 추적 도구에 결함을 등록하고 서로 링크를 건다. "이 테스트 케이스가 실패해서 이 버그가 등록됐다"는 연결이 남아, 나중에 "이 버그가 고쳐졌는지" 재검증할 때 원래 실패했던 테스트 케이스를 다시 찾기 쉬워진다.

반복 실행 이력이 만드는 가치

테스트 관리 도구에 실행 이력이 쌓이면, "이 케이스가 지난 5번의 릴리스에서 몇 번 실패했는가" 같은 패턴을 볼 수 있다. 자주 실패하는 영역은 코드가 불안정하거나, 테스트 케이스 자체가 애매하게 작성됐다는 신호일 수 있다 — 모듈 6(레슨 5)에서 배운 품질 지표와 연결되는 지점이다.

실무에서 왜 필요한가

수동 테스트 케이스가 수십~수백 개를 넘어가면, 스프레드시트만으로는 "이번 릴리스에서 뭘 실행했는지" 추적이 불가능해진다. 테스트 관리 도구는 이 규모의 문제를 해결하기 위한 것이다. 채용공고에서 "TestRail 경험"을 요구하는 이유도, 도구 자체보다는 체계적으로 테스트 범위를 추적하고 릴리스 근거를 남기는 습관을 갖췄는지를 보기 위해서다.

실습 과제

과제 1 — 테스트 스위트 설계하기 (10분)

"온라인 서점" 서비스의 테스트 케이스를 스위트 단위로 나눈다면 어떤 스위트가 필요할지 최소 4개(예: 회원가입, 검색, 결제, 주문내역)를 나열하고, 각 스위트에 들어갈 만한 테스트 케이스를 하나씩 예시로 적는다.

과제 2 — 트레이서빌리티 따라가기 (10분)

"비밀번호는 8자 이상이어야 한다"는 요구사항 하나를 골라, 이 요구사항이 테스트 케이스 → 테스트 실행 결과 → (실패했다면) 결함 등록까지 어떻게 연결되는지 순서대로 적어본다.

자가 체크리스트

• 이슈 추적 도구와 테스트 관리 도구의 역할 차이를 설명할 수 있다
• 테스트 케이스·테스트 스위트·테스트 실행의 관계를 설명할 수 있다
• 트레이서빌리티가 무엇이고 왜 중요한지 설명할 수 있다
• 테스트 관리 도구와 이슈 추적 도구가 실무에서 어떻게 연동되는지 설명할 수 있다

흔한 실수

• 이슈 추적 도구와 테스트 관리 도구를 같은 것으로 착각한다. 목적이 다르므로 역할도 다르다 — 둘 다 필요한 경우가 많다.
• 테스트 케이스를 스프레드시트로만 계속 관리하려 한다. 규모가 커지면 실행 이력·트레이서빌리티 추적이 사실상 불가능해진다.
• 테스트 실행 결과를 도구에 기록하지 않고 머릿속으로만 기억한다. 다음 릴리스에서 "지난번에 뭘 확인했는지" 알 수 없게 된다.

참고 자료

• TestRail 공식 문서 — Getting Started — 테스트 케이스·스위트·실행 개념의 실제 구현 예시
• ISTQB Glossary — Test Management Tool — 테스트 관리 도구의 공식 정의