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

개념

모듈 6의 결함 목록은 찾은 것의 기록이다. 그런데 릴리즈 판단에는 질문이 하나 더 있다 — "무엇을 봤는가". 이 두 질문은 전혀 다르고, 결함 목록으로는 두 번째에 답할 수 없다.

결함이 한 건도 없는 영역을 생각해 보자. 두 가지 뜻이 가능하다.

• 그 영역을 충분히 봤고 괜찮았다
• 그 영역을 아예 안 봤다

결함 목록에서는 둘이 똑같이 비어 있다. 구분하려면 "본 것" 을 따로 기록해야 하고, 그 기록을 다루는 도구가 테스트 관리 도구다.

병원 비유가 맞아떨어진다. 결함 목록은 진단 기록(무엇이 발견됐나)이고 테스트 기록은 검사 항목표(어떤 검사를 했나)다. 검사 항목표가 없으면 "이상 없음" 이 정말 괜찮은 것인지 검사를 안 한 것인지 알 수 없다.

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

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

차이를 네 축으로 보면 더 분명해진다.

마지막 줄이 이 레슨의 존재 이유다. 모듈 6 레슨 5에서 본 커버리지와 "못 한 것" 을 보고할 수 있는 근거가 여기서 나온다. 기록이 없으면 보고서의 "못 한 것" 절은 기억으로 쓰게 되고, 기억은 빠진다.

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

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

가장 중요한 구조 — 저장소와 실행이 분리된다

도구를 처음 보면 혼란스러운 지점이 여기다. 케이스는 한 번 쓰고, 실행은 회차마다 새로 만든다.

[케이스 저장소]                 [실행 런]
  로그인 스위트                  v2.14 릴리즈 런
   ├ TC-001 정상 로그인    ──┐    ├ TC-001  Pass
   ├ TC-002 비밀번호 오류  ──┼──▶ ├ TC-002  Pass
   └ TC-003 계정 잠금      ──┘    └ TC-003  Fail → BUG-512
 
                                v2.15 릴리즈 런
                           ──▶   ├ TC-001  Pass
                                 ├ TC-002  Fail → BUG-530
                                 └ TC-003  Pass

이 구조가 주는 것이 이력이다. 케이스 자체는 하나인데 실행 기록은 릴리즈마다 쌓이므로, "TC-002가 최근 5회 중 3회 실패했다" 를 볼 수 있다. 스프레드시트에서 결과를 덮어쓰면 이 정보가 영원히 사라진다.

실무에서 가장 흔한 실수도 여기서 나온다. 케이스 본문에 결과를 적어 버리는 것이다. "TC-003 — 계정 잠금 (실패)" 처럼 쓰면 다음 회차에 지워야 하고, 이력이 남지 않는다.

케이스 하나는 무엇으로 이루어지나

모듈 3에서 설계한 케이스를 도구에 넣을 때의 형태다.

사전 조건이 비면 케이스가 재사용되지 않는다. 쓴 사람만 실행할 수 있는 케이스가 되고, 다른 사람이 돌리면 "안 되는데요" 가 된다. 모듈 6 레슨 2의 환경 정보와 같은 문제다.

좋은 케이스의 조건은 셋으로 요약된다.

• 혼자 성립한다 — 다른 케이스를 먼저 실행해야 한다는 전제가 없다
• 한 가지를 확인한다 — 통과·실패 판정이 하나로 갈린다
• 누가 봐도 같은 판정 — 기대 결과가 "정상 동작" 처럼 모호하지 않다

세 번째가 자주 깨진다. "화면이 정상적으로 표시된다" 는 사람마다 판정이 다르다. "상품명·가격·재고 세 항목이 모두 표시된다" 처럼 셀 수 있게 쓴다.

스위트를 어떻게 자르나

케이스가 수백 개가 되면 묶는 기준이 필요하다. 세 가지 방식이 흔하다.

