ATDD(Acceptance Test Driven Development)

이동한·2020년 11월 2일

TDD atdd

Software QA

목록 보기

3/5

(그림 출처) 맨땅에 코딩 https://boorownie.github.io/2019-11-27/agail_and_atdd

이 글은 제가 ATDD에 대해서 학습하는 내용을 정리하려고 작성한 글이므로 참고만 부탁드립니다. 상세한 내용은 ATDD에 관련된 서적 혹은 공식 문서들이 정확할 것입니다.

TDD(Test Driven Development)

혹시 TDD(Test Driven Development)를 아시는지요? TDD를 아신다면 Skip하시면 됩니다.

TDD에 대해서 모르시는 분을 위해서 간략하게 TDD를 설명드리겠습니다. TDD를 먼저 설명드리는 것이 ATDD를 이해하시는데에 도움이 됩니다.

다음 그림은 TDD cycle을 나타낸 그림입니다.

(출처: https://www.thinktocode.com/2018/02/05/what-is-tdd/)

TDD는 다음의 세단계를 반복하면서 개발 합니다.

테스트를 먼저 작성하고 결과가 fail인 것을 확인.
작성한 테스트를 통과할 정도 만큼의 코드를 작성
동작(behavior)를 변경하지 않고 코드를 개선

TDD는 단위 테스트를 개발자가 먼저 구현하고 자신의 코드를 개발해나가는 개발방법론입니다.

ATDD(Acceptance Test Driven Development)란?

(그림 출처) 맨땅에 코딩 https://boorownie.github.io/2019-11-27/agail_and_atdd

ATDD를 가장 쉽게 설명하는 그림을 찾아 보다가 가장 적절한 그림을 Boorownie님의 github 블로그에서 가져왔습니다.

ATDD는 다음과 정의할 수 있습니다.

개발 이전에 사용자, 테스터 및 개발자가 인수조건(Acceptance Creteria)을 정의하는 협업 실천법.
모든 프로젝트 구성원이 수행해야 할 작업과 요구사항을 정확히 이해할수 있도록 도와줌
테스트는 비지니스 도메인 용어로 기술됩니다.
인수 테스트(Acceptance Test)의 요구사항을 작성하는 데에 집중(인수테스트 주도 개발)

위키피디아의 정의는 다음과 같습니다.

Acceptance test–driven development (ATDD) is a development methodology based on communication between the business customers, the developers, and the testers. ATDD encompasses many of the same practices as specification by example (SBE),behavior-driven development (BDD), example-driven development (EDD), and support-driven development also called story test–driven development (SDD). All these processes aid developers and testers in understanding the customer's needs prior to implementation and allow customers to be able to converse in their own domain language.
ATDD is closely related to test-driven development (TDD). It differs by the emphasis on developer-tester-business customer collaboration. ATDD encompasses acceptance testing, but highlights writing acceptance tests before developers begin coding.

ATDD는 인수 테스트를 먼저 작성한 다음 기능 개발을 하는 개발방법론입니다. 인수 테스트는 고객이 만들어진 소프트웨어를 실제로 사용하기 전에 테스트 하는 것을 말합니다.

맨 위에 있는 ATDD Cycle을 정리한 그림에 대해서 설명을 하는 것으로 ATDD에 대해서 알아보겠습니다.
4가지 ACTION(Discuss, Distill, Develop, Demo)과 4가지 산출물(User Story, Accpetance Cretieria, Tests, Working software), 하나의 결과(Business Value)로 표현되고 있습니다.

User Story

User Story는 who, why, what을 기준으로 작성합니다.
결과물: User Story

Discuss

User Story를 바탕으로 인수 조건을 작성합니다. 인수조건은 사용자의 단어로 작성되어야 합니다.
인수 조건은 기능 완료 조건으로서 사용자 스토리 보다 조금 더 구체적인 시나리오를 통해 기술합니다.
결과물: 인수 조건

Distill

도출된 인수 조건을 통해 인수 테스트를 작성합니다.
인수 테스트는 사용자의 관점을 나타내며 시스템 작동 방식을 설명하기 위한 요구 사항의 형태로 작동하며 시스템이 의도한 작동하는지 확인하는 방법으로도 사용됩니다.
테스트는 Given-When-Then 형식으로 작성을 하되 해당사항이 없는 부분은 생략할 수 있습니다.
성공 케이스와 실패 케이스를 정의하고 요청/응답에 대한 DTO(Data Transfer Object)를 결정합니다.
인수 테스트 작성의 기준은 팀에서 정합니다.
결과물: 인수 테스트

Develop

문서화
- 벡엔드와 프론트의 작업을 병렬로 진행할 수 있도록 도움을 줍니다.
- 문서화 할 기능의 기준은 팀에서 정합니다. (ex. 사이드 케이스 / 실패 케이스에 대해서는 내부항목으로 기재한다.)
TDD로 개발하기
- 인수 테스트 기반으로 하나씩 기능개발을 진행합니다.
- TDD 프로세스에 따라 테스트를 먼저 작성하고 프로덕션 코드를 작성합니다.
결과물: 소프트웨어 결과물

Demo

인수 테스트가 성공이 되면 해당 이슈는 완료합니다.
완료된 인수 테스트 수에 따라서 개발 진행 상황을 인지할 수 있습니다.

TDD, BDD, ATDD 비교

TDD(Test Driven Development), BDD(Behavioral Deiven Development), ATDD(Acceptance Deiven Development)를 비교하는 것이 이해를 가장 돕는 좋은 방법 같아서 다음의 자료를 찾았습니다.

TDD	BDD	ATDD
TDD focuses on the implementation of a feature	BDD focuses on the system's behavior	ATDD focuses on capturing the accurate requirements
Mainly developers involve in this to write Unit Tests	Developers, QAs and Customers involve in this process	Developers, QAs and Customers involve in this process
Written in a programming language like Python, Java etc.	Written in simple plain English, Gherkin	Written in simple plain English, Gherkin
These tests are technical. Not easy for non technical person to understand this	It is easy for non technical person to understand this	It is easy for non technical person to understand this
Focus is to write Unit Tests	Focus is to understanding requirements	Focus is to write Acceptance Tests
Tools used in TDD are JDave, Cucumber, JBehave, Spec Flow, BeanSpec, Gherkin Concordian, FitNesse, Junit, TestNG, NUnit frameworks, Selenium tool (any open source tools)	Tools used in Gherkin, Dave, Cucumber, RSpec, Behat, Lettuce, JBehave, Specflow, BeanSpec, Concordian, MSpec, Cucumber with Selenium / Serenity	Tools used in TestNG, FitNesse, EasyB, Spectacular, Concordian, Thucydides, Robot Framework, FIT

출처 : TDD vs BDD vs ATDD: Key Differences
https://www.softwaretestingmaterial.com/tdd-vs-bdd-vs-atdd/

위에 표에 나온 용어들을 찾아서 아래에 정리하였습니다. 용어를 모르시면 오이, 피클등으로 해석하실 것 같아서 찾아 놓았습니다.

Cucumber : Cucumber is tool that supports Behaviour-Driven Development(BDD)

Gherkin : Gherkin is set of grammer rules that makes plan text structred enough Cucumber to understand. The senario above is wriiten in Gherkin.

Cucumber Introduction : https://cucumber.io/docs/guides/overview/

Cucumber 한글시나리오 작성 : https://velog.io/@clarekang/cucumber-kr-introduce

Level of Testing

(그림 출처: https://github.com/msbaek/atdd-example)

테스트의 레벨을 그려서 이해하기 쉽게 하려고 만든 그림입니다.

설명하자면 다음과 같습니다.

삼각형 피라미드의 맨 아래는 Unit Test 입니다.
Unit들을 Integration(통합) Test 해보는 입니다.
개발된 전체 내용을 실제 고객(사용자)가 테스트트 해보는 것이 Acceptance Test입니다.
삼각형 아래의 붉은색 선으로 표시된 Coverage 내용은 각 테스트가 Cover하는 크기를 뜻하는 것입니다. Unit Test가 가장 넓고 Accpetance Test가 가장 좁다는 것을 표현하였습니다. 이 표현에 대해서는 논란의 여지가 있기는 합니다. Coverage의 기준이 개발된 코드의 각 행을 테스트하는 것을 의미한다면 이 표현이 맞습니다. 하지만 사용자가 어떤 방식으로 해당 소프트웨어를 사용할지 아니면 어떤 환경에서 소프트웨어가 사용될지를 고려한다면 해당 표현이 딱 맞는 정의는 아닙니다.
삼각형의 왼쪽 양방향 화살표 선은 어느 쪽 테스트가 더 통합되어 있느냐를 표현하고 있습니다. Unit Test는 분리되어 있고 단단합니다. 다른 것에 영향을 받지 않는 편입니다. 반대로 Accpetance Test는 통합테스트이므로 부서지기 쉽습니다. 다른 변화에 영향을 많이 받는 테스트입니다.
삼각형의 오른쪽 양방향 화살표는 테스트를 수행하는 속도에 대해서 정리한 것 같습니다. Unit Test의 수행속도는 빠르며 자동화가 상대적으로 매우 쉽습니다. TDD의 경우 Unit Test code를 먼저 개발하고 개발하게 되어 있으므로 개발이 완료된 경우에는 Unit Test는 모두 완료되어 있고 신속하게 확인이 가능합니다. 반대로 Accpetance Test의 경우에는 상대적으로 복잡한 비지니스 요구사항을 모두 만족시키는지 확인하는 목적의 테스트이므로 수행 속도는 상대적으로 느릴 수 밖에 없습니다.

결론

ATDD는 개발조직과 실제 사용자가 같이 협업을 하면서 전체 개발과정을 진행할수 있다면 매우 매력적인 개발방법론으로 생각합니다.

TDD는 개발 문화상에서 녹여낸다면 충분히 수행이 가능하지만 ATDD는 사용자(고객), QA, 기획자, 개발자 등 모든 관련된 사람이 같이 협업을 해야 하는 개발방법론인 것으로 생각됩니다. 하지만 ATDD를 잘 적용하고 같이 협업한다면 MVP(Minimum Viable Product)를 정말 잘 만들어나갈 수 있는 가장 좋은 개발방법론 같습니다.

좋은 도구가 모든 일을 해주지는 않지만 좋은 도구를 가지고 일을 한다면 더 일을 잘할 수 있는 것은 당연하지 않을까요? 도전해볼만한 개발방법론입니다.

다시 한번 말씀 드리지만, 위에서도 제가 말씀 드렸지만 ATDD를 공부하기 위해서 각종 자료를 찾아보고 공부한 내용을 정리한 자료입니다. 아무래도 제가 가지고 있는 배경지식을 기반으로 정리한 자료임으로 이 글을 읽으시는 분들에게 충분한 자료가 될지는 모르겠습니다.

제가 찾아보고 공부했던 자료를 모두 아래에 참고자료에 정리해 놓았으니 한번 읽어보기를 부탁드리겠습니다.