ISTQB FL-Agile Tester 2. 기본 애자일 테스팅 원칙

키워드

빌드 베리피케이션 테스트	제품이 설계에 맞게 만들어지는가, 명세서를 충족하는가 검사
형상 관리 아이템	시스템을 구성하는 요소들 중 형상관리의 대상들을 구분하고 관리 목록의 번호를 정의하여 부여하는 것. 단순히 바이너리 형태의 파일이나 소스 코드 뿐만 아니라 산출물, 각종 스크립트, 소프으퉤어 개발 이력 등 개발 과정에서 작성되는 문서까지 포함한다.
형상 관리	변경 프로세스에 기술 및 관리 차원의 지시와 감독을 적용하는 원칙. 변경 프로세스는 형상 항목의 기능적/물리적 특성을 식별하여 문서화하고, 그러한 특성들의 변화를 제어하고, 변경 절차와 구현 상태를 기록 및 보호하고, 명시된 요구사항에 적합한지를 검증하는 것이다.

학습 목표

2.1 전통적인 테스팅과 애자일 접근법의 테스팅 차이

2.1.1 애자일 프로젝트와 다른 프로젝트의 테스트 활동의 차이점 (K2)

2.1.2 개발 및 테스트 활동이 애자일 프로젝트에서의 통합 방법 (K2)

2.1.3. 애자일 프로젝트의 독립적인 테스트 역할 (K2)

 

2.2 애자일 프로젝트의 테스팅 상태

2.2.1 테스트 절차와 제품 품질을 포함하여 애자일 프로젝트에서 테스팅의 상태를 의사소통 하는데 사용되는 도구와 기법 (K2)

2.2.2 다수의 반복주기에 걸쳐 테스트의 발전 과정을 설명하고, 테스트 자동화가 애자일 프로젝트에서 리그레션 리스크를 관리하는데 중요한 이유 (K2)

 

2.3 애자일 팀 내 테스터의 역할과 기술 역량

2.3.1 애자일 팀에서 테스터의 역량 (K2)

2.3.2 애자일 팀에서 테스터의 역할 (K2)

 

---

2.1. 전통적인 테스팅과 애자일 접근법의 테스팅 차이

애자일 수명주기와 기존의 수명주기의 차이점을 이해해야 함

애자일 모델은 테스팅과 개발 활동이 통합되어 있다는 점을 포함해 프로젝트 산출물, 용어, 다양한 테스트 레벨에서 사용되는 시작 및 종료 조건, 도구의 활용 및 독립적인 테스팅을 효과적으로 구현하는 데 있어서 차이점이 있음

 

2.1.1. 테스팅과 개발 활동

전통적인 수명주기와 애자일의 주요 차이점 중 하나는 주기가 매우 짧은 반복이라는 개념

각 반복주기가 완료되는 시점엔 동작하는 소프트웨어가 만들어져야 함

프로젝트 시작 단계에서 출시 계획을 수립, 이후 일련의 반복주기가 진행

각 반복주기의 시작 단계에서 반복주기 계획을 수립

선택된 사용자 스토리가 개발되며, 병렬 및 오버랩 개발, 통합과 테스팅이 일어난다.

테스팅은 반복주기의 마지막이 아닌, 진행하는 동안 지속적으로 수행

 

개발자는 사용자 스토리의 기능을 개발하고 단위 테스트를 진행

테스터는 기능을 테스트

비즈니스 이해관계자도 스토리를 같이 테스트 (테스트케이스를 활용하기도 하고, 기능을 사용하며 피드백을 줌)

잔존 결함과 기술 채무를 해결하기 위해 주기적으로 반복주기를 강화(Hardening)하거나 안정화(Stabilization)을 시키기도 함. (가장 좋은 방법은 모든 기능이 테스트되고 통합되는 것)

다른 좋은 방법은 이전 반복주기에서 남겨진 결함들을 다음 반복주기 시작 시 모두 처리하는 것