실무에서는 기능 영역별로 저장하고, 라벨로 실행 목적을 표시하는 조합이 가장 많이 쓰인다. "결제 스위트" 에 저장하고 스모크 라벨을 붙여 두면, 스모크 런을 만들 때 라벨로 뽑을 수 있다.

스모크 스위트를 따로 만들어 두는 것은 거의 모든 팀에 값이 있다. 20~30분 안에 끝나는 핵심 흐름 묶음이고, 배포 직후 지금 켜져 있는지 확인하는 데 쓴다.

결과 상태를 다섯 가지로 나눈다

통과·실패 둘만 두면 보고가 거짓이 된다.

Blocked 와 Skipped 를 구분하는 것이 핵심이다. 둘을 섞으면 실행률이 왜곡된다.

• Blocked 가 많다 → 우리 잘못이 아니다. 선행 결함을 알려야 한다
• Skipped 가 많다 → 우리가 범위를 줄인 것이고, 보고에 적어야 한다

로그인이 깨져서 50건이 실행 불가인데 그것을 Fail 로 적으면 실패율이 폭등하고 원인이 가려진다. Blocked 로 적고 "로그인 결함 1건이 50건을 차단하고 있다" 로 보고하면, 그 결함의 우선순위가 바로 올라간다(모듈 6 레슨 4의 차단 링크).

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

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

연동이 주는 것은 셋이다.

첫 줄이 매일 쓰인다. 모듈 6 레슨 1의 재검증에서 "원래 절차를 그대로 다시 밟는다" 를 하려면 그 절차가 어디 있는지 찾아야 하는데, 링크가 있으면 한 번에 간다.

트레이서빌리티는 양방향 질문에 답한다

이 말이 추상적으로 들리지만 실제로 묻는 것은 두 질문뿐이다.

첫 번째가 모듈 6 레슨 5의 요구사항 커버리지 그 자체다. 케이스 실행률 100%여도 요구 하나에 케이스가 아예 없으면 그 요구는 검증되지 않았고, 이 추적이 없으면 그 사실이 영원히 안 보인다.

실무에서 완벽한 추적을 만들려 하면 비용이 커진다. 현실적인 타협은 고위험 요구만 추적하는 것이다 — 결제·권한·개인정보처럼 모듈 4에서 고위험으로 분류한 요구에만 케이스 링크를 걸어 두면, 비용의 20%로 효과의 80%를 얻는다.

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

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

불안정한 케이스를 찾아낸다

이력이 쌓이면 케이스 자체가 문제인 경우가 드러난다.

세 번째가 가장 해롭다. 같은 조건에서 결과가 갈리는 케이스는 아무 정보도 주지 않으면서 사람의 시간을 쓴다. 원인은 대개 둘이다 — 기대 결과가 모호하거나(판정이 사람마다 다르다), 사전 조건이 덜 적혀 있다.

이런 케이스를 지우는 것도 선택이다. 다만 지우기 전에 왜 불안정했는지 한 줄 남긴다. 그 메모가 모듈 5 레슨 14의 치트시트 한 줄이 되는 경우가 있다.

케이스는 썩는다

도구를 도입한 팀이 1년 뒤 겪는 문제는 거의 항상 같다. 케이스가 1,200개가 되고 아무도 전체를 돌리지 않는다.

그래서 분기마다 한 번 정리하는 자리를 둔다. 기준은 간단하다 — 최근 3회차에서 한 번도 Pass 로 실행되지 않은 케이스를 꺼내 보고, 고치거나 지운다. 지우는 것을 아깝게 여기면 목록이 계속 불어난다.

매번 Skipped 로 넘기는 케이스는 이미 지워진 것과 같다. 목록에만 남아서 실행률의 분모를 키우고, 커버리지 숫자를 거짓으로 만든다.

스프레드시트는 언제까지 괜찮나

도구를 도입할 필요가 있는지 판단하는 기준이다. 작은 팀에는 스프레드시트가 정답인 경우가 많다.

