용어
블랙박스 테스트 기법(black-box test technique), 경계값 분석(boundary value analysis), 체크리스트 기반
테스팅(checklist-based testing), 커버리지(coverage), 결정 커버리지(decision coverage), 결정 테이블
테스팅(decision table testing), 오류 추정(error guessing), 동등 분할(equivalence partitioning), 경험 기반
테스트 기법(experience-based test technique), 탐색적 테스팅(exploratory testing), 상태 전이 테스팅(state
transition testing), 구문 커버리지(statement coverage), 테스트 기법(test technique), 유스케이스(use case
testing), 화이트박스 테스트 기법(white- box test technique)
학습목표
4.1 테스트 기법의 종류 (Categories of Test Techniques)
4.1.1 블랙박스 테스트 기법, 화이트박스 테스트 기법, 경험 기반 테스트 기법의
특성과 공통점 및 차이점을 설명할 수 있다.
4.2 블랙박스 테스트 기법 (Black-box Test Techniques)
4.2.1 주어진 요구사항에 동등 분할을 적용해서 테스트 케이스를 도출할 수 있다.
4.2.2 주어진 요구사항에 경계값 분석을 적용해서 테스트 케이스를 도출할 수
있다.
4.2.3 주어진 요구사항에 결정 테이블 테스팅을 적용해서 테스트 케이스를 도출할
수 있다.
4.2.4 주어진 요구사항에 상태 전이 테스팅을 적용해서 테스트 케이스를 도출할
수 있다.
4.2.5 유스케이스에서 테스트 케이스를 도출하는 방법을 설명할 수 있다.
4.3 화이트박스 테스트 기법 (White-box Test Techniques)
4.3.1 구문 커버리지를 설명할 수 있다.
4.3.2 결정 커버리지를 설명할 수 있다.
4.3.3 구문 및 결정 커버리지의 가치를 설명할 수 있다.
4.4 경험 기반 테스트 기법 (Experience-based Test Techniques)
4.4.1 오류 추정을 설명할 수 있다.
4.4.2 탐색적 테스팅을 설명할 수 있다.
4.4.3 체크리스트 기반 테스팅을 설명할 수 있다.
4.1 테스트 기법의 종류 Categories of Test Techniques
이번 장은 테스트 기법을 설명한다. 테스트 기법의 목적은 테스트 컨디션, 테스트 케이스, 테스트 데이터 식별을
지원하는 것이다.
테스트 기법의 선택은 다음과 같은 여러 요소를 기반으로 이루어진다:
● 컴포넌트나 시스템의 복잡도
● 규제 기준
● 고객 또는 계약 요구사항
● 리스크 수준과 유형
● 사용 가능한 문서
● 테스터의 지식과 역량
● 사용 가능한 도구
● 시간과 예산
● 소프트웨어 개발 수명주기 모델
● 컴포넌트나 시스템에서 예상되는 결함 유형
일부 기법은 특정 상황과 테스트 레벨에 더 적합한 반면, 모든 테스트 레벨에 적합한 기법도 있다. 테스트
케이스를 작성할 때 테스터는 일반적으로 테스트 노력 대비 가장 좋은 결과를 얻기 위해 다양한 테스트 기법을
조합해서 사용한다.
테스트 분석, 테스트 설계, 테스트 구현 활동에서 테스트 기법의 사용은 매우 비공식적인 형식(거의 또는 전혀
문서화하지 않음)부터 매우 공식적인 형식까지 다양할 수 있다. 적절한 수준의 공식성은 테스트 및 개발
프로세스의 성숙도, 시간적인 제한, 안전 또는 규정 요구사항, 관련된 사람들의 지식과 역량, 준수해야 하는
소프트웨어 개발 수명주기 모델을 포함하는 테스팅의 정황에 따라 결정된다.
4.1.1 테스트 기법의 종류와 특성 (Categories of Test Techniques and Their Characteristics)
이 실러버스에서는 테스트 기법을 블랙박스, 화이트박스, 경험 기반으로 분류한다.
블랙박스 테스트 기법(행위 기법 또는 행위 기반 기법이라고도 함)은 적절한 테스트 베이시스(예: 공식 요구사항
문서, 명세서, 유스케이스, 사용자 스토리 또는 비즈니스 프로세스)에 대한 분석을 기반으로 한다. 이 기법은
기능 테스팅과 비기능 테스팅 모두에 적용할 수 있다. 블랙박스 기법은 테스트 대상의 내부 구조를 고려하지
않고, 입력과 출력에 집중한다.
화이트박스 테스트 기법(구조 기법 또는 구조 기반 기법이라고도 함)은 아키텍처, 세부 설계, 내부 구조, 테스트
대상의 코드에 대한 분석을 기반으로 한다. 블랙박스 기법과는 달리, 화이트박스 기법은 테스트 대상의 내부
구조와 처리에 집중한다.
경험 기반 테스트 기법은 개발자, 테스터, 사용자의 경험을 활용하여 테스트를 설계, 구현, 실행한다. 이 기법은
블랙박스 및 화이트박스 테스트 기법과 결합해서 사용하는 경우가 많다.
블랙박스 테스트 기법의 일반적인 특징은 다음과 같다:
● 테스트 컨디션, 테스트 케이스, 테스트 데이터는 소프트웨어 요구사항, 명세서, 유스케이스, 사용자
스토리와 같은 테스트 베이시스로부터 도출한다.
● 테스트 케이스는 요구사항과 요구사항 구현 결과물 간 차이와 편차를 식별하는 데 사용한다.
● 커버리지는 테스트 베이시스에서 테스트된 항목과 테스트 베이시스에 적용한 기법을 기반으로
측정한다.
화이트박스 테스트 기법의 일반적인 특성은 다음과 같다:
● 테스트 컨디션, 테스트 케이스, 테스트 데이터는 코드, 소프트웨어 아키텍처, 상세 설계 또는
소프트웨어 구조와 관련된 기타 정보를 포함한 테스트 베이시스로부터 도출한다.
● 커버리지는 선택한 구조(예: 코드나 인터페이스) 내에서 테스트한 항목과 테스트 베이시스에 적용된
기법을 기준으로 측정한다.
경험 기반 테스트 기법의 일반적인 특징은 다음과 같다:
● 테스트 컨디션, 테스트 케이스, 테스트 데이터는 테스터, 개발자, 사용자, 기타 이해관계자의 지식과
경험과 같은 테스트 베이시스로부터 도출한다.
지식과 경험은 소프트웨어의 예상 동작과 사용 환경, 발생 가능성이 있는 결함과 분포 등을 포함한다.
국제 표준(ISO/IEC/IEEE 29119-4)에서 테스트 기법과 관련 커버리지 측정 방법에 대한 자세한 정보를 찾을 수
있다 (Craig 2002 와 Copeland 2004 에서 기법에 대한 추가 참조).
4.2 블랙박스 테스트 기법 Black-box Test Techniques
4.2.1 동등 분할 (Equivalence Partitioning)
동등 분할은 특정 파티션(partitions)의 모든 변수는 동일한 방식으로 처리된다는 가정으로 파티션(‘동등
클래스’라고도 알려져 있음)에 데이터를 분할한다 (Kaner 2013 과 Jorgensen 2014 참조). 유효한 값과 비유효한
값 모두에 대해 동등 분할을 구성할 수 있다.
● 유효값(valid values)이란 컴포넌트나 시스템에 입력되는 값이다. 유효한 값을 포함하는 동등한
파티션을 “유효 동등 분할”이라고 한다.
● 비유효값(invalid values)이란 컴포넌트나 시스템이 거부하는 값이다. 유효하지 않은 값을 포함하는
동등한 파티션을 “비유효 동등 분할”이라고 한다.
● 분할은 입력값, 출력값, 내부값, 시간관련값(예: 이벤트 전 또는 후), 인터페이스 매개변수(예: 통합
테스팅에서 테스트하는 통합 컴포넌트)를 포함하여 테스트 대상과 관련된 모든 데이터 요소에 대해
식별할 수 있다.
● 필요한 경우 모든 파티션은 하위 파티션으로(sub partitions) 나눌 수 있다.
● 모든 값은 동등 분할에 포함되어야 하며, 하나의 값은 하나의 동등 분할에만 속해야 한다.
● 비유효 동등 분할을 테스트 케이스로 만들 때는 장애가 마스크(masked) 즉, 가려지는 것을 방지하기
위해 개별적으로 테스트해야 하며, 다른 비유효 동등 분할과 조합하지 않아야 한다. 동시에 여러
장애가 발생할 때 겉으로 드러나는 하나의 장애 때문에 나머지가 인식되지 않아 장애가 가려지는
경우가 발생한다.
동등 분할 기법으로 100% 커버리지를 달성하기 위해서는 식별한 모든 분할(비유효 분할 포함)의 각 분할에서
최소 한 개의 값을 사용해 테스트 케이스를 작성해야 한다. 동등 분할 커버리지는 일반적으로 백분율로
표기하며, 최소한 한 개의 값으로 테스트한 동등 분할 수를 식별한 모든 동등 분할의 수로 나눠서 계산한다.
동등 분할은 모든 테스트 레벨에 적용할 수 있다.
4.2.2 경계값 분석 (Boundary Value Analysis)
경계값 분석(BVA)은 동등 분할의 확장 형태이지만 각 파티션이 순서화되어 있고, 숫자 또는 연속 데이터로
구성된 경우에만 적용할 수 있다. 분할의 최소값과 최대값(또는 첫 번째값과 마지막값)은 해당 분할의 경계값이
된다 (Beizer 1990 참고).
예를 들어, 특정 입력 필드가 한 자리 정수값만 입력으로 받아들이고 정수가 아닌 값의 입력은 막기 위해 입력
방법을 키패드(keypad)로 제한한다고 가정해보자. 유효 범위는 1 이상 5 이하이다. 따라서 3 개의 동등 분할이
존재한다: 비유효(너무 낮음); 유효; 비유효(너무 높음). 유효 동등 분할의 경계값은 1 과 5 이다. 비유효(너무
높음) 분할의 경계값은 6 이다. 비유효(너무 낮음) 분할은 변수가 하나뿐인 파티션으로 유일한 값 0 이 경계값이
된다.
위의 예제에서는 각 경계에 대해 두 개의 값을 식별했다. 비유효(너무 낮음)와 유효 사이의 경계에 대해서는
테스트 값 0, 1 을, 유효와 비유효(너무 높음) 사이의 경계에 대해서는 테스트 값 5, 6 을 선택했다. 이 기법의
여러 유형 중에는 경계당 세 개의 경계값을 식별하는 것도 있다: 경계 직전 값, 경계에 해당하는 값, 경계 직후의
값. 경계값을 세 개 선택하는 경우로 앞에 주어진 예제를 살펴보면, 낮은 쪽 경계에 해당하는 테스트 값은 0, 1,
2 가 되고 높은 쪽 경계에 해당하는 테스트 값은 4, 5, 6 이 된다 (Jorgensen 2014).
동등 분할의 경계에서 동작이 잘못될 확률이 동등 분할 중간의 값에서 잘못될 확률에 비해 높다. 명시된
경계값과 구현한 경계값 모두 의도했던 값보다 높거나 낮게 설정되거나, 모두 생략하거나 의도하지 않았던
경계값이 추가되었을 수 있다는 사실을 기억하는 것이 중요하다. 경계값 분석과 테스팅을 통해 소프트웨어가
경계값이 원래 속한 분할의 동작이 아닌 다른 분할의 동작을 수행하는 것과 같은 종류의 결함 대부분을 식별할
수 있다.
경계값 분석은 모든 테스트 레벨에 적용할 수 있다. 이 기법은 일반적으로 숫자의 범위(날짜, 시간 포함)와
연관된 요구사항을 테스트하는 데 적용된다. 경계값 분석 커버리지는 보통 백분율로 표기하며, 테스트한
경계값의 수를 식별한 모든 경계값의 수로 나눠서 계산한다.
4.2.3 결정 테이블 테스팅 (Decision Table Testing)
결정 테이블은 시스템이 구현해야 하는 복잡한 비즈니스 규칙을 기록하기에 좋은 방법이다. 결정 테이블을
작성할 때 테스터는 시스템의 조건(주로 입력)과 예상 동작(주로 출력)을 식별한다. 이것들은 테이블의
행(rows)을 형성하며 일반적으로 조건은 위쪽에, 기대 결과는 아래쪽에 둔다. 각 열(column)은 하나의 결정
규칙으로 특정 조건의 고유한 조합과 연관된 기대 결과로 정의한다. 조건과 기대 결과의 값은 일반적으로 참
또는 거짓으로 표기하거나, 빨간색, 녹색, 파란색 등과 같은 비연속 값으로 표기하지만 숫자나 숫자 범위로
표기하는 경우도 있다. 이러한 여러 가지 유형의 조건과 기대 결과를 하나의 결정 테이블에 표기하는 경우도
있다.
결정 테이블의 일반적인 표기법은 다음과 같다:
조건:
● Y, 조건이 참이라는 것을 의미 (T 또는 1 로 표기할 수 있음)
● N, 조건이 거짓이라는 것을 의미 (F 또는 0 으로도 표기할 수 있음)
● —, 조건의 값이 중요하지 않다는 것을 의미 (N/A 로 표기할 수 있음)
기대 결과:
● X, 행동이 일어난다는 것을 의미 (Y, T, 1 로 표기할 수 있음)
● 공백(blank), 행동이 일어나지 않음을 의미 (—, N, F, 0 으로 표기할 수 있음)
전체 결정 테이블에는 모든 조건 조합을 포괄 할 수 있는 충분한 열 (테스트 사례)이 있다. 결과에 영향을 미치지
않는 열, 예를 들어, 불가능한 조건 조합 등을 삭제하면 테스트 케이스 수가 상당히 줄어들 수 있다. 결정
테이블 축소 방법에 대한 자세한 정보는 ISTQB-CTAL-AT 에서 찾을 수 있다.
결정 테이블 테스팅에서 일반적인 최소 커버리지 기준은 테이블의 결정 규칙당 최소 한 개의 테스트 케이스를
작성하는 것이다. 이것은 일반적으로 모든 조건 조합을 포함한다. 커버리지는 일반적으로 백분율로 표기하며,
최소 한 개의 테스트 케이스로 테스트한 결정 규칙의 수를 식별한 모든 결정 규칙의 수로 나눠서 계산한다.
결정 테이블 테스팅의 장점은 중요한 모든 조건 조합을 식별하는 데 도움이 된다는 것이다. 그 중에는 결정
테이블을 사용하지 않았으면 간과했을 수 있는 조합도 있을 수 있다. 또한, 요구사항의 누락된 부분을 찾는 데
도움이 된다. 이는 소프트웨어의 동작이 조건 조합에 영향을 받는 모든 상황에 적용 가능하며, 모든 테스트
레벨에 적용할 수 있다.
4.2.4 상태 전이 테스팅 (State Transition Testing)
컴포넌트나 시스템은 현재 조건이나 기존 이력(예를 들어, 시스템이 초기화되고 난 후 발생한 이벤트)에 따라
이벤트에 대해 다르게 반응할 수 있다. 기존 이력은 상태라는 개념을 활용해서 요약할 수 있다. 상태 전이
다이어그램은 소프트웨어의 가능한 상태뿐만 아니라 소프트웨어가 상태 간에 어떻게 진입하고 빠져나오는지에
대한 전이 방법을 보여준다. 전이는 이벤트에 의해 시작된다 (예를 들어, 사용자가 입력 필드에 값을 입력). 이
이벤트는 전이라는 결과를 가져온다. 하나의 이벤트에 의해 동일한 상태로부터 두 개 이상의 다른 전이가
발생할 수 있다. 상태 변화로 소프트웨어가 특정 행동을 할 수도 있다 (예: 연산 결과 또는 오류 메시지 출력).
상태 전이 테이블은 상태 간의 모든 유효 전이와 잠재적인 비유효 전이뿐만 아니라, 유효 전이와 관련된 이벤트,
결과 조치를 보여준다. 상태 전이 다이어그램은 일반적으로 유효한 전이만 보여주며, 비유효 전이는 표시하지
않는다.
테스트는 상태의 일반적인 순서를 커버하거나, 모든 상태를 실행하거나 모든 상태 전이를 실행하거나 특정한
상태 전이 순서를 실행하거나 또는 불가능한 상태 전이를 테스트하도록 설계할 수 있다.
상태 전이 테스팅은 메뉴 기반 애플리케이션에 사용하며, 임베디드 소프트웨어 업계에서 널리 사용하고 있다.
이 기법은 또한 구체적인 상태를 포함한 비즈니스 시나리오를 모델링하거나 화면 탐색을 테스팅하는 데
적합하다. 상태의 개념은 추상적이다. 이는 코드 몇 줄 또는 전체 비즈니스 프로세스를 나타낼 수도 있다.
커버리지는 일반적으로 백분율로 표기하며, 식별한 상태나 전이 중 테스트된 수를 식별한 모든 상태나 전이의
수로 나눠서 계산한다. 상태 전이 테스팅 커버지리 조건에 대한 추가 정보는 ISTQB-CTAL-TA 에서 찾을 수 있다.
4.2.5 유스케이스 테스팅 (Use Case Testing)
유스케이스에서 테스트를 도출할 수 있으며, 이것은 소프트웨어 항목 간의 상호작용을 설계하는 특정 방법이다.
유스케이스는 소프트웨어 기능에 대한 요구사항을 통합한다. 유스케이스는 액터(actor, 즉 사용자, 외부
하드웨어, 기타 컴포넌트나 시스템)와 대상(유스케이스를 적용하는 컴포넌트나 시스템) 간의 관계이다.
각 유스케이스는 대상(subject)이 하나 이상의 액터와 협력하여 수행할 수 있는 동작들을 명시하고 있다 (UML
2.5.1 2017). 유스케이스를 상호작용과 활동으로 설명하기도 하고, 적절한 경우 사전조건, 사후조건 및 자연어로
설명할 수도 있다. 액터와 대상 간의 상호작용으로 대상의 상태가 변경될 수 있다. 상호작용은 워크플로우, 활동
다이어그램, 비즈니스 프로세스 모델로 시각화할 수 있다.
유스케이스에는 예외 동작 및 오류 처리(시스템 응답과 프로그래밍, 애플리케이션 및 통신 오류로부터의 복구,
예를 들어, 오류 메시지 발생)를 포함한 기본 동작의 가능한 변형이 포함된다. 테스트는 정의한 동작(기본, 예외
또는 대안, 오류 처리)을 실행하도록 설계된다. 커버리지는 일반적으로 숫자로 표기하며, 테스트한 유스케이스
동작 수를 모든 유스케이스 동작 수로 나눠서 계산한다.
유스케이스의 커버리지 조건에 대한 추가 정보는 ISTQB-CTAL-TA 에서 찾을 수 있다.
4.3 화이트박스 테스트 기법 White-box Test Techniques
화이트박스 테스팅은 테스트 대상의 내부 구조를 기반으로 한다. 화이트박스 테스트 기법은 모든 테스트
레벨에서 적용할 수 있지만, 이 절에서 언급하고 있는 두 가지 코드 관련 기법은 단위 테스트 레벨에서 가장
일반적으로 사용된다. 안전 최우선, 임무 최우선, 높은 무결성 환경에서 더 높은 커버리지 달성을 위해 적용하는
고급 기법들도 있지만, 여기서는 다루지 않는다. 그런 기법에 대한 자세한 내용에 대해서는 ISTQB-CTAL-TTA 를
참조한다.
4.3.1 구문 테스팅과 커버리지 (Statement Testing and Coverage)
구문 테스팅은 코드의 잠재적으로 실행 가능한 구문을 실행한다. 커버리지는 일반적으로 백분율로 표기하며,
테스트로 실행한 구문의 수를 테스트 대상의 모든 실행 가능한 구문의 수로 나눠서 계산한다.
4.3.2 결정 테스팅과 커버리지 (Decision Testing and Coverage)
결정 테스팅은 코드에 존재하는 결정문을 실행하고 결정문의 결과에 따라 실행되는 코드를 테스트한다. 이것을
달성하기 위해 테스트 케이스는 결정문에서 시작되는 제어 흐름을 따라 실행된다 (예를 들어, IF 문에서 결과가
참인 경우와 거짓인 경우; CASE 문에서 기본 결과를 포함한 가능한 모든 결과를 필요로 하는 테스트 케이스).
커버리지는 일반적으로 백분율로 표기하며, 테스트로 실행된 결정문 결과의 수를 테스트 대상의 가능한 모든
결정문 결과의 수로 나눠서 계산한다.
4.3.3 구문 및 결정 테스팅의 가치 (The Value of Statement and Decision Testing)
100% 구문 커버리지를 달성하면 코드에 존재하는 모든 실행 가능한 구문을 최소한 한 번씩은 테스트했다는
것을 의미하지만, 모든 결정 로직을 테스트했다는 것을 보장하지는 않는다. 이 실러버스에서 다루고 있는 두
가지 화이트박스 기법 중 구문 테스팅은 결정 테스팅보다 커버리지가 낮다.
100% 결정 커버리지를 달성하면 명확한 거짓 구문이 명시되지 않은 경우(예를 들어, IF 문에 else 문이 없는
경우)에도 결과가 참인 경우와 거짓인 경우를 포함한 모든 결정 결과가 실행되었다는 것을 의미한다. 구문
커버리지는 다른 테스트에 의해 실행되지 않은 코드의 결함을 찾는 데 도움이 된다. 결정 커버리지는 다른
테스트가 참과 거짓 결과 모두를 테스트하지 않은 코드의 결함을 찾는 데 도움이 된다.
100% 결정 커버리지는 100% 구문 커버리지를 보장하지만, 반대의 경우는 성립하지 않는다.
4.4 경험 기반 테스트 기법 Experience-based Test Techniques
경험 기반 테스트 기법을 적용할 경우 테스트 케이스는 테스터의 기술 역량과 직관 그리고 유사한
애플리케이션과 기술에 대한 경험을 기반으로 도출한다. 이 기법은 체계적인 다른 기법으로는 쉽게 찾아내기
어려운 테스트를 식별하는 데 도움이 된다. 테스터의 접근 방식과 경험에 따라 이 기법으로 달성하는
커버리지와 효과성은 매우 다양하게 나타날 수 있다. 이 기법을 사용할 경우 커버리지를 평가하기 어려울 수
있으며 측정이 불가능할 수도 있다.
이번 절에서는 일반적으로 많이 적용되는 경험 기반 기법을 설명하고 있다.
4.4.1 오류 추정 (Error Guessing)
오류 추정은 다음을 포함한 테스터의 지식을 기반으로 오류, 결함 및 장애 발생을 예측하는 데 적용하는
기술이며 다음을 포함한다:
● 애플리케이션의 과거 동작
● 발생하기 쉬운 오류의 유형
● 다른 애플리케이션에서 발생한 장애
오류 추정 기법에 대한 체계적인 접근법은 발생 가능한 오류, 결함, 장애 목록을 작성하고 이런 장애와 그것의
원인이 되는 결함을 노출하는 테스트를 설계하는 것이다. 이러한 오류, 결함, 장애 목록은 경험, 결함 및 장애
데이터 또는 소프트웨어가 실패한 이유에 대한 일반적인 지식을 기반으로 작성할 수 있다.
4.4.2 탐색적 테스팅 (Exploratory Testing)
탐색적 테스팅에서는 비공식(사전에 정의되지 않은) 테스트를 테스트 실행 중에 동적으로 설계, 실행, 기록하고
평가한다. 테스트 결과는 컴포넌트나 시스템에 대해 더 많이 학습하고, 더 많은 테스트가 필요한 영역에 대한
테스트를 작성하는 데 활용된다.
탐색적 테스팅은 때로 세션 기반 테스팅을 사용하여 활동을 구성한다. 세션 기반 테스팅에서는 탐색적 테스팅을
정해진 시한(time-box)동안 수행하며, 테스터는 테스트 목적이 포함된 테스트 차터(test charter)를 활용해
테스팅 방향을 설정한다. 테스터는 테스트 세션 시트에 수행 단계와 발견 사항을 기록한다.
탐색적 테스팅은 명세가 충분하지 않거나 적은 경우 또는 테스팅에 상당한 시간적 압박이 있을 때 가장
유용하다. 또한, 탐색적 테스팅은 다른 보다 공식적인 테스팅 기법을 보완하는 데도 유용하다.
탐색적 테스팅은 반응적 테스트 전략(5.2.2 절 참조)과 밀접하게 관련되어 있다. 탐색적 테스팅은 다른 블랙박스,
화이트박스, 경험 기반 기법과 통합하여 사용할 수도 있다.
4.4.3 체크리스트 기반 테스팅 (Checklist-based Testing)
체크리스트 기반 테스팅에서는 체크리스트에 기록된 테스트 컨디션을 커버하기 위해 테스터가 테스트를 설계,
구현, 실행한다. 테스터는 분석의 일환으로 새로운 체크리스트를 작성하거나 기존 체크리스트를 확장할 수
있지만, 기존 체크리스트를 수정하지 않고 그대로 사용하는 경우도 있다. 체크리스트는 경험, 사용자에게
무엇이 중요한지에 대한 지식 또는 소프트웨어가 실패하는 이유와 방법에 대한 이해를 기반으로 작성할 수
있다.
체크리스트는 기능 및 비기능 테스팅을 포함한 다양한 테스트 유형을 지원하기 위해 작성할 수 있다. 구체적인
테스트 케이스가 없는 경우, 체크리스트 기반 테스팅은 대략적인 지침과 일관성을 제공할 수 있다. 이런
체크리스트는 상위 수준으로 작성되기 때문에 실제 테스팅에서 어느 정도의 가변성이 있기 마련이며, 따라서
커버리지는 늘어날 수 있지만 재현 가능성은 줄어들 수 있다.
자격증/ISTQB FL2020. 3. 26. 08:00
