2. 기본 애자일 테스팅 원칙, 예제 & 프로세스 - ISTQB CTFL Agile Tester Syllabus v2014

키워드
빌드 베리피케이션 테스트, 형상 관리 아이템, 형상 관리
학습 목표
2.1 전통적인 테스팅과 애자일 접근법의 테스팅 차이
2.1.1  애자일 프로젝트와 다른 프로젝트의 테스트 활동의 차이점을 설명한다
2.1.2  개발 및 테스트 활동이 애자일 프로젝트에서 어떻게 통합되는지 설명한다
2.1.3  애자일 프로젝트의 독립적인 테스트 역할을 설명한다
2.2 애자일 프로젝트의 테스팅 상태
2.2.1  테스트 절차와 제품 품질을 포함하여 애자일 프로젝트에서 테스팅의 상태를 의사 소통하는데 사용되는 도구와 기법을 설명하시오
2.2.2  다수의 반복주기에 걸쳐 테스트의 발전 과정을 설명하고, 테스트 자동화가 애자일 프로젝트에서 리그레션 리스크를 관리하는데 중요한 이유에 대해 설명하시오
2.3 애자일 팀 내 테스터의 역할과 기술 역량
2.3.1  애자일 팀에서 테스터의 역량(사람, 도메인 그리고 테스팅)을 이해한다
2.3.2  애자일 팀에서 테스터의 역할을 이해한다


2.1 전통적인 테스팅과 애자일 접근법의 테스팅 차이
ISTQB Foundation 실라버스[ISTQB_FL_SYL]와 [Black09]에서 설명한 바와 같이, 테스트 활동은 개발 활동과 연관되어 있고 수명주기에 따라 다양하게 변화한다. 테스터는 효과적이고 효율적인 작업을 위해 애자일 수명주기와 기존의 수명주기(예: V -모델과 같은 순차 모델 또는 RUP와 같은 반복적 모델)의 차이점을 이해하고 있어야 한다. 애자일 모델은 테스팅과 개발 활동이 통합되어 있다는 점을 포함해 프로젝트 산출물, 용어, 다양한 테스트 레벨에서 사용되는 시작 및 종료 조건, 도구의 활용 및 독립적인 테스팅을 효과적으로 구현하는 데 있어서 기존 모델과 다르다.
테스터는 조직에 따라 수명주기 구현 방법이 상당히 다르다는 점을 명심해야 한다. 특정 조직의 수명주기 구성은 특별 주문(Customization)으로 제작된다. 다양한 실천방법을 적용함으로써 애자일 수명주기의 이상적인 형태가 달라질 수도 있다. 테스터는 해당 조직에서 사용하는 소프트웨어 개발 실천방법을 포함해 주어진 환경을 적절하게 적용할 수 있어야 한다. 그렇지 않으면 테스터로서 직무에 실패할 수 있다.

