애자일 테스트 수행에서의 수락 기준들 (Acceptance Criteria in Agile Testing)

by | May 15, 2024

애자일이라는 직조물(tapestry)에서, 수락 기준은 황금색 실과 같다. 이것은 사용자 스토리를 최종 형태로 연결한다. 이 기준은 테스터가 테스트 수행 전략을 수립하는데 도움이 된다. 그리고 기능 및 품질 보증을 검증하는 데에도 중요한 임계 값 역할을 한다.

수락 기준은 제공된 제품이 고객의 기대에 부합할 것이라고 약속한다. 고객에게 필요한 사항을 정확히 정의하여, 발생 가능한 오해를 줄이고, 더욱 명료하게 한다. 이렇게 고객의 기대치에 맞춰 조율하는 것은 고객 만족으로 직결된다.

수락 기준을 개발하고 문서화하는 방법

수락 기준을 개발하기 그리고 문서화하기는 애자일 프레임 워크에서 필수다. 또한 공동의 노력이 있어야 가능하다. 수락 기준은 또한 잘 정의된 개요를 설정하여 사용자 스토리가 완료되었다고 생각할 수 있기 위해 필요한 것들을 제시한다.

사용자 스토리와 수락 기준(User Stories and Acceptance Criteria)

사용자 스토리와 수락 기준 문서화는 (애자일 개발 안에서) 서로 밀접하게 관련된 요소다. 사용자 스토리는 요구 사항이나 기능을 위한 서술식 플레이스 홀더 역할을 한다. 수락 기준은 스토리가 완료 상태가 되기 위해 충족되어야 하는 조건에 대해 정의한다.

사용자 스토리(User Stories)

사용자 스토리는 요구되는 기능이나 특성에 대한 짧고 간결한 설명이다. 최종 사용자 관점에서 작성한다. 전형적으로 다음 형식을 따른다 “[사용자 유형]으로서, 나는 [어떤 목표]를 원한다.그래서 [어떤 이유]를 실현하기 위해서다.” 사용자 스토리가 담아 내는 것은 ‘무엇이 완성되어야 하는가’이다. 세부 사항까지 철저하게 들어가지 않는다.

수락 기준(Acceptance Criteria)

이 조건들 또는 요구 사항들은 반드시 충족되어야 한다. 그래야 그 사용자 스토리가 완료된 것으로 간주된다. 이 기준에는 사용자 스토리에 서술된 해당 기능에 대한 경계들과 세부 사항들이 간략히 명시된다. 수락 기준은 특정 스토리에 대한 “완료의 정의”를 규정한다.

사용자 스토리와 수락 기준 사이의 관계를 보자. 수락 기준은 사용자 스토리로부터 파생되고 밀접하게 얽힌다:

  • 사용자 스토리에서 파생됨: 수락 기준은 사용자 스토리에서 뽑아낸다. 그리고 그 사용자 스토리에 직접 연결된다. 이는 그 스토리의 목적 달성을 위해 무엇이 제공되어야 하는지에 대한 세부 사항을 자세히 설명한다.
  • 사용자 스토리에 대한 상세한 설명 및 검증: 수락 기준은 필요한 세부 사항을 제공한다. 그래서 그 사용자 스토리가 잘 정의되어 있고 테스트 가능한 상태인지를 보장한다. 수락 기준은 구현된 기능이 사용자의 기대를 충족하는지 검증하는 데 도움이 된다.
  • 상호 이해: 사용자 스토리와 수락 기준이 둘 다 있으면, 개발 팀, 이해관계자, 고객들 사이에서 서로 이해를 공유할 수 있게 된다. 무엇이 제공되어야 하는지 그리고 그것이 완성되었는지를 어떻게 측정할 것인지에 대해서 말이다.
  • 테스트 가능한 조건들: 수락 기준은 테스트의 작성 기반이 된다. 사용자 스토리가 올바르게 구현되었는지 검증하는 역할을 하기 때문이다. 이 조건들은 구체적인 시나리오를 명시한다. 그 시나리오대로 테스트를 거치고 그 기능이 예상대로 작동하는지 확인한다.

