답변.

이 문제의 역사

수용 기준은 작업(릴리스, 작업, 테스트 케이스)이 완료되었다고 간주되기 위해 충족되어야 할 요구 사항 집합입니다. 수동 테스트에서 명확하게 정의된 조건은 오류, 오해 및 "숨겨진" 미비점을 피하는 데 도움을 줍니다.

문제

투명한 기준이 없으면 "준비 상태"에 대한 다양한 해석이 발생합니다: 개발자는 작업이 완료되었다고 생각하고, 테스터는 대다수는 그렇지 않다며, 고객은 비즈니스 논리에 부합하길 기다리고 있습니다.

해결책

측정 가능하고 이해하기 쉬우며 일관되지 않은 기준을 설정합니다(예: "버튼이 작동함", "페이지 새로 고침 시 데이터가 저장됨", "유효성 검사 오류가 발생하지 않음"). 고객, 테스터 및 개발자 간에 DoD를 조율하고 요구 사항 변화를 반영하며 각 stories/issues의 기준 준수를 기록하는 것이 중요합니다.

주요 특징:

해석의 차이와 불필요한 기대를 피하도록 합니다.
수동 테스트를 위한 체크리스트를 만듭니다.
중요한 사항에 집중하도록 도와줍니다.

함정 질문.

작업을 종료하기 위해 모든 기준을 반드시 충족해야 합니까?

네, 그것이 DoD의 본질입니다 — 작업은 모든 기준이 충족되어야만 완료된 것으로 간주됩니다.

테스트 또는 릴리스 과정에서 DoD를 변경할 수 있습니까?

네, 요구 사항이 변경되거나 새로운 세부 사항이 나타난 경우, 그러나 모든 팀원이, 특히 테스터가 반드시 알아야 합니다.

DoD를 결정해야 하는 사람은 누구입니까?

전체 팀이 함께 — 테스터, 개발자, 비즈니스 분석가 및 고객의 대표가 참여합니다.

일반적인 오류 및 안티 패턴

"기능이 작동합니다"와 같은 모호하고 불명확한 표현.
현장에서 기준 변경을 고정하지 않음.
릴리스 또는 수용 시 DoD를 무시함.

실생활 예시

부정적 사례

형식화된 기준 없이 작업이 수락됨: 동료는 모든 것이 작동한다고 생각했습니다. 고객이 하루 후에 "숨겨진" 버그를 발견합니다. 테스터는 버그가 작업에 관련되지 않았다고 주장합니다.

장점:

작업을 빠르게 종료함

단점:

중요한 결함 누락
고객과의 갈등 상황

긍정적 사례

테스트하기 전에 구체적인 기준이 형성되고, 수동으로 각 작업을 수행한 후 완료 여부를 기록합니다. 모든 변경 사항은 기록되고 팀과 조율됩니다.