1. 애자일 소프트웨어 개발 - ISTQB CTFL Agile Tester Syllabus v2014

키워드
애자일 선언, 애자일 소프트웨어 개발, 점진적 개발 모델, 반복적 개발 모델, 소프트웨어 수명주기, 테스트 자동화, 테스트 베이시스, 테스트 주도 개발, 테스트 오라클, 사용자 스토리
학습 목표
1.1 애자일 소프트웨어 개발 기본
1.1.1  애자일 선언(Agile Manifesto)을 기반으로 하는 애자일 소프트웨어 개발의 기본 개념을 상기한다
1.1.2  전체 팀 접근법의 장점을 이해한다 1.1.3  빠르고 잦은 피드백의 장점을 이해한다
1.2 애자일 접근법
1.2.1  애자일 소프트웨어 개발 접근법을 상기한다
1.2.2 (K3) 개발자와 업무 대표자*가 테스트할 사용자 스토리를 함께 작성한다
1.2.3  회고를 통해 애자일 프로젝트를 개선할 수 있음을 이해한다
1.2.4  지속적인 통합의 목적과 방법을 이해한다
1.2.5  반복주기(Iteration)와 출시(Release) 계획의 차이를 알고, 각각의 활동에 테스터가 어떻게 기여하는지 이해한다


1.1 애자일 소프트웨어 개발 기본
애자일 프로젝트에 참여하는 테스터는 전통적인 프로젝트와는 다른 방식으로 일을 하게 된다. 테스터는 애자일 프로젝트를 뒷받침하는 가치와 원칙을 이해하고 개발자, 업무 대표자와 함께 전체 팀의 일원임을 깨달아야 한다. 애자일 프로젝트의 멤버는 서로 자주 소통해야 하며, 이를 통해 결함을 조기에 제거하고 제품의 품질을 향상시킬 수 있다.

1.1.1 애자일 소프트웨어 개발과 애자일 선언
2001년에 널리 사용되던 경량 소프트웨어 개발 접근법을 대표하는 사람들이 모여 애자일 소프트웨어 개발을 위한 선언 또는 애자일 선언으로 알려진 공통적인 가치와 원칙에 동의하였다. 애자일 선언은 궁극적으로 추구하는 가치를 다음과 같은 4 가지 선언으로 나타냈다.
● 프로세스와 도구보다 개인과 그 개인들간의 상호작용을 중시한다
● 완벽한 문서보다 작동하는 소프트웨어를 중시한다
● 계약의 협상보다 고객과의 협업을 중시한다
● 계획을 고수하기보다 변화에 대한 대응을 중시한다
이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 뜻이다.
개인과 상호작용
애자일 개발은 매우 인간 중심적이다. 팀은 소프트웨어를 만드는 사람들로 구성되어 있으며, 도구나 프로세스에 의존하기 보다 지속적인 의사소통과 상호작용을 통해 더욱 효과적으로 일할 수 있다.
작동하는 소프트웨어
고객의 입장에서 보면 지나치게 자세한 설명서 보다 작동하는 소프트웨어가 훨씬 더 유용하고 가치 있으며, 이를 통해 개발팀은 신속한 피드백을 제공받을 수 있는 기회를 얻는다. 비록 기능이 축소되어 있으나 제대로 작동하는 소프트웨어는 개발 수명주기 초기에도 완전하게 동작하므로 애자일 개발은 타임 투 마켓 전략에 이점을 제공할 수 있다. 따라서 애자일 개발은 문제와 솔루션이 불분명하거나 새로운 영역에서 혁신을 원하는 등의 급격하게 변하는 비즈니스 환경에 특히 유용하다.
고객과의 협력
고객은 그들이 필요로 하는 시스템을 명세화 할 때 큰 어려움을 겪는다. 고객과 직접 협력하여 함께 일하는 것은 고객의 요구사항을 정확하게 이해할 가능성을 향상시킨다. 고객과의 계약도 중요하지만 아울러 그들과 함께 정기적으로 긴밀하게 협력해서 작업하는 것이 프로젝트의 성공 가능성을 더욱 높여준다.
변화에 대응하기
변화는 소프트웨어 프로젝트에서 불가피하다. 사업 운영 환경, 법률, 경쟁사의 활동, 기술진보 및 다른 여러 요인들은 프로젝트와 프로젝트의 목적에 중요한 영향을 미칠 수 있다. 이러한 요소들은 개발 과정에서 수용되어야 한다. 이와 같이 변화를 포용하는 작업 관행에서의 유연성을 갖는 것은 단순히 계획을 엄격하게 준수하는 것보다 더 중요하다.

