ISTQB FL-Agile Tester 3. 애자일 테스팅 방법, 기법 및 도구

Key word

인수 조건	사용자, 고객 또는 다른 인가된 개체에 의해 인수되어 지기 위해 컴포넌트 또는 시스템이 만족시켜야 하는 완료조건
탐색적 테스팅	테스터가 테스트를 수행하면서 테스트 설계를 능동적으로 제어하고, 새롭고 보다 나은 테스트를 설계하기 위해 테스트를 수행하는 동안 얻은 정보를 활용하는 비공식적인 테스트 설계 기법
성능 테스팅	소프트웨어 제품의 성능을 측정하기 위한 테스팅 절차. 효율성 테스팅(소프트웨어 제품의 효율성을 측정하기 위한 테스팅 절차)
제품 리스크	테스트 대상에 직접적으로 관계된 리스크(영향력, 발생 가능성)
품질 리스크	제품을 사용하는 일반적인 상황 아래서 시스템 크래시를 일으키는 잠재적 신뢰성 결함
회귀 테스팅	기능 추가나 오류를 수정한 소프트웨어가 수정에 의해 새로이 유입된 오류가 없는지 확인하는 반복 테스트
테스트 접근법	특정한 프로젝트를 위해 테스트 전략을 구현하는 것. 테스트 접근법은 일반적으로 프로젝트의 목표와 리스크 평가 수행 결과를 기반으로 여러가지 테스팅 관련 의사결정을 한다. 이 밖에도 테스트 접근법은 테스트 프로세스를 시작하는 시점, 적용할 테스트 설계 기법, 완료 조건과 수행할 테스트 유형을 결정하는 역할
테스트 차터	테스트 목적 선언 또는 임무. 테스트 차터는 테스트 아이디어를 포함할 수 있으며, 탐색적 테스팅에서 사용
테스트 추정	테스트에 드는 노력을 추정하는 두가지 접근법 메트릭 기반 접근법: 공식적이거나 비슷한 프로젝트에서 측정한 메트릭이나 전형적인 값을 기반으로 예측 전문성 기반 접근법: 전문가나 작업자가 스스로 작업을 예측
테스트 자동화	테스트 활동을 수행하거나 지원하는 소프트웨어 툴을 사용하여 테스팅 하는 것. 테스트 자동화는 테스트 관리, 테스트 설계, 테스트 실행과 결과 점검과 같은 테스트 활동을 수행하고 지원
테스트 전략	하나의 프로그램에 대해 어떤 테스트 레벨을 수행할 것인지, 해당 테스트 레벨 내에서 어떻게 테스팅 할 것인지를 정의하는 상위 수준 문서
테스트 주도 개발(TTD)	테스트 케이스를 실행하기 위한 소프트웨어가 개발되기 전에, 테스트 케이스를 먼저 개발하고 주로 자동 실행되도록 한 후, 해당 테스트를 통과하도록 소프트웨어를 개발하는 방법
단위 테스트 프레임워크	단위 테스트를 만들고, 실행하고 이러한 테스트 결과를 보고

 

학습 목표

3.1. 애자일 테스팅 방법

3.1.1. 테스트 주도 개발, 인수테스트 주도 개발, 행위 주도 개발의 개념 (K1)

3.1.2. 테스트 피라미드의 개념 (K1)

3.1.3. 테스팅 사분면과 각 사분면의 테스팅 레벨 및 테스팅 종류와의 상관관계 (K2)

3.1.4. 애자일 프로젝트의 스크럼 팀에서 테스터 역할을 수행할 수 있다 (K3)

 

3.2. 품질 리스크 식별 및 테스트 노력 추정

3.2.1. 애자일 프로젝트의 품질 리스크를 식별 (K3)

3.2.2. 품질 리스크와 반복주기 내용에 기반하여 테스팅에 필요한 자원을 추정 (K3)

 

3.3. 애자일 프로젝트의 기법들

3.3.1. 테스팅 활동을 지원하기 위한 관련 정보를 이해 (K3)

3.3.2. 비즈니스 이해관계자들이 테스트 용이성이 있는 인수 조건을 정의하도록 설명 (K2)

3.3.3. 주어진 유저 스토리에 대해 인수 테스트 주도 개발의 테스트케이스를 작성 (K3)

3.3.4. 주어진 유저스토리에 대해 블랙박스 테스트 설계 기법을 활용하여 기능적, 비기능적 행위의 테스트 케이스를 작성 (K3)

3.3.5. 탐색적 테스팅을 수행하여 애자일 프로젝트의 테스팅을 지원 (K3)

 

3.4. 애자일 프로젝트의 도구들

