애자일에서 QA가 실제로 하는 일: 스토리 추정부터 완료의 정의까지

개념

"애자일이라 테스트 계획이 없어요"

레슨 4에서 워터폴·스크럼·칸반을 비교하며 방법론이 테스트 시점을 결정한다는 것을 봤다. 이 레슨은 그중 스크럼 안에서 QA가 실제로 무엇을 하는지 를 이벤트 단위로 내려간다.

시작하기 전에 흔한 오해 하나를 정리하자.

"애자일이니까 문서와 계획이 없다" 는 애자일 선언의 오독이다. 선언은 "포괄적인 문서보다 작동하는 소프트웨어를", "계획을 따르기보다 변화에 대응하기를" 더 가치 있게 여긴다고 했다. 왼쪽 항목에도 가치가 있다 는 문장이 뒤에 붙어 있다.

실제로 바뀌는 것은 문서의 유무가 아니라 크기와 주기 다. 100쪽짜리 테스트 계획서가 한 번 나오는 대신, 짧은 전략 문서 하나와 스프린트마다 갱신되는 범위 판단이 있다. 모듈 4(레슨 1)에서 본 "애자일에서 계획이 축약되는 방식"이 그것이다.

스크럼 이벤트별로 QA가 하는 일

스크럼에는 정해진 이벤트가 있고, 각각에 QA의 자리가 있다.

가장 값이 큰 것은 첫 줄이다. 백로그 리파인먼트에서 스토리를 다듬는 일은 모듈 2(레슨 6)의 요구사항 리뷰이고, 여기서 잡은 모호함 하나가 스프린트 중반의 하루를 아낀다. 모듈 1에서 배운 "결함은 일찍 발견할수록 싸다"가 스크럼 이벤트로 구현되는 지점이다.

백로그의 계층 — 에픽·스토리·태스크

모듈 22(레슨 6)에서 Jira의 업무 항목 계층을 봤다. 여기서는 QA 관점의 의미를 짚는다.

에픽(Epic)         "결제 수단 확대"        ← 테스트 전략 수준
   └ 스토리(Story)  "카카오페이로 결제한다"  ← 인수기준·테스트 조건 수준
       └ 태스크(Task) "PG 연동 모듈 구현"     ← 개발 작업 단위
                     "결제 회귀 케이스 작성"  ← QA 작업도 태스크다

마지막 줄을 강조한다. QA 작업을 태스크로 올리지 않으면 그 일은 스프린트에서 보이지 않는다. 모듈 22 레슨 6에서 한 이야기 그대로다 — "QA가 병목"이라는 말이 나오는데 정작 QA의 작업량이 어디에도 기록돼 있지 않은 상황을 막으려면, 테스트 설계·환경 구축·회귀 수행을 태스크로 올려야 한다.

좋은 사용자 스토리의 형태 도 알아둘 필요가 있다.

As a  [누가]      신규 가입 고객으로서
I want [무엇을]   카카오페이로 결제하고 싶다
So that [왜]      카드 정보를 입력하지 않아도 되도록
 
인수기준(Acceptance Criteria)
  · 결제 수단 선택 화면에 카카오페이가 노출된다
  · 인증 실패 시 결제 수단 선택 화면으로 돌아온다
  · 결제 완료 시 주문 상태가 '결제완료'로 바뀐다

QA가 리파인먼트에서 던질 질문 은 대개 세 갈래다.

• "이 인수기준은 어떻게 확인합니까?" (테스트 가능성)
• "~하지 않으면 어떻게 됩니까?" (예외 흐름)
• "이건 이번 스토리 범위입니까?" (경계 확정)

세 번째가 특히 중요하다. 범위가 흐릿한 스토리는 "완료"를 판정할 수 없다. 그리고 판정할 수 없으면 스프린트 끝에 논쟁이 난다.

인수기준과 완료의 정의는 다르다

가장 자주 혼동되는 두 개념이다.

둘 다 있어야 한다. 인수기준만 있으면 "기능은 되는데 테스트도 문서도 없는" 상태로 완료 처리된다. DoD만 있으면 "절차는 다 밟았는데 원하는 기능이 아닌" 상태가 된다.

