개념
모듈 3(레슨 3)과의 차이
모듈 3(레슨 3)에서 상태 전이 테스트를 배웠다 — 명세를 보고 상태 다이어그램을 먼저 그린 뒤 그 다이어그램을 근거로 테스트 케이스를 설계했다. 이 레슨은 순서가 반대다. 명세에 상태가 다 정리되어 있지 않거나, 실제 구현이 명세와 다를 수 있다는 전제 위에서, 탐험하며 상태 모델을 그 자리에서 발견하고 그려나간다.
발견하며 그리기
탐험을 시작하면서 노트나 화이트보드에 상태 다이어그램을 그리기 시작한다. 액션을 할 때마다 "지금 어떤 상태에 있는가"를 표시하고, 예상 못 한 상태에 도달하면 그것도 다이어그램에 추가한다.
"주문" 상태가 공식 문서엔 4가지(결제대기/결제완료/배송중/배송완료)로 적혀 있었다. 그런데 탐험 중 "결제 시도 중 브라우저를 닫아버린" 케이스를 해봤더니, 시스템이 "결제대기"도 "결제완료"도 아닌 애매한 상태로 남아 있었다 — 이건 문서에 없던 다섯 번째 상태다.
이렇게 발견한 상태는 그 자체로 결함일 수도 있고(의도치 않은 상태), 혹은 그냥 문서화가 안 됐을 뿐 정상적인 상태일 수도 있다 — 어느 쪽이든 몰랐던 상태를 찾아냈다는 것 자체가 탐험의 성과다.
"이게 정말 다야?"라고 계속 묻기
상태 모델을 발견할 때 가장 중요한 질문은 "이 목록이 정말 전부인가?"다. 공식 문서나 다른 사람이 알려준 상태 목록을 그대로 믿지 않고, 의도적으로 비정상적인 경로(레슨 6에서 배운 순서 바꾸기, 중간에 멈추기, 동시 조작 등)를 시도해 숨겨진 상태를 캐낸다.
발견의 결과물은 팀에 남긴다
이 탐험 세션이 끝나면, 그 자리에서 그린 상태 다이어그램 자체가 훌륭한 산출물이 된다 — 팀에 실제 시스템 상태 모델을 문서로 남기는 부수 효과가 있다. 특히 문서가 없던 레거시 시스템(레슨 11에서 다룬다)에서 이 방법이 빛을 발한다.
실무에서 왜 필요한가
실제 시스템은 문서화된 것보다 항상 상태가 더 많다 — 예외 처리 경로, 타임아웃, 동시성으로 인한 경합 상태(race condition) 등이 문서에는 안 적히기 때문이다. 이런 "문서에 없는 상태"에서 결함이 자주 나온다. 상태를 실시간으로 발견하며 탐험하는 능력은, 모듈 3의 상태 전이 테스트가 애초에 전제하는 "완전한 상태 목록"이 실제로는 없다는 현실에 대한 QA의 실전 대응이다.
실습 과제
과제 1 — 숨은 상태 상상하기 (12분)
"게시글" 시스템에 공식 상태가 3가지(임시저장/게시됨/삭제됨)라고 하자. 비정상적인 경로(작성 중 네트워크 끊김, 게시 직후 바로 삭제 시도, 이미 삭제된 글을 다시 열람 시도 등)를 상상해서, 문서에 없을 법한 상태를 최소 2개 찾아본다.
과제 2 — 발견 과정을 다이어그램으로 남기기 (10분)
과제 1에서 찾은 상태를 포함해, 텍스트로 상태 다이어그램을 그려본다. 확실하지 않은 부분은 "?"로 표시해 팀에 공유할 만한 "발견 중" 산출물 형태로 만든다.
자가 체크리스트
- 모듈 3의 상태 전이 테스트와 이 레슨의 "상태 발견"이 어떻게 순서가 반대인지 설명할 수 있다
- 실제 탐험 중 문서에 없던 상태를 찾아내는 방법을 설명할 수 있다
- "이 목록이 정말 전부인가?"라는 질문을 스스로에게 적용할 수 있다
- 상태 발견 세션의 결과물이 왜 팀에 남길 만한 문서가 되는지 설명할 수 있다
흔한 실수
- 공식 문서의 상태 목록을 무조건 신뢰한다. 문서는 종종 오래되었거나 예외 상황을 반영하지 않는다.
- 발견한 새 상태를 "이상하다"고만 생각하고 기록하지 않는다. 결함인지 의도된 것인지는 나중에 판단해도 되지만, 발견한 순간 반드시 기록해야 한다.
- 정상 경로만 반복해서 같은 상태만 계속 확인한다. 숨은 상태는 비정상적인 경로(중단, 동시 조작, 순서 뒤섞기)에서 나온다 — 레슨 6과 연결해서 시도해야 한다.
참고 자료
- Elisabeth Hendrickson, Explore It! — 상태 모델을 실시간으로 발견하는 기법을 다룬 장
- ISTQB Glossary — State Transition Testing — 상태 전이의 공식 정의 (모듈 3 레슨 3과 비교하며 참고)