3.4.1. 애자일 프로젝트에서의 테스팅 목적과 활동에 맞춰 적용 가능한 다양한 도구들을 상기 (K1)

 

---

3.1. 애자일 테스팅 방법

애자일에 상관없이 미리 테스트를 작성하고 초기 결함의 예방∙발견∙제거에 초점을 두고 적절한 테스트가 적절한 시간에 올바른 테스트 레벨의 활동을 수행되어야 함

애자일 프로젝트에서 테스터는 전체 개발 수명주기에 걸쳐 테스팅 방법을 안내함 (코칭)

 

3.1.1. 테스트 주도 개발, 인수 테스트 주도 개발, 행위 주도 개발

테스트 주도 개발(Test Driven Development), 인수 테스트 주도 개발(Acceptance Test-Driven Development), 행위 주도 개발(Behavior-Driven Development)는 애자일 팀이 사용하는 세 가지 상호 보완적인 방법. 코드 작성 전에 테스트가 정의됨

 

테스트 주도 개발 Test-Driven Development

자동화된 테스트 케이스에 맞추어 코드를 개발하는 방법

1. 테스트(코드)를 추가

2. 테스트를 실행 (이 때 코드가 존재하지 않기 때문에 테스트가 실패)

3. 코드를 작성한 후 테스트가 통과할 때까지 테스트를 실행하며 반복

4. 테스트 통과 후 리팩토링, 이후 정상 동작여부를 파악하기 위해 테스트를 실행

5. 다음 코드부터 또 반복

코드에 집중된 단위 테스트 레벨 위주이지만 통합∙시스템 테스트 레벨에서도 사용할 수 있음

XP, 다른 애자일 방법론이나 폭포수 방법론에서도 사용 가능

개발자가 정의한 예상 결과에 초점 / 작성된 테스트는 테스트 자동화와 지속적인 통합에 사용함

 

인수 테스트 주도 개발 Acceptance Test-Driven Development

사용자 스토리를 작성하는 동안 인수 기준 및 테스트 방법을 정의

모든 이해 관계자가 소프트웨어 구성요소의 작동 방식을 이해하고 개발자∙테스터∙업무 대표자가 이 동작을 보장하기 위해 필요한 테스트를 함께 만드는 공동 접근 방식

회귀 테스트를 위한 재사용 가능 테스트를 만듦. 지속적인 통합 프로세스 내부에 생성 및 실행을 지원하는 도구가 있음. 이 도구들은 시스템∙인수 테스트 레벨에서 실행할 수 있도록 연결해줌

결함과 기능 동작의 검증을 신속하게 해결할 수 있음. 이 인수 기준을 완료 여부를 결정하는데 도움이 됨

 

행위 주도 개발 Behavior-Driven Development

개발자가 기대하는 소프트웨어 동작에 기반하여 코드를 테스트하는데 초점

소프트웨어의 특정 행위를 기반으로 하여 이해하기 쉽다.

 

행위 주도 개발 프레임워크는 Given/When/Then 형식으로 정의

1. Given 특정 상황에서

2. When 이벤트가 발생하면

3. Then 다음 몇 가지 결과를 확인한다.

 

요구사항으로부터 도출된 테스트 케이스를 개발자가 사용할 수 있는 코드로 변환

 

3.1.2. 테스트 피라미드

소프트웨어 시스템은 다양한 레벨에서 테스트됨

하위에서부터 상위로 순차적으로 단위∙통합∙시스템 및 인수테스트 순으로 존재

하위에서 상위로 갈수록 테스트 양이 감소

단위 및 통합 레벨의 테스트는 자동화 및 API 기반 도구를 사용하여 생성

시스템 및 인수 레벨에서 자동화된 테스트는 GUI 기반 도구를 사용하여 생성

테스트 피라미드 개념은 조기 결함 검출의 원리를 기초로 한다.

 

 

3.1.3. 테스팅 사분면(Testing Quadrants), 테스트 레벨, 테스트 우형

브라이언 머릭이 정의함

위치	1 사분면 Q1	2 사분면 Q2	3 사분면 Q3	4 사분면 Q4
레벨	단위	시스템	시스템∙인수 테스트	운영 인수 테스트
직면	기술	비즈니스	비즈니스	기술
행위	단위 테스트	제품의 동작 확인	사실적인 시나리오와 데이터를 사용하여 제품을 비판	제품의 비판 테스트
동작	자동화	수동∙자동	종종 수동 사용자 중심	보통 자동
테스트	단위 테스트	기능 테스트 스토리 테스트 사용자 경험 프로토타입 및 시뮬레이션	시나리오 및 프로세스 흐름 테스트 사용성 테스트 사용자 인수 테스트 알파 테스트 베타 테스트	성능, 부하, 스트레스, 및 확장성 테스트 보안 테스트 유지관리 메모리 관리 호환성 및 상호 운용성 데이터 마이그레이션 인프라 및 복구 테스트
비고	지속적인 통합 절차에 포함	인수 기준 확인	제품 인수	운영 인수