QA가 DoD에 넣을 것을 제안할 수 있다. 실무에서 잘 작동하는 항목들이다.

Definition of Done (예시)
  □ 인수기준을 모두 충족한다
  □ 코드 리뷰 승인
  □ 단위 테스트 추가·통과
  □ 회귀 테스트 통과 (CI 초록)
  □ QA 검증 완료 (또는 QA가 검증 불필요로 판정)
  □ 알려진 결함이 없거나, 있다면 등록되고 우선순위가 합의됨
  □ 문서·릴리즈 노트 갱신
  □ 기능 플래그 상태 확인

'알려진 결함이 있다면 등록되고 합의됨' 이 실무적으로 중요하다. "결함 0건"을 DoD로 걸면 지켜지지 않는다. 대신 "묻히지 않았음" 을 조건으로 걸면 현실적이면서도 효과가 있다. 모듈 6(레슨 1)에서 배운 심각도·우선순위 판단이 여기서 쓰인다.

DoD를 정할 때 흔한 실수는 너무 이상적으로 만드는 것 이다. 지킬 수 없는 DoD는 곧 무시되고, 무시되는 순간 DoD는 없는 것과 같다. 처음에는 지킬 수 있는 수준으로 시작해 회고에서 한 항목씩 올린다.

스토리 추정 — QA 공수는 어디에 들어가는가

스크럼 팀은 대개 스토리 포인트 로 추정한다. 시간이 아니라 상대적 크기를 매기는 방식이다.

피보나치 수열을 쓰는 이유
  1, 2, 3, 5, 8, 13, 21
  → 크기가 커질수록 불확실성도 커지므로 눈금을 성기게 둔다
  → "8이냐 9냐"를 논쟁하는 시간을 없앤다

플래닝 포커 는 팀원이 동시에 카드를 내는 방식이다. 목적은 숫자 자체가 아니라 차이가 나는 이유를 드러내는 것 이다. 누군가 3을, 누군가 13을 냈다면 서로 다른 것을 보고 있다는 뜻이고, 그 대화에서 숨은 복잡도나 리스크가 나온다.

여기가 QA가 개입할 지점이다. 개발자가 3을 냈는데 QA가 8을 낼 수 있다. 이유는 대개 이렇다.

핵심 원칙: 스토리 포인트에는 개발 공수만이 아니라 완료까지의 모든 공수 가 들어가야 한다. 테스트를 빼고 추정하면, 스프린트 끝에 "개발은 끝났는데 아직 테스트 중"이라는 상태가 반복된다. 그리고 그건 스프린트가 실패했다는 뜻이다 — DoD를 못 채웠으므로.

기술 부채와 리팩터링에 QA가 대응하는 법

애자일 팀은 속도를 위해 의도적으로 기술 부채 를 지기도 한다. 문제는 그것이 기록되지 않을 때다.

QA가 할 수 있는 일이 셋이다.

1) 부채를 눈에 보이게 만든다. 백로그에 항목으로 올리고, 그 부채가 테스트에 어떤 비용을 만드는지 적는다. "이 모듈은 목 서버 없이는 테스트할 수 없어 매 스프린트 2시간이 든다" 같은 식이다. 모듈 11(레슨 4)의 자동화 부채와 같은 구조다.

2) 리팩터링을 검증 대상으로 다룬다. 모듈 9(레슨 11)에서 다룬 그대로 — "동작 변화 없음"은 주장이지 사실이 아니다. 리팩터링 스토리에는 회귀 범위를 함께 정한다. 테스트가 없는 코드를 리팩터링한다면 특성화 테스트가 먼저다(모듈 4 레슨 6).

3) 부채의 이자를 데이터로 보인다. 회고에서 "이 영역에서 결함이 전체의 40%가 나옵니다"라고 말할 수 있으면 부채 상환이 백로그에 올라간다. 모듈 6(레슨 5)의 결함 밀도가 여기서 쓰인다.

회고에서 QA가 낼 수 있는 것

회고가 인상 비평으로 흐르는 이유는 데이터가 없어서 다. QA는 데이터를 가진 사람이다.