원칙
애자일 선언의 핵심적인 가치는 다음 12가지 원칙에 잘 나타나 있다:
● 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다
● 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다
● 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라
● 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다
● 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라
● 개발 팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다
● 작동하는 소프트웨어를 태스크 진척의 최우선 지표로 삼는다
● 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다
● 기술적 탁월함과 좋은 설계에 대한 지속적 관심이 기민함을 높인다
● 단순성이 – 하지 않는 일의 양을 최대화하는 기술이 - 필수적이다
● 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다
● 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다

다양한 애자일 접근법들이 이러한 가치와 원칙을 실행으로 옮길 수 있는 규정된 실천방안을 제공한다.

1.1.2 전체 팀 접근법
전체 팀 접근법이란 프로젝트의 성공을 보장할 수 있는 지식과 기술을 가진 모든 사람이 필수적으로 팀에 포함되어야 함을 의미한다. 팀에는 고객을 대표할 수 있는 사람과 고객 이외의 비즈니스 이해관계자들이 포함되어 이들이 함께 제품의 기능을 결정한다. 팀은 상대적으로 작게 구성되어야 하는데, 관찰에 따르면 성공적인 팀은 주로 적게는 3명에서 많게는 9명의 인원으로 구성된다. 같은 공간을 공유하는 것은 의사 소통과 상호작용을 강하게 하므로 전체 팀이 동일한 작업 공간을 공유하는 것이 이상적이다.
전체 팀 접근법을 효과적으로 지원하기 위한 방법으로 일일 스탠드업 미팅(2.2.1절 참조)을 실시하는데, 이 미팅에는 팀의 모든 멤버가 참여하여 현재 태스크 진척을 공유하고, 태스크 진행에 장애가 되는 모든 요소들을 확인한다.
작업 진행 상황을 공유하고 모든 문제점을 공유하는 일일 스탠드 업 미팅(2.2.1절 참조)을 통해 전체 팀 접근법은 지원을 받는다. 전체 팀 접근법은 보다 효과적이고 효율적으로 팀의 역동성을 촉진한다.
제품 개발에 전체 팀 접근법을 사용하는 것은 애자일 개발의 주요 장점 중 하나이다. 전체 팀 접근법을 통해 다음과 같은 이익을 얻을 수 있다:
● 팀 내 의사 소통과 협력을 강화한다
● 팀 내의 다양한 스킬 셋을 활용해 프로젝트에 기여할 수 있다
● 제품의 품질을 모두의 책임으로 인식한다
애자일 프로젝트에서 품질에 대한 책임은 전체 팀에게 있다. 전체 팀 접근법의 핵심은 개발 과정의 모든 단계에 테스터, 개발자, 업무 대표자가 함께 참여해서 일한다는 것이다. 테스터는 원하는 품질 수준에 최대한 도달하기 위해 개발자와 업무 대표자 모두와 긴밀하게 일을 해야 한다. 이를 위해 업무 대표자가 적절한 인수 테스트를 만들 수 있도록 지원하고 협력하며, 개발자들이 테스트 전략에 동의할 수 있도록 협업해야 한다. 또한 테스트 자동화 접근 방법을 결정하기도 해야 한다. 이렇게 함으로써 테스터는 다른 팀 멤버에게 테스트 지식을 전달하고 확장시키며, 제품 개발에 영향을 미칠 수 있다.
전체 팀은 제품 기능을 제시하고, 분석하거나 추정하는 모든 협의나 회의에 참여한다. 모든 기능 토론에 테스터, 개발자, 업무 대표자가 참여하는 개념을 “3의 힘(The Power of Three)”이라고 한다 [Crispin08].