이러한 결함들은 다음 반복주기의 백로그에 포함됨 (결함 먼저 수정하기)

각 반복주기가 완료된 시점에서는 소프트웨어 인도(Delivery)가 발생할 수 있음

 

리스크 기반 테스팅 전략 사용 시 상위 레벨의 리스크 분석은 출시 계획 중 수립

각 반복주기와 관련된 특정한 품질 리스크는 반복주기 계획 단계에서 정의

이 리스크 분석 결과는 개발 순서, 구현된 기능과 관련된 테스팅 우선 순위에 영향을 미치며 테스트 작업 추정에 영향을 끼침

 

페어링 (두 명의 테스터가 짝을 지어 하나의 기능을 테스트, 개발자와 할 수도 있음)

테스터는 코칭 역할을 수행하며 테스팅 지식을 팀 구성원과 공유, 품질에 대한 공동 책임을 독려

 

모든 테스팅 레벨에서 테스트 자동화를 수행하고, 이를 유지하는데 많은 시간을 사용함

수동 테스팅의 대부분은 소프트웨어 공격, 탐색적 테스팅, 에러 추정과 같은 경험∙결함 기반 기법들을 사용함.

개발자들은 단위 테스트 생성에, 테스터는 자동화된 통합, 시스템, 시스템 통합 테스트에 집중

 

애자일 원칙 중 한가지 핵심인 변화가 발생할 수 있으며, 이는 리그레션 테스팅에 영향을 끼침

 

2.1.2. 프로젝트 작업 산출물

테스터는 3가지 작업 산출물에 집중해야함

1. 비즈니스 중심의 산출물 (요구사항, 사용방법)

2. 개발 작업 산출물 (시스템 설계, 실제 구현된 시스템, 코드)

3. 테스트 작업 산출물 (시스템 테스트 방법, 실제 시스템 테스트 실행, 테스트 결과)

 

많은 문서 생산을 지양, 자동화된 테스트 코드에 집중

개발 효율성 증가(문서 지양) vs 비즈니스, 테스팅, 개발 및 유지보수 활동 지원(문서 생산)의 균형

출시 계획 수립 시 필요한 산출물의 종류와 문서 작성 수준을 결정

 

비즈니스 중심 산출물 (사용자 스토리 + 인수 기준)

사용자 스토리는 하나의 반복주기에서 완료될 수 있도록 작은 기능으로 정의

에픽: 관련된 기능의 큰 집합 혹은 하나의 복장한 기능으로 조합할 수 있는 하위 기능의 집합

각 에픽과 사용자 스토리는 연관된 인수 기준을 가짐

 

개발자 산출물 (코드)

자동화된 단위 테스트 나 순차적인 테스트를 작성함

 

테스터 작업 산출물 (자동화된 테스트와 테스트 계획, 품질 리스크 카탈로그, 수동 테스트 케이스, 결함 리포트, 결함 결과 로그)

문서들은 간단히 작성

결함 리포트와 테스트 결과 로그로부터 테스트 통계를 도출

 

2.1.3. 테스트 레벨

테스트 레벨은 테스트 대상의 성숙도∙완성도에 관련된 테스트 활동들을 논리적으로 묶은 것

 

순차 주기 모델에서는 종료 기준이 다음 레벨의 시작 조건이지만, 반복적 모델에서는 아님

테스트 레벨은 오버랩(중첩 혹은 병렬) 요구 명세, 설계 명세 및 개발 활동은 테스트 레벨과 오버랩

애자일에서는 요구사항, 설계, 코드에 대한 변화가 발생할 수 있기 때문에 오버랩 됨

스크럼에서는 반복주기 계획 완류 이후 변경은 허락되지 않으나 허락하기도 함

 

모든 사용자 스토리는 다음과 같은 테스팅 활동을 순차적으로 적용함

1. 단위 테스팅: 개발자

2. 기능 인수 테스팅

2.1. 기능 검증(Validation) 테스팅: 자동화 / 개발자or테스터 / 유저 스토리에 대한 인수 기준 검증

