1. Question
User Story
As an Editor I want to review content before it is published so that I can ensure the grammar is correct
Acceptance Criteria (AC):
- The user can log in to the content management system with "Editor" role
- The editor can view existing content pages
- The editor can edit the page content
- The editor can add markup comments
- The editor can save changes
- The editor can reassign to the "content owner" role to make updates
Question: Which of the following is the BEST example of an ATDD test for this user story?
- a) Test if the editor can save the document after edit the page content
- b) Test if the content owner can log in and make updates to the content
- c) Test if the editor can schedule the edited content for publication
- d) Test if the editor can reassign to another editor to make updates
✅ Correct Answer: a)
2. ATDD란 무엇인가? (EN/KR)
ATDD (Acceptance Test–Driven Development) is an agile practice where acceptance tests are derived directly from acceptance criteria and user stories. These tests represent how the system should behave to satisfy the story.
ATDD는 인수 기준(Acceptance Criteria)과 사용자 스토리로부터 직접 테스트를 도출하는 애자일 실천 방법입니다. 즉, “이 스토리가 완료되었다고 인정(accept)하려면 어떤 테스트를 통과해야 하는가?”를 구체적으로 정의하는 것이 ATDD 테스트입니다.
3. Acceptance Criteria 다시 보기
AC에서 중요한 키 포인트를 뽑으면:
- Editor 역할로 로그인 가능
- 기존 콘텐츠 페이지 조회 가능
- 페이지 내용 편집 가능
- 마크업 코멘트 추가 가능
- 변경 사항 저장 가능
- “content owner” 역할에게 재할당 가능
즉, ATDD 테스트는 위의 “에디터가 할 수 있어야 하는 행동들”을 직접 검증하는 시나리오여야 합니다.
4. Option 분석 (EN/KR)
a) Test if the editor can save the document after edit the page content
✔ Correct.
This test directly reflects two acceptance criteria:
- “The editor can edit the page content”
- “The editor can save changes”
So it is a clear example of an ATDD test aligned with the given AC.
이 테스트는 다음 두 인수 기준을 동시에 커버합니다.
- 에디터는 페이지 내용을 편집할 수 있다.
- 에디터는 변경 사항을 저장할 수 있다.
즉, 사용자 스토리의 AC와 직접 연결된 전형적인 ATDD 테스트라고 볼 수 있습니다.
b) Test if the content owner can log in and make updates to the content
❌ Not correct.
The user story and AC are focused on the Editor role, not on the content owner performing updates.
이 스토리는 “Editor” 관점의 스토리입니다. AC도 모두 에디터 역할에 대한 내용이며, content owner가 직접 수정하는 시나리오는 이 스토리의 범위를 벗어납니다.
c) Test if the editor can schedule the edited content for publication
❌ Not correct.
Scheduling for publication is not mentioned in any of the acceptance criteria.
“발행 예약(scheduling)” 기능은 주어진 인수 기준 어디에도 없습니다. 좋은 기능일 수는 있지만, 이 스토리의 AC와는 연결되지 않습니다.
d) Test if the editor can reassign to another editor to make updates
❌ Not correct.
The acceptance criteria explicitly mention reassigning to the “content owner” role, not to another editor.
AC에는 “에디터가 content owner 역할에게 재할당할 수 있다”고 되어 있습니다. 다른 에디터에게 재할당하는 시나리오는 AC와 일치하지 않습니다.
5. Why a) Is the BEST ATDD Test
- Directly tied to given acceptance criteria
- Verifies a realistic and valuable user workflow
- Covers multiple AC in a single test (edit + save)
- Is clearly testable and outcome-based
ATDD 테스트는 “스토리가 완료되었는지”를 보여주는 대표 시나리오여야 합니다. 옵션 a)는 에디터가 내용을 편집하고, 그 내용을 저장할 수 있는지 검증하므로 이 스토리의 핵심 가치를 직접 확인할 수 있는 가장 좋은 예입니다.
6. Summary
- ATDD tests are derived directly from acceptance criteria and user stories
- The best test must align tightly with the given AC
- Here, option a) tests “edit + save”, matching two AC items
- Therefore, the BEST ATDD example is: a)
ATDD에서는 “사용자 스토리 + 인수 기준”과 직접 연결된 테스트를 설계해야 하며, 이 문제에서는 a)가 그 요구를 가장 잘 만족합니다. FL-4.5.3
Related: More ISTQB Posts