1.1.3 조기에 지속적으로 얻는 피드백
애자일 프로젝트는 반복주기를 가능한 짧게 설정하여 개발 수명주기 전반에 걸쳐 프로젝트 팀이 제품 품질에 대한 피드백을 조기에 지속적으로 받을 수 있게 한다. 이를 위한 방법의 한 가지로 지속적인 통합을 사용할 수 있다 (1.2.4절 참조).
순차 개발 접근법을 사용하는 경우, 고객은 프로젝트가 거의 완료된 단계가 되어서야 제품을 확인할 수 있으며, 이 시점에 고객에게 문제점이 발생하는 경우 개발팀에게 이를 해결할 충분한 시간이 주어지지 않게 된다. 프로젝트가 진행됨에 따라 지속적으로 고객의 피드백을 받음으로써 애자일 팀은 제품 개발 프로세스에 가장 새로운 변화를 통합할 수 있다. 조기에 지속적으로 얻는 피드백을 통해 팀은 가장 높은 비즈니스 가치를 갖는 기능이나 위험에 집중하고, 이를 또한 가장 먼저 고객에게 전달할 수 있게 된다. 아울러 팀의 역량 즉, ‘우리가 스프린트나 반복주기 동안 얼마나 많은 일을 할 수 있는가? 우리가 더 빠르게 일을 하는데 도움을 줄 수 있는 것은 무엇인가? 우리가 빠르게 일을 하는데 방해가 되는 요소는 무엇인가?’ 등을 모든 사람에게 투명하게 내보임으로써 팀을 더 잘 관리하는 데 도움을 준다.
조기에 얻는 지속적인 피드백을 통해 얻을 수 있는 장점은 다음과 같다.
● 요구사항에 대한 잘못된 이해를 방지할 수 있다. 요구사항을 정확하기 이해하지 못해서 발생하는 결함은 개발 수명주기 막바지까지도 발견하지 못할 수 있으며 이를 수정하는 데는 더 많은 비용이 소요된다.
● 고객의 기능 요구를 명확히 하여 제품 개발 초기에 고객이 사용해볼 수 있도록 한다. 이를 통해 고객이 원하는 것을 제품에 더 명확히 반영할 수 있다.
● (지속적인 통합을 통해) 품질문제를 조기에 발견하고 분리시키며 해결할 수 있다.
● 애자일 팀의 생산성 및 배포 능력과 관련된 정보들을 전달한다.
● 프로젝트를 일관성 있게 추진하도록 한다.

1.2 애자일 접근법
조직에 따라 적용할 수 있는 애자일 접근법은 다양하다. 대부분의 애자일 조직에서 사용하는 실천방법으로는 사용자 스토리 도출, 회고, 지속적인 통합, 개별 반복주기 및 전체 출시 계획 등이 있다. 이 섹션에서는 일부 애자일 접근법에 대해 설명한다.

