책 요약 – 테스팅 공수 산정 예 by NAIK

grapevine9700 2022. 11. 7. 07:00

출처: SOFTWARE TESTING AND QUALITY ASSURANCE Theory and Practice, KSHIRASAGAR NAIK, PRIYADARSHI TRIPATHY, 2008년, 12장 System Test Planning and Automation, 377~386페이지

테스팅 작업 공수(work effort)를 추정하는 방법에 대해 기술한다. 11장에서 예로 나왔던 FR-ATM PVC 서비스 인터워킹 시스템을 사례로 설명한다.

12.8 테스트 공수 추정(TEST EFFORT ESTIMATION)

시스템 테스트 그룹은 테스트 실행 일정을 생성하기 위해 테스트 공수를 추정할 필요가 있다. 테스트 공수는 “수행해야 하는 작업의 양”으로 정의되며, 구체적으로는 아래 두 가지가 주요 구성 요소이다.

하루에 한 사람이 생성하는 테스트케이스 수
하루에 한 사람이 실행하는 테스트케이스 수

위 구성 요소가 테스트 생산성으로 언급되기도 한다. 불행히도 테스트 생산성 수치를 계산하는 수학 공식은 없으며, 실제 테스트 프로세스를 미시적으로 관찰하여 현실 프로젝트에서 테스트 생성 및 실행 시간을 측정함으로써 테스트 공수 데이터를 수집한다. 많은 테스트 프로젝트에 대한 생산성 데이터를 수집하면 평균 테스트 생산성 측정값을 추정할 수 있게 된다.

계획 단계에서 테스트 비용과 테스트 완료 시간을 추정하는 것이 당연하고, 이 비용(cost)과 시간(time)의 두 패러미터를 함께 테스트 공수(test effort)라고 한다. 대부분의 경우 시스템 테스트 공수의 추정은 전체 소프트웨어 프로젝트 공수의 추정과 결합되어 이루어진다. 그러나 테스트 공수 추정치를 전체 프로젝트의 추정치와 분리하여 초기부터 시스템 테스트를 계획하고 진입 기준(entry criteria)이 충족되는 즉시 수행에 들어갈 수 있도록 충분한 시간을 할당하는 것이 좋다. 테스트 공수를 추정하는 데 있어서 세 가지 핵심 요소가 다음과 같다.

소프트웨어 프로젝트를 위해 설계할 테스트케이스의 수
상세한 테스트케이스를 만드는 데 필요한 공수
테스트케이스를 실행하고 실행 결과 분석하는 데 필요한 공수

테스트 공수에 영향을 미치는 기타 다른 요소는 아래와 같다.

테스트 환경을 구축하는 데 필요한 공수
프로젝트 세부 사항에 대해 테스트 엔지니어를 교육하는 데 필요한 공수
시스템 테스트를 위한 테스트 엔지니어 가용성(특정 분야 전문가를 필요한 시점에 투입할 수 있는지 여부)

이제 테스트 공수의 핵심 요소를 추정하는 방법에 대해 논의해 보자. 테스트 계획 담당자는 유사한 프로젝트를 테스트한 과거 경험과 현재 프로젝트에 대한 면밀한 지식에 의존하여 이 세 가지 핵심 항목의 정확한 추정치를 제공해야 한다.

12.8.1 테스트케이스의 수(Number of Test Cases)

공수 추정에 앞서 흔히 사용하는 "테스트케이스(test case)"라는 용어에 대한 이해가 필요하다. 테스트케이스의 ‘입도(granularity)’는 필요한 테스트케이스 수의 추정에 상당한 영향을 미친다. 예를 들어, 어떤 사람은 테스트케이스라는 용어를 하나의 원자적 테스트 스텝(즉, 테스터와 테스트 대상 시스템 간의 단일 입력-출력 인터액션)을 의미하는 데 사용하고, 또 다른 사람은 동일한 용어를 수백 개 테스트 스텝을 포함하는 것을 의미하는 데 사용할 수 있다. 테스트케이스에 대한 우리의 정의는 하나의 테스트케이스를 구축하는 데 필요한 테스트 스텝의 수와 무관하다. 테스트케이스의 입도는 테스트 목표 또는 목적과 밀접하게 연결되어 있다. 간단한 테스트케이스는 일반적으로 7~10개의 테스트 스텝을 포함하고, 복잡한 테스트케이스는 10~50개에 달하는 테스트 스텝을 거뜬히 포함한다. 다음은 테스트케이스의 수를 추정하는 여러 방법에 대해 논의한다.