세 번째 줄이 보통 전환의 계기가 된다. 두 사람이 같은 시트를 고치기 시작하면 결과가 섞이고, 그때부터 기록을 믿을 수 없게 된다.

도구 도입이 실패하는 지점

도입 자체는 반나절이면 되는데, 실패는 두 곳에서 난다.

• 기존 케이스 이전 — 수백 개를 손으로 옮기다 지친다. 대부분 도구가 CSV·엑셀 가져오기를 지원하므로, 형식을 먼저 맞춰 한 번에 올린다
• 유지보수 주인이 없다 — 누가 케이스를 고치고 정리할지 정해 두지 않으면 반년 뒤에 썩는다. 스위트마다 담당을 정해 둔다

그리고 전부를 옮기지 않는다. 지금 실제로 돌리는 케이스만 옮기는 편이 낫다. 1년간 한 번도 실행되지 않은 케이스는 옮길 가치가 없다.

자동화 결과도 같은 곳에 모은다

자동화가 생기면 "자동 결과는 CI 에서 보고, 수동 결과는 도구에서 본다" 가 되기 쉽다. 그러면 커버리지를 합쳐서 말할 수 없다.

대부분의 테스트 관리 도구는 자동화 결과를 API 로 받아 런에 넣을 수 있다. 그렇게 모으면 보고서에 "이번 릴리즈 확인 항목 480건 중 자동 390 · 수동 90" 처럼 한 숫자로 적을 수 있다. 모듈 11~13의 자동화와 이 레슨이 만나는 지점이다.

사례 — 커버리지를 말할 수 있게 되기까지

스프레드시트로 케이스 320개를 관리하던 팀의 기록이다. 릴리즈 보고서에 늘 "주요 기능 테스트 완료" 라고만 적혀 있었다.

문제가 세 가지 있었다.

도구로 옮기면서 한 일은 셋뿐이었다.

1. 실제로 돌리는 케이스 210개만 옮겼다(110개는 1년간 미실행)
2. 결과 상태에 Blocked·Skipped 를 추가했다
3. 스모크 스위트 24건을 따로 만들었다

다음 릴리즈 보고서가 이렇게 바뀌었다.

실행 210건 중 Pass 186 · Fail 9 · Blocked 12 · Skipped 3. Blocked 12건은 결함 BUG-512 하나가 차단하고 있습니다. Skipped 3건은 기기 미확보(저사양 단말)로 제외했습니다.

"주요 기능 테스트 완료" 와 비교하면 전달되는 정보가 다르다. 특히 세 번째 줄 덕에 기기 확보 요청이 처음으로 받아들여졌다 — 모듈 6 레슨 5의 "못 한 것을 적는다" 가 실제로 자원을 가져온 경우다.

이 개념이 도구에서 어떤 구조로 구현되는지는 모듈 22(레슨 11) 에서 TestRail을 예로 실습한다 — 케이스 저장소와 실행 런이 분리돼 있고, 회차마다 새 런을 만들기 때문에 이력이 남는 구조다. 이어지는 레슨 12는 TestRail·Qase·Xray·PractiTest 같은 후보 중에서 우리 팀 조건에 맞는 도구를 고르는 판단 축 을 다룬다.

실무에서 왜 필요한가

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

"못 본 것" 을 말할 수 있는 유일한 근거

모듈 6 레슨 5의 보고서에서 가장 중요한 절이 "못 한 것" 이었다. 그 절을 기억으로 쓰면 반드시 빠진다. 실행 기록이 있으면 Skipped·Blocked 목록을 그대로 옮기면 되고, 그것이 정직한 보고의 토대가 된다.

인수인계와 온보딩의 비용이 달라진다

사람이 바뀔 때 가장 많이 사라지는 것이 "무엇을 어떻게 확인해 왔는지" 다. 머릿속에만 있으면 퇴사·이동과 함께 사라지고, 새 담당자는 처음부터 다시 알아낸다.