1.2.1 애자일 소프트웨어 개발 접근법
많은 애자일 접근법들이 존재하며, 각각의 접근법들은 서로 다른 방법으로 애자일 선언의 가치와 원칙들을 구현한다. 이 실라버스에서는 애자일 방식을 대표하는 익스트림 프로그래밍(XP), 스크럼과 칸반(Kanban) 세가지 접근법을 소개한다.
익스트림 프로그래밍
켄트 벡이 처음 시작한 익스트림 프로그래밍은 애자일 접근법 중 하나로 소프트웨어 개발을 특정한 가치, 원칙 및 개발 실천법으로 설명한다.
XP는 다섯 가지 가치 즉, 의사소통, 단순성, 피드백, 용기 및 존중을 통해 개발을 가이드 한다.
XP는 또한 추가적인 가이드라인으로 일련의 원칙들을 제공하는데, 그 원칙들은 다음과 같다: 인간성, 경제성, 상호 이익, 자기 유사성, 개선, 다양성, 반성, 흐름, 기회, 잉여, 실패, 품질, 아기걸음 그리고 책임 소재
XP는 13가지 실천법을 제시한다: 함께 앉기, 전체 팀, 정보를 제공하는 작업 공간, 열정적인 작업, 짝 프로그래밍, 스토리, 주 단위 주기, 사분기 주기, 여유, 10분 빌드, 지속적인 통합, 테스트 우선 프로그래밍, 점진적 설계
오늘날 사용되는 애자일 소프트웨어 개발 방식의 대부분은 XP및 XP의 가치와 원칙에 영향을 받았다. 예를 들어, 애자일 팀은 스크럼에 XP 실천법을 자주 포함시킨다.
스크럼 Scrum
스크럼은 애자일 관리 프레임워크의 하나로 다음 구성요소와 실천법들을 포함하고 있다 [Schwaber01]:
● 스프린트: 스크럼은 프로젝트를 고정된 길이(보통 2~4주)의 주기로 나눈다. 이 주기를 스프린트라고 부른다.
● 증분된 산출물: 모든 스프린트는 잠재적으로 출시/배포 가능한 제품(점진적 개발)을 산출한다.
● 제품 백로그: 제품 오너는 계획된 제품 아이템의 우선 순위 목록(제품 백로그)을 관리하며, 이 목록은 스프린트가 진행됨에 따라 계속 진화한다(백로그 정제).
● 스프린트 백로그: 스프린트 시작 시점에 스크럼 팀은 제품 백로그에서 우선 순위가 가장 높은 항목 집합(스프린트 백로그)을 선택한다. 제품 오너의 강제에 의하지 않고 스크럼 팀에서 스프린트 내에 구현 가능한 항목을 선택하므로 밀기(Push) 원리가 아닌 당김(Pull) 원리를 따른다.
● 완료의 정의: 각 스프린트 완료 시점에서 잠정적으로 출시 가능한 제품이 산출되었는지를 확인하기 위해, 스크럼 팀은 적절한 스프린트 종료 기준을 협의하고 정의한다. 종료 기준 논의를 통해 애자일 팀은 백로그 아이템과 제품 요구사항을 더 깊이 이해하게 된다.
● 타임 박싱: 스프린트를 진행하는 애자일 팀이 해당 스프린트 내에서 완료할 수 있을 것으로 예상하는 작업, 요구사항 혹은 기능들만이 해당 스프린트 백로그의 일부가 된다. 만약 개발 팀이 스프린트 내에서 작업을 완료할 수 없다면, 관련 제품의 기능은 스프린트에서 제거되고 작업은 다시 제품 백로그로 이동된다. 타임 박싱은 다른 상황의 작업에도 적용된다. (예: 회의 시작 및 종료 시간)
● 투명성: 개발팀은 일일 스크럼이라 불리는 회의에서 매일 스프린트 상태를 공유한다. 일일 스크럼 회의를 통해 테스트 결과를 포함해 현재 스프린트의 내용과 진척을 팀, 관리자 및 모든 관련담당자에게 공유한다.
스크럼에서는 다음과 같은 3가지 역할을 정의한다:
● 스크럼 마스터: 스크럼 원칙과 규칙이 구현되고 준수되게 한다. 팀이 원칙과 규칙을 따르지 못하게 하는 모든 요소들, 자원 문제 또는 기타 장애물을 해결한다. 이 사람은 팀 리더가 아닌 코치이다.
● 제품 오너: 고객을 대표하고 제품 백로그를 생성, 유지하고 우선순위를 정한다. 이 사람은 팀 리더가 아니다.
● 개발팀: 제품을 개발하고 테스트한다. 개발팀은 팀 리더 없이 스스로 결정하는 자기 조직화 된 팀이다. 또한 이 팀은 복합 기능 팀이다 (2.3.2절과 3.1.4절 참조).
XP와 달리 스크럼은 특정 소프트웨어 개발 기술(예: 테스트 우선 프로그래밍)을 강요하지 않는다. 또한 스크럼은 스크럼 프로젝트에서 테스트가 어떻게 수행되어야 하는지에 대한 지침을 제공하지 않는다.
칸반 Kanban
칸반은 관리 접근법의 하나로 애자일 프로젝트에서 종종 사용된다. 일반적인 목적은 가치 사슬 내의 태스크 흐름을 시각화하고 최적화하는 것이다. 칸반은 세 가지 도구를 사용한다 [Linz14]:
● 칸반 보드: 관리되어야 할 가치 사슬은 칸반 보드를 통해 가시화 된다. 각 열은 관련된 일련의 활동 단계(예: 개발 또는 테스트)를 보여준다. 제작되는 아아템이나 처리할 태스크는 왼쪽에서 오른쪽으로 단계별로 이동하는 카드로 표현된다.
● 진행 작업 제한: 병렬로 동시에 실행되는 태스크의 양은 엄격히 제한된다. 단계 및 보드 전체에서 허용 가능한 카드의 최대수를 제어하는 방식을 사용한다. 작업자는 단계별로 여유 능력이 있을 때마다 이전 단계의 카드를 가져 온다.

● 리드 타임: 칸반은 완전한 가치 흐름에 대해 (평균) 리드 타임을 최소화함으로써 작업의 연속적인 흐름을 최적화하기 위해 사용된다.
칸반과 스크럼은 일부 유사성을 가진다. 두 프레임워크는 진행중인 작업의 시각화(예: 공동의 화이트보드)를 통해 작업 내용과 진척 상황에 대한 투명성을 제공한다. 예약되지 않은 작업은 백로그에 대기하고 있다가 새로운 공간(생산 능력)을 사용할 수 있을 때 칸반 보드로 이동한다.
칸반에서의 반복주기나 스프린트는 선택 사항이다. 칸반 프로세스에서는 산출물을 출시 단위가 아니라 항목별로 릴리즈 할 수 있다. 따라서 동기화 메커니즘인 타임 박싱은 칸반에서 선택적으로 적용된다. 반면 스프린트 내에서 모든 태스크를 동기화하는 스크럼에서는 타임 박싱이 필수적으로 적용된다.

