자격증/Agile Tester2020. 4. 2. 08:00

키워드
인수 조건, 탐색적 테스팅, 성능 테스팅, 제품 리스크, 품질 리스크, 회귀 테스팅, 테스트 접근법, 테스트 차터, 테스트 추정, 테스트 자동화, 테스트 전략, 테스트 주도 개발, 단위 테스트 프레임워크

학습 목표
3.1 애자일 테스팅 방법
3.1.1  테스트 주도 개발, 인수테스트 주도 개발, 행위 주도 개발의 개념을 상기한다
3.1.2  테스트 피라미드의 개념을 상기한다
3.1.3  테스팅 사분면과 각 사분면의 테스팅 레벨 및 테스팅 종류와의 상관관계를 설명한다
3.1.4  애자일 프로젝트의 스크럼 팀에서 테스터 역할을 수행할 있다
3.2 품질 리스크 식별 및 테스트 노력 추정
3.2.1  애자일 프로젝트의 품질 리스크를 식별한다
3.2.2  품질 리스크와 반복주기 내용에 기반하여 테스팅에 필요한 자원을 추정한다
3.3 애자일 프로젝트의 기법들
3.3.1  테스팅 활동을 지원하기 위한 관련 정보를 이해한다
3.3.2  비즈니스 이해관계자들이 테스트 용이성이 있는 인수 조건을 정의하도록 설명한다
3.3.3  주어진 유저스토리에 대해 인수 테스트 주도 개발의 테스트케이스를 작성한다
3.3.4  주어진 유저스토리에 대해 블랙박스 테스트 설계 기법을 활용하여 기능적, 비기능적 행위의 테스트 케이스를 작성한다
3.3.5  탐색적 테스팅을 수행하여 애자일 프로젝트의 테스팅을 지원한다
3.4 애자일 프로젝트의 도구들
3.4.1  애자일 프로젝트에서의 테스팅 목적과 활동에 맞춰 적용 가능한 다양한 도구들을 상기한다


3.1 애자일 테스팅 방법
애자일 적용 여부와 관계없이 높은 품질의 제품을 만들고자 하는 모든 개발 프로젝트에 적용 가능한 테스팅 실천방법들이 있다. 이 실천방법들은 적절한 동작을 표현하기 위해 미리 테스트를 작성하고, 초기 결함의 예방, 발견 및 제거에 초점을 맞추고, 적절한 테스트가 적절한 시간에 올바른 테스트 레벨의 활동으로 수행되는 것을 보장한다. 이런 실천방법을 널리 전파하고자 하는 것이 애자일 실천가들의 목표이다. 애자일 프로젝트에서 테스터는 전체 개발 수명주기에 걸쳐 테스팅 방법을 안내하는 핵심적인 역할을 하게 된다.

3.1.1 테스트 주도 개발, 인수 테스트 주도 개발, 행위 주도 개발
테스트 주도 개발, 인수 테스트 주도 개발, 행위 주도 개발은 다양한 테스트 레벨의 테스트를 수행하기 위해 애자일 팀이 사용하는 세 가지 상호 보완적인 방법이다. 코드 작성 전에 테스트가 정의되어 있기 때문에 각각의 기술은 개발 초기의 테스트 및 QA 활동이 주는 효과에 대한 좋은 사례가 된다.
테스트 주도 개발
테스트 주도 개발 (TDD)는 자동화된 테스트 케이스에 맞추어 코드를 개발하는 방법이다. 테스트 주도 개발을 위한 프로세스는 다음과 같다:
● 테스트(코드)를 추가한다. 테스트 코드는 구현되어야 할 기능에 대한 프로그래머의 개념을 확인하기 위한 작은 코드이다;
● 테스트를 실행한다. 코드가 존재하지 않기 때문에 테스트는 실패한다;
● 코드를 작성하고 테스트가 통과할 때까지 계속 테스트를 실행하고 이를 반복한다;
● 테스트가 통과되면 코드를 리팩토링한다. 리팩토링 이후의 정상 동작여부를 파악하기 위해 테스트를 실행한다;
● 코드의 다음 조각에 대해서 이 과정을 반복한다.
테스트는 주로 코드에 집중된 단위테스트 레벨 위주지만, 통합 또는 시스템 테스트 레벨에서도 진행될 수 있다. 테스트 주도 개발은 익스트림 프로그래밍을 통해 인기를 얻었지만, 다른 애자일 방법론이나 폭포수 방법론에서도 사용 가능하다. 테스트 주도개발은 개발자가 명확하게 정의된 예상 결과에 초점을 맞출 수 있도록 해준다. 작성된 테스트는 테스트 자동화와 지속적인 통합에 사용된다.
.

인수 테스트 주도 개발
인수 테스트 주도 개발은 사용자 스토리를 작성하는 동안 인수 기준 및 테스트 방법을 정의한다 (1.2.2 절 참조). 인수 테스트 주도 개발은 모든 이해 관계자가 소프트웨어 구성요소가 동작하는 방식을 이해하고,
개발자, 테스터 및 업무 대표자가 이 동작을 보장하기 위해 필요한 테스트를 함께 만드는 공동 접근 방식이다. 인수 테스트 주도 개발의 과정은 3.3.2 절에 설명되어 있다.
인수 테스트 주도 개발은 회귀 테스트를 위한 재사용 가능한 테스트를 만든다. 지속적인 통합 프로세스 내부에서 이러한 테스트의 생성 및 실행을 지원하는 도구들도 있다. 이런 도구는 시스템 테스트 또는 인수 테스트 레벨에서 실행할 수 있도록 프로그램의 데이터 및 서비스 층을 연결할 수도 있다. 인수 테스트 주도 개발은 결함과 기능 동작의 검증을 신속하게 해결할 수 있다. 이때 인수 기준은 기능에 대한 완료 여부를 결정하는 데 도움이 된다.

행위 주도 개발
행위 주도 개발 [Chelimsky10]에서는 개발자가 기대하는 소프트웨어 동작에 기반하여 코드를 테스트 하는데 초점을 맞출 수 있다. 테스트가 소프트웨어의 특정 행위를 기반으로 하기 때문에, 일반적으로 다른 팀 구성원 및 이해 관계자가 이해하기 쉽다.
특정 행위 주도 개발 프레임워크는 Given/When/Then의 형식으로 인수 기준을 정의할 수 있다:
Given 특정 상황에서, 
When 이벤트가 발생하면,
Then 다음 몇 가지 결과를 확인한다
행위 주도 개발 프레임워크는 요구사항으로부터 도출된 테스트 케이스를 개발자가 사용할 수 있는 코드로 변환한다.
행위 주도 개발은 개발자가 비즈니스 요구 사항에 초점을 맞추어 정확한 단위 테스트를 정의하여 테스터 등 다른 이해 관계자들과 협력하는 것을 돕는다.

3.1.2 테스트 피라미드
소프트웨어 시스템은 다양한 레벨에서 테스트 될 수 있다. 일반적인 테스트 레벨([ISTQB_FL_SYL] 2.2 절 참조)은 피라미드의 맨 아래부터 위로 순차적으로 단위, 통합, 시스템 및 인수 테스트 순으로 존재한다. 피라미드는 하위 레벨(피라미드의 바닥)에서는 테스트의 양이 강조되고, 상위 레벨(피라미드의 상위)로 올라갈수록 테스트의 양은 감소한다. 보통 단위 및 통합 레벨의 테스트는 자동화 및 API 기반 도구를 사용하여 생성된다. 시스템 및 인수 레벨에서 자동화된 테스트는 GUI 기반 도구를 사용하여 생성된다. 테스트 피라미드 개념은 조기 결함 검출의 원리(즉, 가능한 한 빨리 결함을 찾아서 제거)에 기초한다.