2.2. 기능 확인(Verification) 테스팅: 수동 / 개발자&테스터&비즈니스 이해관계자 / 사용 목적에 적합한지 확인

 

이와 함께 반복주기가 진행되는 동안 리그레션 테스팅이 병렬로 진행

자동화된 단위 테스트, 기능 베리피케이션 테스트, (리그레션 테스팅은 지속적인 통합 프레임워크에 포함됨)

일부 애자일 프로젝트에서는 테스트 대상 사용자 스토리가 준비되는 즉시 시스템 테스트 레벨을 적용 (기능 테스트, 성능, 신뢰성, 사용성 및 다른 관련 테스트 유형 포함)

 

애자일 팀은 다양한 형태의 인수 테스트를 적용

알파 테스트, 외부 베타 테스트, 사용자 인수 테스트, 운영 인수 테스트, 규제 승인 테스티 및 계약 승인 테스트

 

2.1.4. 테스팅과 형상 관리

애자일 프로젝트는 무거운 자동화 도구들을 많이 사용함

개발자들은 정적 분석, 단위 테스팅, 코드 커버리지 측정을 수행

코드와 단위 테스트 코드를 형상 관리 시스템에 입력하며 자동화된 빌드 및 테스팅 프레임워크를 사용 (이때 정적 분석과 단위 테스트를 자동으로 수행)

 

자동화된 테스트는 통합 및 시스템 레벨에서 수행되는 기능 테스트를 포함

자동화된 테스트 케이스는 테스팅 하네스, 오픈 소스 사용자 인터페이스 기능 테스트 도구, 사용 도구로 생성하며 자동화 테스트와 통합하기도 함

기능 테스트에 시간이 오래 걸리면 단위 테스트와 별도로 실행

자동화 테스트의 주 목적은 빌드의 설치∙실행 가능 여부 확인임 (테스트 실패 시 결함 모두 수정해야함) 이 효과를 위해서는 실시간 보고가 필요

결과적으로 비용의 낭비와 효율성 저하를 줄일 수 있음

 

이 자동화된 테스팅과 빌드 도구는 잦은 변경과 관련된 리그레션 리스크를 관리하는데 도움이 됨

하지만 단위 테스트의 제한된 결함 검출 효율성 때문에 과도하게 의존하면 안됨

통합 레벨과 시스템 레벨의 자동화 테스트도 요구됨

 

2.1.5. 독립적 테스팅을 위한 조직 구성 옵션

팀에 테스터를 배치하고 다양한 테스팅을 수행할 수 있으나 독립성과 객관적 평가가 불가능

 

독립적인 테스터들은 결함을 효과적으로 발견할 수 있다. (독립성 보장 / 공정하고 객관적 평가)

하지만 개발팀∙이해관계자 간 관계의 문제나 기능에 대한 이해부족이 발생할 수 있음

 

이를 보완하여 분리된 테스트 팀을 운영하며 프로젝트 시작 시 테스터들을 애자일 팀에 할당함

제품에 대한 이해, 강력한 관계를 유지할 수 있음

이외에 배치하지 않고 별개로 자동화 테스트 도구 개발, 비기능 테스트 수행, 테스트 환경 및 데이터 구축 및 지원, 하나의 스프린트에서 완료할 수 없는 레벨 테스트를 수행시킬 수도 있음

---

2.2. 애자일 프로젝트의 테스팅 상태

애자일에서는 변화가 발생하며 이는 테스트 상태, 테스트 진행 및 제품 품질에 영향을 줌

테스터는 이를 적절한 의사 전달을 할 수 있어야 함

변화는 이전 반복주기에서 기존의 기능에 영향을 줄 수 있으므로 수동 및 자동화 테스트를 지속적으로 업데이트하여 리그레션 리스크를 효과적으로 처리해야 함

 

2.2.1. 테스트 상태, 진행 및 제품 품질 커뮤니케이션