1.2.2 사용자 스토리 공동 작업
충분치 않은 명세는 프로젝트의 실패를 야기하는 주요한 원인이다. 사용자의 실제 요구사항에 대한 스스로의 통찰력 부족, 대상 시스템에 대한 전체적인 비전의 부재, 중복되거나 모순되는 기능 및 기타 커뮤니케이션 이슈로 명세와 관련된 문제들이 발생할 수 있다. 애자일 개발환경에서 사용자 스토리는 개발자, 테스터 및 업무 대표자 관점의 요구사항들을 모두 수집하여 작성한다. 기능의 비전 공유는 순차적 개발 모델에서는 요구사항이 기록된 후 공식 리뷰를 통해 수행되지만, 애자일 개발환경에서는 요구사항이 작성되는 동안 비공식적인 리뷰를 통해 수행된다.
사용자 스토리는 기능 및 비기능 특성을 모두 해결해야 한다. 각각의 사용자 스토리는 이러한 특성에 대한 인수 기준을 가지고 있어야 한다. 이러한 조건은 업무 대표자, 개발자와 테스터 간의 협의에 의해 정의되어야 한다. 인수 기준은 개발자와 테스터에게 기능의 확장된 비전을 제공하고 업무 대표자는 유효성을 검사하기 위한 기준을 제공한다. 애자일 팀은 인수 기준이 충족되었을 때 작업이 완료된 것으로 간주한다.
일반적으로 테스터가 다른 이해관계자들과 다른 고유한 관점, 가령, 누락된 세부 사항 및 비기능적 요구사항 식별 등을 통해 사용자 스토리를 향상시킨다. 또한 테스터는 업무 대표자에게 사용자 스토리와 관련된 개방형 질문을 하고, 테스트 방법을 제안하며 인수조건을 확인함으로써 사용자 스토리 향상에 기여하기도 한다.
사용자 스토리의 공동 저자는 브레인 스토밍과 마인드 매핑 등의 기술을 사용할 수 있다. 테스터는 INVEST 기법을 사용할 수 있다[INVEST]:
● 독립적이다
● 협상 가능하다
● 사용자와 고객에게 가치가 있다
● 추정 가능하다
● 작다
● 테스트 가능하다
3C 개념[Jeffries00]에 따르면 사용자 스토리는 다음 세 가지 요소의 결합이다:
● 카드: 카드는 사용자 스토리를 기록한 물리적 매체로, 요구사항, 요구사항의 중요도, 예상되는 개발 및 테스트 기간, 인수 기준을 기록한다. 상세 설명은 향후 제품 백로그에 사용되므로 정확하게 기술해야 한다.
● 대화: 대화는 소프트웨어를 어떻게 사용하는지에 대해 설명한다. 대화는 문서 또는 구두로 할 수 있다. 개발자와 업무 대표자와 다른 관점을 갖는 테스터[ISTQB_FL_SYL]는 생각, 의견, 경험의 교환에 있어 가치 있는 의견을 제공한다. 대화는 출시 계획 단계에서 시작하여 스토리의 일정이 추정 될 때까지 계속된다.
● 확인: 대화에서 논의된 인수 기준을 사용해 스토리가 완료되었는지 확인한다. 이러한 인수 기준은 여러 사용자 스토리에 동시에 적용될 수도 있다. 인수 기준 만족 여부를 확인하기 위해 긍정적 테스트와 부정적 테스트를 모두 사용해야 한다. 확인 과정에는 다양한 참가자가 테스터의 역할을 수행한다. 참가자에는 개발자는 물론 성능, 보안, 상호 운용성 및 다른 품질 특성에 대한 전문가들도 포함된다. 정의된 인수 기준이 테스트 되고 만족되었음이 증명되면 해당 스토리는 완료된 것으로 확인한다.
애자일 팀은 다양한 방법으로 사용자 스토리를 작성한다. 사용자 스토리를 문서화하는 방법에 관계없이 문서는 간결하고 충분히 필요한 내용이 들어가 있어야 한다.

1.2.3 회고
애자일 개발에서 회고는 각 반복주기의 가장 마지막에 수행하는 회의로 ‘이번 반복주기에서 무엇이 성공적이었는지’, ‘다음 반복주기에서 무엇을 향상시킬 수 있는지’, ‘어떻게 성공을 유지하고 개선 사항을 통합할 수 있을지’에 대해 논의한다. 주로 프로세스, 사람, 조직, 관계, 도구와 같은 주제를 다룬다. 적절한 후속 활동을 이끌어내는 회고 모임은 조직의 개발 및 테스트의 지속적인 개선에 매우 중요하다.
회고를 통해 테스트와 연관된 개선 관련 의사 결정을 할 수 있으며 여기에는 테스트 효과성, 테스트 생산성, 테스트 케이스 품질 및 팀 만족 여부 등이 포함된다. 또한 응용 프로그램, 사용자 스토리, 특성 또는 시스템 인터페이스의 테스트 용이성을 해결할 수 있다. 결함 근본 원인 분석을 통해 테스팅과 개발의 개선을 추진할 수 있으며, 일반적으로 팀은 반복주기를 거듭하며 조금씩 개선을 진행함으로써 꾸준한 속도로 개선을 수행할 수 있게 된다.