3.1.3 테스팅 사분면, 테스트 레벨, 테스트 유형
브라이언 머릭이 정의한 테스팅 사분면은 각 테스팅 레벨을 애자일 방법론에서 사용하는 테스팅 유형으로 잘 분류하고 있다. 테스트 사분면 모델 및 그 변종은 모든 중요한 테스트 유형과 테스트 레벨이 개발 수명 주기에 포함되어 있는지 확인하는데 도움이 된다. 또한, 이 모델은 개발자, 테스터, 업무 대표자 등 모든 이해관계자에게 테스트의 유형을 구별하고 설명하는 방식이 된다.
테스트 사분면에서 테스트는 비즈니스에 직면(사용자)하거나 또는 기술(개발자)에 직면한 것으로 분류될 수 있다.
일부 테스트는 애자일 팀에 의해 수행된 작업을 지원하고, 소프트웨어의 동작을 확인한다. 다른 테스트는 제품을 확인할 수도 있다. 테스트는 완전 수동 혹은 완전 자동 혹은 자동과 수동의 조합으로 만들어질 수 있다. 네 개의 사분면은 다음과 같다:
● 1사분면은 단위 레벨, 기술적 측면이며, 개발자를 지원한다. 여기에는 단위 테스트가 포함된다. 1사분면의 테스트는 자동화되어야 하고, 지속적인 통합 절차에 포함되어야 한다.
● 2사분면은 시스템 레벨에서 비즈니스에 직면하고 있다. 여기에서는 제품의 동작을 확인한다. 따라서, 기능 테스트, 스토리 테스트, 사용자 경험 프로토타입 및 시뮬레이션이 포함되어 있다. 2사분면의 테스트는 인수 기준을 확인하며, 수동 또는 자동으로 수행된다. 인수 기준은 종종 사용자 스토리를 개발하는 동안 생성되고, 이는 스토리의 품질을 향상시키는데 도움이 된다. 또한, 자동화된 회귀 테스트 스위트를 만들 때에도 유용하다.
● 3사분면은 시스템 또는 제품 인수 테스트 레벨에서 비즈니스에 직면하고 있다. 여기에서는 사실적인 시나리오와 데이터를 사용하여 제품을 비판하는 테스트가 포함되어 있다. 3 사분면은 시나리오 및 프로세스 흐름 테스트, 사용성 테스트, 사용자 인수 테스트, 알파 테스트, 베타 테스트를 포함한다. 이런 테스트는 종종 수동이며 사용자 중심적이다.
● 4사분면은 시스템 또는 운영 인수 테스트 레벨에서 기술에 직면하고 있다. 여기에서는 제품의 비판 테스트가 포함되어 있다. 4사분면은 성능, 부하, 스트레스, 및 확장성 테스트, 보안 테스트, 유지 관리, 메모리 관리, 호환성 및 상호 운용성, 데이터 마이그레이션, 인프라 및 복구 테스트를 포함한다. 이런 테스트는 보통 자동화되어 있다.
반복주기를 반복하는 동안, 모든 사분면에 걸쳐 테스트를 진행해야 할 수도 있다. 테스트 사분면은 정적 테스트보다는 동적 테스트에 더 적합하다.

3.1.4 테스터의 역할
실라버스 전반에 걸쳐 애자일 방법론과 기법, 다양한 애자일 수명 주기 내에서 테스터의 역할을 참조했다. 이번 섹션은 스크럼 수명 주기[Aalst13]를 따르는 프로젝트에서 테스터의 역할에 대해 특별히 살펴볼 것이다.
팀워크
팀워크는 애자일의 기본 원칙이다. 애자일는 함께 일하는 개발자, 테스터 및 업무 대표자로 구성된 전체 팀 접근 방식을 강조한다. 모범적인 스크럼 팀의 특징은 다음과 같다:
● 교차 기능팀: 각 팀 구성원이 팀에 다양한 기술 영역을 제공한다. 이 팀은 테스트 전략, 테스트 계획, 테스트 설계, 테스트 실행, 테스트 평가 및 시험 결과 보고를 함께 진행한다.
● 자기 조직화: 팀은 개발자로만 구성할 수도 있지만, 2.1.5 절에서 언급 한 바와 같이 최소 한 명 이상의 테스터를 포함하는 것이 이상적이다.
● 공간 공유: 테스터는 개발자 및 제품 소유자와 같은 공간에서 함께 일한다.
● 협업: 테스터들은 자신의 팀 구성원, 다른 팀, 이해 관계자, 제품 소유자 및 스크럼 마스터와 공동 작업을 수행한다.
● 위임: 필요한 경우 설계와 테스트에 관한 기술 결정은 제품 소유자 및 다른 팀과 협력하여 팀 전체(개발자, 테스터, 그리고 스크럼 마스터)가 만든다.
● 헌신: 테스터는 질문과 기대와 고객과 사용자의 요구 사항과 관련하여 제품의 동작 및 특성을 평가하기 위해 최선을 다한다.
● 투명성: 개발 및 테스트의 진행 상황을 애자일 상황판에서 볼 수 있다 (2.2.1 절 참조).
● 신뢰: 테스터는 테스트 설계 및 실행 전략에 대한 신뢰를 확보해야 한다. 그렇지 않으면 이해 관계자가 테스트 결과를 신뢰하지 않는다. 이는 종종 테스트 프로세스에 대한 정보를 이해 관계자에게 제공함으로써 만들어지기도 한다.
● 열린 피드백: 피드백은 특히 애자일 프로젝트에서 성공의 중요한 기초이다. 회고는 팀이 성공과 실패에서 배우고 성장하도록 만든다.
● 탄력성: 테스팅는 애자일 프로젝트의 다른 모든 활동과 마찬가지로 변화에 기민하게 대응할 수 있어야 한다.
이러한 모범적인 팀의 특성은 스크럼 프로젝트에서 테스트의 성공 가능성을 극대화하는데 도움이 된다.
스프린트 제로
스프린트 제로는 프로젝트의 첫 번째 반복주기로 많은 준비 활동을 포함하고 있다 ( 1.2.5참고). 테스터는 스프린트 제로에서 팀과 협업해 다음 활동을 수행 한다:
● 프로젝트의 범위 정의 (예: 제품 백로그)
● 초기 시스템 아키텍처와 프로토타입 생성
● 필요한 도구를 계획, 수급, 설치 (예: 테스트 관리, 결함 관리, 테스트 자동화, 형상 관리)
● 모든 테스트 레벨에 걸쳐 테스트 범위, 기술적 리스크, 테스트 종류(섹션 3.1.3참고), 커버리지 목표를 포함한 초기 테스트 전략 수립
● 초기 품질 리스크 분석 수행 (섹션 3,2.1 참고)
● 테스트 프로세스, 진척율, 제품 품질을 측정하기 위한 품질 지표 정의
● "완료"의 의미 정의
● 태스크 보드 생성(섹션 2,2,1 참고)
● 고객에게 제품을 전달하기 전에 테스팅의 지속 및 중단 여부 정의
스프린트 제로에서는 전체 스프린트가 진행되는 동안 어떤 테스팅이 수행되어야 하는지, 어떻게 테스팅을 진행할지에 대한 방향을 설정한다.
통합
애자일 프로젝트에서 이상적인 목표는(가능한 모든 스프린트에서) 지속적으로 고객에게 가치를 전달하는 것이다. 이를 위해서 통합 전략은 설계와 테스트를 모두 고려해야 한다. 출시할 기능과 특징을 지속적으로 테스트하려면, 기본 기능과 기능 사이의 모든 종속 관계를 확인하는 것이 중요하다.
테스트 계획
테스트가 애자일 팀에 완전히 통합되면, 테스트 계획은 릴리즈 계획 시 시작되고 각 스프린트 동안 업데이트 된다. 각 릴리즈와 스프린트의 테스트 계획은 섹션 1.2.5에서 제시한 내용을 다루어야 한다.
스프린트 계획의 결과, 모든 일은 하루나 이틀 분량의 태스크로 정의되어 태스크 보드에 기재된다. 또한, 모든 테스팅 이슈는 테스팅의 흐름을 지속적으로 유지하기 위해 추적되어야 한다.
애자일 테스팅 실천방법
스크럼 팀에서 테스터는 많은 실천 방법들을 적용할 수 있으며, 여기에는 다음과 같은 실천방법들도 포함된다:
● 페어링: 두명의 멤버(예: 개발자와 테스터, 테스터와 테스터, 테스터와 제품 소유자)가 테스트 또는 다른 작업을 수행하기 위해 하나의 동일한 작업 공간 앞에 함께 앉아 공동으로 태스크를 수행한다.
● 점진적인 테스트 설계: 사용자 스토리 및 기타 테스트 베이시스로부터 만들어진 테스트 케이스 및 차터가 점진적으로 간단한 테스트에서 시작해서 더 복잡한 테스트를 향해 발전한다.
● 마인드맵: [Crispin08] 테스트할 때 마인드맵은 유용한 도구이다. 예를 들어, 테스터는 테스트 전략을 표시하거나, 테스트 데이터를 설명하거나, 수행된 테스트 세션을 식별하기 위해 마인드맵을 사용할 수 있다.
위에 언급된 실천방법들을 포함한 다른 실천방법들은 ISTQB Foundation 실라버스 4장에 설명되어 있다.