'발견 시점 분포'가 가장 강력하다. 결함이 스프린트 마지막 이틀에 몰려 있다면 그건 QA가 늦게 시작했다는 뜻이 아니라 개발 완료가 늦게 몰렸다는 뜻 일 가능성이 높다. 이 그래프 하나가 "테스트 시간이 부족하다"는 말보다 훨씬 강하게 전달된다.

지속적 통합이 애자일 QA의 전제다

스프린트마다 동작하는 소프트웨어를 내놓으려면 통합이 자동이어야 한다. 모듈 14 전체가 이 이야기이고, 애자일 관점에서 QA가 확인할 것은 셋이다.

• CI가 초록인 상태가 기본인가 — 빨간 채로 며칠 방치되면 신호가 죽는다
• 회귀 테스트가 매 병합마다 도는가 — 아니면 스프린트 끝에 몰린다
• DoD에 CI 통과가 들어 있는가 — 들어 있지 않으면 "나중에 고칠게요"가 반복된다

스프린트 중간에 범위가 바뀔 때

스크럼에서 스프린트 범위는 원칙적으로 고정이지만, 실무에서는 긴급 요청이 들어온다. QA가 그때 할 일이 정해져 있다.

첫 줄이 핵심이다. "넣자" 는 결정에 "대신 무엇을 빼는가" 를 붙이지 않으면, 스프린트 끝에 전부 미완으로 남는다. 이 질문은 PM의 일처럼 보이지만 실제로 밀리는 것을 먼저 보는 사람이 QA이므로 꺼내기 좋은 자리다.

네 번째도 중요하다. 운영 긴급 배포는 스프린트 리듬 밖에 있으므로, 별도의 짧은 검증 경로(스모크 + 영향 범위 확인)를 미리 합의해 둬야 한다. 없으면 긴급할 때마다 검증을 건너뛰게 된다.

애자일 확산 — 팀을 넘어설 때

한 팀이 애자일을 잘해도 조직 전체가 워터폴이면 마찰이 생긴다. QA가 자주 마주치는 형태들이다.

두 번째가 특히 흔하다. 팀별로는 다 초록인데 합치면 깨진다. 대응은 모듈 12에서 배운 계약 테스트 다 — 통합을 마지막에 몰지 않고 각 팀이 계약을 지키는지 상시 검증하는 구조.

사례 — DoD 한 줄이 바꾼 스프린트

2주 스프린트를 돌리는데 매번 마지막 이틀에 QA가 몰리고, 결함이 나오면 다음 스프린트로 밀리는 팀이었다. 회고마다 "시간이 부족하다" 가 나왔고 대책은 "다음엔 좀 더 일찍 주세요" 였다.

QA가 회고에 숫자를 가져갔다.

두 숫자를 나란히 놓자 결론이 자동으로 나왔다 — 8.5일차에 도착해서 재검증까지 1.5일이 걸리면 10일 안에 끝날 수가 없다. 역량이 아니라 산수였다(레슨 4의 전환 사례와 같은 구조).

바꾼 것은 DoD에 한 줄이었다.

기존: 개발 완료 + 코드 리뷰 통과 변경: 개발 완료 + 코드 리뷰 통과 + QA 검증 통과

이 한 줄의 효과가 연쇄로 왔다.

세 번째가 가장 컸다. 그전까지 QA 몰림은 "QA의 문제" 였는데, DoD가 바뀌자 개발자에게도 자기 문제가 됐다. 구조를 바꾸면 사람을 설득할 필요가 줄어든다.

석 달 뒤 밀린 스토리가 스프린트당 1건 이하가 됐다. 다만 첫 스프린트는 오히려 나빠졌다 — 완료 처리되는 스토리 수가 줄어 속도가 떨어진 것처럼 보였다. 그 구간을 팀에 미리 설명해 두지 않으면 한 번에 되돌려진다.

실무에서 왜 필요한가

애자일 팀에서 QA가 겪는 가장 흔한 어려움은 "테스트할 시간이 없다" 이다. 그런데 이 문제의 원인은 대부분 스프린트 후반이 아니라 앞쪽에 있다. 추정에 테스트 공수가 안 들어갔거나, DoD에 검증이 없거나, 스토리가 모호한 채로 개발에 들어갔거나.

