개념
글로 설명하면 세 문단, 그림이면 한 장
이런 문장을 써본 적이 있을 것이다.
주문 상태가 '결제대기'일 때 결제가 성공하면 '결제완료'로 가고, 결제완료 상태에서 24시간 안에 취소하면 '취소'로, 배송이 시작되면 '배송중'으로 갑니다. 배송중에서는 취소가 안 되고 반품만 가능한데, 반품은 수령 후 7일 이내여야 하고…
읽는 사람은 세 문장쯤에서 놓친다. 그런데 같은 내용을 상태 전이도 로 그리면 한 번에 들어오고, 심지어 빠진 경로가 눈에 보인다.
이것이 QA가 다이어그램을 그려야 하는 진짜 이유다. 예뻐서가 아니라, 그림이 누락을 드러내기 때문이다. 모듈 3(레슨 3)에서 상태 전이 테스트를 배울 때 이미 경험했다 — 표와 그림으로 옮기는 순간 아무도 정의하지 않은 전이가 튀어나온다.
Confluence에서 이 그림을 그리는 표준 도구가 draw.io 다.
설치 — 관리자 권한이 필요하다
Confluence 편집 화면에서 /draw 를 쳤는데 아무것도 안 나온다면 앱이
설치되지 않은 것이다. draw.io는 기본 탑재가 아니라 Marketplace 앱이다.
설정(톱니바퀴) → 앱 찾기(Find new apps) / Atlassian Marketplace
→ "draw.io" 검색
→ draw.io Diagrams & Whiteboards → Get it now / Try it free이 작업은 Confluence 관리자 권한이 필요하다. 일반 사용자라면 관리자에게 요청해야 하고, 요청할 때는 용도를 함께 적는 편이 통과가 빠르다 — "테스트 계획서의 상태 전이도와 환경 구성도 작성용" 정도면 충분하다.
무료 플랜 여부와 라이선스 정책은 조직 규모·플랜에 따라 다르므로, 설치 전에 마켓플레이스 페이지에서 확인한다.
삽입과 저장 — 발행을 두 번 해야 한다
기본 흐름은 이렇다.
① 페이지 편집 모드 진입 (연필 아이콘 또는 단축키 E)
② 빈 줄에서 /draw 입력 → draw.io Diagram 매크로 선택
③ Blank Diagram 또는 템플릿 선택
(Software / Flowcharts 카테고리에 쓸 만한 것이 많다)
④ 다이어그램 이름 입력 → Create → 편집 창에서 작업
⑤ 편집 창 우측 상단 [Save] / [Publish] ← 다이어그램 저장
⑥ Confluence 페이지의 [Publish] ← 페이지 저장⑤와 ⑥을 둘 다 눌러야 한다. 여기가 초보자가 가장 많이 겪는 함정이다. 다이어그램만 저장하고 페이지를 발행하지 않으면 나에게는 보이는데 팀원에게는 안 보인다. "그림이 안 보인다는데요?"라는 말이 나오면 십중팔구 ⑥을 안 한 것이다.
기본 조작은 일반 드로잉 도구와 같다.
- 도형 배치 — 왼쪽 도형 라이브러리에서 드래그. 사각형은 처리, 마름모는 판단·조건
- 연결 — 도형에 마우스를 올리면 나타나는 화살표를 다른 도형으로 드래그
- 텍스트 — 도형이나 선을 더블 클릭
- 스타일 — 우측 Format 패널에서 색·선 종류·글자 크기
QA가 실제로 그리는 다이어그램 다섯 종류
도구 사용법보다 무엇을 그릴 것인가 가 훨씬 중요하다. 실무에서 값을 하는 다섯 가지를 정리한다.
1) 상태 전이도 — 가장 값이 크다
모듈 3(레슨 3)의 상태 전이 테스트가 그대로 그림이 된다. 주문 상태, 계정 상태, 결제 상태, 승인 워크플로처럼 상태를 갖는 모든 것 이 대상이다.
[결제대기] ──결제성공──▶ [결제완료] ──배송시작──▶ [배송중]
│ │ │
결제실패 24h내 취소 수령완료
▼ ▼ ▼
[실패] [취소] [배송완료]
│
7일내 반품
▼
[반품]그리고 나면 곧바로 질문이 생긴다 — [배송중]에서 취소를 시도하면? [취소] 상태에서 결제 승인이 뒤늦게 들어오면? 이 질문들이 그대로 테스트 케이스가 된다. 그림의 목적은 예쁜 산출물이 아니라 정의되지 않은 전이를 찾는 것 이다.
2) 결함 재현 경로 플로우차트
복잡한 조건에서만 재현되는 결함은 글로 쓰면 개발자가 재현하지 못한다. 분기가 있는 재현 절차는 그림이 훨씬 정확하다.
모듈 6(레슨 2)에서 배운 좋은 결함 리포트의 조건에 하나를 더하는 셈이다. "이 경로로만 재현되고 저 경로로는 안 된다"를 보여주면 원인 범위가 즉시 좁혀진다.
3) 테스트 환경 구성도
어떤 서버·DB·외부 연동이 어떤 환경에 붙어 있는지 그린 그림. 모듈 7 (레슨 3)의 환경 관리와 직결된다.
특히 외부 연동이 실제인지 목(mock)인지 표시 해두면 "스테이징에서만 결제가 이상하다"류의 혼선이 크게 준다. 신규 입사자 온보딩 자료로도 이 그림 한 장이 문서 열 장보다 낫다.
4) 시퀀스 다이어그램
API 호출 순서와 응답을 시간 축으로 그린 것. 모듈 12(API 테스트)에서 다룬 흐름을 시각화한다. 결함 분석에서 "어느 구간에서 끊겼는가" 를 표시하는 용도로 특히 강력하다.
클라이언트 API 게이트웨이 주문 서비스 결제 PG
│ │ │ │
│─ 주문 생성 ───▶│ │ │
│ │─ 주문 저장 ─────▶│ │
│ │ │─ 결제 요청 ──▶│
│ │ │◀── 타임아웃 ──│ ← 여기서 끊김
│ │◀── 500 ──────────│ │
│◀── 500 ────────│ │ │5) 기능 트리 / 커버리지 맵
제품의 기능을 계층으로 펼치고, 각 노드에 테스트 상태를 색으로 표시한다. "어디를 안 봤는가"가 한눈에 보인다. 모듈 4의 리스크 기반 테스트에서 우선순위를 논의할 때 이 그림이 있으면 대화가 빨라진다.
색으로 정보를 실을 때의 원칙
통과는 녹색, 실패는 빨간색. 직관적이고 자주 쓰인다. 그런데 여기에 반드시 지켜야 할 규칙이 하나 있다.
색만으로 정보를 전달하지 않는다.
모듈 16의 접근성 테스트에서 배운 원칙이 우리 산출물에도 적용된다. 적록색약인 사람에게 빨강과 녹색은 구분되지 않고, 흑백으로 인쇄하거나 캡처해서 공유하면 모두가 구분하지 못한다.
| 이렇게만 하면 위험 | 이렇게 |
|---|---|
| 녹색 박스 / 빨간 박스 | 녹색 박스 + PASS / 빨간 박스 + FAIL |
| 색으로 우선순위 구분 | 색 + 숫자(P1, P2) 또는 도형 모양 차이 |
| 색으로 미테스트 표시 | 색 + 점선 테두리 |
색은 보조 수단으로 쓰고, 텍스트나 모양으로 한 번 더 말한다. 자기 산출물에서 이 원칙을 지키는 QA는 남의 제품에서도 이 문제를 잘 찾아낸다.
그림도 썩는다
앞 레슨에서 "숫자를 적지 말고 심어라"라고 했다. 그런데 다이어그램은 심을 수가 없다. 사람이 그렸고, 사람이 고쳐야 한다. 그래서 문서보다 더 빨리 낡는다.
대응은 셋이다.
1) 그림 옆에 메타데이터를 적는다. 최종 수정일, 소유자, 그리고 "이 그림이 실제와 다르면 무엇을 봐야 하는가"(예: 워크플로 설정 화면, 아키텍처 문서). 그림이 틀렸을 때 어디를 봐야 할지 알려주는 것만으로 피해가 줄어든다.
2) 정확도 수준을 명시한다. 모든 그림이 최신일 필요는 없다. "이 그림은 흐름 이해용이며 세부 필드는 실제와 다를 수 있음"이라고 적어두면, 그 그림은 낡아도 거짓말이 되지 않는다.
3) 바뀌는 것은 그리지 않는다. 자주 바뀌는 화면 캡처나 필드 목록을 그림에 박아 넣지 않는다. 구조는 그림으로, 세부는 링크로.
언제 그리지 말아야 하는가
정직하게 반대편도 짚자. 다이어그램이 항상 이득은 아니다.
| 상황 | 판단 |
|---|---|
| 상태·분기·순서가 있는 것 | 그린다 |
| 한 번 보고 버릴 임시 설명 | 그리지 않는다(말이나 글이 빠르다) |
| 자주 바뀌는 세부 사항 | 그리지 않는다(유지보수 비용이 이득을 넘는다) |
| 이미 개발팀이 유지하는 그림이 있음 | 링크한다(같은 그림을 두 곳에 두면 반드시 어긋난다) |
| 텍스트 목록으로 충분한 것 | 그리지 않는다 |
네 번째 줄이 중요하다. 같은 다이어그램이 두 페이지에 따로 존재하면 반드시 어긋난다. 개발팀의 아키텍처 문서에 이미 있다면 그것을 링크하고, QA 관점의 주석만 덧붙이는 편이 낫다.
대안 — Mermaid와 화이트보드
draw.io만이 답은 아니다.
- Mermaid — 텍스트로 그림을 정의하는 방식. 코드 저장소에서 관리할 수 있고 diff가 보인다는 게 큰 장점이다. 개발 문서·README에 넣는 다이어그램이라면 이쪽이 더 잘 맞는다. 반면 자유로운 배치는 어렵다.
- Confluence 화이트보드 — 브레인스토밍이나 리뷰 회의에서 함께 그릴 때. 정돈된 산출물보다 논의 과정 에 가깝다.
선택 기준은 단순하다. 버전 관리와 diff가 중요하면 텍스트 기반(Mermaid), 자유로운 표현과 발표용 완성도가 중요하면 draw.io, 함께 그리는 과정이 목적이면 화이트보드.
실무에서 왜 필요한가
QA의 일 상당 부분은 다른 사람을 이해시키는 일 이다. 개발자에게 결함을 설명하고, 기획자에게 놓친 경로를 지적하고, 신규 입사자에게 시스템을 설명한다. 그림을 그릴 줄 알면 이 모든 대화의 시간이 줄어든다.
그런데 더 큰 이득은 그리는 과정 자체에 있다. 상태 전이도를 그리다 보면 정의되지 않은 전이가 나오고, 시퀀스 다이어그램을 그리다 보면 "이 응답이 실패하면 어떻게 되지?"라는 질문이 나온다. 이 질문들이 곧 테스트 케이스다. 그림은 산출물이기 전에 분석 도구다.
요구사항 리뷰(모듈 2 레슨 6)에서 이 능력이 특히 빛난다. 문서를 읽고 "여기 애매합니다"라고 말하는 것과, 그 자리에서 상태 전이도를 그려 "이 전이는 정의가 없는데 어떻게 됩니까"라고 묻는 것은 회의의 결과가 다르다. 후자는 결정을 만들어낸다.