3.2 품질 리스크 식별 및 테스트 노력 추정
테스팅의 일반적인 목적은 릴리즈 이전에 허용 가능한 수준으로 품질 문제의 리스크를 감소시키는 것이고, 애자일이든 전통적인 프로젝트이든 이러한 목적은 동일하다. 그러나, 짧은 반복주기와 애자일 프로젝트의 잦은 변화에 대응하기 위해서 일부 변형이 필요하다.

3.2.1 애자일 프로젝트에서 품질 리스크 식별하기
테스팅에서 직면하는 도전 중 하나는 테스트 컨디션을 적절하게 선택하고, 할당하며 우선 순위를 선정하는 것이다. 이것은 각 시험 조건을 커버하기 위해 할당할 적절한 노력의 양을 결정하고, 테스트 작업의 효율성 및 효율을 최적화하기 위한 테스트 절차를 포함한다. 많은 제약 사항과 변수를 고려해야 하지만, 리스크 식별, 분석 및 리스크 완화 전략은 애자일 팀의 테스터가 실행할 테스트 케이스의 수를 결정하는 데 도움이 된다.
리스크란 부정적이거나 원하지 않는 결과 혹은 이벤트가 발생할 수 있는 가능성을 의미한다. 리스크의 수준은 발생 가능성과 영향도를 평가함으로써 파악할 수 있다. 제품의 품질에 잠재적인 문제가 있는 경우, 이 잠재적인 문제는 품질 리스크 또는 제품 리스크로 나타난다. 프로젝트에 잠재적인 문제가 있는 경우, 이 잠재적인 문제는 프로젝트의 리스크 또는 계획 과정의 리스크로 나타난다 [vanVeenendaal12] [Black07].
애자일 프로젝트에서 품질 리스크 분석은 두 군데에서 이루어진다:
● 릴리즈 계획: 기능의 리스크에 대해 전반적으로 파악하고 있는 업무 대표자와 테스터를 포함한 전체 팀이 리스크를 식별하고 평가한다.
● 반복주기 계획: 전체 팀이 품질 리스크를 식별하고 평가한다.
시스템 품질 리크스에는 다음 사항들이 포함된다:
● 보고서의 잘못된 계산식(기능적 리스크로 정확성과 관련됨)
● 사용자 입력에 대한 느린 응답(비기능 리스크로 효율성 및 응답 시간과 관련됨)
● 이해하기 어려운 화면 구성 및 입력 필드(비기능 리스크로 사용성 및 이해도와 관련됨)

앞서 언급한 바와 같이 반복주기는 반복주기 계획에서 시작하며, 반복주기 계획은 추정한 태스크들을 태스크 보드에 붙임으로써 마무리된다.
이 태스크들은 해당 태스크들과 관련된 품질 리스크의 수준에 기초해 우선 순위를 정할 수 있다.
높은 리스크과 관련된 작업은 빠르게 시작하고 더 많은 테스트 노력을 배정해야 하며, 낮은 리스크와 관련된 작업은 나중에 시작하고 테스트 노력을 상대적으로 덜 배정해야 한다.
다음은 반복주기 계획 시 애자일 프로젝트의 품질 리스크의 분석 과정을 예로 든 것이다:
1. 애자일 팀원 전체를 모은다. 물론 테스터도 포함된다;
2. 현재 반복주기의 모든 백로그 아이템을 나열한다;
3. 적절한 품질 특성을 고려하여 각 아이템에 대한 품질 리스크를 식별한다;
4. 식별한 리스크를 진단한다. 리스크를 분류하고 영향도와 발생 빈도에 따라 리스크의 수준을 파악한다;
5. 리스크의 수준에 따라 테스트의 수준을 결정한다;
6. 리스크, 리스크 수준, 품질 특성을 고려하여 각 리스크를 해결하기 위한 적절한 테스트 기법을 선택한다.
이후 테스터는 테스트 설계, 구현, 실행을 통해 리스크를 완화한다. 테스트는 고객, 사용자, 이해 관계자의 만족도에 영향을 미치는 기능, 행동, 품질 특성 및 속성 전체를 포함한다.
프로젝트 전반에 걸쳐 팀은 리스크 또는 알려진 품질 리스크 수준을 변화시키는 정보에 대해 항상 파악하고 있어야 한다. 테스트에 대한 결과를 반영하여 주기적으로 품질 리스크를 분석하고 조절한다. 조절 단계에는 기준 리스크 수준의 재평가, 새로운 리스크의 식별, 리스크 완화 활동에 대한 효과 평가 등이 포함된다.
테스트 실행 전에도 품질 리스크를 완화시킬 수 있다. 예를 들어, 사용자 스토리 관련 문제가 리스크 식별 과정에서 발견된 경우, 프로젝트 팀은 완화 전략으로 사용자 스토리를 철저하게 리뷰할 수 있다.