2.1.1 테스팅과 개발 활동
전통적인 수명주기와 애자일 수명주기의 주요 차이점 중 하나는 주기가 매우 짧은 반복이라는 개념이며, 각 반복주기가 완료되는 시점에는 이해관계자에게 가치를 전달할 주요 기능을 갖는 동작하는 소프트웨어가 만들어져야 한다. 프로젝트 시작 단계에서 출시 계획을 수립하며, 이후 일련의 반복주기가 진행된다. 각 반복주기의 시작 단계에서 반복주기 계획을 수립한다. 선택된 사용자 스토리가 개발되고 시스템에 통합되어 테스트가 실행된다. 이러한 반복주기는 각 반복주기마다 상당량의 병렬 및 오버랩(동시 발생)을 포함한 개발, 통합 그리고 테스팅 활동이 일어나는 매우 역동적인 활동으로 이루어진다. 테스팅 활동은 반복주기의 마지막 활동이 아니라 반복주기를 진행하는 동안 지속적으로 수행된다.
테스터, 개발자 그리고 비즈니스 이해관계자 모두 기존의 수명주기에서와 마찬가지로 테스팅에서 각자의 역할을 가지고 있다. 개발자는 사용자 스토리에서 기능을 개발하고 단위 테스트를 수행하며, 이 후 테스터는 이러한 기능들을 테스트한다. 비즈니스 이해관계자도 구현기간 동안 스토리를 같이 테스트한다. 비즈니스 이해관계자는 작성된 테스트 케이스를 활용하기도 하고, 개발팀에게 빠른 피드백을 제공하기 위한 목적으로 기능을 사용해보기도 한다.
어떤 경우에는 잔존 결함 혹은 다른 형태의 기술 채무를 해결하기 위해 주기적으로 반복주기를 강화(Hardening)하거나 안정화(Stabilization)시키기도 한다. 그러나 가장 좋은 방법은 모든 기능이
시스템과 같이 테스트되고 통합되어야만 완료되었다고 간주하는 것이다 [Goucher09]. 또 다른 좋은 방법은 이전 반복주기에서 남겨진 결함들을 다음 반복주기 시작 시 모두 처리하는 것이다. 물론 결함들은 다음 반복주기의 백로그에 포함된다 (이것을 “결함 먼저 수정하기”라고 한다). 그러나 일각에서는 이러한 접근법을 사용하는 경우, 해당 반복주기에서 수행해야 할 태스크량을 전체적으로 확인할 수 없음은 물론, 남아 있는 기능들을 구현하는데 필요한 공수를 추정하기는 더 어렵다는 의견을 제시하기도 한다. 몇 차례의 반복주기가 완료된 시점에서 소프트웨어 인도(Delivery)를 위한 일련의 출시 활동이 발생할 수 있으며, 하나의 반복주기가 완료되는 시점마다 소프트웨어 인도가 발생할 수 있다.
테스트 전략의 하나로 리스크 기반 테스팅 전략을 사용하는 경우, 상위 레벨의 리스크 분석은 출시 계획 중에 수립하며, 대개 테스터들이 리스크 분석을 주도한다. 그러나, 각각의 반복주기와 관련된 특정한 품질 리스크는 반복주기 계획 단계에서 정의되고 평가된다. 리스크 분석 결과는 개발 순서는 물론, 구현된 기능과 관련된 테스팅의 우선 순위와 깊이에 영향을 미칠 수 있다. 또한 각 기능에 필요한 테스트 공수의 추정에 영향을 미친다(3.2절 참조).
일부 애자일 방법론(예: 익스트림 프로그래밍)에서는 페어링을 사용한다. 페어링 기법에서는 두 명의 테스터가 짝을 지어 하나의 기능을 같이 테스트하며, 경우에 따라 개발자와 테스터가 협업을 하기도 한다. 테스트 팀이 분산되어 있는 경우에는 페어링을 적용하기 쉽지 않으나, 분산된 페어링을 수행하기 위해 적절한 프로세스나 도구들을 활용할 수 있다. 분산된 환경에서의 태스크 수행에 대한 자세한 내용은 [ISTQB_ALTM_SYL] 2.8절을 참조한다.
테스터는 팀 내에서 테스팅 및 품질과 관련된 코칭 역할을 수행할 수 있다. 즉 테스팅 지식을 팀과 공유하고 팀의 품질 보증 태스크를 지원할 수 있으며, 이를 통해 제품 품질에 대한 공동의 책임을 독려한다.
많은 애자일 팀이 모든 테스팅 레벨에서의 테스트 자동화를 수행하고 있으며, 이는 테스터들이 자동화된 테스트 케이스와 수행 결과를 만들어내고, 실행하고, 모니터링하고 유지하는데 많은 시간을 사용해야 함을 의미한다. 자동화 테스트를 대량으로 수행하기 때문에, 애자일 프로젝트에서 수행되는 수동 테스팅의 대부분은 소프트웨어 공격, 탐색적 테스팅, 에러 추정과 같은 경험기반 혹은 결함기반 기법들이 사용된다 ([ISTQB_ALTA_SYL], 3.3 과 3.4 절 그리고 [ISTQB_FL_SYL], 4.5 절 참조).
개발자들은 단위 테스트 생성에 집중하며, 테스터는 자동화된 통합, 시스템, 시스템 통합 테스트를 만드는데 초점을 맞추어야 한다. 이런 이유로 애자일 팀은 높은 기술 및 테스트 자동화 경험을 가진 테스터를 선호하는 경향이 있다.

애자일 원칙의 한가지 핵심은 변화가 프로젝트 전반에 걸쳐 발생할 수 있다는 것이다. 따라서 애자일 프로젝트에서는 가벼운 제품 설명서를 선호한다. 기존 기능에 대한 변경은 테스팅 특히, 리그레션 테스팅에 영향을 미친다. 자동화된 테스팅의 사용은 변화와 관련된 테스트 노력의 양을 관리하는 하나의 방법이다. 그러나 변화의 양이 변화로 인해 발생 가능한 리스크에 대처할 수 있는 팀의 능력을 초과하지 않도록 주의해야 한다.

