Xray·Zephyr Scale — Jira 플러그인형 테스트 관리

개념

"Jira 플러그인형"이라는 계열

모듈 7(레슨 1)에서 TestRail을 다뤘다. 그건 독립형(standalone) 도구다 — 별도 서버, 별도 URL, 별도 로그인, 별도 권한 체계를 가진 독립된 애플리케이션이고, Jira와는 연동(integration)으로 이어붙인다.

Xray와 Zephyr Scale은 계열 자체가 다르다. 둘 다 Atlassian Marketplace에서 설치하는 Jira 앱 이다. 설치하고 나면 별도 앱이 생기는 게 아니라, Jira 안에 새로운 이슈 타입이 추가된다.

모듈 6(레슨 4)에서 배운 이슈 타입·워크플로·필드·필터라는 네 가지 공통 개념을 떠올려보자. 플러그인형의 핵심은 테스트 케이스가 그 네 가지 개념을 그대로 물려받는다 는 데 있다. JQL로 "이번 스프린트에 실행 실패한 테스트"를 검색할 수 있고, 결함 등록 시 링크를 거는 게 아니라 이미 같은 이슈 그래프 위에 있다.

추가되는 이슈 타입

도구마다 이름은 조금씩 다르지만 골격은 같다.

• Test — 테스트 케이스 하나. 사전조건·절차·기대결과를 담는다
• Test Set / Test Suite — 관련 케이스를 묶은 그룹
• Test Execution / Test Cycle — 특정 시점의 실행 회차. 각 케이스의 통과·실패·보류가 여기 기록된다
• Test Plan — 릴리스 단위로 여러 실행 회차를 묶는 상위 개념

모듈 7(레슨 1)에서 배운 테스트 케이스 → 스위트 → 실행 구조가 이름만 바뀌어 Jira 이슈로 들어온 것이다. 개념을 새로 배우는 게 아니라, 같은 개념이 어디에 앉아 있는지 만 옮겨 잡으면 된다.

Xray와 Zephyr Scale의 차이

같은 계열이므로 기본 구조는 거의 같다. 실무에서 갈리는 지점은 두 가지 정도다.

선택 기준은 기능 목록 비교가 아니라 "우리 팀이 BDD를 실제로 쓰는가" 한 줄로 정리된다. Cucumber 시나리오를 이미 쓰고 있다면 Xray가 그 파일을 이슈로 승격시켜주는 값을 한다. BDD를 안 쓰는데 Xray를 고르면, 쓰지 않을 기능의 복잡도만 떠안는다.

⚠️ 한 가지 주의 — Zephyr는 제품이 셋이다. 여기서 말한 Zephyr Scale 외에 Zephyr Squad(구 Zephyr for Jira)와 독립 제품인 Zephyr Enterprise가 있고, 특히 Squad와 Scale은 테스트 케이스가 Jira 이슈인지 아닌지 부터 다르다. 두 제품의 실전 사용법과 그 차이가 만드는 실무 결과는 레슨 13 에서 다룬다.

실무에서 왜 필요한가

플러그인형을 고르는 이유는 기능이 더 좋아서가 아니라 전환 비용이 0에 가깝기 때문 이다.

이미 Jira를 쓰는 조직 — 특히 개발팀과 QA가 같은 스프린트 보드를 보는 조직을 떠올려보자. 독립형을 도입하면 계정을 새로 발급하고, 권한 체계를 두 벌 관리하고, 연동이 끊기면 누가 고칠지 정해야 한다. QA 아닌 사람(PO, 개발자)에게 "테스트 결과는 저쪽 도구에서 보세요"라고 말해야 하는 순간, 실제로는 아무도 안 본다.

플러그인형은 이 마찰이 없다. 스프린트 보드에서 스토리를 열면 그 스토리에 연결된 테스트와 최근 실행 결과가 같은 화면에 있다. 도구 도입 회의 없이 관리자가 앱 하나 설치하는 것으로 테스트 관리가 시작된다는 게 현실적인 강점이다.

대가 — Jira에 종속된다

트레이드오프를 분명히 알아야 한다.