본질적으로 보면, 사용자 스토리는 무대와 맥락을 설정한다. 그래서 달성해야 할 필요가 있는 것들을 담는다. 한편, 수락 기준은 상세한 조건들과 요구 사항들을 제공한다. 그것들은 사용자 스토리에 기술된 목적들을 충족하기 위해 필요한 것들이다.

사용자 스토리와 수락 기준의 예시

실제 시나리오를 생각해보자. 전자상거래 애플리케이션을 예로 들면:

사용자 스토리: 고객으로서, 나는 구매 상태를 확인하고 싶다. 그래서 내 주문을 추적할 수 있기를 바란다.

수락 기준:

  1. 로그인한 경우: 사용자가 로그인하면, “나의 주문” 섹션이 표시되어야 한다. 그것은 네비게이션 바 안에 있어야 한다.
  2. 주문 내역: “나의 주문” 섹션에서, 사용자는 과거 주문 내역을 모두 볼 수 있어야 한다. 여기에는 주문 번호, 날짜, 상태(예: 처리 중, 배송 중, 배송 완료)가 표시되어야 한다.
  3. 주문 세부 정보: 주문을 클릭하면 상세 정보가 표시되어야 한다. 여기에는 구매한 품목, 수량, 가격, 배송 정보가 포함되어야 한다.
  4. 주문 상태 업데이트: 주문 상태는 실시간으로 업데이트 되어야 한다. 예를 들어, 주문의 상태가 ‘처리 중’에서 ‘배송 중’으로 바뀌면, 이 변경 사항은 즉시 반영되어야 한다.
  5. 이메일 알림: 사용자는 주문 상태 변경에 대한 이메일 알림을 받을 수 있어야 한다. 이메일은 변경 상태에 대한 요약을 포함해야 한다. 그리고 링크가 제공되어 세부 정보를 웹사이트에서 볼 수 있어야 한다.

이 시나리오에서, 사용자 스토리는 높은 수준의 요구 사항(주문 추적 기능)을 간략하게 설명한다. 고객의 관점에서 작성한다.

수락 기준은 필요한 구체적인 기능과 동작을 상세히 설명해 준다. 해당 사용자 스토리를 충족시키기 위한 것들이다. 이 기준에는 완성된 기능적인 특성을 구성하는 것이 무엇인가 정의된다. 그리고 개발 및 테스트 수행에 대한 지침을 제공한다.

이 수락 기준은 주문 추적 기능이 고객의 기대를 충족시킨다는 점을 보장한다. 그리고 하나의 명확한 구조를 제시하여 전자상거래 애플리케이션 안에 포함되어야 하는 기능과 그것이 어떻게 동작해야 하는지를 제시한다.

누가 수락 기준을 정의하는가?

수락 기준은 전형적으로 소프트웨어 개발 프로젝트에 속한 여러 역할들이 협업하여 공동으로 정의한다. 수락 기준을 정의하는 데 참여하는 핵심 이해 관계자들은 다음과 같다:

  • 제품 관리자: 제품 관리자가 주도하여 수락 기준을 정의하는 경우가 많다. 왜냐하면 사용자 경험 및 요구 사항, 시장 요구 사항, 그리고 전반적인 제품의 비전을 이해해야 할 책임이 있는 사람들이기 때문이다. 이들은 이해관계자들과 긴밀하게 협력하면서 요구 사항들을 수집한다. 그리고 그 수락 기준이 사용자의 관점과 일치하는지 확인한다.
  • 비즈니스 분석가: 이 전문가들은 사업적 니즈(needs) 이해, 요구 사항 분석, 그것들을 전환하여 실행 가능한 수락 기준 제시에서 중요한 역할을 한다. 이들은 사업 부문의 이해관계자들과 개발 팀 사이의 간극을 좁혀준다.
  • 개발 팀(개발자들과 테스터들): 개발자들과 테스터들은 기술적인 측면과 실현 가능성에 대한 인사이트를 제공하여, 특정 기준을 충족시키도록 한다. 그 중에서도 테스터는, 그 기준이 테스트 가능한지, 검증 가능한지 확인하는 역할을 한다.
  • 이해관계자(들): 다른 이해관계자들 즉 최종 사용자, 고객 담당자 등도 수락 기준을 정의하는 데 기여할 수 있다. 그들은 사용자의 기대와 필요한 사항에 대한 인사이트를 제공한다.