2.1.2 프로젝트 작업 산출물
애자일 테스터는 다음과 같은 세 가지 작업 산출물에 특히 관심을 가져야 한다:
1. 요구사항(예: 요구명세)과 사용 방법(예: 사용자 설명서)을 설명하는 비즈니스 중심의 산출물
2. 개발 작업 산출물: 시스템 설계(예: 데이터베이스 개체 관계 다이어그램), 실제 구현된 시스템(예: 코드) 또는 코드의 각 부분에 대한 평가(예: 자동화된 단위 테스트)
3. 테스트 작업 산출물: 시스템 테스트 방법(예: 테스트 전략과 계획), 실제 시스템 테스트 실행(예: 수동 및 자동화 테스트) 또는 테스트 결과 (예: 2.2.1절에서 언급된 테스트 대시 보드)
일반적으로 애자일 프로젝트에서는 많은 양의 문서 생산을 지양하며 대신 작동하는 소프트웨어 및 해당 소프트웨어가 요구사항을 만족함을 입증하는 자동화된 테스트 코드에 집중한다. 고객에게 가치를 전달하지 못하는 문서는 과감히 줄일 수 있다. 애자일 프로젝트에서는 문서를 줄여 개발 효율성을 증가시키는 관점과 비즈니스, 테스팅, 개발 및 유지보수 활동을 지원하기에 충분한 문서를 제공하는 관점의 균형이 맞물려 있다. 애자일 팀은 출시 계획을 수립하는 과정에서 필요한 산출물의 종류와 문서 작성 수준을 결정해야 한다.
애자일 프로젝트의 일반적인 비즈니스 중심 산출물에는 사용자 스토리와 인수 기준이 포함된다. 사용자 스토리는 요구사항 명세의 애자일 양식으로, 시스템이 하나의 일관된 특성 또는 기능으로 어떻게 동작하는지에 대해 설명이 들어있어야 한다. 사용자 스토리는 하나의 반복주기에서 완료될 수 있도록 작은 기능으로 정의해야 한다.
관련된 기능의 큰 집합 혹은 하나의 복잡한 기능으로 조합할 수 있는 하위 기능의 집합을 “에픽”이라고 부른다. 에픽은 다른 개발팀을 위한 사용자 스토리를 포함할 수 있다. 예를 들어, 하나의 사용자 스토리에서 API 레벨(미들웨어)에서 필요한 사항에 대해 설명하면서 다른 스토리에서는 UI 레벨(애플리케이션)에서 필요한 사항에 대해 설명할 수 있다. 이러한 집합은 스프린트 전체에 걸쳐 개발될 수 있다. 각각의 에픽과 사용자 스토리는 연관된 인수 기준을 가져야 한다.

애자일 프로젝트의 일반적인 개발자 산출물에는 코드가 포함된다. 애자일 개발자 역시 종종 자동화된 단위 테스트를 만들 수 있다. 이러한 테스트는 코드 개발 이후에 작성되기도 한다. 그러나 개발자가 코드의 각 부분을 작성한 후 제품이 예상대로 동작하는지 여부에 대한 검증 방법을 제공하기 위해 코드의 각 부분이 기록되기 전에 순차적인 테스트를 작성하는 경우도 있다. 이러한 방법을 테스트 우선 혹은 테스트 주도 개발이라고 일컫지만, 실제 이러한 환경에서 작성하는 테스트 코드는 테스트라기 보다 실행 가능한 하위 레벨의 설계 명세에 가깝다.
애자일 프로젝트의 일반적인 테스터 작업 산출물에는 자동화된 테스트와 여러 문서들이 포함된다. 이 문서에는 테스트 계획, 품질 리스크 카탈로그, 수동 테스트 케이스, 결함 리포트, 결함 결과 로그들이 포함된다. 이러한 문서들은 가능한 간단히 작성한다(전통적인 개발 라이프사이클에서도 이러한 문서들은 일반적으로 간단히 작성된다). 또한 테스터는 결함 리포트와 테스트 결과 로그로부터 테스트 통계를 도출하며, 통계 역시 가능한 가벼운 방식으로 접근한다.
일부 특별한 경우, 가령, 규제, 안전 우선, 분산된 환경 혹은 매우 복잡한 프로젝트나 제품을 구현하는 경우, 일부 애자일 팀은 이러한 작업 산출물을 보다 공식적으로 작성해야 할 수 있다. 예를 들어, 일부 팀은 사용자 스토리와 인수 조건을 좀 더 공식화된 요구사항 명세의 형태로 기술해야 할 수도 있다. 2차원 매트릭스(예: 수직 및 수평 추적) 보고서를 작성해서 감사, 규정 및 기타 요구 사항 만족여부를 확인해야 할 수 있다.

