프로그램 목록이 완성됐다. SOM ID가 붙었다. 이제 무엇을 할 것인가.
테스트 시나리오를 설계할 차례다. 그런데 SOM 기반 시나리오 설계는 기존 방식과 시작점이 다르다. 기존에는 "무엇을 테스트할까"를 고민하면서 시나리오를 만들었다. SOM에서는 이미 무엇을 테스트해야 하는지 목록이 있다. 프로그램 목록이 곧 테스트 대상 목록이다.
Program이 시나리오의 단위 The Program is the unit of a scenario
SOM에서 테스트 시나리오는 Program 단위로 설계된다.
SOM-0003 '회원가입 화면'이 하나의 시나리오 묶음이 된다. 이 Program에 대해 어떤 상황을 테스트해야 하는지 — 정상 흐름, 오류 상황, 경계값 — 을 Component와 Action 수준으로 풀어내는 것이 시나리오 설계다.
구조로 표현하면 이렇다.
SOM-0003 회원가입 화면 ├── TC-0003-001 정상 가입 (이메일 + 비밀번호) ├── TC-0003-002 이메일 중복 검사 ├── TC-0003-003 비밀번호 규칙 위반 ├── TC-0003-004 필수 항목 미입력 └── TC-0003-005 이메일 인증 완료 후 가입
테스트 케이스 번호 앞에 SOM ID가 붙는다. TC-0003-xxx는 SOM-0003의 테스트라는 것이 번호만 봐도 명확하다.
시나리오 설계 순서 The order of scenario design
1단계: 정상 흐름(Happy Path) 먼저
가장 전형적인 사용 시나리오를 먼저 작성한다. 오류 없이 목적을 달성하는 흐름이다.
SOM-0003 회원가입의 정상 흐름:
TC-0003-001 정상 가입 전제조건: 사용자가 가입 페이지에 접근한 상태 단계: Action 1. 이메일 입력 (신규 이메일) Action 2. 비밀번호 입력 (규칙 충족) Action 3. 비밀번호 확인 입력 (일치) Action 4. 이름 입력 Action 5. 가입 버튼 클릭 기대 결과: - 이메일 인증 안내 페이지로 이동 - 입력한 이메일로 인증 메일 발송
2단계: 오류 흐름(Negative Path)
입력 오류, 중복, 권한 없음 등 예외 상황을 다룬다.
TC-0003-002 이메일 중복 Action 1. 이미 가입된 이메일 입력 Action 2. 가입 버튼 클릭 기대 결과: - "이미 사용 중인 이메일입니다" 오류 메시지 표시 - 페이지 이동 없음
3단계: 경계값(Boundary)
입력 길이, 특수문자, 빈 값 등 경계 조건을 테스트한다.
TC-0003-003 비밀번호 규칙 위반 대상: 8자 미만 / 영문 없음 / 숫자 없음 / 특수문자 없음 각 조건별 기대 결과: - 규칙 위반 안내 메시지 각각 표시 - 가입 버튼 비활성 또는 제출 차단
Component로 내려가기 Descending into Components
시나리오 안의 각 Action은 Component와 연결된다.
SOM-0003의 Component 목록:
SOM-0003 회원가입 화면 Component A. 이메일 입력 필드 Component B. 비밀번호 입력 필드 Component C. 비밀번호 확인 입력 필드 Component D. 이름 입력 필드 Component E. 가입 버튼 Component F. 오류 메시지 영역 Component G. 이메일 중복 확인 버튼
Action은 Component에 가해지는 동작이다.
"이메일 입력" = Component A에 fill('user@example.com')
"가입 버튼 클릭" = Component E에 click()
"오류 메시지 확인" = Component F의 text 검증이 구조가 자동화 테스트 코드와 자연스럽게 연결된다.
자동화 코드와의 연결 Connecting to automation code
Playwright 기준으로 보면, SOM의 계층이 코드 구조로 그대로 번역된다.
// TC-0003-001: SOM-0003 회원가입 - 정상 가입
test('SOM-0003 | TC-001 | 정상 가입', async ({ page }) => {
await page.goto('/signup');
// Component A — 이메일 입력 필드
await page.getByLabel('이메일').fill('newuser@example.com');
// Component B — 비밀번호 입력 필드
await page.getByLabel('비밀번호').fill('Test1234!');
// Component C — 비밀번호 확인
await page.getByLabel('비밀번호 확인').fill('Test1234!');
// Component D — 이름
await page.getByLabel('이름').fill('홍길동');
// Component E — 가입 버튼
await page.getByRole('button', { name: '가입하기' }).click();
// 기대 결과 검증
await expect(page).toHaveURL('/signup/verify-email');
});테스트 이름에 SOM-0003 | TC-001이 포함된다. 테스트 실행 결과 리포트에서 SOM ID로 필터링하면, 어떤 Program의 어떤 시나리오가 통과하고 실패했는지 즉시 파악된다.
얼마나 많은 시나리오가 필요한가 How many scenarios do you need
흔한 질문이다. "Program 하나에 시나리오를 몇 개나 만들어야 하나요?"
정답은 없다. 다만 기준이 있다.
P1(핵심 기능): 정상 흐름 + 주요 오류 흐름 + 핵심 경계값. 최소 5~10개.
P2(중요 기능): 정상 흐름 + 대표 오류 흐름. 3~5개.
P3 이하(보조 기능): 정상 흐름 중심. 1~3개.
처음부터 모든 Program을 완벽하게 커버하려 하지 않아도 된다. P1 Program의 정상 흐름부터 시작해서, 오류 흐름을 추가하고, P2로 넓혀가는 것이 현실적이다.
시나리오 설계의 부산물 The by-products of scenario design
SOM 기반으로 시나리오를 설계하면, 설계 과정에서 자연스럽게 발견되는 것들이 있다.
기획 누락: "비밀번호 찾기 완료 후 어디로 이동하는가"가 화면 정의서에 없다. QA가 시나리오를 작성하다 발견하고 기획자에게 확인한다.
중복 기능: 두 개의 다른 Program이 실은 같은 Component를 공유하고 있다. SOM 레벨에서 이것을 파악하면 테스트를 효율화할 수 있다.
영향 범위: "이메일 인증 로직이 바뀌면 어떤 시나리오를 재실행해야 하나"를 SOM 연결 관계로 즉시 파악할 수 있다.
시나리오 설계는 테스트를 준비하는 과정이기도 하지만, 동시에 시스템 전체를 점검하는 과정이기도 하다.
다음 이야기 What comes next
시나리오가 설계되고 테스트가 실행되면, 결과를 어떻게 읽어야 하는가. 커버리지 몇 퍼센트, 통과 몇 건 — 이 숫자들을 SOM 기준으로 어떻게 해석하고 관리할 것인가.
다음 화에서는 SOM 기반 품질 지표를 다룬다.