이 레슨의 내용은 전부 그 앞쪽을 손보는 방법이다. 리파인먼트에서 질문을 던지고, 추정에 참여하고, DoD를 합의하고, 회고에 데이터를 가져간다. 시간을 더 달라고 하는 대신 구조를 바꾸는 접근 이다.

채용 관점에서도 신호가 된다. "애자일 환경에서 QA 경험"은 공고에 흔히 적히는 문구인데, 실제로 요구되는 것은 스크럼 용어를 아는 것이 아니라 이벤트마다 무엇을 기여했는지 말할 수 있는가 다. "리파인먼트에서 인수기준의 예외 흐름을 짚어 스프린트 중 재작업을 줄였습니다"는 구체적인 답이다.

채용시장에서의 위치

"애자일 환경 QA 경험" 은 거의 모든 공고에 적힌다. 그래서 이 항목은 가점이 아니라 통과 조건이고, 변별력은 이벤트마다 무엇을 기여했는지에서 나온다.

세 번째와 다섯 번째가 리드 역량을 가른다. "시간이 없다" 를 구조의 문제로 바꿔 본 사람과 개인의 노력으로 버틴 사람의 차이가 거기서 드러난다.

특히 다섯 번째는 합의를 끌어낸 경험이라 무게가 다르다. DoD 변경은 팀 전체의 일하는 방식을 바꾸는 것이고, 그것을 통과시켰다면 설득과 데이터를 모두 써 본 사람이다.

두 번째는 기본 질문인데 의외로 많이 틀린다. 인수기준은 스토리별, DoD는 전체 공통 — 이 한 줄만 정확히 말해도 다르게 읽힌다.

공고 표현으로는 "스크럼 환경", "애자일 QA", "Shift-Left", "테스트 전략 수립", "크로스 펑셔널 팀 협업" 이 이 레슨에 걸린다. 그리고 ISTQB Agile Tester 자격이 이 범위를 그대로 다룬다.

실습 과제

과제 1 — 우리 팀 DoD 만들기 (20분)

팀에서 쓸 완료의 정의를 작성한다. 조건이 하나 있다 — 지금 당장 지킬 수 있는 항목만 넣는다.

작성 후 검증한다 — 지난 스프린트의 스토리들이 이 DoD를 통과했겠는가?

과제 2 — 스토리 추정에 QA 관점 넣기 (15분)

최근 스프린트의 스토리 3개를 골라, 개발 관점 추정과 QA 관점 추정을 따로 매긴다.

차이가 큰 스토리에 대해 리파인먼트에서 무엇을 물었어야 했는지 적는다.

과제 3 — 리파인먼트 질문 목록 만들기 (15분)

다음 스프린트에 들어올 스토리를 하나 고르고, 리파인먼트에서 던질 질문을 세 갈래로 각각 2개씩 만든다.

• 테스트 가능성 — "이건 어떻게 확인합니까?"
• 예외 흐름 — "~하지 않으면 어떻게 됩니까?"
• 범위 경계 — "이건 이번 범위입니까?"

과제 4 — 회고용 데이터 준비하기 (15분)

다음 회고에 가져갈 데이터를 하나 정하고, 실제로 뽑아본다.

• 어떤 데이터인가
• 어디서 뽑는가(Jira JQL, 테스트 관리 도구, CI)
• 그 데이터가 어떤 대화를 만들 것으로 기대하는가
• 그 대화의 결과로 무엇이 바뀌길 원하는가

'결함 발견 시점 분포'를 권한다. 모듈 22(레슨 7)에서 배운 JQL로 created 날짜별 집계를 뽑으면 된다.

자가 체크리스트