테스터는 각 반복주기 별 테스트 진척과 상태를 기록함

테스트 자동화 결과, 애자일 태스크 보드 상의 테스트 태스크와 스토리 진행 내용, 위키 대시보드나 대시보드 스타일의 이메일 혹은 구두로 공유함

이를 활용해 테스트 결과 기반 상태 보고서를 자동으로 생성하는 도구를 활용 (시간 절약)

 

번다운 차트 (출시 또는 반복주기에 할당된 시간 및 그 안에 수행할 작업 양)로 진척 상황을 확인

애자일 팀은 현재 상태를 시각화하기 위해 애자일 태스크 보드를 사용함

여기엔 스토리 카드, 개발 태스크, 테스트 태스크, 반복주기 계획 중 만들어진 다른 태스크를 포함함 (색상 별로)

태스크 작업은 사용자 스토리에 정의된 인수기준을 가지고 완료 기준을 달성한 것은 done 처리함 (테스트 자동화 스크립트, 수동 테스트, 탐색적 테스트 수행 후)

그리고 태스크 보드의 상태를 리뷰하며 속도가 적절한지, 느린 태스크가 없는지 방해하는 이슈를 확인함

 

일일 스탠드업 회의는 모두가 참여함, 다음과 같은 상황을 공유

1. 지난 일일 미팅 이후 완료한 작업

2. 다음 회의까지 완료할 작업

3. 현재하고 있는 작업

 

제품 품질 향상을 위해 고객 만족도 조사를 하며 피드백을 수집함.

팀은 테스트 성공/실패율, 결함 발견율, 확인과 리그레션 테스트 결과, 결함 밀도, 결함 발견과 수정률, 요구사항 커버리지, 리스크 커버리지, 코드 커버리지, 코드 변동들을 활용하여 기존 라이프사이클과 동일하게 매트릭 수집과 보고로 의사결정을 할 수 있음

 

2.2.2. 수동 및 자동화된 테스트 케이스 갱신을 통한 리그레션 리스크 관리하기

제품이 완성되어 가며 테스팅 범위 역시 늘어남

코드 변경 테스팅과 함께 이전 반복주기 기능에 리그레션이 발생하지 않았는지 확인.

(애자일에서의 변경 때문에 리그레션 리스크로 인해 광범위한 코드 변경 가능성이 있음)
조기에 모든 테스트 레벨에서 테스트 자동화에 투자해야 함

(자동화 테스트 케이스, 수동 테스트 케이스, 테스트 데이터 및 다른 형상 관리 도구를 통해 항상 최신으로 유지해야 함)

시간 압박 시 모든 테스트를 하는 것을 불가능

이전과 현재의 반복주기에서 수행한 수동 및 자동화 테스트 케이스를 리뷰해서 리그레션 테스트 스위트에 할당 가능한 테스트를 선택하고 불필요한 테스트 케이스는 삭제함

 

테스트 케이스 검토 시 테스터는 자동화에 대한 적합성을 고려해야 한다.

변경에 대한 테스트 케이스 최신화할 수 있는 역량을 가져야 한다. (기존 설계는 출시 계획 동안 수립하고 이를 일관적으로 적용해야 함)

 

자동화된 테스트를 적용함으로써 제품 품질에 대한 빠른 피드백을 얻을 수 있음

자동화된 테스트 케이스와 그 결과를 형상 관리 시스템에 저장해서 언제든 애자일 팀은 확인할 수 있음

 

자동화된 단위 테스트 코드를 수행해서 빌드 중단이 일어나지 않도록 해야함.

이 결과는 즉각적인 피드백을 제공하긴 하지만 제품 품질에 대해서는 제공하지 못함

 

지속적인 통합을 전체 시스템 빌드에 적용하는 경우, 자동화된 인수 테스트를 정기적으로 실행함. 하지만 시간이 오래 걸리기 때문에 코드 체크인 시 마다 하지는 않는다.

이 또한 즉각적인 피드백을 제공하긴 하지만 제품 품질에 대해서는 제공하지 못함

 