애자일 환경에서는, 이 역할들 간의 협업이 핵심이다. 제품 소유자가 주로 주도적인 역할을 하여 수락 기준의 우선순위를 지정하고 마무리한다. 하지만 팀의 노력도 필요하다. 그래서 그 기준이 종합적이고, 명확하며, 프로젝트 전반의 목표와 일치하는지 확인해야 한다.

수락 기준 개발의 모범 사례

효과적인 수락 기준 개발은 성공적인 소프트웨어 개발을 위해서 매우 중요하다. 그 목표는 기준들의 세트를 만드는 것이다. 그 기준들은 테스트가 가능해야 한다. 또한 지원하고자 하는 사용자 스토리에 직접적으로 연관되어야 한다. 고려해야 할 몇 가지의 모범 사례들은 다음과 같다:

  • 협업하라: 모든 이해관계자를 참여시킨다. 협업을 하면 다양한 관점에서 생각할 수 있다. 그래서 요구 사항에 대해 포괄적으로 이해할 수 있게 된다. 그리고 수락 기준에 대한 주인 의식을 공유할 수 있도록 하고, 오해를 최소화한다.
  • 명확하고, 간결하며, 측정할 수 있는 언어를 사용하라: 명확한 언어는 혼동이나 오해를 피하는데 도움이 된다. 측정할 수 있는 구체적인 기대치를 지정한다. 그러면 객관적으로 검증할 수 있게 된다. 그래서, 모든 사람들이 성공에 대한 공통된 이해를 가지게 된다.
  • 기준을 구체적이고 테스트 가능하게 하라: 구체적인 기준은 모호함을 방지한다. 명확한 지침을 통해 무엇이 제공되어야 하는 지를 제시한다. 테스트 가능한 기준은 검증을 할 수 있도록 해준다. 그래서 그 요구 사항이 객관적으로 증명될 수 있다는 점을 보장한다.
  • 기준을 사용자 스토리 또는 기능에 일치하도록/연결하라: 수락 기준을 사용자 스토리 또 기능에 연결하면, 맥락과 관련성을 이해할 수 있다. 그래서, 각 기준이 직접적으로 어느 특정 기능 또는 사용자의 필요 사항에 연관된 것임을 보장한다.
  • 우선순위 정하라: 수락 기준에 우선순위를 부여하면, 시간과 리소스를 효과적으로 관리하는 데 도움이 된다. 그리고 확실히 필수 기능 또는 필수 요구 사항이 먼저 처리된다는 점을 보장한다.
  • 명확한 표현과 예시 사용하라: 승인 기준을 모호하지 않게 하는 것이 중요하다. 예시나 시나리오를 사용하면 기대하는 바를 명확히 전달할 수 있다. 그러면 오해의 여지가 줄어든다.
  • 정기적으로 수락 기준을 업데이트 하라 (필요에 맞춰라): 수락 기준은 진화한다. 프로젝트가 진행됨에 따라, 혹은 새 정보가 제공됨에 따라 변할 수 있다. 정기적인 검토와 개선은, 그 기준이 프로젝트의 목표 및 이해관계자들의 니즈에 필요와 나란히 유지하고 있다는 점을 보장한다.
  • 기준에 대한 이해관계자들의 동의 여부 확인하라: 수락 기준에 대해 이해관계자들 간의 합의는 매우 중요하다. 그러면 모두가 공통된 이해와 약속을 그 기준에 대해 가질 수 있다. 그렇게 되면 갈등이나 오해가 프로젝트에서 나중에 생길 가능성이 줄어든다.

좋은 수락 기준 예시

수락 기준의 모범 사례들의 예시를 보자:

사용자 스토리: 등록된 사용자로서, 나는 내 비밀번호를 재설정하고 싶다. 그래서 비밀번호를 잊어버린 경우, 내 계정에 다시 접근할 수 있기 위해서다.