테스트 그룹 카테고리를 기반으로 한 추정

이 방법은 테스트스위트(test suite) 구조와 테스트 목표(test objectives)가 생성된 후 단순히 테스트 목표의 수를 세어 테스트케이스 수를 간단히 추정한다. 그러나 이 추정치는 시스템 테스트 실행 주기가 끝날 때까지 설계된 테스트케이스의 총 수 보다 과소평가된 값이다. 처음 추정대로 설계된 테스트케이스로 시스템 테스트를 진행하는 동안 테스트 엔지니어는 시스템의 예상치 못한 실패를 마주치고 추가적인 동작 관찰이 필요해지기 때문이다. 즉, 시스템 테스트 단계가 끝날 때까지 사용된 테스트케이스의 수가 초기 추정치보다 많아진다. 각 그룹별 테스트케이스 수에 대한 더 정확한 추정치는 해당 그룹의 식별된 총 테스트 목표 수에 10~15%의 "퍼지 팩터(fudge factor)"를 추가하여 얻을 수 있다. 테스트케이스의 수를 과소평가하면 초기에 시스템 테스트에 대한 리소스 할당이 줄어들지만, 막상 필요해지면 더 많은 리소스를 요구하므로 제어할 수 없는 프로젝트 지연을 초래한다. 반면에 테스트케이스의 수를 과대평가하면 비효율적인 리소스 활용으로 이어진다.

테스트 카테고리 기반 공수 추정 사례

표 12.6은 11장에서 논의한 FR-ATM PVC 서비스 인터워킹의 테스트 카테고리(관련 포스팅 보려면 여기 클릭)를 기반으로 테스트 공수를 추정한 예이다.

표 12.6 FR-ATM PVC 서비스 인터워킹의 테스트 공수 추정

두 번째 열은 시스템에 대해 식별된 테스트 목표의 수를 기반으로 테스트케이스 수를 추정한 것이다. FrAtm 컴포넌트의 구성가능 속성(configurable attributes)에 대해 각 속성을 테스트하는 데 1개의 테스트케이스가 필요하다. 40개의 구성가능 속성이 있다고 가정했을 때 구성 기능을 테스트하려면 40개 테스트케이스가 필요할 것이다. 마찬가지로 FrAtm 컴포넌트 구현에서 30개의 모니터링 속성을 사용할 수 있다고 가정하면 모니터링 기능을 테스트하기 위해 30개의 테스트케이스를 생성해야 한다. 이러한 구성 및 모니터링 속성 정보는 FrAtm 컴포넌트의 기능 명세서에서 찾을 수 있어야 한다. 트래픽 관리 테스트케이스는 FR에서 ATM으로 매핑되는 QoS 패러미터 수(여기서는 3개)를 기반으로 추정한다. 인터페이스 테스트의 수는 FrAtm 컴포넌트가 지원하는 RF 및 ATM 카드의 수(즉, 9개)를 기반으로 추정한다. 각 인터페이스 카드에 대해 하나의 테스트케이스가 생성되어야 하므로 인터페이스 테스트 그룹에서 9개의 예상 테스트케이스 수가 나온다. 견고성 그룹에 대해서는 44개의 테스트케이스를 추정하였다. 이 중 4개는 FrAtm 테스트 서브그룹을 위한 테스트케이스이고, 나머지 40개는 경계값 테스트를 위한 것이다(각 구성가능 속성에 대해 1개의 경계값 테스트케이스를 설계하므로 40개 추정). 성능 테스트케이스는 다음 가정을 기반으로 추정하였다.