3.2.2 리스크와 내용을 근거로 테스트 노력 추정하기
출시 계획 과정에서 애자일 팀은 출시를 완료하기 위한 공수를 추정하며, 여기에는 물론 테스팅을 위한 공수도 포함된다. 애자일 프로젝트에서는 일반적으로 플래닝 포커 기법을 사용해 공수를 추정하는데, 이 기법은 참여자의 합의에 기반을 두고 있다. 제품 소유자 또는 고객은 공수를 추정해야 할 사용자 스토리를 읽는다. 스토리의 공수를 추정하는 인원들은 피보나치 수열(0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 99, ……)과 같은 값 혹은 다른 방식의 순차적으로 증가하는 값(예: 가장 작은 것부터 가장 큰 셔츠의 크기)이 적힌 한 세트의 카드를 가지고 있다. 카드의 각 숫자는 해당 팀이 추정한 공수를 의미하며, 스토리의 크기에 따라
공수에 대한 불확실성이 기하급수적으로 증가할 수 있으므로, 피보나치 열을 사용할 것을 권장한다. 높은 추정치는 일반적으로 스토리가 잘 이해되지 않거나 여러 개의 작은 스토리로 분해되어야 한다는 것을 의미한다.
추정에 참여하는 사람들은 기능에 대해 논의하며 필요하다고 생각되는 모든 질문을 제품 소유자에게 던져야 한다. 추정을 함에 있어서 개발 및 테스팅 공수, 스토리의 복잡성, 테스팅 범위 등의 내용도 고려해야 한다. 따라서, 플래닝 포커가 시작되기 전에, 제품 소유자가 정한 우선 순위에 추가로 백로그 항목의 리스크 레벨을 표기하는 것이 바람직하다. 기능을 논의할 때, 각 추정자는 개인적으로 자신의 추정치를 대표하는 하나의 카드(숫자)를 선택한다. 모든 사람이 카드를 다 고르면 카드를 동시에 공개한다. 모든 추정치가 같은 카드일 경우 그 값을 추정치로 사용하고, 같은 추정치의 카드가 아닌 경우, 추정에 참여한 사람들은 추청치가 상이한 이유에 대해 논의하고 동일한 추정치에 도달할 때까지 추정을 반복한다. 포커 라운드 수를 제한하기 위해 카드 사용 규칙(예를 들면, 최종적으로 평균값을 사용하거나 최대값을 선택할 수 있다)을 별도로 정의할 수 있다.
이 토론은 제품 소유자가 요청한 제품 백로그 항목에서 해야 할 작업에 대한 집단의식을 향상시키고, 추정의 신뢰성을 높이는 데 도움이 된다 [Cohn04].


3.3 애자일 프로젝트의 테스트 기법들
전통적인 프로젝트에 적용된 테스트 및 테스트 기법의 대부분은 애자일 프로젝트에도 적용할 수 있다. 다만 테스트 기법, 용어 및 문서화와 관련해 조금 더 주의를 기울여야 할 차이점들이 있다.

3.3.1 인수 조건, 적절한 커버리지, 테스팅을 위한 기타 정보
애자일 프로젝트는 프로젝트의 초기 요구 사항을 백로그 우선 순위에 따라 사용자 스토리에 기재한다. 초기 요구 사항은 짧고 일반적으로 미리 정의된 형식을(1.2.2 절 참조) 따른다. 사용성 및 성능과 같은 비기능 요구 사항 역시 똑같이 중요하며, 이들은 고유의 사용자 스토리 혹은 다른 기능 사용자 스토리에 연결하여 명세를 작성할 수 있다. 비기능 요구 사항은 미리 정의된 형식이나 ISO25000과 같은 국제 표준 또는 특정 산업 표준을 따를 수 있다.
사용자 스토리는 중요한 테스트 베이시스의 하나이며, 이 외에 다음과 같은 요소들을 테스트 베이시스에 포함시킬 수 있다:
● 이전 프로젝트의 경험
● 해당 시스템에 이미 존재하는 기능 및 품질 특성
● 코드, 아키텍처, 디자인
● 사용자 프로파일 (컨텍스트, 시스템 설정 및 사용자 행동)
● 현재 및 과거 프로젝트의 결함 정보
● 결함 사전의 결함 분류
● 적용되는 표준 (예: DO-178B, 등)
● 품질 리스크 (섹션 3.2.1 참고)
각 반복주기 동안, 개발자는 사용자 스토리에서 설명하는 특정한 품질 특성과 관련된 기능/특징의 구현을 위해 코드를 생성하고, 이 코드는 확인 및 인수 테스트를 통해 검증된다. 테스트가 가능하기 위해 인수 기준은 다음과 같은 주제를 반드시 포함해야 한다 [Wiegers13]:
● 기능 동작: 특정 설정에서 입력된 사용자의 행위에 대해 외부에서 관찰 가능한 동작 결과
● 품질 특성: 시스템이 지정된 동작을 수행하는 방법. 특성은 품질 속성 또는 비기능 요구사항을 포함할 수 있다. 일반적인 품질 특성으로는 성능, 안정성, 사용성 등이 있다
● 시나리오 (유스 케이스): 특정 목표 또는 비즈니스 작업을 수행하기 위한 외부 액터 (주로 사용자)와 시스템 사이의 작업 순서
● 비즈니스 규칙: 외부 절차나 제약사항에 의해 정의된 특정 조건 하에서 시스템에서 수행할 수 있는 활동 (예: 보험 청구를 처리하도록 보험 회사에서 사용하는 절차 등)
● 외부 인터페이스: 개발된 시스템과 외부 세계의 연결에 대한 설명. 외부 인터페이스는 서로 다른 유형으로 구분할 수 있다 (사용자 인터페이스, 다른 시스템 인터페이스 등)
● 제약 사항: 개발자의 옵션을 제한하는 모든 설계 및 구현의 제약 사항. 임베디드 소프트웨어를 탑재한 장비들은 일반적으로 크기, 무게, 인터페이스 연결과 같은 물리적 제약을 준수해야 한다
● 데이터 정의: 고객이 복잡한 구조의 비즈니스 데이터에 대해서 각 항목의 포맷, 데이터 종류, 허용되는 값 및 디폴트 값을 기술할 수 있다 (예: US 우편 주소의 ZIP 코드 등)
사용자 스토리 및 이와 관련된 인수 조건 외에도 테스터는 다음과 같은 부가적인 정보를 고려해야 한다:
● 시스템의 의도된 동작 방식 및 사용 방식
● 시스템을 테스트하는데 사용할 수 있는 시스템 접근/사용 인터페이스
● 현재 사용하는 도구 지원의 충분성 여부
● 테스터가 시험을 수행하는데 필요한 충분한 지식과 기술이 있는지의 여부
반복주기가 진행되는 과정에서 테스터들은 종종 추가적인 정보(예: 코드 커버리지 등)의 필요성을 발견하게 되므로 다른 애자일 팀 멤버들과의 협업을 통해 이러한 정보들을 수집해야 한다. 관련 정보는
특정 작업을 완료로 간주할 수 있는지의 여부를 결정하는 역할을 한다. 애자일 프로젝트에서 완료 정의는 매우 중요하며, 이어지는 절에서 논의할 바와 같이 다양한 방식으로 적용된다.

테스트 레벨
각 테스트 레벨은 레벨 고유의 종료 조건을 가지고 있으며 다음 리스트의 예를 종료 조건으로 적용할 수 있다:
● 단위테스팅
● 불가능한 경로에 대한 강도 높은 리뷰 및 결정 커버리지 100% 만족
● 모든 코드에 대한 정적 분석 수행
● 해결되지 않는 메이저 결함 없음(우선순위 및 심각도를 고려하여 분류)
● 설계와 구현 시 수용 불가능한 기술적 부채 없음 [존스11]
● 모든 코드, 단위 테스트, 단위 테스트 결과 리뷰
● 모든 유닛 테스트 자동화
● 중요한 특성에 대한 제약사항에 동의 (예: 성능)
● 통합 테스팅
● 크기/복잡도 리스크에 기반한 다수의 긍정/부정 테스트를 포함한 모든 기능 요구사항 테스트
● 단위 간 모든 인터페이스 테스트
● 합의한 테스트 강도에 따라 모든 품질 리스크 대응
● 해결되지 않은 메이저 결함 없음(리스크와 중요도에 따라)
● 발견된 모든 결함 보고 완료
● 가능한 모든 회귀 테스트 자동화 및 자동화된 테스트의 공용 저장소 저장
● 시스템 테스팅
● 사용자 스토리 및 기능의 엔드-투-엔드 테스트
● 모든 사용자 페르소나 고려
● 시스템의 가장 중요한 품질 특성(예: 성능, 안정성, 신뢰성) 커버 완료
● 가능한 지원되는 환경 구성에 대한 모든 하드웨어 및 소프트웨어를 포함하여 실제 사용 환경에서 테스트 완료
● 테스트에서 커버하기로 한 모든 품질 리스크 커버 완료
● 가능한 모든 회귀 테스트 자동화 및 자동화된 테스트의 공용 저장소 저장
● 발견된 모든 결함 보고 및 가능한 수정 완료
● 해결되지 않은 주요 결함 없음(리스크과 중요도에 따라 우선 순위화)