수락 기준:

  1. ‘비밀번호 찾기’링크에 접근할 때:
    • 내가 로그인 페이지에 있다면, 내가 ‘비밀번호 찾기’ 링크를 클릭하면, 비밀번호 재설정 페이지로 이동해야 한다.
  2. 비밀번호 재설정을 위해 이메일 입력하기:
    • 내가 비밀번호 재설정 페이지에 있다면, 나는 내 등록된 이메일 주소를 입력하고 제출한다. 그러면 확인 메시지가 나타나 비밀번호 재설정을 위한 이메일이 전송되었음을 알려준다.
  3. 비밀번호 재설정 이메일 수신하기:
    • 내가 비밀번호 재설정을 요청했다면, 내가 내 이메일을 확인했을 때, 비밀번호 재설정 링크가 포함된 이메일이 수신되어 있어야 한다.
  4. 비밀번호 재설정 링크 클릭하기:
    • 내가 비밀번호 재설정 이메일을 수신했다면, 내가 그 이메일 안에 있는 비밀번호 재설정 링크를 클릭했을 때, 나는 새 비밀번호를 입력할 수 있는 페이지로 이동해야 한다.
  5. 새로운 비밀번호 설정하기:
    • 내가 비밀번호 재설정 페이지에 있다면, 내가 새로운 비밀번호를 입력하고 확인했을 때, 성공 메세지가 표시되어야 한다. 그래서 비밀번호가 업데이트 되었음을 알려주어야 한다.
  6. 새로운 비밀번호로 로그인하기:
    • 내가 비밀번호를 재설정했다면, 내가 새 비밀번호를 사용해 로그인을 시도했을 때, 나는 계정에 성공적으로 액세스할 수 있어야 한다.

이 수락 기준들은 모범 사례의 전형적인 예시다. 구체적이고, 테스트 가능하며, 측정할 수 있고, 사용자의 니즈에 맞다. 그리고 포괄적이다. 이 기준들은 비밀번호 재설정 기능이 사용자의 기대를 충족한다는 점 그리고 그 기능이 전체 과정에 있어서 즉, 재설정 요청부터 새 비밀번호로 계정 로그인에 성공하는 것까지 작동한다는 점을 보장한다.

모범 사례를 따르면, 팀이 만드는 수락 기준들은 포괄적이고, 명료하고, 이해관계자들의 기대에 부합하게 된다. 따라서 성공적인 프로젝트의 결과물과 향상된 소통으로 이어진다.

Gherkin 구문(Syntax)

Gherkin은 사람이 읽을 수 있는 언어다. 주로 행동 중심 개발(BDD, Behavior-driven development)에 사용된다. 이것은 구조화된 방식을 제공한다. 그래서 소프트웨어의 동작을 정의하고 문서화할 수 있도록 한다. 그 형식은 기술 및 비기술 이해관계자들 모두가 이해하기 쉽다.

Gherkin은 Given, When, Then, And, But 등의 키워드가 들어가는 구문을 사용한다. 그렇게 시스템의 동작을 서술하면 그 서술들은 Cucumber 또는 SpecFlow와 같은 도구를 통해 자동화된 테스트로 변환될 수 있다.

Gherkin은 흔하게 사용된다. 명확성 그리고 BDD 원칙에 대한 부합 때문이다. 그런데 애자일 팀들은 다른 형식이나 다른 도구를 사용해 수락 기준들을 정의할 수도 있다. 어떤 팀에서 사용하는 것들로는 간단한 사용자 스토리, 상세한 체크리스트, 일반 텍스트 설명, 또는 프로젝트의 필요에 맞춘 특정 템플릿들 등이 있을 수 있다.

결국, 애자일에서, 수락 기준들을 어떻게 문서화하고 정의할 것인가에 대한 선택은, 그 팀의 선호도, 프로젝트의 성격, 사용 가능한 도구, 팀의 기술적 전문성 수준 에 따라 달라진다.

Gherkin에서 수락 기준 작성하기

수락 기준을 Gherkin 형식으로 사용자 인증과 같은 단순한 기능에 대해 작성하는 방법의 예시를 보자.

이 예시 안을 보면:

  • Feature에는 전체 기능이 서술되어 정의된다.
  • Scenarios에는 사용자 로그인과 관련된 구체적인 인스턴스들 또는 동작들이 서술된다.
  • Given, When, Then, And와 같은 키워드들이 사용되어 이 시나리오의 단계의 윤곽을 제시한다. 이것들이 표현하는 것은 설명된 기능에 대한 시작 맥락(initial context), 동(action)들, 예상 결과(expected outcome)들이다.