2.1.3 테스트 레벨
테스트 레벨은 대개 테스트 대상의 성숙도와 완성도에 관련된 테스트 활동들을 논리적으로 묶은 것이다.
순차 주기 모델에서는 테스트 레벨이 종종 어느 레벨의 종료 기준이 다음 레벨의 시작 조건의 일부라는 식으로 정의되기도 하지만, 일부 반복적 모델에서는 이 규칙이 적용되지 않는다. 테스트 레벨은 오버랩(중첩 혹은 동시 발생)된다. 요구 명세, 설계 명세 및 개발 활동은 테스트 레벨과 오버랩 될 수 있다.
일부 애자일 라이프사이클에서는 요구사항, 설계, 코드에 대한 변화가 반복주기 상의 모든 지점에서 발생할 수 있기 때문에 오버랩(중첩 또는 동시발생)이 발생한다. 스크럼에서는 이론적으로 반복주기 계획이 완료된 이후의 사용자 스토리가 변경되는 것을 허용하지 않으나, 실제 상황에서는 때로 변경이 발생한다. 반복주기가 진행되는 동안, 일반적인 경우 모든 사용자 스토리를 대상으로 다음과 같은 테스팅 활동을 순차적으로 적용한다:
● 단위 테스팅: 일반적으로 개발자가 수행한다
● 기능 인수 테스팅: 두 가지 활동으로 구분되어 수행되기도 한다
● 기능 검증 테스팅: 주로 자동화되어 개발자나 테스터에 의해 수행되며, 유저 스토리에 대한 인수 기준 검증을 포함한다
● 기능 확인 테스팅: 보통 수동으로 개발자, 테스터, 비즈니스 이해관계자가 함께 진행하며 구현된 기능이 사용 목적에 적합한지 확인하기 위해 개발자, 테스터 그리고 비즈니스 이해관계자의 협업이 포함될 수 있다
이와 함께 반복주기가 진행되는 동안 리크레션 테스팅이 병렬로 진행되는 경우가 있다. 이 병행 테스트 과정에는 현재 반복주기와 이전 반복주기에서의 자동화된 단위 테스트와 기능 베리피케이션 테스트가 수행되며, 지속적인 통합 프레임워크가 리그레션 테스트를 포함한다.
일부 애자일 프로젝트에서는 시스템 테스트 레벨을 적용하며, 해당 테스트 대상 사용자 스토리가 준비되는 즉시 시작된다. 시스템 테스트에는 기능 테스트는 물론 성능, 신뢰성, 사용성 및 다른 관련된 테스트 유형이 포함되기도 한다.
애자일 팀은 다양한 형태의 인수 테스트를 적용할 수 있다(ISTQB Foundation 실라버스 [ISTQB_FL_SYL] 에서 설명한 용어 사용). 각 반복주기 마다, 각 반복주기가 종료된 이후 또는 일련의 반복주기가 종료된 이후 내부 알파 테스트, 외부 베타 테스트, 사용자 인수 테스트, 운영 인수 테스트, 규제 승인 테스트 및 계약 승인 테스트를 수행할 수 있다.

2.1.4 테스팅과 형상 관리
애자일 프로젝트에서는 무거운 자동화 도구들을 많이 사용해 소프트웨어 개발, 테스트 및 관리를 수행한다. 개발자들은 도구를 사용해 정적 분석, 단위 테스팅, 코드 커버리지 측정을 수행한다. 개발자들은 지속적으로 코드와 단위 테스트 코드를 형상 관리 시스템에 입력하며, 자동화된 빌드 및 테스팅 프레임워크를 사용한다. 이 프레임워크는 기존 시스템과 새로운 소프트웨어를 지속적으로 통합하도록 해주며, 통합 과정에서 새롭게 체크인 된 코드에 대한 정적 분석과 단위 테스트를 자동으로 수행한다 [Kubaczkowski].
자동화 된 테스트는 통합 및 시스템 레벨에서 수행되는 기능 테스트를 포함할 수 있다. 이러한 기능 자동화 테스트 케이스는 테스팅 하네스, 오픈 소스 사용자 인터페이스 기능 테스트 도구, 혹은 상용 도구들을 사용해 생성할 수 있으며, 지속적인 통합 프레임워크의 한 부분으로 실행되는 자동화 테스트와 통합되기도 한다. 기능 테스트에 시간이 오래 소요되는 경우에는 단위 테스트와 별도로 실행하기도
하는데, 예를 들어 새로운 소프트웨어(코드)가 체크인 될 때마다 단위 테스트를 실행하는 반면 기능 테스트는 며칠을 주기로 실행할 수도 있다.
자동화 테스트의 목적 중 하나는 빌드가 작동 가능하고 설치 가능한지를 확인하는 것이다. 자동화 테스트가 실패하는 경우 팀은 다음 코드를 체크인 하기 전에 발견된 결함들을 모두 수정해야 한다. 이러한 자동화 테스트 결과를 효과적으로 표시하기 위해 실시간 보고에 대한 투자가 필요하다. 이러한 접근법은 빌드가 깨지거나 소프트웨어 설치가 실패하는 원인을 빠르게 감지하기 때문에 많은 전통적인 프로젝트에서 발생할 수 있는 “빌드 -> 설치 -> 실패 -> 재빌드 -> 재설치” 과정에서 발생하는 비용의 낭비와 효율성 저하를 줄일 수 있다.
자동화 테스팅과 빌드 도구는 종종 애자일 프로젝트에서 발생하는 잦은 변경과 관련된 리그레션 리스크를 관리하는데 도움이 된다 [Jones11]. 그러나 단위 테스트의 제한된 결함 검출 효율성[Jones11] 때문에 이러한 리스크를 관리하기 위해 과도하게 자동화된 단위 테스트에만 의존하는 것은 문제가 될 수 있다. 통합 레벨과 시스템 레벨의 자동화 테스트도 요구된다.

