테스트·결함 관리 도구 실전

학습 목표

이 모듈 한 줄 요약 — "팀마다 다른 도구를 쓰지만 구조는 같다". 이직하면 도구가 바뀐다. 그때마다 처음부터 배우지 않으려면 계열을 알아 두면 된다 — 무엇에 붙어서 쓰는 것인지, 케이스를 어디에 두는지, 결함과 어떻게 연결되는지. 그 구조가 같으면 화면만 다르다.

이 모듈을 마치면 모듈 6·7에서 배운 Jira·TestRail 외에, 실무에서 자주 마주치는 테스트·결함 관리 도구 계열을 구분하고 각각의 실전 감각을 익힌다 — Jira 플러그인형(Xray·Zephyr Scale), 현대적 독립형(Testmo·Testiny), 오픈소스(TestLink, Bugzilla·MantisBT· Redmine), 그리고 엔터프라이즈(HP ALM)까지 다룬다. 마지막 다섯 레슨은 가장 많이 쓰이는 Atlassian 두 도구를 실전 기준으로 파고든다 — Jira의 프로젝트·업무 항목·필드 구조, JQL과 저장된 필터, 대시보드로 품질 지표를 굴리는 법, 그리고 Confluence의 매크로로 스스로 갱신되는 문서를 만들고 draw.io로 테스트를 그림으로 설명하는 법이다. 이어서 TestRail과 Zephyr(Squad·Scale)를 실전 수준으로 다루고, 지금까지 본 도구들을 놓고 고르는 방법과 갈아타는 비용 을 따지는 판단 틀까지 갖춘다.

완료 후 할 수 있는 것

• Xray·Zephyr Scale이 왜 "Jira 플러그인형"으로 분류되는지, TestRail 같은 독립형과 무엇이 다른지 설명할 수 있다
• Testmo·Testiny 같은 최신 도구들이 기존 도구 대비 무엇을 개선했는지 설명할 수 있다
• TestLink로 오픈소스·무료 환경에서도 테스트 케이스 관리가 가능하다는 것을 안다
• Bugzilla·MantisBT·Redmine 세 오픈소스 이슈 추적 도구의 공통점과 각각의 특징을 구분할 수 있다
• HP ALM/Quality Center가 왜 여전히 일부 대기업·금융권의 표준으로 남아 있는지 설명할 수 있다
• Jira의 프로젝트 유형·업무 항목 계층·필드 3층 구조를 이해하고, 결함 리포트 품질을 필드 설계로 강제할 수 있다
• JQL로 원하는 업무 항목을 검색하고, 이력 검색(WAS·CHANGED)으로 재오픈·검증 누락 같은 지표를 뽑을 수 있다
• 저장된 필터를 재료로 독자별 대시보드를 설계해 품질 지표를 자동으로 갱신되게 만들 수 있다
• Confluence 매크로로 Jira와 연결된 '살아 있는' 테스트 계획서·결과 보고서를 만들고, 여러 페이지의 결과를 자동 집계할 수 있다
• 상태 전이도·재현 경로·환경 구성도 같은 QA 다이어그램을 draw.io로 그려 누락을 찾아낼 수 있다
• TestRail의 케이스 저장소와 실행 이력 분리 구조를 이해하고, 런·플랜·구성·마일스톤으로 회차를 운영하며 trcli로 자동화 결과를 합칠 수 있다
• 다섯 개 판단 축으로 도구 후보를 좁히고, 교체가 필요한 문제와 운영으로 풀 문제를 구분할 수 있다
• Zephyr Squad와 Scale을 구분하고, 버전·사이클 운영과 ZQL·커버리지 쿼리로 요구사항부터 결함까지의 추적 사슬을 만들 수 있다

채용시장에서의 위치

테스트·결함 관리 도구는 회사의 규모·예산·기존 시스템(특히 Jira를 쓰는지 여부)에 따라 완전히 다른 선택지가 나온다. 이 모듈은 특정 도구 하나를 깊게 파기보다, "이 도구가 어느 계열에 속하는가"를 빠르게 분류하는 능력을 기르는 데 초점을 둔다 — 처음 보는 도구도 "아, 이건 Jira 플러그인형이구나"라고 알아채면 적응이 훨씬 빠르다.

다만 예외가 하나 있다 — Jira는 깊게 파둘 값어치가 있다. 국내외 QA 채용공고에서 가장 자주 등장하는 도구이고, 대부분의 조직에서 QA가 하루 중 가장 오래 붙잡고 있는 화면이기 때문이다. 특히 JQL은 면접에서 직접 물어보는 경우가 있을 만큼 변별력이 있다 — "결함이 좀 쌓인 것 같습니다"와 "60일 이상 방치된 High 결함이 14건, 그중 5건은 담당자가 없습니다"의 차이를 만드는 능력이다.

Confluence도 같은 맥락이다. QA는 조직에서 문서를 가장 많이 쓰는 직군 중 하나이고, "QA 페이지에 가면 최신 상태를 알 수 있다" 는 평판은 그 자체로 영향력이 된다. 특히 다이어그램을 그릴 줄 아는 QA는 요구사항 리뷰에서 결정을 만들어낸다 — "여기 애매합니다"와 그 자리에서 상태 전이도를 그려 "이 전이는 정의가 없는데 어떻게 됩니까"는 회의의 결과가 다르다.

경력이 쌓이면 "우리 팀 도구 좀 정해주세요"라는 요청을 받게 된다. 그때 필요한 것은 도구 지식이 아니라 조건을 질문으로 바꾸는 능력 이고, 더 자주 쓰이는 것은 교체를 말리는 능력 이다. 마지막 레슨이 그 판단 틀을 다룬다.