회고의 시기와 구성은 애자일 기법에 따라 달라진다. 중재자(Facilitator)가 회의를 구성하고 진행하는 동안 업무 대표자 및 팀 참가자는 각 회고에 참석한다. 어떤 경우에는 팀 미팅에 다른 참가자를 초대할 수 있다.
테스터는 회고에서 중요한 역할을 수행한다. 테스터는 팀에 소속되어 있으며 ISTQB 실라버스 1.5 절에 언급된 바와 같이 그만의 독특한 관점을 팀에 제공한다. 모든 스프린트에서 테스팅을 수행하고 프로젝트의 성공에 실질적으로 기여해야 한다.
테스터를 포함한 모든 팀 구성원은 테스팅을 포함한 모든 활동에 입력 정보를 제공할 수 있다.
회고는 상호 신뢰를 특징으로 하는 전문적인 환경에서 수행되어야 한다. 성공적인 회고를 위해서는 다른 리뷰들과 동일한 특성들을 참고해야 하며, 이런 특성에 관한 내용은 ISTQB Foundation 실라버스 3.2절을 참조한다.
1.2.4 지속적인 통합
증분 산출물을 전달하기 위해서 모든 스프린트가 완료되는 시점에는 신뢰할 수 있고 제대로 작동하는 통합된 소프트웨어가 완성되어야 한다. 지속적인 통합은 적어도 하루에 한번 소프트웨어의 모든 변경 사항을 통합하고 정기적으로 변경된 모든 구성 요소를 통합함으로써 이 문제를 해결한다. 형상 관리, 편집, 소프트웨어 빌드, 배포 및 테스트를 하나의 자동화된 반복적인 프로세스로 통합한다. 개발자는 자신의 작업을 지속적으로 통합하고, 지속적으로 구축하고, 지속적으로 테스트하기 때문에 코드의 결함을 더 빨리 발견할 수 있다.
개발자가 코딩, 디버깅 후 공유 소스 코드 저장소에 코드를 체크인하고 나면 지속적인 통합 프로세스는 다음과 같은 활동을 자동으로 수행한다:
● 정적 코드 분석: 정적 코드 분석을 실행하고 결과를 보고한다
● 컴파일: 코드를 컴파일하고 링크를 걸어 실행 파일을 생성한다
● 단위 테스트: 단위 테스트를 실행하고 코드 커버리지를 확인하며, 테스트 결과를 보고한다
● 배포: 테스트 환경에 빌드를 설치한다
● 통합 테스트: 통합 테스트 실행과 경과를 보고한다
● 보고(현황판): 모든 활동의 상태는 오픈된 장소에 공개하거나, 해당 팀에 메일을 보내 상태를 공유한다
자동화 빌드 및 테스트 프로세스가 매일 실행되고 초기에 빠르게 통합 에러를 발견한다. 지속적인 통합 환경에서 애자일 테스터는 자동화된 테스트를 정기적으로 수행하며(자동화 테스트의 어느 부분은 지속적인 통합 환경에서 자체적으로 제공하기도 한다), 코드 품질에 대한 즉각적인 피드백을 팀에 제공할 수 있다. 이러한 테스트 결과는 특히 자동화된 보고서가 프로세스에 통합되어 있을 때 모든 팀 구성원에게 공개된다. 반복주기가 진행되는 동안 자동화된 리그레션 테스트를 지속적으로 수행할 수 있고, 바람직하게 자동화된 리그레션 테스트는 이전 반복주기에서 전달된 사용자 스토리를 포함하여 가능한 많은 기능을 포함한다. 자동화된 리그레션 테스트에서 좋은 커버리지는 큰 규모의 통합 시스템을 구축하고 테스트를 수행하는데 도움이 된다. 리그레션 테스트를 자동화함으로써 애자일 테스터들은 새로운 기능과 변경된 구현 사항에 대한 수동 테스트 및 결함 수정 확인 테스트에 집중할 수 있다.
일반적으로 지속적인 통합을 사용하는 조직은 테스트를 자동화하는 것뿐만 아니라 지속적인 품질 관리를 위해 빌드 도구를 사용한다. 즉, 단위 및 통합 테스트를 실행하는 것 외에도 이러한 도구는 추가적인 정적 및 동적 테스트, 성능 측정 및 프로파일링, 소스코드 문서화를 실행하고 수동 품질 보증 프로세스를 용이하게 할 수 있다. 이러한 응용 프로그램의 지속적인 품질 관리는 제품의 품질을 향상시킬 뿐만 아니라 모든 개발의 완료 후에야 품질 관리를 적용하는 전통적인 방법을 대체하여 제품 출시에 걸리는 시간을 단축시킨다.
빌드 도구는 자동 배포 도구에 연결하여 사용할 수 있다. 자동 배포 도구들은 지속적인 통합 서버 혹은 빌드 서버에서 적절한 빌드 산출물을 복사하여, 하나 혹은 그 이상의 개발 환경, 테스트 환경, 스테이징 환경 혹은 실제 사용환경에 배포한다. 이것은 해당 환경에서 출시를 담당하는 전문직원 또는 프로그래머와 관련된 오류 및 지연을 줄일 수 있게 해준다.
지속적인 통합을 통해 얻을 수 있는 이점은 다음과 같다:
● 문제와 변경관련 충돌의 조기발견과 근본적인 원인 분석이 가능하다
● 개발팀에 코드가 작동하는지에 대한 정기적인 피드백을 제공한다
● 개발 중인 소프트웨어 버전 당일 내에 테스트 중인 버전을 유지한다
● 코드 베이스가 변경되는 즉시 (자동화 된) 재테스팅을 수행함으로써 개발자의 코드 리팩토링과 관련된 리그레션 리스크를 줄일 수 있다
● 탄탄한 기초를 기반(빌드 및 테스트가 정상 수행되지 않으면 해당 이슈를 먼저 해결해야 한다)으로 코드 개발 작업에 대한 확신을 제공한다
● 제품의 추가 개발에 대한 완료 여부를 시각화 함(테스트 주도 개발 방법론을 도입한 경우, 먼저 작성된 테스트 코드를 지속적인 통합 환경에서 수행하게 된다. 자동화된 단위 테스트가 모두 성공할 때까지 제품 코드를 작성하게 된다)으로써 개발자와 테스터를 격려한다
● 빅뱅 통합 방법에 따른 일정 상의 리스크를 제거한다
● 실행 가능한 소프트웨어를 지속적으로 적용함으로써 이 소프트웨어는 스프린트 테스팅, 데모, 교육 목적 등으로 활용할 수 있다
● 반복적인 수동 테스트 작업을 줄일 수 있다