2.1.5 독립적 테스팅을 위한 조직 구성 옵션
ISTQB Foundation 실라버스[ISTQB_FL_SYL]에서 설명하고 있는 바와 같이, 개발팀과 별도로 독립적으로 구성된 팀의 테스터들은 결함을 더 효과적으로 발견할 수 있는 장점이 있다. 일부 애자일 팀에서는 개발자가 자동화 테스트 형식으로 여러 테스트를 생성한다. 각 팀에는 한 명 혹은 그 이상의 테스터가 포함될 수 있으며 이들은 다양한 테스팅 작업을 수행한다. 그러나 개발팀 내에 테스터가 포함되는 경우 독립성과 객관적인 평가를 하지 못하게 되는 위험 요소가 존재하게 된다.
이와 달리 어떤 애자일 팀은 완전히 독립적이고 개별적인 테스터 팀을 유지하며 각 스프린트의 마지막 날에 필요에 따라 테스터를 할당한다. 이는 독립성을 보장할 수 있으며, 이러한 테스터들은 소프트웨어의 공정하고 객관적인 평가를 제공할 수 있다. 그러나 이러한 방법을 사용할 경우 시간이나 제품의 새로운 기능에 대한 이해가 부족할 수 있으며 비즈니스 이해관계자와 개발자 사이의 관계에서 문제가 발생할 여지도 있다.
세 번째 옵션은, 장기적인 관점에서는 독립되고 분리된 테스트 팀을 운영하고 프로젝트가 시작되는 시점에 각 테스터들을 애자일 팀에 할당하는 방법이다. 이 방법을 통해 테스트 팀은 독립성을 유지하면서도 제품에 대해 깊이 이해할 수 있으며 다른 팀 멤버들과도 강력한 관계를 유지할 수 있다. 또한 전문적인 역량을 가진 테스터들을 애자일 팀에 할당하지 않고, 이들이 보다 장기적이거나 반복주기와 별개로 수행하는 태스크 즉, 자동화 테스트 도구 개발, 비기능 테스팅 수행, 테스트 환경 및

데이터 구축 및 지원, 하나의 스프린트에서 완료할 수 없는 레벨 테스트 수행(예: 시스템 통합 테스트) 등을 수행하도록 할 수 있다.


2.2 애자일 프로젝트의 테스팅 상태
애자일 프로젝트에서는 빠르게 변경사항이 발생하며, 이는 테스트 상태, 테스트 진행 및 제품의 품질이 끊임없이 진화한다는 것을 의미한다. 테스터는 이와 관련된 정보들을 애자일 팀에 전달해서 팀이 각 반복주기의 성공적 완료를 위해 적절한 의사 전달을 할 수 있도록 지원해야 한다. 또한 변화는 이전 반복주기에서 기존의 기능들에 영향을 줄 수 있다. 따라서 수동 및 자동화 테스트를 지속적으로 업데이트하여 리그레션 리스크를 효과적으로 처리해야 한다.