이 시나리오들이 기여하는 바는 둘 다이다. 즉, 그 기능이 무슨 일을 해야 하는 지에 대한 문서화 그리고 자동화되는 테스트들의 기반이 된다. Gherkin 구문을 이해하는 자동화 테스트 도구들은 이 시나리오를 번역해서 실행 가능한 테스트들을 만든다. 그 테스트들은 애플리케이션이 명시된 대로 작동하는지를 검증한다.

이 시나리오들은 기능이 수행해야 하는 작업에 대한 문서이자 자동화된 테스트의 기초가 될 수 있다. Gherkin 구문을 이해하는 자동화 테스트 도구는 이 시나리오를 실행 가능한 테스트로 변환할 수 있다. 그로 인해 애플리케이션이 지정된 대로 작동하는지 확인할 수 있다.

이것은 수락 기준들을 Gherkin 형식으로 작성하는 하나의 방법에 불과하다. 팀은 이 구조를 조정하거나 확장할 수 있다. 그래서 기능의 복잡성이나 프로젝트의 특정 요구 사항에 맞출 수 있다.

수락 기준 문서화를 위한 도구

몇 가지 도구들은 수락 기준들을 효과적으로 문서화하고 관리하는 데 도움이 된다:

  • Jira: Jira는 널리 사용되는 프로젝트 관리 도구다. 팀이 자신들의 작업을 관리하는 것을 도와준다. 즉, 커스터마이징 가능한 워크플로, 이슈 추적, 실시간 협업을 제공한다. Jira가 협업에 강한 이유는 다음과 같은 능력 때문이다. 프로젝트 정보를 중앙 집중화한다. 그리고 팀 구성원 간의 소통을 촉진한다. 또한 사용자 스토리들과 수락 기준들을 그 플랫폼 안에서 만들 수 있다. 따라서, 작업 항목들의 진행 상황에 대한 명확한 가시성을 팀 구성원들 사이에서 보장한다.
  • Confluence: 종종 Jira와 함께 사용된다. Confluence는 협업 작업 공간 (workspace) 도구다. 즉, 프로젝트 문서를 작성, 정돈, 토론하는 데 사용된다. Confluence는 중앙 집중화 플랫폼으로서 역할을 한다. 그 안에서 팀은 수락 기준, 사용자 스토리, 기타 다른 프로젝트 관련 정보들을 문서화하고 공유다.
  • TestRail: TestRail은 테스트 관리 도구다. 팀이 자신들의 소프트웨어 테스트 노력을 조직, 관리, 추적하는 것을 도와주도록 설계되었다. 이것은 수락 기준 만들기에 직접적으로 관여하지 않는다. 하지만, TestRail을 사용하면, 이슈-추적 도구 안에 있는 수락 기준들에 직접적으로 연결되는 테스트 케이스들을 만들고 관리할 수 있다. 따라서 테스트 커버리지를 쉽게 추적하고 보장한다.
  • Trello: 또 다른 인기 있는 프로젝트 관리 도구다. Trello를 사용하면, 카드(card)를 생성해서 사용자 스토리들과 그것드에 연결된 협업적인 칸반(Kanban)식 보드 안의 관련 수락 기준을 담을 수 있다.

어느 도구를 사용하든지, 그 문서들은 모든 팀 구성원이 접근할 수 있어야 한다. 또한 새로운 통찰(insight)를 획득하거나 절차가 발전해 감에 따라 업데이트 되어야 한다.

수락 기준과 테스트 수행 단계

수락 기준은 소프트웨어 테스트 수행 절차에 대한 지침을 모든 단계마다 제공한다. 다음은 수락 기준과 소프트웨어 개발의 여러 테스트 수행 단계 사이의 관계에 대해 요약한 표다.

