SDD — Scenario-Driven Detection

합리적 추론으로 "기능은 되지만 논리적으로 이상한" 동작을 찾아 고친다.

핵심 개념

기존 테스트가 잡지 못하는 영역:

• "편집" 버튼 → 대시보드로 이동 (crash 아님, 하지만 비정상)
• 삭제 후 목록에 여전히 존재 (API 200 반환, 하지만 비정상)
• 빈 목록인데 empty state 없이 그냥 빈 화면 (에러 아님, 하지만 비정상)

SDD는 AI가 코드 구조/네이밍/DOM을 보고 "이건 이렇게 동작해야 한다"를 스스로 추론하여 검증한다.

워크플로우

SCAN → INFER → VERIFY → FIX → CONFIRM

Phase 1: SCAN — 탐색

입력에 따라 모드 자동 선택:

Mode A: 소스코드 분석

트리거: 프로젝트 경로가 주어졌을 때

1. 프로젝트 구조 파악 (프레임워크, 라우팅, 컴포넌트)
2. 인터랙션 포인트 수집:
   • 클릭 핸들러 (onClick, @click, onPress 등)
   • 라우팅 정의 (routes, pages, navigation)
   • API 엔드포인트 (controllers, handlers)
   • 상태 변경 포인트 (setState, dispatch, mutation)
3. 각 포인트를 시나리오 단위로 목록화

Mode B: URL 크롤링 (DOM 기반)

트리거: URL이 주어졌을 때

1. 대상 URL 진입, DOM 스냅샷 캡처
2. 클릭 가능한 요소 전수 수집:
   • <a>, <button>, [role="button"], [onclick], 클릭 가능한 <div> 등
3. 각 요소를 순차 클릭하며 결과 페이지 DOM 캡처
4. 계층 사이트맵 생성:

/ (대시보드)
├── /users (사용자 목록)
│   ├── [편집 버튼] → ?
│   ├── [삭제 버튼] → ?
│   └── [행 클릭] → ?
├── /settings (설정)
│   └── [저장 버튼] → ?

5. 사이트맵을 깊이 우선(DFS) 순회하며 시나리오 단위 분해
6. 로그인이 필요한 경우: 인증 정보를 먼저 요청하거나 쿠키/토큰 제공받기

SCAN 산출물

# SDD 사이트맵
- 총 페이지: N개
- 총 인터랙션 포인트: M개
- 시나리오 후보: K건

Phase 2: INFER — 시나리오 추론

AI가 각 인터랙션 포인트에 대해 "합리적 기대 결과"를 자율 생성한다.

추론 카테고리

네비게이션 추론

• 편집/수정/edit → 해당 항목의 편집 화면/모달
• 상세/detail/view → 해당 항목의 상세 화면
• 목록/list/back → 상위 목록으로 복귀
• 삭제/delete → 확인 다이얼로그 → 삭제 후 목록 갱신
• 생성/추가/new/create → 생성 폼/모달

상태 변경 추론

• 저장/save/submit → 성공 피드백(토스트/알림) + 데이터 반영
• 취소/cancel/close → 변경사항 버리고 이전 상태 복귀
• 토글/switch → 상태 즉시 반전 + 시각적 피드백

데이터 정합성 추론

• 생성 후 → 목록에 새 항목 존재
• 삭제 후 → 목록에서 해당 항목 소멸
• 수정 후 → 상세에서 변경값 반영
• 검색 후 → 결과가 검색어와 관련

접근성/UX 추론

• 빈 목록 → empty state 표시 (빈 화면 X)
• 로딩 중 → 로딩 인디케이터 표시
• 에러 발생 → 에러 메시지 표시 (무반응 X)
• 필수 필드 미입력 → 유효성 검증 피드백

추론 신뢰도

• HIGH — 네이밍/패턴이 명확 (예: editUser → 편집)
• MEDIUM — 추론 가능하나 여러 해석 가능
• LOW — 확신 없음 → UNCERTAIN 판정으로 분류

INFER 산출물

각 시나리오에 대해:

[SDD-001]
- 요소: 편집 버튼
- 위치: /users > 테이블 3행
- 기대 결과: 해당 사용자의 편집 모달/화면 오픈
- 신뢰도: HIGH

Phase 3: VERIFY — 런타임 검증

사이트맵 기준 깊이 우선 순회하며 각 시나리오 실행:

1. 해당 페이지 진입
2. 대상 요소 클릭/실행
3. 결과 DOM 스냅샷 캡처
4. INFER의 기대 결과와 비교