3가지 타입의 ATM 카드로 FrAtm에 대한 지연(delay) 측정. 이를 위해 3개의 테스트케이스를 설계해야 한다.
6가지 타입의 FR 카드를 가진 FrAtm의 지연 측정. 이를 위해 6개 테스트케이스를 설계해야 한다.
한 번에 하나의 FR 카드를 사용하여 처리량(throughput) 측정. FR 카드는 6가지 타입이 있으므로 6개의 테스트케이스가 필요하다.
한 번에 하나의 ATM 카드를 사용하여 처리량 측정. 3가지 타입의 ATM 카드가 있으므로 3개의 테스트케이스가 필요하다.

만약 우리 목표가 카드 조합(combination)을 고려하는 경우라면 성능 테스팅의 위 테스트케이스 추정치가 달라질 수 있다. 마지막으로 회귀 테스트는 단순화를 위해 기존 FR 및 ATM 테스트스위트에서 각각 60개와 90개 테스트케이스를 선택한다고 가정한다.

기능점수를 기반으로 한 추정(Estimation Based on Function Points)

1979년 A. J. Albrecht는 소프트웨어 시스템이 수행하는 "기능"의 수로 소프트웨어 시스템을 측정하는 것이 유용하다는 것을 보여주고 이러한 기능의 수를 "세는" 방법을 제공했다. 이러한 기능 집계를 기능점수(function points)라고 한다. 기능점수의 핵심 아이디어는 사용자 입력 수, 사용자 출력 수, 사용자 온라인 쿼리 수, 논리 파일 수, 외부 인터페이스 수 등의 형태로 시스템의 기능적 관점이 주어지면, 시스템을 구현하는 데 필요한 코드 라인 수와 시스템을 테스트하는 데 필요한 테스트케이스 수로 프로젝트 크기를 추정할 수 있다는 것이다.

<시스템의 기능점수를 계산하는 방법에 대한 설명은 기존 소프트웨어 공학 책이나 많은 사이트에서 쉽게 찾을 수 있으므로 생략>

기능점수 메트릭을 사용하여 테스트케이스 수를 추정하는 방법이 아래와 같다.

간접 방법: 기능점수에서 코드 크기를 추정하고, 코드 크기에서 테스트케이스의 수를 추정한다.
직접 방법: 기능점수에서 직접 테스트케이스의 수를 추정한다.

간접 방법(Indirect Method)

소프트웨어 시스템의 기능점수가 시스템 요구사항의 세부 사항을 조사하여 계산되며, 이러한 계산이 이루어질 시점에 시스템을 구현할 프로그래밍 언어가 미확정 상태일 수 있다. 어떤 프로그래밍 언어로 시스템을 구현할지에 따라 LOC(Line of Code) 측정값도 달라지므로 프로그래밍 언어의 선택이 LOC 메트릭에 직접적인 영향을 미친다. Capers Jones는 기능점수와 소프트웨어 시스템 코드 크기 사이의 관계를 제시했다. 구체적으로 표 12.9와 같이 여러 프로그래밍 언어에 대한 기능점수 당 LOC 수를 제시했다.

표 12.9 경험에 기반한 기능점수와 LOC 간의 관계

시스템의 기능점수가 주어지면 해당 시스템을 구현할 프로그래밍 언어를 가정하여 LOC 수를 예측할 수 있다. 이제 시스템 테스팅을 위해 설계할 테스트케이스 수를 추정하기 위해서 우리의 경험을 활용할 필요가 있다. 이 추정 방법이 조직마다 다르며 심지어 동일한 조직에서도 소프트웨어 시스템의 범주에 따라 다르다. 예를 들어, Hitachi Software는 30년의 경험적 연구를 통해 10~15LOC 당 1개의 테스트케이스라는 표준을 제시하였다. 기능점수가 100이고 C로 구현된 시스템은 100 × 128 = 12,800LOC의 코드 크기를 가지며, 이 소프트웨어 시스템의 시스템 레벨 테스팅을 위해 850~1,280개의 테스트케이스가 설계된다. 이러한 테스트케이스에는 단위 테스트 및 통합 테스트에 필요한 테스트케이스가 포함되지 않음을 유의해야 한다. 시스템 테스팅 그룹의 테스트 엔지니어가 편향되거나 프로그래머의 테스트케이스를 재사용해서는 안되기 때문이다. 대신 시스템 테스팅 팀은 테스트케이스를 맨처음부터 설계해야 한다.