좌에서 우로 갈수록 개발이 진행된 상태

 

반복주기를 반복하는 동안, 모든 사분면에 걸쳐 테스트를 진행할 수도 있음

정적보다 동적 테스트에 더 적합

 

 

3.1.4. 테스터의 역할

 

팀워크

애자일의 기본원칙 다음은 스크럼 팀의 특징

1	교차 기능팀	각 팀 구성원이 팀에 다양한 기술 영역을 제공 테스트 전략∙계획∙설계∙실행∙평가 및 시험 결과 보고를 함께 진행
2	자기 조직화	팀에 최소 한명 이상의 테스터를 포함하는 것이 이상적
3	공간 공유	같은 공간에서 같이 일함
4	협업	테스터들은 자신의 팀 구성원, 다른 팀, 이해 관계자, 제품 소유자 및 스크럼 마스터와 함께 일함
5	위임	설계화 테스트에 관한 기술 결정은 팀 전체가 만듦
6	헌신	제품의 동작 및 특성을 평가하기 위해 최선
7	투명성	애자일 상황판을 통해 개발 및 테스트의 진행 상황을 볼 수 있음
8	신뢰	테스트 설계 및 실행 전략에 대한 신뢰 확보
9	열린 피드백	피드백이 성공의 기초, 회고를 통해 팀을 성장시킴
10	탄력성	변화에 기민하게 대응

 

스프린트 제로

프로젝트의 첫 번째 반복주기, 다음 활동을 수행

1. 프로젝트의 범위 정의 (제품 백로그)

2. 초기 시스템 아키텍처와 프로토타입 생성

3. 필요한 도구를 계획∙수급∙설치 (테스트 관리, 결함 관리, 테스트 자동화, 형상 관리)

4. 모든 테스트 레벨에 걸쳐 테스트 범위, 기술적 리스크, 테스트 종류, 커버리지 목표를 포함한

초기 테스트 전략 수립

5. 초기 품질 리스크 분석 수행

6. 테스트 프로세스, 진척율, 제품 품질을 측정하기 위한 품질 지표 정의

7. 완료의 의미 정의

8. 태스크 보드 생성

9. 고객에게 제품을 전달하기 전에 테스팅의 지속 및 중단 여부 정의

전체 스프린트가 진행되는 동안 어떤 테스팅, 어떻게 테스팅 할지 방향 설정

통합

지속적인 가치 전달을 위해 통합 전략은 설계와 테스트를 모드 고려해야 함

기본 기능과 기능 사이의 모든 종속 관계를 확인

 

테스트 계획

테스트 계획은 출시 계획 시 시작, 각 스프린트 동안 업데이트됨

모든 일은 하루나 이틀 분량으로 정의, 태스크 보드에 기재

모든 테스팅 이슈는 테스팅 흐름을 유지하기 위해 추적

 

애자일 테스팅 실천 방법

1. 페어링: 두 명의 멤버가 같은 공간에서 같은 태스크를 수행

2. 점진적인 테스트 설계: 테스트 케이스 및 차터가 점진적으로 더 복잡한 테스트를 향해 발전

3. 마인드맵: 테스트 전략을 표시, 테스트 데이터 설명, 수행된 테스트 세션 식별을 위한 도구

---

3.2. 품질 리스크 식별 및 테스트 노력 추정

릴리즈 이전 품질 문제의 리스크 감소가 테스팅의 일반적인 목적이지만

애자일에서의 짧은 반복주기와 잦은 변화에 대응하기 위해서 일부 변형이 필요

 

3.2.1. 애자일 프로젝트에서 품질 리스크 식별하기

테스트 컨디션을 적절하게 선택∙할당∙우선 순위를 설정

각 시험 조건을 커버하기 위한 적절한 노력의 양을 결정, 효율성 및 효율을 최적화하기 위한 테스트 절차를 포함.

리스크 식별∙분석 및 완화 전략은 실행할 테스트 케이스의 수를 결정하는 데 도움

 

리스크: 부정적이거나 원하지 않는 결과 혹은 이벤트가 발생할 수 있는 가능성

발생 가능성과 영향도를 평가하여 수준을 결정

제품의 품질에 관련된 경우: 품질 리스크, 제품 리스크

프로젝트에 관련된 경우: 프로젝트의 리스크, 계획 과정의 리스크

 

품질 리스크 분석