테스트 수행 단계수락 기준의 역할
테스트 계획-테스트 계획과 전략 개발의 기반이 된다.
-무엇을 테스트해야 하는지 파악하는 데 도움이 된다.
테스트 설계-테스트 케이스와 시나리오 설계를 위한 참고 자료 역할을 한다.
-각 기준은 테스트 조건이 된다.
테스트 실행-구현된 기능을 검증하기 위한 기반이 된다.
-테스터들은 이 기준들이 충족되는지 실행 중에 확인한다.
결함 리포트-기준 편차들이 문서화 된다. 그러면 결함(defect) 또는 이슈(issue)가 된다.
-예상 동작과 실제 동작 간의 불일치를 포착하는 데 도움이 된다.
검증-소프트웨어가 기대치에 맞는지 검증하는 기준 역할을 수행한다.
-소프트웨어가 고객의 요구 사항을 충족하는지 결정한다.
회귀 테스트 수행-회귀 테스트에 지침을 제공한다. 그래서 새 변경의 영향이 충족된 기준들에 미치지 않도록 보장한다.
-기준들은 재 검증이 필요한 영역을 파악하는 데 도움이 된다.

테스트 케이스 생성과 수락 기준

테스트 케이스 개발은 수락 기준들에 크게 의존한다. 그 기준들은 필요한 지침, 구조, 세부 사항을 제공하기 때문이다. 테스터는 그것들을 사용해 테스트 케이스를 설계, 실행, 검증한다. 그래서 그 소프트웨어가 예상 수준과 및 요구 사항을 충족하도록 보장한다.

테스트 케이스의 개발은 수락 기준에 크게 의존한다. 테스터가 테스트 케이스를 설계, 실행, 검증하는 데 필요한 지침, 구조 및 세부 사항을 제공하여 소프트웨어가 예상 표준 및 요구 사항을 충족하는지 확인하기 때문이다.

예시 하나를 살펴보자:

수락 기준:

전자상거래 플랫폼의 결제 기능에 대한 수락 기준은 다음과 같을 수 있다:

  1. 사용자는 장바구니에 품목을 추가할 수 있어야 한다.
  2. 사용자는 장바구니에서 결제를 진행할 수 있어야 한다.
  3. 결제가 진행되는 중에, 사용자는 배송 정보와 결제 정보를 입력해야 한다.
  4. 사용자는 결제 방법을 선택할 수 있어야 한다.
  5. 결제가 성공적으로 완료되면, 사용자는 주문 확인서를 받아야 한다.

테스트 케이스의 개발:

이 수락 기준들을 사용해, 테스트 케이스들이 설계되어 결제 과정의 기능을 검증하게 된다:

  1. 테스트 케이스 1: 장바구니에 품목 추가하기
    • 단계(step): 제품 페이지로 간다 > 장바구니에 품목을 추가한다
    • 예상 결과: 그 품목이 카트에 추가된다.
  2. 테스트 케이스 2: 장바구니에서 결제 진행하기
    • 단계(step): 장바구니에서 ‘결제 진행’을 클릭한다.
    • 예상 결과: 사용자는 결제 페이지로 이동한다.
  3. 테스트 케이스 3: 배송 정보와 결제 정보를 입력하기
    • 단계(step): 배송 및 결제 상세 정보를 입력한다.
    • 예상 결과: 정보가 성공적으로 입력되고 저장된다.
  4. 테스트 케이스 4: 결제 방법 선택하기
    • 단계(step): 결제 방법을 선택한다. (예: 신용카드, 페이팔)
    • 예상 결과: 오류 없이 결제 방법이 선택된다.
  5. 테스트 케이스 5: 주문 확인
    • 단계(step): 결제를 완료다.
    • 예상 결과: 사용자는 주문 확인 메시지 또는 이메일을 받는다.

이 시나리오에서, 수락 기준들은 결제 과정에서 예상되는 높은 수준의 요구 사항과 기능을 정의한다. 테스트 케이스는 이 기준으로 부터 파생된다. 그리고 구체적인 단계와 예상 결과를 간략하게 명시한다. 그래서 해당 기준의 각 측면을 검증한다.

각 테스트 케이스는 특정 기준 하나와 나란히 맞춰진다. 그래서 그 시스템이 기준들 안에 명시된 대로 동작하는지 확인한다. 이 테스트 케이스들을 실행하면, 구현된 결제 기능이 수락 기준에 명시된 사용자의 기대를 충족시키는지를 검증할 수 있다. 테스트 수행 중에 발견된 모든 불일치는 기록되어 결함(defect)이 된다. 거기에서부터, 피드백 루프가 시작된다. 그래서 정의된 기준에 그 소프트웨어가 맞도록 결함을 해소하게 된다.