직접 방법(Direct Method)

Capers Jones는 기능점수와 생성된 테스트케이스 총 수 사이의 직접적인 관계를 아래처럼 제시했다.

총 테스트케이스 수 = (기능점수)^1.2

위에서 추정된 테스트케이스의 수는 단위 테스팅, 통합 테스팅, 시스템 테스팅과 같이 소프트웨어 시스템에서 수행되는 모든 형태의 테스트를 포함한다. 즉, 전체 테스트 공수에서 시스템 테스트 크기를 따로 구별하지 않는다.

이제 Hitachi Software와 Caper Jones의 테스트 추정 방법을 비교해 보자. Hitachi Software에서는 LOC로 코드 크기를 고려하여 테스트케이스 수를 추정하고 Caper Jones는 기능점수를 통해 테스트케이스 수를 추정한다. 앞의 예에서 100개의 기능점수에 대해 타겟 언어가 C라고 가정하면 생성될 C코드의 예상 크기가 12,800LOC이였다. Hitachi Software 방법에서 12,800LOC 시스템을 테스트하기 위해 850~1,280개 테스트케이스를 생성하는 반면, Caper Jones 방법은 100^1.2 = 251개의 테스트케이스를 추정한다. 이 두 방법으로 추정한 테스트케이스 수가 4~5배의 차이가 나는 데, 이 차이는 다음과 같이 해석된다. 일본 소프트웨어 산업(예: Hitachi Software)에서는 테스트케이스가 아닌 테스트 포인트(test point)라는 용어를 사용하며, 테스트 포인트는 테스트 스텝(test step)과 유사하다. 하나의 테스트케이스는 일반적으로 1~10개의 테스트 스텝을 포함한다. Hitachi Software 방법을 사용하여 추정한 테스트케이스의 수는 테스트 스텝(또는 테스트 포인트)의 수를 나타낸다. 하나의 테스트케이스가 평균적으로 5 단계의 테스트 스텝을 포함한다고 가정하면 Hitachi Software 방법으로 추정된 테스트케이스의 수는 170에서 256 사이이다. 이 범위는 Caper Jones 방법으로 추정한 수인 251과 가깝다.

12.8.2 테스트케이스 생성 공수(Test Case Creation Effort)

테스트스위트 구조와 테스트 목표가 식별된 후 테스트케이스를 생성하기 위한 시간을 할당하는 것이 필수적이다. 표 12.10은 수동 테스트케이스 생성의 평균 생산성을 제시한다.

표 12.10 수동 테스트케이스 생성 공수에 대한 가이드라인

테스트케이스 생성과 관련된 액티비티는 11장에서 자세히 논의되었으며 아래와 같이 요약된다.

시스템 요구사항 및 기능 명세 문서 읽고 이해하기
테스트케이스 생성하기
테스트 스텝, 합격-불합격 기준 같은 테스트케이스의 모든 필수 필드 입력하기
테스트케이스 검토 및 업데이트하기

테스트 엔지니어의 기술과 효율성은 테스트케이스 생성 공수 추정에 영향을 미치는 중요한 요소이다. 표 12.10에 제공된 가이드라인은 테스트 엔지니어가 테스트케이스 개발에 능숙하다는 가정에서 나온 것이다(테스터가 관련 분야에서 테스트케이스를 개발하는 데 4~6년의 사전 경험이 있다고 가정). Caper Jones는 1인 당 월 30~300개의 테스트케이스를 생성한다고 추정했다. 달리 말하면 하루에 한 사람이 1.5~15개의 테스트케이스를 생성할 수 있다고 보았다. 표 12.6의 세 번째 열에 제시된 FR-ATM 서비스 인터워킹의 테스트케이스 생성 공수 추정치는 표 12.10에 제시된 가이드라인을 기반으로 예측한 것이다.