유저 스토리 User Story
유저 스토리 완료 조건은 다음과 같다:
● 반복주기에서 선택된 사용자 스토리가 팀에 의해 완료되고, 테스트 가능한 상세한 인수 기준을 가짐
● 인수 테스트를 포함한 사용자 스토리의 모든 요소가 구체화되어 리뷰되고 구현이 완료됨
● 선택한 사용자 스토리의 테스트에 필요한 작업을 식별하고 팀에 의해 추정 완료

기능Feature
여러 유저 스토리와 에픽을 포함하는 기능에서 완료의 정의는 다음을 포함할 수 있다:
● 인수 기준이 있는 모든 사용자 스토리가 정의되고 고객에 의해 승인 완료
● 알려진 기술 부채 없이 설계 완료
● 알려진 기술 부채 또는 미완성 리팩토링 없이 코딩 완료
● 단위 테스트가 수행되고, 정의된 커버리지 수준 달성
● 기능의 통합 테스트 및 시스템 테스트가 정의된 커버리지 기준에 따라 수행 완료
● 주요 결함 수정 완료
● 릴리즈 노트, 사용자 설명서 및 온라인 도움말 기능을 포함한 기능 설명서 완성

반복주기 Iteration
반복주기에서 완료의 정의는 다음을 포함할 수 있다:
● 반복주기에 대한 모든 기능은 기능 수준의 기준에 따라 준비되고 개별적으로 테스트 완료
● 반복주기의 제약 내에서 해결할 수 없는 중요하지 않은 결함을 제품 백로그에 추가하고 우선 순위에 따라 분류
● 반복주기에 대한 모든 기능의 통합을 완료하고 테스트 완료
● 문서의 작성, 검토, 승인 완료
반복주기가 완료되었기 때문에 이 시점에서 소프트웨어는 잠재적으로 출시가 가능하지만, 출시의 모든 반복주기가 완료된 것은 아닐 수 있다.
출시(릴리즈)
여러 반복주기를 포함하는 출시에서 완료의 정의는 다음을 포함할 수 있다:
● 커버리지: 출시의 모든 내용에 대한 모든 관련 테스트 기준이 테스트에 포함되어 있다. 커버리지의 적정성은 복잡성과 크기, 그리고 실패와 관련된 리스크 및 변경 사항에 의해 결정된다
● 품질: 결함 강도(예: 하루 또는 트랜잭션 당 발견되는 결함의 수), 결함 밀도 (예: 사용자 스토리, 노력, 또는 품질 특성의 수에 비례해 발견된 결함의 수), 결함 허용 범위 내에 있는 잠재 결함의 수, 해결되지 않거나 남아있는 결함(예: 심각도 및 우선 순위), 식별한 각각의 품질 리스크와 관련된 리스크의 잔류 수준이 이해하고 허용할 만한 수준인가
● 시간: 미리 정해진 납기에 도달한 경우, 연관된 비즈니스 사항을 고려하여 출시를 결정한다
● 비용: 예상된 수명 주기 비용은 출시 시스템에 대한 투자 대비 수익률을 계산하는데 사용된다 (즉, 계산된 개발 및 유지 보수 비용이 제품의 예상 총 매출보다 상당히 낮아야 한다). 제품 생산 이후에 발생한 결함으로 인해 수명주기 비용의 주요 부분은 종종 유지보수 단계에서 발생하기도 한다

3.3.2 인수 테스트 주도 개발 적용하기
인수 테스트 주도 개발은 테스트 우선 접근법이다. 테스트 케이스들은 해당 사용자 스토리를 구현하기 전에 작성된다. 테스트 케이스는 개발자, 테스터, 업무 대표자[Adzic09]를 포함한 애자일 팀에 의해 생성되고, 수동 또는 자동으로 수행된다. 첫번째 단계로 사용자 스토리를 분석/논의하고, 개발자, 테스터 및 업무 대표자가 요구사항을 작성하는 워크숍을 진행한다. 사용자 스토리의 모든 불완전성, 모호성, 오류가 이 과정에서 보완된다.
다음 단계는 테스트 케이스를 생성하는 것이다. 테스트 케이스 작성은 모든 사람이 참여하거나 테스트 팀에 의해 개별적으로 진행될 수 있다. 테스트 케이스의 작성 방식과 관계없이, 비즈니스 대표자와 같은 제3자가 테스트 케이스를 검증한다. 테스트 케이스는 사용자 스토리의 특정한 특성을 기술하고 있는 예제들이며, 애자일 팀이 해당 사용자 스토리를 정확하게 구현하도록 도움을 준다. 예제와 테스트는 동일한 대상을 지칭하며, 이 용어들은 대부분은 동일한 의미로 사용된다. 테스트 케이스 생성 작업은 기본적인 예제와 개방형 질문에서 시작한다.
통상적으로, 첫번째 테스트는 예상했던 대로 실행되면 동작 단계에서 예외 또는 오류 없이 올바르게 동작함을 확인하는 긍정 테스트이다. 긍정적인 경로에 대한 테스트를 완료한 후, 팀은 부정적인 경로에 대한 테스트뿐만 아니라 비기능적 특성도 추가해야 한다(예: 성능, 가용성). 테스트 케이스는 모든 이해관계자들이 이해할 수 있도록 기술되어야 하며, 필요한 사전조건, 예를 들면 입력 및 해당 입력에 대한 출력 값 등을 자연어 문장으로 포함할 수도 있다.
예제는 사용자 스토리의 모든 특성을 포함해야 하며 임의의 내용을 덧붙여서는 안된다. 즉, 예시는 스토리 자체에서 설명하지 않은 측면을 다루지 말아야 한다는 것을 의미한다. 또한, 두 개의 예시가 사용자 스토리의 동일한 특성을 설명해서도 안 된다.

3.3.3 기능 및 비기능 블랙박스 테스트 설계
애자일 테스팅에서 수행되는 많은 테스트는 테스터에 의해 생성되며, 이는 개발자가 프로그래밍 활동을 하는 시기에 동시에 이루어진다. 개발자가 사용자 스토리 및 완료 기준에 따라 프로그래밍을 하는 것처럼, 테스터는 사용자 스토리와 완료 기준에 따라 테스트를 설계한다(섹션 3.3.4에 설명한대로 탐색적 테스트 및 다른 경험 기반 테스트와 같은 일부 테스트는 테스트 실행 중에 테스트를 설계한다). 테스터는 동등 분할, 경계값 분석 등 기존의 블랙 박스 테스트 설계 기법을 활용할 수 있다. 결정 테이블 테스트 및 상태 전이 테스트를 통해서도 이러한 테스트를 설계할 수 있다. 예를 들어, 경계값 분석은 고객이 구입할 수 있는 항목의 수가 한정되어 있는 경우, 테스트 데이터를 선택하는데 사용될 수 있다.
많은 경우, 비기능적 요구사항은 사용자 스토리와 같이 문서화 된다. 경계값 분석과 같은 블랙 박스 테스트 설계 기법도 비기능적 품질 특성에 대한 테스트를 작성하기 위해 사용될 수 있다. 사용자 스토리에서 성능이나 신뢰성 요구 사항을 포함 할 수도 있다. 예를 들어, 주어진 실행 제한 시간을 초과 할 수 없다거나 특정 작업의 실패는 특정 횟수보다 적어야 한다고 명시하는 것이다.
블랙 박스 테스트 설계 기법의 사용에 대한 자세한 내용은 Foundation level실라버스[ISTQB_FL_SYL] 및 Advanced level_Test Analysis 실라버스[ISTQB_ALTA_SYL]를 참고하자.