케이스 저장소가 있으면 인수인계가 "스위트 목록을 보고 한 번 돌려 보는 것" 으로 바뀐다. 신입이 첫 주에 스모크 런을 돌려 보는 것만으로 제품 전체 흐름을 익히는 효과도 있다.

같은 일을 두 번 하지 않게 된다

이력이 없으면 "지난 릴리즈에 이 영역을 봤나" 를 알 수 없어 다시 본다. 반대로 위험한 영역을 안 보고 지나치기도 한다. 둘 다 이력이 해결한다 — 회차별 결과가 남아 있으면 이번에 무엇을 더 볼지 판단이 선다.

채용시장에서의 위치

공고에 "TestRail / Zephyr / qTest 등 테스트 관리 도구 경험" 이 자주 적힌다. 그런데 면접에서 실제로 묻는 것은 도구 조작이 아니다.

두 번째가 가장 변별력이 크다. 두 도구의 차이를 "결함 vs 테스트" 로만 답하는 사람은 많고, "결함 목록으로는 안 본 영역을 알 수 없다" 까지 말하는 사람은 드물다. 이 한 문장이 테스트 관리를 왜 하는지 아는 증거다.

네 번째도 좋은 답이다. 도구를 도입해 본 사람과 운영해 본 사람이 여기서 갈린다. 케이스를 지우는 기준을 가진 사람은 후자다.

공고 표현으로는 "테스트 케이스 관리", "테스트 자산 관리", "트레이서빌리티", "테스트 커버리지 관리" 가 이 레슨에 걸린다. 도구별 실전과 선택 기준은 모듈 22 레슨 11~12 에서 이어 받는다.

실습 과제

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

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

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

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

요구 REQ-014  "비밀번호는 8자 이상이어야 한다"
      │
      ├─ TC-101  8자 비밀번호로 가입 → 성공          Pass
      ├─ TC-102  7자 비밀번호로 가입 → 거부 + 안내문  Fail ──┐
      └─ TC-103  공백 8자로 가입 → 거부                Pass   │
                                                              ▼
                                                        BUG-233
                                                   "7자 비밀번호가 통과됨"

과제 3 — 결과 상태 가려 쓰기 (10분)

릴리즈 런 100건을 실행했고 상황은 아래와 같다. 각각을 Pass / Fail / Blocked / Skipped / Retest 중 무엇으로 적을지 정하고, 보고서에 쓸 한 줄을 만든다.

1. 60건 — 기대대로 동작
2. 8건 — 기대와 다름, 결함 등록
3. 25건 — 로그인이 깨져서 아예 진입 불가
4. 5건 — 저사양 기기 미확보로 이번엔 제외
5. 2건 — 어제 수정됐다고 하는데 아직 확인 못 함

자가 체크리스트

• 이슈 추적 도구와 테스트 관리 도구의 역할 차이를 설명할 수 있다
• 테스트 케이스·테스트 스위트·테스트 실행의 관계를 설명할 수 있다
• 트레이서빌리티가 무엇이고 왜 중요한지 설명할 수 있다
• 테스트 관리 도구와 이슈 추적 도구가 실무에서 어떻게 연동되는지 설명할 수 있다
• 결함 목록으로는 "안 본 영역"을 알 수 없는 이유를 설명할 수 있다
• 케이스 저장소와 실행 런이 분리된 구조가 왜 중요한지 말할 수 있다
• 케이스에서 사전 조건이 비면 생기는 문제를 설명할 수 있다
• 좋은 케이스의 세 조건을 말할 수 있고, 기대 결과를 셀 수 있게 쓸 수 있다
• 스위트를 자르는 세 기준을 비교할 수 있고, 스모크 스위트의 쓸모를 안다
• Blocked 와 Skipped 를 구분해 적는 이유를 설명할 수 있다
• 트레이서빌리티가 답하는 양방향 질문 두 개를 말할 수 있다
• 번갈아 통과·실패하는 케이스의 두 원인을 안다
• 케이스를 정리하는 기준(최근 3회차 미실행)을 말할 수 있다
• 스프레드시트로 버틸 수 있는 경계를 판단할 수 있다

