1. Introduction
In Agile testing, the quality of a user story is measured by how clearly it can be turned into Acceptance Criteria (AC) and later into test cases. This flow ensures shared understanding and enables ATDD/BDD practices.
애자일 환경에서는 사용자 스토리가 인수 기준(Acceptance Criteria)으로 명확히 확장되고, 그 AC가 다시 테스트 케이스로 전환되어야 합니다. 이 흐름(User Story → AC → TC)은 ATDD·BDD 실무의 핵심입니다.
2. Structure Overview
| Step | Description | 한국어 설명 |
|---|---|---|
| User Story | High-level requirement written in user–goal–benefit format | 사용자의 목표와 이득을 담은 고수준 요구사항 |
| Acceptance Criteria | Conditions that must be true for the story to be accepted | 스토리 완성을 판단하기 위한 필수 조건 |
| Test Cases | Concrete test scenarios that verify AC | AC를 검증하는 구체적인 테스트 시나리오 |
3. Example User Story
As a registered customer, I want to view my previous orders, so that I can keep track of my purchases.
예) 등록된 고객으로서 지난 주문 내역을 조회하고 싶다. 그래서 구매 이력을 관리할 수 있다.
4. Step-by-Step Mapping
4.1 Derived Acceptance Criteria
Good Acceptance Criteria must be:
- Specific
- Testable
- Unambiguous
- Independent
좋은 AC 조건: 구체적, 테스트 가능, 명확, 독립적
AC Example
- The customer can log in to the system.
- The customer can open the order history page.
- The system displays all past orders with date, order number, and total cost.
- The customer can click an order to view detailed items.
- The customer can sort order history by date and order number.
위 AC는 사용자 스토리의 목적(“지난 주문 보기”)을 명확하게 지원합니다.
4.2 Converting AC → Test Cases
Each Acceptance Criterion should generate one or more **test cases** to fully verify expected behavior—including positive, negative, and edge scenarios.
각 AC는 최소 1개의 테스트 케이스를 생성하며 필요하면 긍정·부정·경계 시나리오로 확장됩니다.
TC Examples
| AC | Test Case | 설명 |
|---|---|---|
| 1. User can log in | TC1: Login with valid credentials → Success | 정상 로그인 |
| 2. Can open order history | TC2: After login, click “Order History” → Page loads | 주문 내역 페이지 로딩 |
| 3. System displays full order list | TC3: Verify order list contains date/number/total | 목록 필드 검증 |
| 4. View order details | TC4: Click an order → Show items/price/qty | 주문 상세 보기 |
| 5. Sorting supported | TC5: Click “Sort Asc” → List sorted correctly | 정렬 기능 검증 |
5. Mapping Diagram
User Story → AC → Test Case Flow
User Story
↓
Acceptance Criteria (AC1 ~ AC5)
↓
Test Cases (TC1 ~ TC5+)
스토리는 AC로 분해되고, AC는 테스트 케이스로 확장됩니다.
6. Full Example in Gherkin (ATDD/BDD Style)
This can be used directly in ATDD or BDD frameworks.
Scenario: View full order history Given the customer is logged in When the customer opens the "Order History" page Then the system displays all past orders with date, number, and total cost
위 시나리오는 ATDD/BDD에서 그대로 사용할 수 있는 Given/When/Then 형식의 인수 테스트입니다.
7. Best Practices
- Write user stories at a business-value level, not UI-level
- Acceptance criteria should be testable and unambiguous
- Each AC should map to one or more concrete test cases
- Use Gherkin for scenario-oriented AC
- Use examples to clarify complex conditions (Example Mapping)
✓ 스토리는 “비즈니스 가치” 중심
✓ AC는 “테스트 가능”하게
✓ AC 1개 → 테스트 케이스 1개 이상
✓ 복잡한 로직은 Example Mapping 활용 (Given/When/Then과 조합)
8. Summary
- User Story defines the business goal
- Acceptance Criteria define conditions for completion
- Test Cases verify each AC through executable scenarios
- This mapping ensures high clarity and testability in Agile teams
이 흐름(User Story → AC → Test Case)은 애자일 팀에서 품질과 정렬된 이해를 보장하는 핵심 절차입니다.
Related: More ISTQB Posts