개념
세 번째 축 — "왜"를 남기는 도구
레슨 1에서 이슈 추적 도구(Jira)와 테스트 관리 도구(TestRail)의 역할 차이를 배웠다. 문서 협업 도구(Confluence, Notion 등) 는 이 둘과 또 다른 세 번째 질문을 다룬다.
| 도구 | 핵심 질문 |
|---|---|
| 이슈 추적 도구 (모듈 6 레슨 4) | 이 결함이 지금 어떤 상태인가? |
| 테스트 관리 도구 (레슨 1) | 이번 릴리스에서 무엇을 테스트했는가? |
| 문서 협업 도구 | 왜 이렇게 하기로 결정했는가? |
이슈와 테스트 케이스는 "지금 상태"를 보여주지만, 몇 달 뒤 "이거 왜 이렇게 만들었죠?"라는 질문에 답할 근거는 별도로 남겨두지 않으면 사라진다. 문서 협업 도구는 그 근거를 남기는 자리다.
QA가 Confluence에 남기는 것들
- 테스트 계획서 — 모듈 4(레슨 1)에서 배운 범위·리스크·일정을 문서로 정리해 팀 전체가 볼 수 있게 공유
- 요구사항 리뷰 회의록 — 모듈 2(레슨 6)에서 짚은 모호함과 누락이, 회의에서 어떻게 결론 났는지 기록. "그때 왜 이렇게 정했었지?"를 몇 달 뒤에도 찾을 수 있게 한다
- 테스트 전략·가이드라인 — "우리 팀은 어떤 경우에 회귀 테스트를 전체 실행하는가" 같은, 매번 새로 설명하기 아까운 팀 공통 규칙
- 회고(Retrospective) 기록 — 지난 릴리스에서 무엇이 잘 안 됐고, 다음엔 어떻게 바꾸기로 했는지
이슈·테스트 케이스와 서로 링크로 연결된다
실무에서는 Confluence 문서 안에 관련 Jira 이슈나 TestRail 스위트로 가는 링크를 걸어둔다. "이 기능의 테스트 전략 문서 → 관련 테스트 스위트 → 실행 결과 → (실패 시) 이슈"까지 클릭 몇 번으로 이어지게 만드는 것이, 레슨 1에서 배운 트레이서빌리티를 문서 차원까지 확장한 것이다.
버전 이력이 만드는 가치
Confluence 같은 도구는 문서가 언제, 누구에 의해, 어떻게 바뀌었는지 이력을 남긴다. "지난달엔 이 조건이 없었는데 언제 추가됐지?"를 이력에서 바로 확인할 수 있다 — 이건 모듈 2(레슨 5)에서 배운 요구사항 변경 추적성과 정확히 같은 원리를, 요구사항 문서 자체에 적용한 것이다.
문서가 오래돼 못 믿게 되는 문제
문서 협업 도구의 가장 흔한 실패는 아무도 안 지켜서 낡아버린 문서다. 화면은 바뀌었는데 스크린샷은 예전 그대로이거나, 결정이 번복됐는데 회의록만 옛날 채로 남아있으면, 사람들은 점점 그 문서를 안 보게 된다. 그러면 처음부터 문서가 없던 것과 다를 게 없다.
실무에서 왜 필요한가
신입 QA가 팀에 합류했을 때 "우리 팀은 왜 이 방식으로 테스트하나요?" 라는 질문에 선임이 매번 구두로 설명해야 한다면, 그 선임의 시간이 계속 소모된다. 잘 정리된 Confluence 문서가 있으면 새로 온 사람이 스스로 찾아 읽고, 정말 애매한 부분만 질문하면 된다. 또한 "그때 왜 이렇게 결정했는지"에 대한 근거가 문서로 남아있지 않으면, 같은 논쟁을 몇 달마다 반복하게 된다 — 이건 조직 전체의 시간 낭비다.