3.3.4 탐색적 테스팅과 애자일 테스팅
탐색적 테스팅은 애자일 프로젝트에서 매우 중요한데, 이는 테스트 분석에 사용 가능한 시간과 사용자 스토리의 세부 사항들이 제한되어 있기 때문이다. 최상의 결과를 얻기 위해서는 탐색적 테스팅을 다른 경험 기반 테스팅 기법과 조합함은 물론, 리스크 분석 기반 테스팅, 요구사항 분석 기반 테스팅, 모델 기반 테스팅 및 리그레션 회피 테스팅과 같은 다양한 테스팅 전략을 적절히 혼합해서 활용해야 한다. 테스트 전략 및 이 전략들의 조합과 관련된 자세한 내용은 Foundation level 실라버스를 참조한다.
탐색적 테스팅에서 테스트 설계와 테스트 실행은 미리 준비한 테스트 차터에 기반해 동시에 실행된다. 테스트 차터는 주어진 테스팅 세션 시간 동안 커버해야 할 테스트 조건들을 제공하며, 탐색적 테스트를 진행하는 동안 가장 최근의 테스트 결과 즉, 이전 세션의 테스트 결과에 따라 다음 테스트의 방향을 조정한다. 미리 설계된 테스팅을 수행할 때 사용하는 화이트 박스, 블랙 박스 기법을 테스트 케이스를 설계하는 경우에도 동일하게 사용할 수 있다.
테스트 차터는 다음 정보들을 포함할 수 있다:
· 액터: 시스템을 사용할 것으로 예상되는 사용자
· 목적: 액터가 달성하고자 하는 특정 목적 즉, 테스트 조건을 포함한 차터의 전체 목적
· 준비: 테스트 실행의 시작을 위해 필요한 준비 사항
· 우선 순위: 해당 테스트 차터의 상대적인 중요성으로, 관련된 사용자 스토리 혹은 리스크 수준에 따라 결정함
· 참조: 요구사항(예: 사용자 스토리), 리스크, 그외 다른 정보들
· 데이터: 테스트에 필요한 데이터
· 활동: 액터가 시스템에서 수행할 수 있는 것(예: "슈퍼 사용자로 시스템에 로그온"), 흥미로운 테스트 항목(긍정적 테스트와 부정적 테스트 모두 포함)
· 오라클: 결함인지 여부를 판단할 수 있는 제품의 올바른 동작 결과(예: 화면에 일어나는 캡처와 사용 설명서에 기록된 화면을 비교)
· 변화: 대안 활동 및 활동을 보완할 수 있는 아이디어
탐색적 테스팅을 관리하기 위해 세션 기반 테스트 관리 기법이 사용될 수 있다.
테스팅 세션은 60~120분 사이의 시간으로 정의되며, 이 시간 동안에는 외부로부터의 어떠한 방해도 받지 않아야 한다. 테스트 세션은 다음 사항을 포함한다:
· 조사 세션(작동 방법에 대한 세부 내용 학습)
· 분석 세션(기능이나 특징 평가)
· 커버리지 확장(예외 또는 경계 케이스, 시나리오, 상호 작용)
테스트의 품질은 대상 제품에 대해 질문할 수 있는 테스터의 능력에 따라 달라진다. 다음과 같은 질문이 포함될 수 있다:
· 이 시스템에서 가장 중요한 것은 무엇인가?
· 어떤 방식으로 시스템이 실패 할 수 있는가?
· 만약 ~ 하면 어떤 일이 생길까?
· …일 때 어떤 일이 발생해야 하는가?
· 고객의 니즈, 요구 사항, 기대가 모두 충족되었는가?
· 시스템 설치(혹은 제거) 시 모든 업그레이드 경로에서 정상적으로 설치(및 삭제)가 수행되는가?
테스트를 실행하는 동안, 테스터는 창의성, 직관, 지식과 모든 역량을 동원해 제품에서 발생 가능한 문제점들을 찾아낸다. 테스터는 또한 테스트 대상, 비즈니스 영역, 소프트웨어 사용 방법, 시스템의 실패 여부 결정 방법에 대한 충분한 지식과 이해를 가지고 있어야 한다.
테스트 중, 다음의 휴리스틱 항목을 적용할 수 있다. 휴리스틱은 경험 기반 테스트를 수행하는 방법 및 결과를 평가하는 방법을 안내해줄 수 있다 [헨드릭슨]. 휴리스틱의 예는 다음과 같다:
· 경계값
· CRUD (쓰기, 읽기, 갱신, 삭제)
· 설정 변경
· 의도치 않은 장애 상황(예: 로그 오프, 종료, 혹은 시스템 재부팅)
테스터는 테스팅 과정을 최대한 문서화해야 한다. 그렇지 않으면 시스템에서 문제가 발견된 경로를 재현하기 어렵다. 다음은 문서에 포함할 유용한 정보의 예시이다:
· 테스트 커버리지: 어떤 입력 데이터가 사용되었고, 어느 만큼의 영역을 커버했는지, 앞으로 테스트 해야 할 부분이 얼마나 남았는지에 대한 정보
· 평가 노트: 테스트하는 동안 관찰한 내용. 시스템과 기능은 안정적인지, 현재 관찰에 따라 다음에 어떤 부분을 테스트하면 좋을 지에 대한 아이디어 등
· 리스크 및 전략: 어떤 리스크가 해소되었는지, 가장 중요한 리스크 중 테스트 안된 부분은 어디인지, 초기 테스트 전략이 지켜지고 있는지, 어떤 변화가 필요한지에 대한 정보
· 문제, 질문, 이상한 점: 예상치 못한 결과, 접근 방식의 효율성에 관한 질문, 아이디어 및 테스트 시도에 대한 우려사항, 테스트 환경, 테스트 데이터, 기능, 테스트 스크립트 또는 테스트중인 시스템에 대한 오해
· 실제 동작: 시스템의 실제 동작에 대한 기록 (예: 비디오, 화면 캡처, 출력 데이터 파일 등)
기록된 정보는 저장되고 특정한 상태 관리 도구(예: 테스트 관리 도구, 태스크 관리 도구, 태스크 보드 등)에 적합한 형태로 요약되어 이해 관계자가 수행된 모든 테스팅의 현재 상태를 쉽게 이해할 수 있도록 해야 한다.


3.4 애자일 프로젝트를 위한 도구들
ISTQB Foundation level 실라버스에 소개된 도구들은 애자일 팀의 테스트와 무관하지 않으며, 실제로 프로젝트에서 테스터들이 사용한다. 모든 도구가 동일한 방식으로 사용되지는 않으며, 몇몇 도구들은 특히 애자일 프로젝트와 더욱 밀접하게 관련되어 있다. 예를 들어, 테스트 관리 도구, 요구 사항 관리 도구, 결함 관리 도구(결함 추적 도구)는 애자일 팀에서 사용될 수 있지만, 일부 애자일 팀은 작업 보드, 번 다운 차트, 사용자 스토리와 같은 애자일 개발과 관련된 기능을 포함하는 도구를 선택하기도 한다 (예: 애플리케이션 라이프사이클 관리 또는 작업 관리 도구). 모든 수준에서 자동화된 테스트 및 관련된 테스트 아티팩트를 관리할 필요가 있으므로 애자일 팀에서 형상 관리 도구는 중요하다.