• 비용이 Jira 라이선스에 얹혀서 커진다. 대부분의 Atlassian 앱은 Jira 사용자 수에 비례해 과금한다. 테스트를 실제로 쓰는 사람이 QA 5명이어도, Jira 사용자가 200명이면 200명 기준으로 계산되는 구조를 마주치게 된다.
• Jira가 느려지면 테스트 관리도 같이 느려진다. 이슈가 수십만 건 쌓인 인스턴스에서 테스트 실행 화면만 빠를 수는 없다. 대량 실행 결과 입력이 느려지는 건 흔한 불만이다.
• Jira를 버리면 테스트 자산도 같이 묶여 나간다. 테스트 케이스가 Jira 이슈이므로, 이관은 곧 이슈 마이그레이션이다.
• Jira 관리자에게 의존한다. 앱 설치·권한·워크플로 변경 권한이 QA에게 없는 조직이 많다.

실습 과제

과제 1 — 계열 판별 연습 (7분)

아래 상황 세 가지를 읽고, 각각 독립형과 플러그인형 중 무엇을 권할지 와 그 이유를 한 문장씩 적는다.

1. 스타트업. Jira를 전사에서 쓰고 개발자 12명·QA 2명이 같은 보드를 본다.
2. QA 외주 조직. 고객사마다 이슈 추적 도구가 다르고, Jira를 안 쓰는 고객도 있다.
3. 사내 Jira에 이슈가 40만 건 쌓여 있고 검색이 이미 느리다.

과제 2 — 개념 이사 시키기 (8분)

모듈 7(레슨 1)의 실습에서 만든 "온라인 서점" 테스트 스위트를 떠올려, 그 구조를 플러그인형의 이슈 타입(Test / Test Set / Test Execution / Test Plan)에 각각 어떻게 대응시킬지 표로 옮긴다. 대응되지 않아 애매한 항목이 있다면 그것도 적는다 — 계열이 바뀔 때 실제로 헤매는 지점이다.

과제 3 — 도입 제안서 한 문단 (5분)

"우리 팀은 Xray를 도입해야 한다" 또는 "Zephyr Scale이 맞다"를 고르고, 근거 한 문장과 감수해야 할 단점 한 문장 을 함께 적는다. 단점을 쓰지 않은 제안은 실무에서 신뢰를 얻지 못한다.

자가 체크리스트

• 독립형과 Jira 플러그인형 테스트 관리 도구의 근본적 차이를 설명할 수 있다
• 플러그인형에서 테스트 케이스가 "Jira 이슈"라는 사실이 왜 중요한지 설명할 수 있다
• Test / Test Set / Test Execution / Test Plan이 모듈 7의 어떤 개념에 대응하는지 안다
• Xray와 Zephyr Scale 중 무엇을 고를지 팀 상황을 근거로 판단할 수 있다
• Jira 종속으로 인한 비용·성능·이관 리스크를 설명할 수 있다

흔한 실수

• "Zephyr"라는 이름 하나로 뭉뚱그린다. 모듈 7에서 언급한 Zephyr 계열은 제품군이 여러 개다. 채용공고나 인수인계 문서에서 "Zephyr"를 봤다면, 어느 제품인지 확인하는 게 첫 질문이다.
• BDD를 쓰지 않으면서 Xray를 고른다. Cucumber 연동은 Xray의 최대 강점이지만, 쓰지 않으면 그저 늘어난 개념일 뿐이다.
• 플러그인형이면 연동을 신경 쓸 필요가 없다고 생각한다. CI에서 자동화 결과를 올리는 부분은 여전히 API·토큰 설정이 필요하다.
• 라이선스 단가를 QA 인원 기준으로 계산해 보고한다. 대부분 Jira 전체 사용자 수 기준이라, 도입 회의에서 숫자가 뒤집힌다.

참고 자료

• Xray 공식 문서 — Documentation — 이슈 타입 구조와 Cucumber 연동 방식
• Zephyr Scale 공식 문서 — 폴더 기반 케이스 관리와 대량 편집
• Atlassian Marketplace — 플러그인형 도구가 배포되는 경로