흔한 실수

• 이슈 추적 도구와 테스트 관리 도구를 같은 것으로 착각한다. 목적이 다르므로 역할도 다르다 — 둘 다 필요한 경우가 많다.
• 테스트 케이스를 스프레드시트로만 계속 관리하려 한다. 규모가 커지면 실행 이력·트레이서빌리티 추적이 사실상 불가능해진다.
• 테스트 실행 결과를 도구에 기록하지 않고 머릿속으로만 기억한다. 다음 릴리스에서 "지난번에 뭘 확인했는지" 알 수 없게 된다.
• 케이스 본문에 결과를 적는다. "TC-003 (실패)" 처럼 쓰면 다음 회차에 지워야 하고 이력이 남지 않는다. 결과는 런에 적는다.
• 사전 조건을 비워 둔다. 쓴 사람만 실행할 수 있는 케이스가 된다.
• 기대 결과를 "정상 동작한다"로 쓴다. 사람마다 판정이 달라지고, 그 케이스는 번갈아 통과·실패한다.
• 실행 불가를 Fail 로 적는다. 실패율이 폭등하고 원인이 가려진다. Blocked 로 적고 차단 결함을 알린다.
• Skipped 를 분모에서 조용히 뺀다. 실행률은 좋아 보이지만 못 본 영역이 사라진다.
• 기능 영역별로만 스위트를 자른다. 영역을 가로지르는 사용자 흐름이 어느 스위트에도 안 들어간다.
• 케이스를 지우지 않는다. 매번 Skipped 로 넘기는 케이스는 이미 지워진 것과 같고, 분모만 키워 커버리지를 거짓으로 만든다.
• 도구 도입 때 케이스 전부를 옮긴다. 1년간 미실행 케이스는 옮길 가치가 없다. 지금 돌리는 것만 옮긴다.
• 유지보수 주인을 정하지 않는다. 반년 뒤에 썩는다. 스위트마다 담당을 둔다.
• 자동화 결과를 따로 본다. 수동·자동을 합쳐야 커버리지를 하나의 숫자로 말할 수 있다.

참고 자료

• TestRail 공식 문서 — Getting Started — 테스트 케이스·스위트·실행 개념의 실제 구현 예시
• ISTQB Glossary — Test Management Tool — 테스트 관리 도구의 공식 정의
• ISO/IEC/IEEE 29119-3 — Test Documentation — 케이스·실행 기록의 표준 항목
• Qase — 테스트 케이스 작성 가이드 — 케이스 구조와 유지보수에 대한 실무 관점

이 커리큘럼 안에서

• 모듈 3 — 테스트 설계. 여기서 만든 케이스가 저장소에 들어간다
• 모듈 3 레슨 8 — 체크리스트. 케이스로 올릴 것과 아닌 것의 구분
• 모듈 4 레슨 2~3 — 리스크. 고위험 요구만 추적하는 타협의 근거
• 모듈 6 레슨 4 — 이슈 추적 도구. 연동되는 다른 한쪽
• 모듈 6 레슨 5 — 품질 지표. 실행률·요구 커버리지·"못 한 것"의 출처
• 모듈 7 레슨 2~3 — 테스트 데이터·환경. 사전 조건을 실제로 만드는 방법
• 모듈 11~13 — 자동화. 자동 결과를 같은 런에 모으는 이유
• 모듈 22 레슨 11~12 — TestRail 실전과 도구 선택 축

한 줄 정리 — 결함 목록은 찾은 것이고 테스트 기록은 본 것이다. 결함이 없는 영역이 "괜찮은 것" 인지 "안 본 것" 인지는 후자만 답할 수 있다. 케이스 저장소와 실행 런을 분리해 이력을 쌓고, Blocked 와 Skipped 를 구분해 적고, 안 돌리는 케이스는 지운다.