ISTQB Foundation level실라버스에 설명된 도구 이외에도 애자일 프로젝트에서 테스터는 이번 장에서 설명하는 도구를 활용할 수 있다. 이 도구들은 애자일 실천방법의 핵심인 팀 협업 및 정보 공유를 보장하기 위해 사용된다.

3.4.1 작업 관리 및 추적 도구
일부 애자일 팀은 각 스프린트가 진행되는 동안 물리적인 스토리/태스크 보드(예: 화이트 보드, 코르크 보드 등)를 사용해 사용자 스토리, 테스트 및 다른 태스크들을 관리하고 추적한다. 다른 팀들은 애플리케이션 수명 주기 관리 및 태스크 관리 소프트웨어를 사용하기도 하며, 여기에는 소프트웨어 태스크 보드가 포함된다.
· 스토리 및 스토리와 관련된 개발 및 테스트 작업을 기록하여 스프린트가 진행되는 동안 태스크가 누락되지 않도록 한다
· 각 태스크에 팀 구성원의 공수 추정치를 기재하고 사용자 스토리를 구현하기 위해 필요한 공수를 자동으로 계산함으로써, 효율적인 반복주기 계획을 수립하도록 한다
· 동일한 사용자 스토리와 연관된 개발/테스트 작업을 묶음으로써 해당 스토리를 구현하는데 필요한 팀의 전체적인 공수를 파악하도록 한다
· 개발자 및 테스터의 작업 완료 상태를 태스크에 반영함으로써, 각각의 스토리, 반복주기 및 전체적인 릴리즈 진행 상태의 스냅샷을 제공한다
· 지리적으로 분산된 팀원을 포함한 모든 이해 관계자들이 각 사용자 스토리, 반복주기, 릴리즈의 현재 상태를 통계, 차트 및 대시 보드를 통해 신속하게 파악할 수 있도록 돕는 시각적 자료를 제공한다
· 태스크와 형상 관리 도구를 연동한다. 이들 형상 관리 도구는 코드 체크인 및 해당 태스크과 관련된 빌드 내역을 자동으로 기록하며, 일부 도구들은 태스크의 업데이트 상태도 기록한다
커뮤니케이션 및 정보 공유 도구
이메일, 문서, 구두 커뮤니케이션 외에도 애자일 팀은 종종 커뮤니케이션과 정보 공유를 강화하는 세 가지 추가적인 도구(위키, 메신저, 데스크탑 공유)를 사용한다.
위키를 사용하면 팀은 프로젝트의 다양한 관점에 대한 지식을 온라인상에서 생성하고 공유할 수 있으며, 다음 정보들을 포함할 수 있다:
· 제품 기능 다이어그램, 기능 관련 토론, 프로토타입 다이어그램, 화이트 보드 상에 기록된 토의 내용의 사진 및 기타 정보
· 팀의 다른 구성원에게 유용할 수 있는 개발 및 테스트를 위한 도구 또는 기술
· 제품 상태와 관련된 지표, 차트 및 대시 보드. 이러한 요소들은 위키가 제품 상태를 자동으로 업데이트 해주는 빌드 서버 및 작업 관리 시스템 등과 연동된 경우 특히 유용하다.
· 인스턴트 메신저 및 이메일 등의 방식으로 팀의 다른 사람들과 공유된 팀 구성원 간의 대화
인스턴트 메시징, 컨퍼런스 콜, 화상 채팅 도구는 다음과 같은 이점을 제공한다:
· 팀 구성원, 특히 지리적으로 분산된 팀원 사이의 실시간 대면 커뮤니케이션이 가능
· 스탠드업 미팅에 지리적으로 분산된 팀 참여 가능
· VoIP 기술을 활용해 통신비를 줄임으로써, 분산된 팀 구성원의 커뮤니케이션을 물리적으로 줄어들게 하는 비용 문제를 줄임
데스크탑 공유 및 캡처 도구는 다음과 같은 이점을 제공한다:
· 분산된 팀에서 제품 시연, 코드 리뷰 및 페어 작업 가능
· 각 반복주기의 끝에서 제품 시연을 캡처하여 팀의 위키에 게시 가능
이러한 도구들은 대면 의사 소통을 대처하는 수단이 아니라 보완하고 확장하는 수단으로만 사용해야 한다.

3.4.3 소프트웨어 빌드 및 배포 도구
본 실라버스의 앞에서 이미 설명한 바와 같이, 소프트웨어를 매일 빌드하고 배포하는 작업이 애자일팀에게는 매우 중요하다. 이 작업을 수행하기 위해서는 지속적인 통합 및 빌드 배포 도구가 필요하며, 이러한 도구들의 장점과 리스크는 1.2.4절에서 설명되었다. 이는 분산 빌드 도구 및 지속적인 통합 도구의 사용을 필요로 한다. 이러한 도구의 사용으로 인한 장점 및 리스크은 1.2.4 절 앞부분에서 설명되어 있다.

3.4.4. 형상 관리 도구
애자일 팀에서 형상 관리 도구는 소스 코드 저장 및 자동 테스트에 사용될 뿐만 아니라 수동 테스트 및 기타 테스트 산출물 또한 종종 제품 소스 코드와 같은 저장소에 저장된다. 형상관리 도구는 소프트웨어 버전과 테스트 산출물 버전 사이의 추적성을 제공하고, 기록된 정보의 손실을 없애 빠르게 변화에 대응할 수 있게 한다. 버전 관리 시스템의 주요유형은 중앙 소스 제어 시스템 및 분산 버전 제어 시스템을 포함한다. 팀의 크기, 구조, 위치, 타른 도구와의 연동 요구 사항을 바탕으로 특정 애자일 프로젝트에 적합한 형상 관리 도구를 결정한다.