각 테스트 케이스는 특정 기준을 충족시키며, 시스템이 기준에 명시된 대로 작동하는지 확인한다. 이 테스트 케이스들을 실행하여, 구현된 결제 기능이 수락 기준에 명시된 사용자의 기대를 충족시키는지 확인한다. 테스트 수행 중에 발견된 모든 불일치는 결함으로 기록된다. 그런 다음 소프트웨어를 정의된 기준에 맞게 조정해서 해결하기 위한 피드백 루프가 시작된다.

수락 기준을 검증하고 확인하는 방법

수락 기준들은 개발 절차가 사용자의 요구 사항을 충족하도록 보장한다. 그런데 기준이 잘못 정의된 경우에는 어떻게 해야 할까?

수락 기준들 안에서 불분명한 부분 찾아내

수락 기준이 불분명하면, 개발된 기능이 사용자의 필요를 충족하지 못할 수 있다. 이는 개발 기간의 연장, 납기의 지연, 소프트웨어가 고객을 만족시키지 못하는 결과로 이어질 수 있다.

예를 들어, 온라인 결제 시스템을 위한 수락 기준이 제대로 정의되지 않은 경우는 다음과 같다: “고객은 온라인으로 결제할 수 있어야 한다.”

이 문장은 반드시 보다 자세한 정보를 담고 있어야 한다. 즉 진행 단계들, 결과들, 제공 시점 등이 포함되어야 한다.

반면에, 잘 정의된 수락 기준의 경우는 다음과 같다: “고객이 구매할 상품을 선택하고 유효한 결제 정보를 입력했다면, 고객은 확정되었다는 메시지와 이메일 영수증을 받아야 한다. 그 시점은 구매가 확정되는 즉시다.”

명확성 및 완전성 보장하기

애자일 소프트웨어 개발에서, INVEST(Independent Negotiable Valuable Estimable Small Testable)기준은 잘 정리된 사용자 스토리를 평가하고 만드는 지침이다. 주로 사용자 스토리에 사용된다. 그런데, 이 기준은 수락 기준들이 과연 효과적인지 보장하기 위해 평가하고 검증하는 데에도 적용할 수 있다. INVEST 방식을 적용하는 방법은 다음과 같다:

  • Independent(독립적인): 기준은 독립적으로 존재해야 한다.
  • Negotiable(협상 가능한): 기준에 대한 논의와 조정이 가능해야 한다.
  • Valuable(가치 있는): 기준은 의미 있는 가치를 전달해야 한다.
  • Estimable(예측 가능한): 기준을 완료하기 위한 예상 활동들이 명확하고 현실적이어야 한다.
  • Small(작은): 기준은 구체적이고 관리하기 쉬워야 한다.
  • Testable(테스트 가능한): 기준은 테스트 수행을 통해 검증될 수 있어야 한다.

전자상거래 웹사이트를 위한 기능을 여러분이 개발하고 있다고 가정해 보자. 장바구니 안에 있는 품목들의 총 가격을 계산하고 표시하는 것과 관련해 아래 기능을 보자.

  • Independent(독립적인): 총 가격에 대한 수락 기준들은 다른 모듈에 의존하지 않아야 한다. 예를 들어, 이 기능이 배송 모듈에 의존하면 안 된다.
  • Negotiable(협상 가능한): 이 기준에 대해서 항상 논의 및 조정이 가능해야 한다. 가격 정책이 변경되면, 기준을 조정해야 할 수도 있다.
  • Valuable(가치 있는): 이 예시는 정확한 총 가격이 최종 사용자인 고객에게 매우 중요하므로 “Valuable(가치 있는)”에 해당된다.
  • Estimable(예측 가능한): 팀은 얼마나 많은 활동이 들어가야 총 가격을 정확하고 현실적으로 계산할 수 있는지 예측할 수 있어야 한다.
  • Small(작은): 기준은 가능한 한 구체적이어야 한다. 그리고 한 가지 특정 행동에 집중해야 한다. 예를 들면, 세금 및 할인이 반영해 총액 계산하기를 들 수 있다.
  • Testable(테스트 가능한): 기준은 테스트가 가능해야 한다. 그래서 최종 사용자가 지불할 총 가격이 항상 올바르게 계산된다고 보장해야 한다.