● 품질 및 테스트를 개선하기 위해 내린 결정에 대한 빠른 피드백을 제공한다.
그러나, 지속적인 통합에도 다음과 같은 리스크와 어려움이 존재한다:
● 지속적인 통합 도구가 도입되고 잘 유지되어야 한다
● 지속적인 통합 프로세스를 정의하고 설정해야 한다
● 테스트 자동화는 추가적인 자원을 필요로 하며 설정이 복잡할 수 있다
● 자동화된 테스트의 장점을 활용하기 위해서는 철저한 테스트 커버리지를 만족시켜야 한다
● 팀이 단위 테스트에 지나치게 의존한 나머지 시스템/인수 테스팅을 불충분하게 수행할 수 있다
지속적인 통합 환경을 잘 구축하기 위해서는 테스팅 도구, 빌드 프로세스 자동화 도구, 형상 관리 도구 등을 함께 사용해야 한다.

1.2.5 출시와 반복주기 계획
ISTQB Foundation 실라버스[ISTQB_FL_SYL]에서 언급한 바와 같이, 계획은 지속적인 활동이며, 이것은 애자일 수명주기에서도 마찬가지이다. 애자일 라이프사이클의 경우 계획 활동에는 출시 계획과 반복주기 계획 두 가지가 있다.
출시 계획은 제품의 출시를 계획하며, 종종 프로젝트 시작 몇 개월 전에 수립된다. 출시 계획 단계에서는 새로운 백로그를 정의하거나 기존 백로그를 재정의하는 활동을 실행하며 이 과정에서 작은 사용자 스토리들을 모아 큰 사용자 스토리로 만들기도 한다. 출시 계획은 모든 반복주기에 대한 테스트 접근법과 테스트 계획을 위한 기초를 제공한다. 출시 계획은 상위 레벨 수준의 계획이다.
출시 계획에서 업무 대표자는 팀과 공동으로 출시에 대한 사용자 스토리를 설정하고 우선순위를 정한다. (1.2.2 절 참조) 이 사용자 스토리에 기반하여 프로젝트 리스크와 품질 리스크를 식별하고 상위 레벨 수준에서 공수를 추정한다 (3.2절 참조).
테스터도 출시 계획에 참여하며 특히 다음과 같은 활동을 통해 계획에 기여할 수 있다:
● 테스트 가능한 사용자 스토리를 정의한다. 여기에는 인수 기준도 포함된다
● 프로젝트 리스크 및 품질 리스크 분석에 참여한다
● 사용자 스토리와 관련된 테스트 공수를 추정한다
● 필요한 테스트 레벨을 정의한다
● 출시에 대한 테스팅을 계획한다
출시 계획이 완료되면 첫 번째 반복주기를 위한 계획을 수립한다. 반복주기 계획은 하나의 반복주기의 종료 조건과 반복주기 백로그에 관한 내용을 다룬다.
반복주기 계획에서 팀은 출시 백로그로부터 사용자 스토리를 선택하고 사용자 스토리를 상세화하고, 사용자 스토리를 위한 리스크 분석을 실행하고, 각 사용자 스토리에 필요한 작업을 추정한다. 선택한 사용자 스토리가 너무 모호하여 명확화할 수 없는 경우, 애자일 팀은 해당 스토리를 거부하고 우선 순위에 따라 다음 사용자 스토리를 선택할 수 있다. 업무 대표자는 각 스토리에 대한 팀의 질문에 응답해야 하며, 이를 통해 팀은 각 스토리와 관련해 무엇을 구현하고 어떻게 테스트해야 할지 이해하게 된다.
팀의 속도와 선택되고 추정된 사용자 스토리의 크기에 따라 반복주기에서 구현되는 스토리의 수는 달라진다. 반복주기 내용이 확정된 후 사용자 스토리는 작업으로 분할되고 적절한 팀 멤버에게 할당된다.
테스터 역시 반복주기 계획에 참가하며 특히 다음과 같은 활동을 통해 계획 단계에 기여할 수 있다:
● 사용자 스토리와 관련된 상세 리스크 분석에 참여한다
● 사용자 스토리의 테스트 용이성을 결정한다
● 사용자 스토리와 관련된 인수 테스트를 작성한다
● 사용자 스토리를 태스크 단위(특히 테스팅 업무 단위)로 분리한다
● 모든 테스팅 업무와 관련된 공수를 추정한다
● 테스트 대상 시스템의 기능적/비기능적 측면을 식별한다
● 다양한 테스트 레벨의 테스팅 자동화를 지원하고 이에 참여한다
출시 계획은 프로젝트 진행에 따라 변경될 수 있으며, 여기엔 제품 백로그에 포함된 개별 사용자 스토리의 변경도 포함될 수 있다. 이러한 변경은 내부 또는 외부 요인에 의해 유발될 수 있다. 내부 요인으로는 배포 능력, 속도, 기술적인 문제 등이 포함될 수 있으며 외부 요인으로는 새로운 시작과 기회, 새로운 경쟁 업체 발견 혹은 비즈니스 위협에 따른 출시 목표나 출시 날짜 변경이 있다. 또한 반복주기 계획은 반복주기 중에 변경될 수 있다. 예를 들어, 비교적 간단하다고 간주했던 특정 사용자 스토리가 분석 결과 예상보다 더 복잡한 경우 등이다.
이러한 변화는 테스터에게 도전이 될 수 있다. 테스터는 테스트 계획을 위해 출시의 큰 그림을 이해해야 하며, ISTQB Foundation 실라버스[ISTQB_FL_SYL] 1.4절에 설명된 대로 테스트 개발을 위해 각 반복주기에서 적절한 테스트 베이시스와 테스트 오라클을 가지고 있어야 한다. 필요한 정보는 개발 초기에 테스터가 사용 가능해야 하고 일어날 변화는 애자일 원칙에 따라 수용해야 한다. 이러한 딜레마는 테스트 전략과 테스트 문서에 관한 주의 깊은 결정을 필요로 한다. 애자일 테스팅 변화에 대한 자세한 내용은 [Black09] 제12장을 참조한다.

출시와 반복주기 계획은 개발 계획 활동에 따른 테스트 계획을 다룬다. 고려해야 할 특정 테스트 관련 문제는 다음과 같다:
● 테스팅의 목적, 목적에 따른 테스팅의 범위, 테스트 목표 및 이러한 결정에 대한 이유
● 테스트 활동을 수행할 팀 멤버
● 필요한 테스트 데이터와 환경, 그리고 테스트 환경이나 데이터에 대한 어떠한 추가 또는 변경이 프로젝트 동안 발생할지에 대한 여부
● 개발 활동과 관련이 있거나 의존적인 테스트 활동을 포함한 기능 및 비기능 테스트 활동 및 이를 위한 타이밍, 순서, 종속성과 전제 초건(예: 다른 기능 또는 테스트 데이터에 따라 달라지는 기능에 대해 리그레션 테스트를 얼마나 자주 실행해야 하는가?)
● 해결해야 하는 프로젝트와 품질 리스크(3.2.1절 참조)
아울러 큰 팀의 공수를 추정하는 경우에는 요구된 테스팅 활동의 완료에 필요한 시간과 공수를 포함시켜야 한다.