3.4.5 테스트 설계, 구현, 실행 도구
몇몇 도구들은 소프트웨어 테스팅 프로세스의 특정 지점에서 애자일 테스터에 유용하다 대부분의 도구들은 애자일에 특화되어있거나 애자일을 위해서만 만들어진 것은 아니지만, 애자일 프로젝트의 빠른 변화에 대응할 수 있는 중요한 기능들을 제공한다.
· 테스트 설계 도구: 마인드 맵과 같은 도구를 사용해 새로운 기능과 관련된 테스트를 빠르게 설계하고 정의하는 것이 보편화되었다
· 테스트 케이스 관리 도구: 애자일에서 사용하는 테스트 케이스 관리 도구는 팀 전체의 개발 수명 주기 관리 또는 작업 관리 도구의 일부가 될 수 있다
· 테스트 데이터의 준비 및 생성 도구: 데이터 및 데이터의 조합이 많은 애플리케이션을 테스트하는 경우, 애플리케이션의 테스트 데이터를 생성해주는 도구는 매우 유용하다. 이러한 도구는 또한 애자일 프로젝트 도중에 변경이 발생했을 때, 데이터 베이스 구조를 재정의하기 위한 데이터를 생성하는 스크립트의 리팩토링에도 도움이 된다. 이를 통해 변경 사항이 발생한 경우 테스트 데이터를 신속하게 업데이트할 수 있다. 원본 데이터를 초기 입력자료로 사용하는 일부 테스트 데이터 준비 도구는 민감한 데이터를 제거하거나 익명화하기 위한 스크립트를 지원하기도 한다. 또한, 대규모 데이터 입력 또는 출력의 유효성 검증도 가능하다.
· 테스트 데이터 입력 도구: 테스트 데이터를 생성한 후에는 해당 데이터를 어플리케이션에 입력해야 한다. 수동 데이터 입력에는 보통 많은 시간이 소요되고 많은 에러가 발생하므로 데이터 입력 도구를 이용하여 이를 안정적이고 효율적으로 만드는 것이 가능하다. 사실, 데이터 생성 도구의 대부분은 데이터 입력 기능을 지원한다. 지원하지 않는 경우, 데이터베이스 관리 시스템을 사용하여 직접 접근하는 방식(벌크 로딩)도 가능하다.
· 자동화 테스트 실행 도구: 애자일 테스팅에 좀 더 최적화된 테스트 실행 도구들이 있다. 이런 도구들은 행위 주도 개발, 테스트 주도 개발 및 인수 테스트 주도 개발과 같은 테스트 우선 접근 방식을 지원하며, 상용 또는 오픈 소스로 사용이 가능하다. 또한 일부 도구는 테스터 및 비즈니스 관련 인력이 테이블이나 자연어 키워드를 사용하여 시스템의 예상 동작을 표현할 수도 있다.
· 탐색적 테스트 도구: 탐색적 테스트 세션 동안 응용 프로그램에서 수행된 내용 및 로그를 기록하여 테스터 및 개발자에게 도움을 주는 도구이다. 오류가 발생하기 전에 취해진 행동을 기록함으로써 개발자가 결함을 재 발생시키고 분석하는데 유용하다. 궁극적으로 자동화된 회귀 테스트 스위트가 구축되어있는 경우, 탐색적 테스트 세션에서 행동을 기록하는 것이 더욱더 도움이 된다는 것은 이미 증명되어 있다.

3.4.6 클라우드 컴퓨팅과 가상화 도구
가상화는 하나의 물리적 자원(서버)을 다수의 개별 자원으로 활용할 수 있게 해주는 기술이다. 가상 머신 또는 클라우드 인스턴스를 사용하면, 팀은 개발 및 테스트를 위한 대규모 서버 자원을 가질 수 있게 된다. 이는 물리적 서버의 활용과 관련된 개발 지연을 방지하는데 도움이 된다. 대부분의 가상화 도구는 스냅샷 기능을 포함하고 있어 새로운 서버를 구축하거나 서버 복원 작업도 손쉽게 수행할 수 있다. 일부 테스트 관리 도구는 가상화 기술을 이용해 결함 발생 시점에 서버의 스냅샷을 저장함으로써, 테스트와 개발자가 문제점을 공유하고 해당 결함을 조사할 수 있도록 지원한다.




4. 참고자료

4.1 표준
● [DO-178B] RTCA/FAA DO-178B, Software Considerations in Airborne Systems and Equipment Certification, 1992.
● [ISO25000] ISO/IEC 25000:2005, Software Engineering - Software Product Quality Requirements and Evaluation (SQuaRE), 2005.

4.2 ISTQB 문서
● [ISTQB_ALTA_SYL] ISTQB Advanced Level Test Analyst Syllabus, Version 2012
● [ISTQB_ALTM_SYL] ISTQB Advanced Level Test Manager Syllabus, Version 2012
● [ISTQB_FA_OVIEW] ISTQB Foundation Level Agile Tester Overview, Version 1.0
● [ISTQB_FL_SYL] ISTQB Foundation Level Syllabus, Version 2011

4.3 관련 서적
[Aalst13] Leo van der Aalst and Cecile Davis, “TMap NEXT® in Scrum,” ICT-Books.com, 2013. [Adzic09] Gojko Adzic, “Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing,” Neuri Limited, 2009.
[Anderson13] David Anderson, “Kanban: Successful Evolutionary Change for Your Technology Business,” Blue Hole Press, 2010.
[Beck02] Kent Beck, “Test-driven Development: By Example,” Addison-Wesley Professional, 2002.
[Beck04] Kent Beck and Cynthia Andres, “Extreme Programming Explained: Embrace Change, 2e” Addison-Wesley Professional, 2004.
[Black07] Rex Black, “Pragmatic Software Testing,” John Wiley and Sons, 2007.
[Black09] Rex Black, “Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing, 3e,” Wiley, 2009.
[Chelimsky10] David Chelimsky et al, “The RSpec Book: Behavior Driven Development with Rspec, Cucumber, and Friends,” Pragmatic Bookshelf, 2010.
[Cohn04] Mike Cohn, “User Stories Applied: For Agile Software Development,” Addison-Wesley Professional, 2004.
[Crispin08] Lisa Crispin and Janet Gregory, “Agile Testing: A Practical Guide for Testers and Agile Teams,” Addison-Wesley Professional, 2008.
[Goucher09] Adam Goucher and Tim Reilly, editors, “Beautiful Testing: Leading Professionals Reveal How They Improve Software,” O'Reilly Media, 2009.
[Jeffries00] Ron Jeffries, Ann Anderson, and Chet Hendrickson, “Extreme Programming Installed,” Addison-Wesley Professional, 2000.
[Jones11] Capers Jones and Olivier Bonsignour, “The Economics of Software Quality,” Addison-Wesley Professional, 2011.
[Linz14] Tilo Linz, “Testing in Scrum: A Guide for Software Quality Assurance in the Agile World,” Rocky Nook, 2014.
[Schwaber01] Ken Schwaber and Mike Beedle, “Agile Software Development with Scrum,” Prentice Hall, 2001.
[vanVeenendaal12] Erik van Veenendaal, “The PRISMA approach”, Uitgeverij Tutein Nolthenius, 2012.
[Wiegers13] Karl Wiegers and Joy Beatty, “Software Requirements, 3e,” Microsoft Press, 2013.

4.4 애자일 용어
ISTQB의 키워드들은 각 장의 시작 부분에 제시되어 있다. 일반적인 애자일 용어들은 다음의 잘 알려진 출처의 정의를 참고 했다.
http://guide.Agilealliance.org/
http://whatis.techtargetcom/glossary
http://www.scrumalliance.org/
이 문서에서 애자일과 관련된 친숙하지 않은 단어를 확인하고 싶다면 위 사이트의 활용을 추천한다. 위 사이트들은 이 문서가 릴리즈되는 시점에 활성화되어 있음이 확인되었다.

4.5 그외 리소스
다음의 참고목록은 인터넷이나 혹은 그 외 가능한 정보들을 정리한 것이다. 이 참고자료들이 본 문서를 릴리즈하는 시점에 활성화되어 있음이 확인되었지만, 더 이상 활용 가능하지 않을 수도 있으며, ISTQB는 이에 대해서 아무런 책임도 없음을 명시한다.
● [Agile Alliance Guide] Various contributors, http://guide.Agilealliance.org/.
● [Agilemanifesto] Various contributors, www.agilemanifesto.org.
● [Hendrickson]: Elisabeth Hendrickson, “Acceptance Test-driven Development,” testobsessed.com/2008/12/acceptance-test-driven-development-atdd-an-overview.
● [INVEST] Bill Wake, “INVEST in Good Stories, and SMART Tasks,” xp123.com/articles/invest-in-good-stories-and-smart-tasks.
● [Kubaczkowski] Greg Kubaczkowski and Rex Black, “Mission Made Possible,” www.rbcs-us.com/images/documents/Mission-Made-Possible.pdf.

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."
Posted by 프리스케이터