• "애자일이라 문서가 없다"가 왜 오독인지 설명할 수 있다
• 스크럼 이벤트별로 QA가 하는 일을 열거할 수 있다
• 백로그 리파인먼트가 왜 가장 값이 큰 개입 지점인지 말할 수 있다
• 에픽·스토리·태스크의 계층을 설명하고, QA 작업을 어디에 올릴지 안다
• 사용자 스토리에 대해 세 갈래 질문을 던질 수 있다
• 인수기준과 완료의 정의를 범위·주체·시점으로 구분할 수 있다
• DoD에 '결함 0건' 대신 무엇을 넣어야 하는지 설명할 수 있다
• 지킬 수 없는 DoD가 왜 없는 것보다 나쁜지 말할 수 있다
• 스토리 포인트에 피보나치 수열을 쓰는 이유를 설명할 수 있다
• 플래닝 포커의 목적이 숫자가 아니라 차이의 이유임을 안다
• QA가 개발자보다 크게 추정하게 되는 이유를 다섯 가지 들 수 있다
• 기술 부채에 QA가 대응하는 세 가지 방법을 말할 수 있다
• 리팩터링을 검증 대상으로 다뤄야 하는 이유를 설명할 수 있다
• 회고에 가져갈 데이터를 다섯 가지 이상 들 수 있다
• 결함 발견 시점 분포가 무엇을 드러내는지 설명할 수 있다
• 여러 팀이 각자 스프린트를 돌 때 생기는 통합 병목과 그 대응을 말할 수 있다

흔한 실수

• 추정에서 테스트 공수를 뺀다. 스프린트 끝에 "개발은 끝났는데 테스트 중"이 반복되고, 그건 스프린트 실패다.
• QA 작업을 태스크로 올리지 않는다. 기록되지 않은 일은 조직에서 없는 일이다.
• 인수기준과 DoD를 혼동한다. 하나는 스토리마다, 하나는 전체 공통이다.
• DoD를 이상적으로 만든다. 지킬 수 없으면 곧 무시되고, 무시되면 없는 것과 같다.
• DoD에 '결함 0건'을 넣는다. "등록되고 합의됨"이 현실적이면서 효과가 있다.
• 리파인먼트에 참석하지 않는다. 가장 값싼 개입 지점을 통째로 버리는 것이다.
• 범위 경계를 묻지 않는다. 흐릿한 스토리는 완료를 판정할 수 없다.
• 리팩터링을 안전하다고 가정한다. "동작 변화 없음"은 검증 대상이다.
• 회고에 데이터 없이 간다. 인상 비평으로 끝나고 아무것도 바뀌지 않는다.
• "테스트 시간이 부족하다"고만 말한다. 결함 발견 시점 분포를 보여주면 원인이 앞쪽에 있다는 것이 드러난다.

참고 자료

• 애자일 소프트웨어 개발 선언 — 한국어 원문
• 스크럼 가이드 (한국어) — 이벤트·역할·산출물의 공식 정의
• ISTQB Certified Tester — Agile Tester — 애자일 환경의 테스터 자격증
• Atlassian — Definition of Done — DoD 작성 실무 가이드
• Martin Fowler — Technical Debt — 기술 부채 개념의 원전

이 커리큘럼 안에서

• 모듈 7 레슨 4 — 방법론 비교. 미니 워터폴의 증상과 이 레슨의 대응
• 모듈 7 레슨 5 — BDD·Three Amigos. 인수기준을 함께 쓰는 방법
• 모듈 7 레슨 6 — 성숙도. DoD가 "표준 절차" 역할을 한다
• 모듈 7 레슨 7 — 문서화. 회고 결정을 결정 기록으로 남긴다
• 모듈 7 레슨 9 — 조직과 역할. 애자일 팀에서 QA를 어떻게 배치하나
• 모듈 4 레슨 4 — 종료 조건. DoD와 같은 원리
• 모듈 6 레슨 5 — 지표. 회고에 가져갈 데이터의 출처
• 모듈 8 — 회귀 테스트. 스프린트마다 반복되는 부담
• 모듈 12 — 계약 테스트. 여러 팀 통합이 병목일 때
• 모듈 14 — CI/CD. 애자일 QA의 전제

한 줄 정리 — 애자일에서 "테스트할 시간이 없다" 의 원인은 거의 항상 앞쪽에 있다. 리파인먼트에서 묻고, 추정에 검증 공수를 넣고, DoD에 검증을 넣는다. 인수기준은 스토리별이고 DoD는 전체 공통이며, 회고에는 느낌이 아니라 숫자를 가져간다. 구조를 바꾸면 사람을 설득할 필요가 줄어든다.