모두가 같은 목표를 향해 달리는 법, 인수 테스트 주도 개발(ATDD)

개발이 모두 끝난 후, 기획자가 완성된 기능을 보고 말합니다.

목차 숨기기

“아, 제가 생각했던 기능은 이게 아닌데요.”

이런 비극적인 상황은 왜 발생할까요?

팀원 모두가 ‘완성’의 기준에 대해 서로 다른 그림을 그리고 있었기 때문입니다.

개발을 시작하기 ‘전’에, 팀 전체가 ‘완성’의 기준을 함께 정의하고 합의하는 개발 방법론.

이것이 바로 ‘ATDD(Acceptance Test-Driven Development, 인수 테스트 주도 개발)’입니다.

‘ATDD’는 실제 제품 코드를 작성하기 전에, 그 기능이 통과해야 할 ‘인수 테스트(Acceptance Test)’를 먼저 상세하게 정의하는 협업 개발 방법론입니다.

여기서 가장 중요한 점이 있습니다.

이 ‘인수 테스트’를 개발자나 QA 혼자 만드는 것이 아닙니다.

‘고객(또는 PO/기획자)’, ‘개발자’, ‘QA’ 세 그룹의 전문가(Three Amigos)가 함께 모여, 대화를 통해 인수 테스트를 만들고 합의하는 과정을 거칩니다.

‘ATDD’는 보통 다음과 같은 워크숍 형태로 진행됩니다.

1. 논의 (Discuss):
- 기획자, 개발자, QA가 한자리에 모여, 개발할 사용자 스토리에 대해 함께 논의합니다.
- QA와 개발자는 기획자에게 수많은 질문을 던지며, 요구사항의 모호한 부분을 명확하게 만듭니다.
2. 구체화 (Distill):
- 논의한 내용을 바탕으로, 구체적인 예시와 함께 ‘인수 테스트’ 시나리오를 만듭니다.
- 이 테스트는 누구나 이해할 수 있는 자연어 형태(Gherkin 문법 등)로 작성되는 경우가 많습니다.
3. 개발 (Develop):
- 이제 개발자는 이 ‘인수 테스트’를 통과시키는 것을 유일한 목표로 삼아 제품 코드를 개발합니다. (이 과정에서 TDD 방식을 사용할 수도 있습니다.)
- 동시에 QA는 이 시나리오를 자동화 테스트 코드로 만들 준비를 합니다.
4. 시연 (Demo):
- 개발이 완료되면, 처음에 작성했던 ‘인수 테스트’가 성공하는 것을 팀원 모두가 함께 확인합니다.
- 이는 기능이 우리 팀이 합의한 대로 정확히 만들어졌음을 증명하는, 가장 확실한 과정입니다.

세 가지는 비슷해 보이지만, ‘초점’과 ‘참여자’에서 차이가 있습니다.

‘ATDD’는 QA의 역할을 개발 프로세스의 핵심으로 끌어올리는 강력한 힘을 가집니다.

1. 진정한 Shift Left:
- QA가 개발 시작 전 요구사항을 명확히 하는 과정에 공식적으로 참여하게 됩니다.
- 테스트하기 어려운 요구사항이나, 잠재적인 위험을 가장 이른 시점에 발견하고 개선할 수 있습니다.
2. 명확한 테스트 목표:
- “무엇을 테스트해야 할까?”에 대한 고민이 줄어듭니다.
- 팀과 함께 합의한 ‘인수 테스트’ 시나리오가 바로 QA의 가장 중요한 테스트 목표가 되기 때문입니다.
3. 개발자와의 강력한 파트너십:
- ‘ATDD’ 과정에서 개발자와 QA는 같은 목표(‘인수 테스트’ 통과)를 향해 함께 달리는 파트너가 됩니다.
- 이는 “버그를 찾는 사람”과 “버그를 만드는 사람”이라는 전통적인 대립 구도를 허물고, 건강한 협업 문화를 만드는 데 큰 도움이 됩니다.

‘인수 테스트 주도 개발(ATDD)’은 단순히 테스트를 먼저 하는 것이 아닙니다.

이는 개발을 시작하기 전에, 제품을 만드는 모든 사람이 ‘성공의 모습’에 대해 완벽하게 합의하고 출발하는 강력한 협업 프레임워크입니다.

QA가 ‘ATDD’ 프로세스를 주도적으로 이끌 때, 팀은 불필요한 재작업을 줄이고, 처음부터 올바른 방향으로 나아가며, 더 높은 품질의 제품을 더 빠르게 만들 수 있습니다.