2.2.1 테스트 상태, 진행 및 제품 품질 커뮤니케이션
애자일 팀은 각 반복주기의 마무리 지점에 적절히 동작하는 소프트웨어를 제공하며 프로세스를 진행한다. 동작하는 소프트웨어의 제공 가능 시점을 결정하기 위해 개발팀은 반복주기와 출시의 모든 아이템 진행 상황을 예의 주시해야 한다. 애자일 팀의 테스터들은 다양한 방법을 활용해 테스트 진척과 상태를 기록한다. 여기에는 테스트 자동화 결과, 애자일 태스크 보드 상의 테스트 태스크와 스토리 진행 내용, 팀의 진척을 보여주는 번다운 차트 등이 포함된다. 기록한 테스트 진척과 상태는 팀 내 다른 멤버들과 위키 대시보드나 대시보드 스타일의 이메일 혹은 스탠드업 미팅 시에 구두로 공유한다. 애자일 팀은 위키 스타일 대시보드와 이메일을 업데이트하여 작업 진행과 테스트 결과에 기반한 상태 보고서를 자동으로 생성하는 도구를 활용할 수 있다. 이러한 의사소통 수단을 통해 프로세스 개선에 사용할 수 있는 테스트 프로세스에서 메트릭을 수집할 수 있다. 또한 자동화된 방식으로 테스트 상태를 의사 소통하는 것은 더 많은 테스트 케이스를 설계하고 실행하는데 집중할 수 있도록 테스터의 시간을 절약해줄 수 있다.
팀은 번다운 차트를 활용해서 전체 출시 기간과 각 반복주기 기간 중의 진척상황을 추적하기도 한다.
번다운 차트[Crispin08]는 출시 또는 반복주기에 할당 된 시간 및 그 안에 수행할 남아있는 작업의 양을 나타낸다.
테스트 상태를 포함해 전체 팀의 현재 상태를 즉각적이고도 자세하게 시각화하기 위해 애자일 태스크 보드를 사용할 수 있다. 스토리 카드, 개발 태스크, 테스트 태스크, 반복주기 계획 중 만들어진 다른 태스크 들(섹션 1.2.5 참조)은 태스크 보드에 표시하며, 각각 다른 색상의 카드를 사용해 태스크 종류를 구분한다. 반복주기가 진행되는 동안 이 태스크들의 진행 상황은 해당 태스크의 카드를 To do, WIP, Verify, Done와
같이 태스크 보드 위의 열 위에서 이동하면서 관리된다. 애자일 팀은 대시보드나 상태 업데이트를 자동화하는 도구를 사용해서 스토리 카드와 애자일 태스크 보드를 관리하기도 한다.
작업 보드의 태스크 작업은 사용자 스토리에 대해 정의된 인수 기준에 관한 것이다. 테스트 작업에 대한 테스트 자동화 스크립트, 수동 테스트 그리고 탐색적 테스트가 완료 기준을 달성하면 작업은 작업 보드의 done 열로 이동한다. 전체 팀은 정기적(주로 일일 스탠드업 미팅에서)으로 태스크 보드의 상태를 리뷰 함으로써 적절한 속도로 태스크들이 진행되고 있는지 확인한다. 전혀 진행되지 않거나 계획보다 너무 느리게 진행되는 태스크가 있는 경우, 팀은 해당 태스크를 리뷰하고 태스크의 진행을 방해하는 이슈들이 없는지 확인한다.
일일 스탠드업 회의에는 테스터를 포함해 애자일 팀의 모든 구성원이 참여한다. 이 회의는 각 구성원의 현재 상태 공유를 목적으로 하며 각 멤버는 다음 사항들을 공유한다 [Agile Alliance Guide]:
● 지난 일일 미팅 이후 완료한 작업은 무엇인가?
● 다음 회의까지 완료할 작업은 무엇인가?
● 현재 하고 있는 작업은 무엇인가?
테스트 진행을 방해할 수 있는 모든 문제도 일일 스탠드업 회의에서 다루어지므로, 전체 팀은 해당 문제를 함께 인식하고 적절하게 해결할 수 있다.
전반적인 제품의 품질을 향상시키기 위해 많은 애자일 팀은 고객 만족도 조사를 통해 제품이 고객의 기대를 충족시키는지에 대한 피드백을 수집한다. 팀은 테스트 성공/실패율, 결함 발견율, 확인과 리그레션 테스트 결과, 결함 밀도, 결함 발견과 수정률, 요구사항 커버리지, 리스크 커버리지, 코드 커버리지 그리고 제품 품질을 향상하기 위한 코드 변동과 같은 기존 개발 방법론에서 다루던 것과 유사한 다른 기준을 사용할 수 있다. 다른 라이프사이클과 동일하게 매트릭의 수집과 보고는 의사결정을 할 수 있도록 적절한 연관관계를 가지고 이루어져야 한다. 메트릭은 어떤 경우에도 구성원에 대한 보상, 처벌 또는 구분(차별)을 목적으로 사용되어서는 안 된다.