자동화 테스트는 전체 시스템을 대상으로 지속적으로 실행할 수 있다.

시스템 기능과 통합 지점을 검증하기 위한 자동화 테스트의 초기 집합은 새로운 빌드가 테스트 환경에 배포되는 즉시 생성되어야 한다. 이를 일반적으로 빌드 베리피케이션 테스트라고 한다.

 

리그레션 테스트 셋에 포함된 자동화 테스트는 매일 주요 빌드의 일부로 실행되고, 새로운 빌드가 배포될 때 다시 실행된다. 만약 실패하는 즉시 원인을 분석해야 한다.

변경된 기능으로 인해 실패할 수 있으며, 이땐 테스트 케이스 및 사용자 스토리는 새로운 인수기준에 따라 업데이트 되어야 한다.

 

다음 테스트 업무들은 자동화가 가능하다.

1. 테스트 데이터 생성

2. 시스템의 테스트 데이터 기록

3. 테스트 환경에 빌드 배포

4. 테스트 기준점으로 테스트 환경 복원

5. 데이터 결과 비교

 

이를 통해 새로운 기능 테스트에 집중할 수 있다.

---

2.3. 애자일 팀의 테스터 역할과 역량

팀 내 인원들과의 협력이 중요하다.

 

2.3.1. 애자일 테스터의 역량

CTFL 실라버스에 언급된 모드 역량을 보유해야 함

테스트 자동화, 테스트 주도 개발, 인수 테스트 주도 개발, 화이트∙블랙 박스 기반 테스팅, 경험기반 테스팅

 

대인 관계 역량도 중요

1. 팀 멤버들 및 이해관계자와 협업 시 긍정적이며 문제 해결 중심적인 태도로 임함

2. 제품과 관련해 핵심적이고, 품질 중심적이며, 비판적인 생각을 제안

3. 작성된 명세에 의존하기 보다는 이해관계자로부터 적극적으로 정보를 획득

4. 테스트 결과, 테스트 진척 및 제품 품질에 대해 정확하게 평가하고 보고

5. 고객 대표자 및 이해관계자들과의 효과적인 협업을 통해 테스트 가능한 사용자 스토리, 인수기준을 정희

6. 프로그래머 및 다른 팀 멤버들과의 협업

7. 변경, 추가 또는 테스트 개선 등 변화에 대한 빠른 대응

8. 스스로 작업을 조직화하고 계획을 수립

 

 

2.3.2. 애자일 팀의 테스터 역할

테스트 상태, 진척, 제품 품질에 대한 피드백 생성 및 제공, 프로세스 품질에 대한 피드백 제공

1. 테스트 전략을 이해하고 실행하며 업데이트

2. 적용 가능한 모든 커버리지 영역에서 테스트 커버리지를 측정하고 보고

3. 적절한 테스팅 도구의 사용을 보장

4. 테스트 환경과 테스트 데이터를 구성하고 활용하며 관리

5. 결함을 보고하고 해결하기 위해 팀과 협업

6. 테스팅 관련 코칭

7. 출시 계획 및 반복주기 계획에 적절한 테스팅 업무를 반영

8. 개발자 및 비즈니스 이해관계자들과 능동적 협력을 통해 요구사항, 테스트 가능성, 일관성, 완전성 측면을 명확화

9. 팀 회고에 적극적으로 참여하여 개선안을 제안하고 구현

 

애자일 조직은 다음과 같은 조직적인 리스크를 마주할 수 있음

1. 테스터와 개발자의 밀접한 작업 때문에 테스터 사고 방식을 잃을 수 있음

2. 테스터가 팀 내 비효율적, 비효과적, 낮은 품질 관행에 관용 또는 침묵할 수 있음

3. 반복주기에서 발생화는 변화를 제한된 시간 때문에 변화의 속도를 따라갈 수 없음

 

이를 위해 테스터의 독립성을 보장할 수 있어야 한다.