INVEST 방법을 적용하면, 팀이 애자일 원칙을 지키는 데 도움이 된다. ‘기준이 명확하고, 관리 가능하며, 고객에게 가치를 전달한다’는 원칙 말이다.

결론

수락 기준들은 애자일 팀에 필수적이다. 정밀하고 공유되는 정의를 통해 완료된 작업의 요건을 제공하기 때문이다. 그러면 명확성을 팀 구성원들과 이해관계자들 사이에서 보장한다. 또한 수락 기준들은 노력을 집중할 수 있도록 해준다. 우선 순위의 윤곽을 잡아주고 보다 가치 있는 기능 방향으로 개발을 유도하기 때문이다.

결정적으로, 이 기준들은 테스트 수행과 검증의 기반이 된다. 따라서 그 제품이 제공하는 것들이 명시된 요구 사항을 충족하도록 보장한다.

모두가 공감하는 이해 그리고 명확하게 정의된 “완료”를 촉진함으로써, 수락 기준들은 점진적인 개발, 지속적인 개선, 효과적인 협업이 애자일 팀 내에서 가능하도록 환경을 조성한다.

신뢰할 수 있는 테스트 관리 도구를 찾아보자. TestRail과 같은 도구를 사용하면 여러분의 수락 기준들에 대한 절차가 간소화 될 수 있다. TestRail의 14일 무료 평가판을 통해 자세히 알아보자!

(원문: Hannah Son | December 22nd, 2023 | Acceptance Criteria in Agile Testing)

다른 기고들

소프트웨어 개발사 ELEKS는 어떻게 가시성과 생산성을 높였을까: Jira와 TestRail을 통합한 사례 연구

게스트의 글입니다. (작성자: Ostap Elyashevskyy) QA 절차를 처음부터 구축하거나 기존 QA 절차를 개선하는 경우, 올바른 테스트 관리 도구 선택은 매우 중요하다. 그것은 여러분이 버그를 찾고, 테스트 케이스를 관리하는 것을 도와준다. 또한 궁극적으로는, 소프트웨어 개발 절차를 잘 다듬을 수 있도록 돕는다. 이 글에서 나는 ELEKS의 우리 팀에게 효과적인 테스트 관리 솔루션을 찾은 경험을 공유하고자 한다. 그리고 그 과정에서 평가한 다른 몇 가지 대안들...

테스트 관리를 위한 Jira: 선택, 과제, 그리고 솔루션

여러분의 팀이 소프트웨어 개발 관리를 위해 Jira를 사용하고 있다면, 테스트 수행 및 QA 절차를 Jira와 통합하는 것은 필수적이다. 일반적으로 두 가지 기본 선택권이 있다: Jira를 직접 활용하여 테스트 수행 작업을 모니터링한다. (주로 개발 이슈와 관련된 하위 작업 또는 사용자 정의 이슈 유형을 통해) Jira 기반 테스트 관리 애드-온을 사용한다. (무료일 수도, 유료일 수 있다.) 테스트 관리를 위해 Jira 사용하기 Jira는 애초에 소프트웨어 테스트 수행을...

애자일 테스트 수행 방법론: 수명 주기, 기법, 전략

애자일에서는 개발과 테스트 수행이 동시에 진행된다. 그로 인해 개발 파이프라인이 간소화 된다. 이는 효율적이고 정확한 소프트웨어 출시를 보장하기 위한 것이다. 애자일 개발에서는 프로젝트를 스프린트로 세분화한다. 이와 비슷하게, 애자일 테스트 수행에서는, 대규모 기능 개발을 더 작고 관리하기 쉬운 스프린트 기반 프로젝트와 제품으로 세분화 한다. 애자일 테스트 수행의 원칙은 무엇인가? 애자일 프레임워크에서 테스트 수행을 할 때, 절차의 지침이 되는 몇 가지 원칙이 있다: 테스트...