2.2.2 수동 및 자동화된 테스트 케이스 갱신을 통한 리스레션 리스크 관리하기
애자일 프로젝트에서는 각 반복주기가 종료됨으로써 제품이 완성되어 가며, 이와 함께 테스팅 범위 역시 증가한다. 현재 반복주기에서 발생한 코드 변경 테스팅과 함께, 테스터는 이전 반복주기에서 개발되고 테스트된 기능에 리그레션이 발생하지 않았는지 확인해야 한다. 애자일 개발에서 발생하는 리그레션 리스크로 인해 코드가 광범위하게 변경될 확률이 높다(현재 버전에서 다른 버전으로 코드 라인이 추가, 수정, 삭제됨). 변경에 대응하는 것이 애자일 원칙의 핵심이기 때문에, 비즈니스 요구를 만족시키기 위해
이미 고객에게 전달된 기능에도 변경 사항이 발생할 수 있다. 많은 기술 부채를 발생시키지 않으면서 개발 속도를 유지하기 위해, 팀은 가능한 조기에 모든 테스트 레벨에서 테스트 자동화에 투자해야 한다. 또한 모든 테스트 자산들, 예를 들어 자동화 테스트 케이스, 수동 테스트 케이스, 테스트 데이터 및 다른 테스팅 산출물 등은 매 반복주기가 수행될 때마다 최신 상태로 유지되어야 한다. 모든 테스트 자산들은 형상 관리 도구를 통해 관리하는 것이 바람직하다. 이를 통해 버전을 컨트롤하고 모든 팀 멤버가 해당 자산에 쉽게 접근하게 할 수 있으며 기존 테스트 자산의 이력 정보를 유지하면서도 기능 변경으로 인한 변화 내용을 적절하게 반영할 수 있다.
시간 압박이 강한 애자일 프로젝트의 경우 모든 테스트를 완전하게 반복하는 것이 거의 불가능하다. 따라서 테스터는 매 반복주기 마다 별도의 시간을 할당해 이전 반복주기와 현재 반복주기에서 수행한 수동 테스트 케이스와 자동화 테스트 케이스를 리뷰해서 리그레션 테스트 스위트에 할당 가능한 테스트 케이스를 선택해야 하고, 더 이상 수행할 필요가 없는 테스트 케이스는 제거한다. 초반의 반복주기에서 특정한 기능을 테스트하기 위해 작성한 테스트 케이스는 반복주기 후반에서는 그 가치가 작아질 수 있는데, 이는 기능 자체가 변경되거나 새로운 기능이 해당 기능의 동작 방식을 변경할 수 있기 때문이다.
테스트 케이스를 검토하는 동안, 테스터는 자동화에 대한 적합성을 고려해야 한다. 팀은 이전과 현재 반복주기에서 가능한 많은 테스트를 자동화 할 필요가 있다. 이를 통해 자동화된 리그레션 테스트를 수행함으로써 리그레션 테스트를 수동으로 수행했을 때보다 적은 공수를 사용해 리그레션 리스크를 줄일 수 있고, 테스터는 남은 시간을 현재 반복주기의 새로운 기능을 더 철저하게 테스트하는데 사용할 수 있다.
테스터는 현재 반복주기에서 발생한 변경에 의해 영향을 받은 이전 반복주기 및 출시 테스트 케이스를 확인하고 신속하게 업데이트 할 수 있는 역량을 반드시 가지고 있어야 한다. 팀이 테스트 케이스를 어떻게 설계하고 작성하고 저장할 지의 결정은 출시 계획 동안 수립한다. 테스트 설계 및 구현과 관련된 좋은 실천방법을 조기에 채택해 일관적으로 적용해야 한다. 각 반복주기에 대한 짧은 테스팅 일정과 지속적으로 발생하는 변경은 부족한 테스트 설계와 구현 실천방법의 영향을 증가시킬 것이다.
자동화 테스트를 적용함으로써 애자일 팀은 모든 테스트 레벨에서 제품 품질 관련 피드백을 빠르게 얻을 수 있다. 잘 작성된 자동화 테스트는 현재 시스템의 기능을 생생하게 기술한다 [Crispin08]. 자동화 된 테스트 케이스와 해당 테스트 케이스의 결과를 해당 제품의 빌드 버전과 함께 형상 관리 시스템에 저장함으로써 애자일 팀은 언제든 테스트 기능과 그 결과를 확인할 수 있게 된다.
자동화된 단위 테스트 코드에서 소스코드를 형상 관리 시스템의 메인 라인에 체크인하기 전에 수행하여, 변경한 코드가 소프트웨어 빌드를 중단시키지 않도록 해야 한다. 빌드가 깨지면 전체 팀의 업무 속도가 떨어지며, 이를 방지하기 위해서 자동화된 단위 테스트를 모두 통과한 코드만을 메인 라인에 체크인해야 한다. 자동화된 단위 테스트 결과는 코드와 빌드 품질에 대한 즉각적인 피드백을 제공하기는 하지만, 제품 품질의 좋고 나쁨에 대한 피드백을 제공하지는 못한다.
지속적인 통합을 전체 시스템 빌드에 적용하는 경우, 자동화된 인수 테스트를 정기적으로 실행한다. 전체 시스템을 대상으로 최소한 1회 이상 실행하며, 일반적으로 개별적인 코드 체크인이 발생하는 경우에는 실행하지 않는다. 이러한 테스트는 자동화된 단위 테스트를 수행할 때 보다 많은 시간을 필요로 하며 결과적으로 코드 체크인 속도를 저하시킬 수 있기 때문이다. 자동화 된 인수 테스트 시험 결과는 마지막 빌드의 리그레션에 대한 제품 품질 피드백은 제공하지만 전반적인 제품 품질 상태를 제공하지는 않는다.
자동화 테스트는 전체 시스템을 대상으로 지속적으로 실행할 수 있다. 핵심적인 시스템 기능과 통합 지점을 검증하기 위한 자동화 테스트의 초기 집합은 새로운 빌드가 테스트 환경에 배포되는 즉시 생성되어야 한다. 이러한 테스트는 일반적으로 빌드 베리피케이션 테스트로 알려져 있다. 빌드 베리피케이션 테스트 결과는 배포된 소프트웨어에 대한 즉각적인 피드백을 제공하므로 팀은 불안정한 빌드를 테스트하기 위해 시간을 소모하지 않아도 된다.
리그레션 테스트 셋에 포함된 자동화 테스트는 지속적 통합 환경에서 매일 주요 빌드의 일부로 실행되고, 테스트 환경에 새로운 빌드가 배포될 때 다시 실행된다. 자동화된 리그레션 테스트가 실패하는 즉시, 팀은 다른 작업을 멈추고 테스트가 실패한 이유를 조사한다. 현재 반복주기에서 정상적인 절차에 의해 변경된 기능으로 인해 테스트가 실패할 수 있으며, 이러한 경우 테스트 케이스 및 사용자 스토리는 새로운 인수 기준에 맞게 업데이트 되어야 한다. 이와 반대로 다른 테스트가 이미 변경된 내용을 커버하는 경우, 해당 테스트는 더 이상 필요하지 않을 수도 있다. 어떤 경우든 결함으로 인해 테스트가 실패하게 되면, 새로운 기능을 추가하기 전에 결함을 조치할 수 있으므로 팀에게 도움이 된다.
테스트 자동화와 더불어 다음의 테스트 업무들도 자동화가 가능하다:
● 테스트 데이터 생성
● 시스템의 테스트 데이터 기록
● 테스트 환경에 빌드 배포
● 테스트 기준점으로 테스트 환경(데이터 베이스 혹은 웹사이트 데이터 파일 등) 복원
● 데이터 결과 비교
이러한 태스크들을 자동화함으로써 해당 태스크를 수행하는데 필요한 오버헤드를 줄일 수 있으며, 팀은 개발과 새로운 기능 테스트에 집중할 수 있다.