1. 릴리즈 계획: 기능의 리스크를 파악하고 있는 업무 대표자와 테스터를 포함한 전체 팀이 리스크를 식별하고 평가

2. 반복주기 계획: 전체 팀이 품질 리스크를 식별하고 평가

 

시스템 품질 리스크

1. 보고서의 잘못된 계산식 (기능적 리스크, 정확성)

2. 사용자 입력에 대한 느린 응답 (비기능적 리스크, 효율성 및 응답 시간)

3. 이해하기 어려운 화면 구성 및 입력 필드 (비기능 리스크, 사용성 및 이해도)

 

반복주기는 반복주기 계획에서 시작하며, 반복주기 계획은 추정한 태스크들을 대스크 보드에 정리하여 마무리

이 태스크들은 품질 리스크의 수준에 기초하여 우선순위를 정함 (높은 리스크는 빠르고 더 많은 노력)

 

반복주기 계획 (iteration planning) 시 품질 리스크 분석 과정

1. 팀원 전체 소집

2. 현재 반복주기의 모든 백로그 아이템을 나열

3. 제품 특성을 고려하여 각 아이템에 대한 품질 리스크를 식별

4. 리스크를 분류하고 영향도와 발생 빈도에 따라 수준을 파악

5. 리스크 수준 별 테스트의 수준을 결정

6. 각 리스크를 해결하기 위한 적절한 테스트 기법을 선택

이후 테스터는 테스트 설계∙구현∙실행을 통해 리스크를 완화 (항상 팀은 리스크 수준을 변화시키는 정보에 대해 파악하고 있어야 한다. 주기적으로 품질 리스크를 분석하고 조절함)

 

3.2.2. 리스크와 내용을 근거로 테스트 노력 추정

출시 계획 과정에서 출시 완료를 위한 작업을 추정

플래닝 포커: 순차적으로 증가하는 값이 적힌 카드를 이용해 팀원 모두가 같은 카드일 경우 그 값을 추정치로 선택, 아닐 경우 논의하며 결정

집단 의식을 향상시키고, 추정의 신뢰성을 높인다.

---

3.3. 애자일 프로젝트의 테스트 기법들

전통적인 프로젝트에 적용된 테스트 및 테스트 기법의 대부분 애자일 프로젝트에 적용할 수 있으나 차이점이 있다

 

3.3.1. 인수 조건, 적절한 커버리지, 테스팅을 위한 기타 정보

프로젝트의 초기 요구 사항을 백로그 우선 순위에 따라 사용자 스토리에 기재함

비기능 요구 사항 역시 중요하며 고유의 사용자 스토리나 다른 기능 사용자 스토리에 연결하여 명세를 작성함 (국제 표준, 산업 표준)

 

사용자 스토리는 중요한 테스트 베이시스이며 다음을 포함시킬 수 있음

1. 이전 프로젝트의 경험

2. 해당 시스템에 이미 존재하는 기능 및 품질 특성

3. 코드, 아키텍처, 디자인

4. 사용자 프로파일 (컨텍스트, 시스템 설정 및 사용자 행동)

5. 현재 및 과거 프로젝트의 결함 정보

6. 결함 사전의 결함 분류

7. 적용되는 표준

8. 품질 리스크

 

 

인수 기준은 다음과 같은 주제를 반드시 포함해야 함

1. 기능 동작(Function behavior): 입력된 행위에 대한 결과

2. 품질 특성(Quality characteristics): 시스템이 동작을 수행하는 방법 (품질 속성, 비기능 요구사항 포함) 일반적인 제품 특성으로 성능, 안정성, 사용성 등이 있음

3. 시나리오 (유스 케이스)(Scenarios, use cases): 작업 순서

4. 비즈니스 규칙(Business rules): 특정 조건 하 시스템에서 수행할 수 있는 활동

5. 외부 인터페이스(External interfaces): 시스템과 외부 세계의 연결

6. 제약 사항(Constraints): 모든 설계 및 구현의 제약 사항

7. 데이터 정의(Data definitions): 각 항목의 포맷, 데이터 종류, 허용되는 값, 디폴트 값

 

사용자 스토리 및 이와 관련된 인수 조건 외에도 테스터는 다음과 같은 부가 정보를 고려해야 함

1. 시스템의 의도된 동작 방식 및 사용 방식

2. 시스템을 테스트하는데 사용할 수 있는 시스템 접근/사용 인터페이스

3. 현재 사용하는 도구 지원의 충분성 여부

4. 테스터가 시험을 수행하는데 필요한 충분한 지식과 기술이 있는 지의 여부

 

반복주기가 진행되는 과정에서 테스터들은 추가적인 정보의 필요성을 발견하게 되고, 팀 멤버와의 협업을 통해 수집해야 함. 이를 통해 완료를 정의함 (중요)

 

