개념
Jira는 '무엇을'을 담고 Confluence는 '왜'를 담는다
모듈 7(레슨 7)에서 Confluence를 "세 번째 축"으로 배웠다. 이슈 추적 도구가 개별 작업을, 테스트 관리 도구가 케이스를 담는다면, Confluence는 결정의 이유와 맥락 을 담는다.
이 레슨은 그 개념을 실제 화면에서 굴리는 방법이다. 그리고 핵심 주장은 하나다.
좋은 QA 문서는 사람이 갱신하는 문서가 아니라, 스스로 갱신되는 문서다.
테스트 계획서에 "미해결 결함 12건"이라고 타이핑해 넣는 순간 그 숫자는 낡기 시작한다. 다음 주에 보면 틀린 숫자고, 그걸 본 사람은 문서 전체를 믿지 않게 된다. 모듈 7에서 배운 "문서가 오래돼 못 믿게 되는 문제"의 가장 흔한 형태다.
Confluence의 매크로는 이 문제를 구조적으로 푼다. 숫자를 적는 대신 Jira 쿼리를 심어두면, 문서를 열 때마다 그 자리의 숫자가 지금 값으로 채워진다. 앞 레슨에서 배운 JQL이 여기서 두 번째 쓰임을 갖는다.
시작은 빈 페이지가 아니라 템플릿
새 문서를 만들 때 빈 페이지에서 시작하는 것은 대부분 손해다. Confluence는 템플릿을 제공하고, QA에게 유용한 것들이 이미 들어 있다.
| 템플릿 | 쓰는 상황 |
|---|---|
| 테스트 계획(Test Plan) | 새 프로젝트·차수 시작 시 범위·일정·환경 정의 |
| 제품 요구사항(Product Requirements) | 기획 문서를 QA가 함께 검토할 때 |
| 회의록(Meeting Notes) | 요구사항 리뷰·결함 트리아지 회의 기록 |
| 의사결정(Decision) | "이 결함은 이번 릴리즈에 고치지 않는다" 같은 결정 |
| 회고(Retrospective) | 릴리즈 후 회고 |
의사결정 템플릿을 특히 권한다. 모듈 4에서 배운 리스크 기반 판단이나 릴리즈 승인 결정은 시간이 지나면 "왜 그렇게 했더라"가 된다. 결정·근거· 대안·결정자를 한 페이지로 남겨두면 나중에 같은 논쟁을 반복하지 않는다.
템플릿을 그대로 쓸 필요는 없다. 팀에 맞게 고친 뒤 사용자 정의 템플릿 으로 저장해두면 그다음부터는 팀의 표준이 된다. 이게 모듈 18a(레슨 8)에서 배운 "반복 업무를 표준 절차로 만들기"의 문서 버전이다.
QA가 실제로 쓰는 매크로
편집 화면에서 슬래시(/)를 누르면 매크로 목록이 뜬다. 종류는 수십 개지만
QA가 실제로 쓰는 것은 한정적이다.
| 매크로 | 무엇을 하나 | QA가 쓰는 상황 |
|---|---|---|
Jira 업무 항목 (/jira) | 단일 이슈 링크 또는 JQL 결과를 표로 삽입 | 미해결 결함 목록, 이번 릴리즈 범위 |
| Jira 차트 | Jira 데이터를 차트로 | 결함 해결 추이, 우선순위 분포 |
상태(/status) | 색이 있는 라벨 | Pass / Fail / 진행중 / 보류 |
| 할 일 목록 | 체크박스 | 릴리즈 체크리스트, 스모크 항목 |
| 정보 / 경고 / 주의 | 강조 박스 | 테스트 계정, 환경 주의사항, 알려진 이슈 |
확장(/expand) | 접었다 펴기 | 긴 로그, 상세 재현 절차, 스크린샷 묶음 |
| 레이아웃 | 2·3열 분할 | 왼쪽 시나리오 / 오른쪽 화면 캡처 |
목차(/toc) | 자동 목차 | 긴 테스트 계획서 |
| 콘텐츠 속성 + 보고서 | 여러 페이지의 메타데이터를 표로 집계 | 차수별 테스트 결과 대시보드 |
마지막 줄이 가장 강력한데 가장 덜 알려져 있다. 조금 뒤에 따로 다룬다.
참고 — Atlassian은 도구 용어를 계속 손본다. 앞 레슨에서 본 '이슈 → 업무 항목' 변경에 이어, Confluence Cloud에서는 페이지 속성(Page Properties) 매크로가 '콘텐츠 속성(Content Properties)'으로 이름이 바뀌었다. 검색해서 나오는 자료의 이름이 화면과 달라도 같은 기능이다.
Jira 연동 — 문서 안에서 결함까지 등록한다
Confluence와 Jira를 함께 쓸 때의 진짜 이득은 맥락 전환이 사라지는 것 이다. 두 가지 흐름을 익혀두면 된다.
1) 텍스트를 드래그해서 바로 이슈 만들기
탐색적 테스트 중 페이지에 메모를 적어두다가, 그 텍스트를 드래그하면
떠오르는 툴바에서 + Jira 업무 항목 을 눌러 그 자리에서 결함을
등록할 수 있다. 등록된 이슈는 원래 텍스트 자리에 링크로 남는다.
이 흐름이 좋은 이유는 모듈 5(탐색적 테스팅)의 원칙과 맞기 때문이다. 탐색 중에는 흐름이 끊기면 안 된다. 이상한 점을 발견할 때마다 Jira로 가서 폼을 채우면 탐색 세션이 망가진다. 메모로 쭉 쌓아두고, 세션이 끝난 뒤 한 번에 이슈로 전환하는 방식이 훨씬 낫다.
2) JQL 결과를 페이지에 심기
/jira 매크로에 앞 레슨에서 만든 JQL을 넣으면, 그 결과가 표로 페이지에
박힌다. 예를 들어 릴리즈 노트 페이지에 이렇게 심어둔다.
project = SHOP AND fixVersion = "v2.4.0" AND issuetype = Bug
ORDER BY priority DESC이러면 릴리즈 범위가 바뀔 때마다 문서가 저절로 따라온다. 사람이 목록을 복사해 붙였다면 그 순간부터 어긋나기 시작했을 것이다.
테스트 계획서에도 같은 방식을 쓴다.
| 문서의 자리 | 심을 것 |
|---|---|
| "테스트 대상 범위" | 해당 에픽 하위 스토리 목록(JQL) |
| "현재 미해결 결함" | 미해결 Bug 목록(JQL) |
| "차단 요소" | status = Blocked 또는 차단 링크가 걸린 항목 |
| "릴리즈 판단 근거" | 우선순위별 잔여 건수 차트(Jira 차트 매크로) |
콘텐츠 속성 보고서 — 차수별 결과를 자동으로 모으기
여기가 이 레슨에서 가장 실무적인 부분이다. 문제 상황부터 보자.
테스트를 차수별로 수행하고 매번 결과 페이지를 만든다. 3개월이 지나면 페이지가 12개다. 팀장이 "지금까지 차수별 결과를 한눈에 보고 싶다"고 한다. 지금까지는 매번 손으로 표를 다시 만들었다.
콘텐츠 속성(구 페이지 속성) 매크로 가 이걸 해결한다. 동작 원리는 단순하다.
① 각 차수 페이지 안에 '콘텐츠 속성' 매크로를 넣고
그 안에 2열 표로 메타데이터를 적는다
┌─────────────┬──────────────┐
│ 차수 │ 3차 │
│ 기간 │ 09-01 ~ 09-04 │
│ 대상 버전 │ v2.4.0 │
│ 수행 케이스 │ 184 │
│ Pass / Fail │ 176 / 8 │
│ 판정 │ [조건부 통과] │ ← 상태 매크로
└─────────────┴──────────────┘
↓ (라벨로 묶는다: test-round)
② 요약 페이지에 '콘텐츠 속성 보고서' 매크로를 넣고
라벨 test-round 를 지정한다
↓
③ 12개 페이지의 표가 한 장의 집계표로 자동 생성된다새 차수 페이지를 만들면 요약표에 자동으로 한 줄이 추가된다. 손으로 갱신할 것이 없다. 이 구조를 한 번 만들어두는 데 20분쯤 걸리고, 그 뒤로는 영원히 공짜다.
같은 패턴을 쓸 수 있는 곳들이다.
- 릴리즈별 테스트 결과 요약
- 환경별 점검 결과(개발/스테이징/운영)
- 결함 트리아지 회의록 모음(회차·참석자·결정 건수)
- 기능 영역별 테스트 커버리지 현황
테스트 케이스를 Confluence에 쓸까, 전용 도구를 쓸까
Confluence 표로 테스트 케이스를 관리하는 팀이 많다. 되긴 된다. 다만 어디까지가 적정선인지 를 알아야 한다.
| 상황 | 권장 | 이유 |
|---|---|---|
| 기능별 체크리스트, 스모크 목록 | Confluence | 가볍고, 맥락과 함께 읽힌다 |
| 탐색적 테스트 세션 노트 | Confluence | 자유 서술이 필요하다 |
| 릴리즈 점검 항목 | Confluence | 할 일 목록 매크로로 충분 |
| 케이스 300개 이상의 회귀 스위트 | 전용 도구(Xray·Zephyr·TestRail) | 실행 이력·차수 관리가 필요 |
| 요구사항 ↔ 케이스 ↔ 결과 추적성 | 전용 도구 | 매트릭스와 리포트가 필요 |
| 자동화 결과와 결합 | 전용 도구 | API로 결과가 밀려 들어와야 한다 |
경계선은 "같은 케이스를 여러 번 실행하고 그 이력을 비교해야 하는가" 다. 한 번 보고 끝나는 체크리스트는 Confluence가 낫고, 실행 이력이 쌓여야 하는 것은 전용 도구가 낫다. 모듈 22 레슨 1~3에서 본 도구들이 그 자리다.
Confluence 표로 관리하다 무너지는 전형적 신호 도 알아두면 좋다 — 표가 화면 밖으로 넘쳐 가로 스크롤이 생기고, "지난 차수 결과는 어디 있죠"라는 질문이 나오기 시작하고, 같은 케이스가 두 페이지에 다르게 적혀 있는 상태. 이 셋 중 둘이 보이면 이사할 때다.
결과 보고서와 승인 기록
테스트 차수가 끝나거나 배포 전 단계에서 쓰는 테스트 결과 보고서 는 Confluence가 가장 잘 맞는 문서다. 숫자는 매크로로 살아 있게 하고, 판단과 근거는 글로 쓴다.
보고서에 반드시 들어가야 할 것은 넷이다.
- 범위 — 무엇을 테스트했고 무엇을 안 했는가(안 한 것을 쓰는 게 더 중요하다)
- 결과 수치 — 수행/통과/실패, 미해결 결함(JQL 매크로로 삽입)
- 판단과 근거 — "출시 가능하다고 보는 이유" 또는 "권고하지 않는 이유"
- 승인 기록 — 누가 언제 승인했는가
4번을 가볍게 보면 안 된다. 릴리즈 후 문제가 생겼을 때 "QA가 괜찮다고 했다"와 "QA는 잔여 리스크 3건을 명시했고, PO가 그것을 인지한 상태에서 출시를 결정했다"는 완전히 다른 상황이다. 멘션(@이름)으로 승인을 요청하고 그 응답이 페이지에 남으면 그것이 기록이 된다.
모듈 25에서 배운 것과 같은 원리다 — 안전·인증 도메인에서 요구하는 "검증했음을 증명하는 문서"가, 일반 서비스 조직에서는 이런 형태로 나타난다.
문서가 썩지 않게 하는 세 가지 장치
모듈 7에서 "문서가 오래돼 못 믿게 되는 문제"를 배웠다. 실무에서 쓸 수 있는 대응은 셋이다.
1) 숫자는 적지 말고 심어라. 이 레슨의 핵심. 손으로 적은 숫자는 반드시 낡는다.
2) 소유자와 검토 주기를 페이지에 적어라. 콘텐츠 속성 매크로에
소유자 / 최종 검토일 / 다음 검토일 을 넣어두고, 보고서 매크로로
모아 보면 검토 기한이 지난 문서 목록 이 자동으로 만들어진다.
3) 죽은 문서는 지우거나 표시하라. 보관(Archive)하거나 상단에 경고 매크로로 "이 문서는 v1.x 기준이며 갱신되지 않습니다"를 붙인다. 틀린 문서는 없는 문서보다 나쁘다.
실무에서 왜 필요한가
QA는 조직에서 문서를 가장 많이 쓰는 직군 중 하나다. 테스트 계획, 결과 보고, 회의록, 체크리스트, 환경 안내. 이 문서들이 신뢰를 잃으면 QA의 말도 함께 신뢰를 잃는다. 반대로 "QA 페이지에 가면 최신 상태를 알 수 있다" 는 평판이 생기면 그것 자체가 영향력이 된다.
매크로를 쓸 줄 아는 것과 모르는 것의 차이는 시간으로도 크다. 차수별 결과 집계, 릴리즈 범위 목록, 미해결 결함 현황을 매번 손으로 만들던 것이 한 번의 설정으로 대체된다. 그 시간은 테스트로 돌아온다.
그리고 이 능력은 QA가 회의에서 자료를 만드는 방식 을 바꾼다. 회의 전날 밤에 스크린샷을 모아 슬라이드를 만드는 대신, 항상 최신인 페이지 링크 하나를 공유하면 된다. 앞 레슨의 대시보드와 같은 원리다 — 살아 있는 화면이 정적인 보고서를 대체한다.