판정 기준

• ✅ PASS — 기대와 실제가 일치
• ❌ LOGIC DEFECT — 명확한 불일치 (신뢰도 HIGH/MEDIUM)
• ❓ UNCERTAIN — AI가 확신 못 함 (신뢰도 LOW) → 수동 검토 태그

VERIFY 산출물

검증 완료: 42건
- ✅ PASS: 36건
- ❌ LOGIC DEFECT: 4건
- ❓ UNCERTAIN: 2건

Phase 4: FIX — 자동 수정

Mode A (소스코드 있을 때)

LOGIC DEFECT 각 건에 대해:

1. 원인 코드 위치 특정 (파일:라인)
2. 수정 코드 작성
3. 기존 테스트 실행 → 사이드이펙트 확인
4. 사이드이펙트 없으면 수정 적용 + 커밋
5. 사이드이펙트 있으면 → 수동 검토 태그

Mode B (URL만 있을 때)

소스코드 없으므로 직접 수정 불가:

1. 수정 제안서 생성
2. 포함 내용:
   • 원인 추정 (DOM 구조/이벤트 핸들러 기반)
   • 수정 방향 (의사코드 또는 예상 코드 변경)
   • 우선순위 (HIGH/MEDIUM/LOW)

Phase 5: CONFIRM — 수정 검증

1. 수정된 시나리오만 재실행 (전체 재실행 X → 효율)
2. 판정:
   • PASS → ✅ FIXED
   • FAIL → ⚠️ RETRY NEEDED + 수동 검토 요청
3. Mode B는 수정 제안서 제출로 CONFIRM 대체

최종 보고서 포맷

# SDD 테스트 보고서

## 개요
- 대상: [URL 또는 프로젝트 경로]
- 일시: YYYY-MM-DD HH:mm
- 모드: URL 크롤링 / 소스코드 분석
- 소요 시간: Nm Ns

## 사이트맵
(계층 트리)

## 검증 요약
| 구분 | 건수 |
|------|------|
| 전체 시나리오 | 42 |
| ✅ PASS | 36 |
| ❌ LOGIC DEFECT | 4 |
| ❓ UNCERTAIN | 2 |
| ✅ FIXED | 3 |
| ⚠️ RETRY NEEDED | 1 |

## 상세 결과

### [SDD-001] 편집 버튼 클릭
- 위치: /users > 테이블 3행 > 편집 버튼
- 기대: 해당 사용자 편집 모달 오픈
- 실제: 대시보드(/)로 이동
- 판정: ❌ LOGIC DEFECT
- 신뢰도: HIGH
- 원인: onClick → navigate('/') 호출
- 수정: navigate('/') → openEditModal(userId)
- 검증: ✅ FIXED

### [SDD-002] ...

## 수정 이력
| ID | 내용 | 결과 |
|----|------|------|
| SDD-001 | onClick 핸들러 수정 | ✅ FIXED |
| SDD-017 | API 응답 후 목록 미갱신 | ✅ FIXED |
| SDD-028 | empty state 추가 | ✅ FIXED |
| SDD-031 | 삭제 확인 누락 | ⚠️ 수동 검토 |

실행 트리거 예시

사용자가 이렇게 요청하면 SDD를 실행:

• "이 URL 논리 테스트해줘: https://example.com"
• "SDD 돌려줘"
• "이 프로젝트 시나리오 검증해"
• "화면 흐름 논리적으로 맞는지 확인해"

보고서 출력

최종 보고서는 반드시 md 파일로 저장하고 전달한다.

• 파일명: sdd-report-{대상명}-{YYYY-MM-DD}.md
• 저장 위치: 작업 디렉토리 또는 지정 경로
• 채널에 파일 첨부로 전달 (Discord, Slack 등)
• 보고서 본문도 채팅에 요약 표시하되, 전체 내용은 md 파일로 제공

제약사항

• UNCERTAIN 판정은 절대 자동 수정하지 않는다 (수동 검토만)
• 수정 시 기존 테스트를 깨뜨리지 않는다
• 파괴적 동작(DELETE, DROP 등)은 실제 실행하지 않고 시뮬레이션
• 인증이 필요한 페이지는 사전에 인증 정보 확보 후 진행
• Mode B에서 SPA(Single Page App)의 경우 URL 변화 없이 DOM만 바뀔 수 있으므로 DOM diff 기반으로 판정