테스트 레벨

각 테스트 레벨은 고유의 종료 조건을 가지고 있음

(단위 테스팅/통합 테스팅/시스템 테스팅/유저스토리/기능/반복주기/출시)

 

1. 단위 테스팅 Unit testing

1	불가능한 경로에 대한 강도 높은 리뷰 및 결정 커버리지 100% 만족
2	모든 코드에 대한 정적 분석 수행
3	해결되지 않는 메이저 결함 없음(우선순위 및 심각도 고려)
4	설계와 구현 시 수용 불가능한 기술적 부채 없음
5	모든 코드, 단위 테스트, 단위 테스트 결과 리뷰
6	모든 유닛 테스트 자동화
7	중요한 특성에 대한 제약사항에 동의 (성능)

 

2. 통합 테스팅 Integration testing

1	크기∙복잡도 리스크에 기반한 긍정∙부정 테스트를 포함한 모든 기능 요구사항 테스트
2	단위 간 모든 인터페이스 테스트
3	합의한 테스트 강도에 따라 모든 품질 리스크 대응
4	해결되지 않은 메이저 결함 없음 (리스크와 중요도에 따라)
5	발견된 모든 결함 보고 완료
6	가능한 모든 회귀 테스트 자동화 및 자동화된 테스트의 공용 저장소 저장

 

3. 시스템 테스팅 System testing

1	사용자 스토리 및 기능의 엔드-투-엔드 테스트
2	모든 사용자 페르소나 고려
3	시스템의 가장 중요한 품질 특성 (성능, 안정성, 신뢰성) 커버 완료
4	가능한 지원되는 환경 구성에 대한 모든 하드웨어 및 소프트웨어를 포함하여 실제 사용 환경에서 테스트 완료
5	테스트에서 커버하기로 한 모든 품질 리스크 커버 완료
6	가능한 모든 회귀 테스트 자동화 및 자동화된 테스트의 공용 저장소 저장
7	발견된 모든 결함 보고 및 가능한 수정 완료
8	해결되지 않은 주요 결함 없음 (리스크와 중요도에 따라 우선 순위화)

 

4. 유저 스토리 User story

1	반복주기에서 선택된 사용자 스토리가 팀에 의해 완료되고, 테스트 가능한 상세한 인수기준을 가짐
2	인수 테스트를 포함한 사용자 스토리의 모든 요소가 구체화되어 리뷰되고 구현이 완료됨
3	선택한 사용자 스토리의 테스트에 필요한 작업을 식별하고 팀에 의해 추정 완료

 

5. 기능 Feature

여러 유저 스토리와 에픽을 포함하는 기능에서 완료의 정의

1	인수 기3준이 있는 모든 사용자 스토리가 정의되고 고객에 의해 승인 완료
2	알려진 기술 부채 없이 설계 완료
3	알려진 기술 부채 또는 미완성 리팩토링 없이 코딩 완료
4	단위 테스트가 수행되고, 정의된 커버리지 수준 달성
5	기능의 통합 테스트 및 시스템 테스트가 정의된 커버리지 기준에 따라 수행 완료
6	주요 결함 수정 완료
7	릴리즈 노트, 사용자 설명서 및 온라인 도움말 기능을 포함한 기능 설명서 완성

 

6. 반복주기 Iteration

1	반복주기에 대한 모든 기능은 기능 수준의 기준에 따라 준비되고 개별적으로 테스트 완료
2	반복주기의 제약 내에서 해결할 수 없는 중요하지 않은 결함을 제품 백로그에 추가하고 우선순위에 따라 분류
3	반복주기에 대한 모든 기능의 통합을 완료하고 테스트 완료
4	문서의 작성, 검토, 승인 완료

반복주기가 완료되었기 때문에 이 시점에서 소프트웨어는 잠재적 출시가 가능하지만, 출시의 모든 반복주기가 완료된 것이 아닐 수 있음

 

7. 출시 Release

여러 반복주기를 포함하는 출시에서 완료의 정의

1	커버리지	출시의 모든 내용에 대한 모든 관련 테스트 기준이 테스트에 포함되어 있다. 커버리지의 적정성은 복잡성과 크기, 그리고 실패와 관련된 리스크 및 변경 사항에 의해 결정된다.
2	품질	결합 강도(하루 또는 트랙잭션 당 발견되는 결함의 수), 결함 밀도(사용자 스토리, 노력, 또는 품질 특성 수에 비례해 발견된 결함의 수), 결함 허용 범위 내에 있는 잠재 결함의 수, 해결되지 않거나 남아있는 결함(심각도 및 우선순위), 식별한 각각의 품질 리스크와 관련된 리스크의 잔류 수준이 이해하고 허용할 만한 수준인가
3	시간	미리 정해진 납기에 도달한 경우, 관련된 비즈니스 사항을 고려하여 출시
4	비용	예상된 수명 주기 비용은 출시 시스템에 대한 투자 대비 수익률을 계산하는데 사용됨(개발 및 유지보수 비용 < 제품의 예상 총 매출) 제품 생산 이후에 발생한 결함으로 인해 수명주기 비용의 주요 부분은 종종 유지보수 단계에서 발생

 