12.8.3 테스트케이스 실행 공수(Test Case Execution Effort)

테스트케이스를 실행하는 데 필요한 시간은 테스트케이스의 복잡성과 실행자가 특정 시스템 주제에 얼마나 전문성을 가지고 있는지에 따라 달라진다. 예를 들어, 통신 분야의 테스트케이스는 가장 복잡성이 높고 스위치, 라우터 및 다양한 프로토콜의 구성에 대한 이해가 필수적이라 여겨진다. 어느 분야가 되었든 수동 테스트 실행을 위한 작업 공수를 추정하려면 다음 요소를 고려해야 한다.

테스트케이스를 생성한 사람이 테스트 실행자가 아닌 경우 테스트케이스 대한 이해
테스트 베드 구성
테스트 스텝 실행 및 평가
테스트케이스의 실행 상태(pass-fail) 판단
테스트 팩토리 데이터베이스(테스트케이스 저장소)에 테스트 결과 로깅
성능, 스트레스, 부하 테스트케이스가 실행 중인 경우 데이터 수집 및 분석
11장에서 논의된 대로 테스트 팩토리의 테스트케이스 업데이트
실패가 발생한 경우 아래 태스크 수행:
- 실패를 재현하려고 시도하고,
- 관찰된 실패와 관련된 여러 다른 시나리오를 실행하고,
- 구성, 로그, 하드웨어 구성에 대한 세부 정보를 수집하고,
- 결함 추적 시스템에 결함 보고서를 제출한다.
소프트웨어 개발자가 실패를 재현할 수 없는 경우 그들과 함께 문제를 디버깅하고 위치를 찾는 후속 작업

테스트 실행률은 테스트케이스의 통과율(pass rate)에 선형 비례한다. 즉, 테스트케이스 실패율이 높으면 테스트케이스 실행률이 느려진다. 개발자가 문제를 복제하고 시행착오를 통해 문제의 근본 원인을 식별할 수 있도록 테스트 엔지니어가 도와야 하고, 결과적으로 테스트케이스 실행에 쏟을 시간을 많이 뺏기기 때문이다.

표 12.11과 12.12는 우리의 경험을 바탕으로 신규 테스트와 회귀 테스트에 대한 테스트케이스 실행률을 추정한 것이다. 새로 생성된 테스트케이스의 실행 시간과 회귀 테스트의 실행 시간이 차이가 나는 것은 회귀 테스트케이스는 이전에 실행한 경험이 있고 그 테스트 스텝과 합격-불합격 기준(pass-fail criteria)이 더 일찍 검증되었기 때문이다. 그러나 테스트 엔지니어가 이전에 특정 회귀 테스트 그룹을 실행하지 않은 경우라면 할당된 회귀 테스트를 실행하기 위해 테스트를 이해하고 테스트 베드를 설정하는 데 더 많은 시간을 소비해야 할 수도 있다. 결과적으로 회귀 테스트의 실행 시간이 새로 생성된 테스트케이스의 실행 시간과 거의 동일하게 된다(이런 이유로 회귀 테스트를 위한 테스트 자동화를 반드시 고려해야 함).

표 12.6의 네 번째 열은 FR-ATM 서비스 인터워킹의 각 테스트 카테고리에 대한 테스트케이스 실행 공수를 표 12.11과 12.12에 제공된 가이드라인을 기반으로 추정한 것이다. 만약 자동화된 회귀 테스트를 사용할 수 있다면 총 실행 시간이 단축될 수 있다.

표 12.11 수동 테스트케이스 실행 공수에 대한 가이드라인

표 12.12 회귀 테스트케이스를 수동으로 실행하기 위한 공수 추정 가이드라인

저작자표시 비영리 변경금지 (새창열림)