2.3 애자일 팀의 테스터 역할과 역량
애자일 팀에서 테스터는 반드시 모든 다른 팀 구성원 및 비즈니스 이해관계자들과 협력해야만 한다. 이는 테스터가 가지고 있어야 할 역량과 애자일 팀에서 테스터들이 수행해야 하는 활동과 관련하여 많은 시사점을 제공한다.

2.3.1 애자일 테스터의 역량
애자일 테스터는 ISTQB Foundation Level 실라버스에서 언급된 모든 역량을 보유하고 있어야 한다. 이 뿐 아니라 테스트 자동화, 테스트 주도 개발, 인수 테스트 주도 개발, 화이트박스, 블랙박스 테스팅은 물론 경험기반 테스팅 역량도 보유해야 한다.
애자일 방법론은 협업, 팀 멤버 및 팀 외부 이해관계자화의 상호 작용을 매우 중시하기 때문에 애자일 팀의 테스터는 다음과 같은 뛰어난 대인 관계 역랑을 가지고 있어야 한다:
● 팀 멤버들 및 이해관계자와 협업 시 긍정적이며 문제 해결 중심적인 태도로 임한다
● 제품과 관련해 핵심적이고, 품질 중심적이며, 비판적인 생각을 제안한다
● 작성된 명세에 전적으로 의존하기보다는 이해관계자로부터 적극적으로 정보를 획득한다
● 테스트 결과, 테스트 진척 및 제품 품질 등에 대해 정확하게 평가하고 보고한다
● 고객 대표자 및 이해관계자들과의 효과적인 협업을 통해 테스트 가능한 사용자 스토리, 특히 인수 기준을 정의한다
● 프로그래머 및 다른 팀 멤버 등 팀 내에서 협업한다
● 변경, 추가 또는 테스트 개선 등 변화에 빠르게 대응한다
● 스스로 작업을 조직화하고 계획을 수립한다
애자일 팀에 소속된 테스터를 포함하여 모든 테스터는 대인 관계 역량을 지속적으로 키워나가야 한다.

2.3.2 애자일 팀의 테스터의 역할
애자일 팀의 테스터는 테스트 상태, 테스트 진척, 제품 품질에 대한 피드백을 생성하고 제공하는 것뿐만 아니라 프로세스 품질에 대한 피드백도 함께 제공해야 한다. 이 실라버스에서 기술된 활동들뿐만 아니라 다음과 같은 활동도 수행해야 한다:
● 테스트 전략을 이해하고 실행하며 업데이트 한다
● 적용 가능한 모든 커버리지 영역에서 테스트 커버리지를 측정하고 보고한다
● 적절한 테스팅 도구의 사용을 보장한다
● 테스트 환경과 테스트 데이터를 구성하고 활용하며 관리한다
● 결함을 보고하고 해당 결함을 해결하게 위해 팀과 협업한다
● 팀 멤버들에게 테스팅 관련 코칭을 제공한다
● 출시 계획 및 반복주기 계획에 적절한 테스팅 업무를 반영한다
● 개발자 및 비즈니스 이해관계자들과 능동적으로 협력해 요구사항, 특히 테스트 가능성, 일관성, 완전성 측면을 명확화 한다
● 팀 회고에 적극적으로 참여하여 개선안을 제안하고 구현한다
애자일 팀의 모든 멤버는 제품 품질에 대해 책임을 지며 테스트와 관련된 태스크들을 수행한다.
애자일 조직은 다음과 같은 테스트와 관련된 조직적인 리스크를 마주할 수 있다:
● 테스터가 개발자와 너무 밀접하게 작업하여 적절한 테스터 사고 방식을 잃을 수 있다
● 테스터가 팀 내에서 비효율적, 비효과적 또는 낮은 품질 관행에 대해 관용 또는 침묵할 수 있다
● 테스터가 제한된 시간의 반복주기에서 발생하는 변화의 속도를 따라갈 수 없다
이러한 리스크를 완화하기 위해 2.1.5절에서 언급했듯이 테스터의 독립성을 보장할 수 있는 조직 형태를 고려해야 할 수 있다.