3.3.2. 인수 테스트 주도 개발 적용하기 Applying Acceptance Test-Driven Development

인수 테스트 주도 개발은 테스트 우선 접근법(Test-fist approach)이다.

테스트 케이스는 사용자 스토리를 구현하기 전 작성된다. (애자일 팀에 의해 생성, 수동∙자동으로 수행)

1. 사용자 스토리를 분석∙논의 (사용자 스토리의 모든 불완전성, 모호성, 오류 보완)

2. 테스트 케이스 생성 (모든 사람 참여 혹은 테스트 팀이 생성 후, 제3자가 검증)

기본 예제와 개방형 질문

3. 첫번째 테스트 (긍정 테스트) 완료 후 부정적인 경로에 대한 테스트 및 비기능적 특성 추가

(모든 이해관계자들이 이해할 수 있도록 기술하며 자연어 문장을 포함할 수 있음)

 

예제는 사용자 스토리의 모든 특성을 포함해야 하며 임의의 내용을 추가하지 않는다.

두 개의 예시가 사용자 스토리의 동일한 특성을 설명해서도 안된다.

 

3.3.3. 기능 및 비기능 블랙박스 테스트 설계 Functional and Non-Functional Black Box Test Design

테스트는 테스터에 의해 생성되며 개발자가 개발하는 시기에 동시에 이루어짐

사용자 스토리와 완료 기준에 따라 테스트를 설계함

(탐색적 테스트, 경험 기반 테스트와 같은 일부 테스트는 테스트 도중 설계)

동등 분할, 경계값 분석같은 기존 블랙 박스 세트스 설계 기법을 활용할 수 있음

결정 테이블 테스트, 상태 전이 테스트 포함

 

비기능적 요구 사항은 사용자 스토리와 같이 문서화 되며 블랙 박스 설계 기법도 비기능적 품질 특성에 대한 테스트를 작성하기 위해 사용될 수 있음

 

 

3.3.4. 탐색적 테스팅과 애자일 테스팅

탐색적 테스팅은 애자일에서 중요함 (테스트 분석에 사용 가능한 시간과 사용자 스토리의 세부 사항들이 제한적이기 때문)

탐색적 테스팅을 다른 경험 기반 테스팅 기법과 조합해서 사용

(이외에도 리스크 분석 기반∙요구사항 분석 기반∙모델 기반∙리그레션 회피 테스팅 과도 혼합)

테스트 설계와 테스트 실행은 미리 준비한 테스트 차터에 기반해 동시에 실행

테스트 차터는 테스트 조건들을 제공하며 이전 세션의 테스트 결과에 따라 다음 테스트의 방향을 조정함 (미리 설계된 테스팅 수행 시 화이트∙블랙 박스 테스트 기법을 설계하는 경우에도 동일)

 

테스트 차터가 포함하는 정보

1. 액터: 시스템을 사용할 것으로 예상되는 사용자

2. 목적: 액터가 달성하고자 하는 특정 목적, 테스트 조건을 포함한 차터의 전체 목적

3. 준비: 테스트 실행의 시작을 위해 필요한 준비 사항

4. 우선 순위:해당 테스트 차터의 상대적인 중요성, 사용자 스토리 혹은 리스크 수준에 따라 결정

5. 참조: 요구사항, 리스크, 그외 다른 정보들

6. 데이터: 테스트에 필요한 데이터

7. 활동: 액터가 시스템에서 수행할 수 있는 것, 흥미로운 테스트 항목 (긍정∙부정 테스트 포함)

8. 오라클: 결함인지 여부를 판단할 수 있는 제품의 올바른 동적 결과

9. 변화: 대안 활동 및 활동을 보완할 수 있는 아이디어

 

탐색적 테스팅을 관리하기 위해 세션 기반 테스트 관리 기법이 사용될 수 있음

테스팅 세션은 60~120분으로 방해받지 않아야 함

테스트 세션은 다음 사항을 포함함

1. 준비 세션 (작동방법에 대한 세부 내용 학습)

