개념
개체 중심으로 보는 관점
지금까지는 주로 "화면 흐름"을 탐험했다. 이 레슨은 관점을 바꿔, 시스템이 다루는 개체(Entity) — 사용자, 주문, 상품, 쿠폰 같은 "것들" — 을 중심으로 탐험한다. 각 개체는 속성(예: 주문의 금액, 상태)을 가지고, 다른 개체와 관계(예: 주문은 사용자에 속하고, 여러 상품을 포함한다)를 맺는다.
CRUD로 탐험하기
각 개체에 대해 **생성(Create)·조회(Read)·수정(Update)·삭제(Delete)**를 탐험하되, 연결된 다른 개체에 무슨 일이 일어나는지까지 함께 본다.
개체: 사용자
- Create: 사용자를 만들면 프로필, 장바구니가 자동으로 함께 생성되는가?
- Update: 이메일을 바꾸면 과거 주문 내역의 연락처 정보도 바뀌는가, 그대로 남는가?
- Delete: 사용자를 삭제하면 그 사용자의 주문·리뷰·쿠폰은 어떻게 되는가? 같이 지워지는가, 남아서 "탈퇴한 사용자"로 표시되는가, 아니면 참조가 끊긴 채(고아 레코드) 남는가?
삭제가 특히 흥미로운 지점이다 — 부모 개체를 지웠을 때 자식 개체가 멀쩡히 참조 없이 남아있는("고아 레코드") 결함은 화면상으로는 잘 안 보이다가 나중에 이상한 곳(예: 관리자 페이지에서 "알 수 없는 사용자"가 쓴 리뷰)에서 드러난다.
데이터 따라가기 (Data Trail)
한 값이 시스템 여러 곳에 걸쳐 일관되게 나타나는지 추적한다.
"할인 10%"라는 값 하나를 따라가보자 — 체크아웃 화면에 표시된다, 주문 확인 이메일에도 나온다, 주문 상세 페이지에도 나온다, 관리자 대시보드 매출 통계에도 반영된다. 이 네 곳의 숫자가 전부 같은가?
한 곳에서만 확인하면 절대 못 잡는, 화면 간 데이터 불일치 결함을 찾는 유일한 방법이 이 "따라가기"다. 재무 관련 값(금액, 할인, 포인트)일수록 불일치의 파장이 크다.
실무에서 왜 필요한가
화면 흐름 중심으로만 탐험하면, "이 화면은 잘 동작한다"는 확인은 되지만 **"이 화면과 저 화면의 숫자가 서로 맞는가"**는 확인이 안 된다. 실무에서 발생하는 심각한 결함 중 상당수가 이런 데이터 불일치다 — 특히 결제·정산처럼 여러 화면·시스템에 걸쳐 같은 값이 반복 표시되는 영역에서 자주 터진다. 개체 중심 탐험은 이런 결함을 정면으로 겨냥한다.
실습 과제
과제 1 — 삭제 영향 추적하기 (12분)
"쿠폰" 개체를 삭제(또는 만료 처리)했을 때, 연결되어 있을 법한 다른 개체(주문, 사용자, 통계 등) 세 가지를 떠올리고 각각에 어떤 영향이 있을지 예상해 적는다.
과제 2 — 데이터 따라가기 (10분)
"회원 등급(일반/VIP)"이라는 값이 시스템 어느 화면들에 걸쳐 나타날 수 있을지 최소 4곳을 나열하고, 이 값이 한 곳에서만 바뀌고 다른 곳엔 반영이 안 되는 결함이 생긴다면 어떤 문제가 생길지 적는다.
자가 체크리스트
- 개체·속성·관계를 예시로 구분해 설명할 수 있다
- CRUD 탐험 시 연결된 다른 개체까지 함께 확인해야 하는 이유를 설명할 수 있다
- "고아 레코드" 결함이 무엇이고 왜 화면만 봐서는 안 보이는지 설명할 수 있다
- 하나의 값을 여러 화면에 걸쳐 추적하는 "데이터 따라가기"를 직접 해볼 수 있다
흔한 실수
- 삭제(Delete)를 테스트하고 "삭제됐다"는 화면 메시지만 확인하고 끝낸다. 연결된 다른 개체까지 확인해야 진짜 결함을 잡는다.
- 한 화면에서 값이 맞으면 다른 화면도 맞을 거라 가정한다. 값이 화면마다 다른 곳(다른 API, 다른 캐시)에서 오는 경우, 한쪽만 갱신되고 다른 쪽은 안 되는 불일치가 실무에서 흔하다.
- 개체 관계도를 전혀 모른 채 탐험한다. 최소한 "이 시스템에 어떤 개체들이 있고 서로 어떻게 연결되는지" 대략적인 그림은 먼저 그려두는 게 효율적이다.
참고 자료
- Elisabeth Hendrickson, Explore It! — 개체·관계 탐험 기법을 다룬 장
- ISTQB Glossary — Data Integrity Testing — 데이터 일관성 검증의 공식 개념과 연결된다