2. 분석 세션 (기능이나 특징 평가

3. 커버리지 확장 (예외 또는 경계 케이스, 시나리오, 상호 작용)

테스트의 품질은 대상 제품에 대해 질문할 수 있는 테스터의 능력에 따라 달라짐

1. 이 시스템에서 가중 중요한 것은?

2. 어떤 방식으로 시스템이 실패할 수 있는가?

3. 만약 ~ 하면 어떤 일이 생길까?

4. …일 때 어떤 일이 발생하는가?

5. 고객의 니즈, 요구 사항, 기대가 모두 충족되었는가?

6. 시스템 설치∙제거 시 모든 업그레이드 경로에서 정상적으로 수행되는가?

 

테스터의 모든 역량을 동원해서 문제점을 찾아내야 함. 이를 위해 충분한 지식과 이해가 필요

(테스트 대상, 비즈니스 영역, 소프트웨어 사용 방법, 시스템의 실패 여부 결정 방법)

 

휴리스틱은 경험 기반 테스트를 수행하는 방법 및 결과를 평가하는 방법을 안내해줌

1. 경계값

2. CRUD (쓰기, 읽기, 갱신, 삭제)

3. 설정 변경

4. 의도치 않은 장애 상황 (로그오프, 종료, 재부팅 등)

 

테스터는 테스팅 과정을 최대화 문서화해야 함, 다음과 같은 정보를 포함한다.

1. 테스트 커버리지: 입력 데이터가 무엇인지, 어느 만큼의 영역을 커버했는지, 앞으로 테스트 해야할 영역에 대한 정보

2. 평가 노트: 테스트 동안 관찰한 내용. 시스템과 기능은 안정적인지, 어떤 부분을 테스트 해야할지에 대한 아이디어 등

3. 리스크 및 전략: 어떤 리스크가 해소되었는지, 가장 중요한 리스크 중 테스트 안된 부분은 어디인지, 초기 테스트 전략이 지켜지고 있는지, 어떤 변화가 필요할지 등

4. 문제, 질문, 이상한 점: 예상치 못한 결과, 접근 방식의 효율성, 아이디어 및 테스트 시도에 대한 우려사항, 테스트 환경, 테스트 데이터, 기능, 테스트 스크립트 또는 테스트 중인 시스템에 대한 오해

5. 실제 동작: 시스템의 실제 동작에 대한 기록

 

기록된 정보는 저장되고 특정 상태 관리 도구에 적합한 형태로 요약되어 현재 상태를 쉽게 이해할 수 있도록 한다.

---

3.4. 애자일 프로젝트를 위한 도구들

애자일에서는 기존에 사용하던 테스트 관리 도구, 요구 사항 관리 도구, 결함 관리 도구(결함 추적)을 사용할 수 있지만 작업 보드, 번 다운 차트, 사용자 스토리 같은 애자일 개발에 관련된 도구를 선택하기도 한다. (애플리케이션 라이프사이클 관리 또는 작업 관리 도구)

모든 수준에서 자동화된 테스트 및 관련된 테스트 아티팩트를 관리할 필요가 있으므로 애자일에서 형상 관리 도구는 중요하다.

 

이번 장에서 설명하는 도구들은 애자일 실천 방법의 핵심인 팀 협업 및 정보 공유 보장을 위해 사용한다.

 

3.4.1. 작업 관리 및 추적 도구

애자일에서 각 스프린트가 진행되는 동안 물리적인 스토리/태스크 보드를 사용해 사용자 스토리, 테스트 및 다른 태스크들을 관리하고 추적함

애플리케이션 수명 주기 관리 및 태스크 관리 소프트웨어를 사용할 수도 있음

1. 스토리 및 스토리와 관련된 개발 및 테스트 작업을 기록하여 태스크 누락을 방지

2. 각 태스크에 팀 구성원의 작업 추정치를 기재하고 자동으로 필요한 작업을 계산하여 효율적인 반복주기 계획을 수립

3. 동일한 사용자 스토리와 연관된 개발/테스트 작업을 묶어서 팀의 전체적인 작업을 파악

4. 작업 완료 상태를 태스크에 반영함으로써 전체적인 진행 상태의 스냅샷을 제공

5. 모든 이해 관계자들이 현재 상태를 통계, 차트 및 대시 보드를 통해 신속하게 파악할 수 있는 시각적 자료를 제공

6. 태스크와 형상 관리 도구를 연동하여 코드 체크인 및 관련된 빌드 내역을 자동으로 기록한다.

일부 도구들은 업데이트 상태도 기록함

커뮤니케이션 및 정보 공유 도구

이메일, 문서, 구두 커뮤니케이션 외에도 정보공유를 강화하는 세 가지 추가 도구를 사용한다.

(위키, 메신저, 데스크탑 공유)

 

위키를 사용하면 프로젝트의 다양한 관점에 대한 지식을 온라인 상에서 생성하고 공유할 수 있다.

1. 제품 기능 다이어그램, 기능 관련 토론, 프로토타입 다이어그램, 화이트 보드 상에 기록된 토의 내용의 사진 및 기타 정보

2. 개발 및 테스트를 위한 도구 또는 기술

3. 제품 상태와 관련된 지표, 차트 및 대시 보드. 이러한 요소를 자동으로 업데이트 해주는 빌드 서버 및 작업 관리 시스템 등과 연동하면 특히 유용함

4. 팀 구성원 간의 대화

 

인스턴트 메시징, 컨퍼런스 콜, 화상 채팅 도구의 이점

1. 지리적으로 분산된 팀원 사이의 실시간 대면 커뮤니케이션

2. 스탠드업 미팅에 분산된 팀원의 참여

3. 커뮤니케이션을 물리적으로 줄어들게 하는 비용 문제를 줄임

 

데스크탑 공유 및 캡처 도구의 이점

1. 분산된 팀에서 제품 시연, 코드 리뷰 및 페어 작업 가능

2. 각 반복주기 끝의 제품 시연을 캡처하여 팀의 위키에 게시 가능

 

이러한 도구들은 의사 소통을 대처하는 수단이 아닌 보완하고 확장하는 수단으로만 사용해야 함

 

3.4.2. (실라버스 오류인지 없습니다.)

 

3.4.3. 소프트웨어 빌드 및 배포 도구

소프트웨어를 매일 빌드하고 배포하는 작업이 애자일 팀에게는 매우 중요

이를 수행하기 위해서는 지속적인 통합 및 빌드 배포 도구가 필요함ㅁ

 

3.4.4. 형상 관리 도구

형상 관리 도구는 소스 코드 저장 및 자동 테스트 뿐만 아니라 수동 테스트 및 기타 테스트 산출물도 같은 저장소에 저장됨.

이는 소프트웨어 버전과 테스트 산출물 버전 사이의 추적성을 제공하고 빠르게 변화에 대응할 수 있게 한다.

주요 유형엔 중앙 소스 제어 시스템 및 분산 버전 제어 시스템이 있다.

팀에 특성에 따라 적합한 형상 관리 도구를 결정한다.

 

3.4.5. 테스트 설계, 구현, 실행 도구

대부분은 애자일을 위해서 설계된 것은 아니지만 빠른 변화에 대응할 수 있게 중요 기능을 제공

1. 테스트 설계 도구: 마인드 맵과 같은 도구를 사용해 새로운 기능과 관련된 테스트를 빠르게 설계하고 정의하는 것인 보편적임

2. 테스트 케이스 관리 도구: 팀 전체의 개발 수명 주기 관리 또는 작업 관리 도구의 일부

3. 테스트 데이터의 준비 및 생성 도구: 데이터 및 데이터의 조합이 많은 애플리케이션을 테스트 하는 경우 유용함. 데이터의 변경이 발생했을 경우에도 DB 구조 재정의를 위한 데이터 생성 스크립트의 리팩토링에도 도움이 됨. 민감한 데이터의 제거∙익명화 스크립트도 지원하기도 하며, 대규모 데이터 입력 또는 출력의 유효성 검증도 가능

4. 테스트 데이터 입력 도구: 수동 데이터 입력에는 많은 시간이 소요되며 많은 에러가 발생함.

이를 안정적이고 효율적이게 해줌. 테스트 데이터 생성 도구 대부분은 이를 지원함.

아닐 경우 DB 관리 시스템을 사용하여 직접 접근 방식(벌크 로딩)도 가능

5. 자동화 테스트 실행 도구: 테스트 주도 개발 및 인수 테스트 주도 개발과 같은 테스트 우선 접근 방식을 지원. 테스터 및 비즈니스 관련 인력이 테이블이나 자연어로 예상 동작 표현 가능

6. 탐색적 테스트 도구: 테스트 세션 동안 응용 프로그램에서 수행된 내용 및 로그를 기록하여 결함을 재 발생시키고 분석하는데 유용. 자동화된 회귀 테스트 스위트가 구축된 경우 큰 도움이 됨

 

3.4.6. 클라우드 컴퓨팅과 가상화 도구

가상화는 하나의 물리적 자원(서버)를 다수의 개별 자원으로 활용할 수 있게 해줌

이를 통해 대규모 서버 자원을 가질 수 있다. 이는 개발 지연 방지에 도움이 됨

일부 테스트 관리 도구는 가상화 기술을 이용해 결함 발생 시점에 서버의 스냅샷을 기록하여 해당 결함의 조사를 지원한다.