테스트 계획/결과서 확인

1. 개요

테스트 계획 및 결과서 확인은 정보시스템 개발 사업에서 시스템 테스트가 체계적으로 계획되고, 그 결과가 적절히 기록·평가되었는지를 감리자가 검토하는 활동이다. 테스트는 개발된 시스템이 요구사항을 충족하는지를 검증하는 마지막 관문으로서, 충분하고 효과적인 테스트가 수행되지 않으면 결함이 남아있는 시스템이 인도될 위험이 있다. 감리자는 테스트 계획의 적절성과 테스트 결과의 신뢰성을 평가하여 시스템 인도 전 품질을 확인해야 한다.

테스트 활동은 다양하게 구분된다. 단위 테스트는 개별 프로그램 모듈 단위로 수행되며, 개발자가 수행한다. 통합 테스트는 여러 모듈을 조합하여它们간의 인터페이스가 올바르게 작동하는지를 검증한다. 시스템 테스트는 시스템 전체를 하나의 블랙박스로 간주하여 기능과 성능을 검증한다. 인수 테스트는 사용자가 실제 업무 시나리오 기반으로 시스템이 요구사항을 충족하는지를 확인한다. 감리자는 이러한 각 테스트 단계가 적절히 수행되었는지를 검토해야 한다.

테스트 계획서에는 테스트 목적, 범위, 방법, 일정, 환경, 통과 기준, 실패 기준 등이 명시되어야 한다. 테스트 결과서에는 실제로 수행된 테스트 케이스, 그 결과(성공/실패), 발견된 결함의 내용과 처리 결과 등이 기록되어야 한다. 감리자는 이 두 문서를 대조하여 테스트가 계획대로 수행되었는지를 확인해야 한다.

2. ASCII 다이어그램

테스트 단계별 구분

[테스트 단계별 구분]

┌─────────────────────────────────────────────────────────────────────┐
│                      테스트 단계 (V-모델 대응)                        │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   ┌─────────────┐              ┌─────────────┐                      │
│   │ 요구사항 정의 │───────────▶│  인수 테스트 │                      │
│   └─────────────┘              └─────────────┘                      │
│          │                           │                              │
│          ▼                           ▼                              │
│   ┌─────────────┐              ┌─────────────┐                      │
│   │   설계      │───────────▶│ 시스템 테스트 │                      │
│   └─────────────┘              └─────────────┘                      │
│          │                           │                              │
│          ▼                           ▼                              │
│   ┌─────────────┐              ┌─────────────┐                      │
│   │   구현     │───────────▶│ 통합 테스트  │                      │
│   └─────────────┘              └─────────────┘                      │
│          │                           │                              │
│          └────────────┬───────────────┘                              │
│                         ▼                                            │
│                  ┌─────────────┐                                     │
│                  │  단위 테스트 │                                     │
│                  └─────────────┘                                     │
│                                                                     │
│   [각 테스트 단계에서 확인해야 할 사항]                                │
│   단위 테스트: 모듈 내logic 오류, 경계 조건 오류                     │
│   통합 테스트: 모듈 간 接口 오류, 데이터 흐름 오류                     │
│   시스템 테스트: 기능 완전성, 성능, 보안, 사용자 환경                  │
│   인수 테스트: 업무 시나리오 충족, 사용자기본 만족                    │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

테스트 결과 검토 포인트

[테스트 결과 주요 검토 포인트]

┌─────────────────────────────────────────────────────────────────────┐
│                    테스트 결과 검토 포인트                            │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   ┌───────────────────────────────────────────────────────────┐    │
│   │  1. 테스트 계획 대실행 일치성                              │    │
│   │     ○ 계획된 테스트 케이스 수 vs. 실제 실행 수              │    │
│   │     ○ 계획된 일정 vs. 실제 일정                           │    │
│   │     ○ 계획된 환경 vs. 실제 환경                           │    │
│   ├───────────────────────────────────────────────────────────┤    │
│   │  2. 테스트 결과 신뢰성                                     │    │
│   │     ○ 각 테스트 케이스의 실행 결과 기록                     │    │
│   │     ○ 실패 테스트 케이스의 결함 분석 및 조치 결과           │    │
│   │     ○ 통과율 및 목표 대비 달성 여부                       │    │
│   ├───────────────────────────────────────────────────────────┤    │
│   │  3. 결함 관리 적절성                                       │    │
│   │     ○ 발견된 결함의 severity/priority 분류                │    │
│   │     ○ 결함의 재현 가능성 및 수정 여부                     │    │
│   │     ○ 미수정 결함의 사업 영향도 분석                      │    │
│   ├───────────────────────────────────────────────────────────┤    │
│   │  4. 테스트 커버리지                                        │    │
│   │     ○ 요구사항 대비 테스트 커버율                          │    │
│   │     ○ 코드 커버율 (가능한 경우)                           │    │
│   └───────────────────────────────────────────────────────────┘    │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

3. 해석

3.1 테스트 계획 적절성 검토

테스트 계획은 테스트 활동의 근간이 되는 문서로, 감리자는 테스트 계획의 적절성을 사전에 검토해야 한다.

테스트 범위 정의: 테스트 대상 시스템의 범위, 포함되는 기능과 제외되는 기능이 명확히 정의되어야 한다. 테스트 범위가 모호하면 핵심 기능에 대한 테스트가 누락될 수 있다.

테스트 방법 정의: 적용할 테스트 방법론(예: 블랙박스 테스트, 화이트박스 테스트)과 기법(예: 경계값 분석, 등가 분할, 결정 테이블)이 명시되어야 한다.

통과/실패 기준: 테스트의 성공 기준과 실패 기준이 명확히 정의되어야 한다. 예를 들어, "테스트 케이스 100% 통과" 또는 "Critical/Major 결함 0건" 등이 통과 기준이 될 수 있다.

자원 및 일정: 필요한 테스트 환경, 장비, 인력, 그리고 일정이 계획되어야 한다. 테스트 일정만으로는 불가능한 일정 계획은 품질 저하로 이어진다.

3.2 테스트 결과 신뢰성 검증

테스트 결과의 신뢰성을確保하기 위해以下の 사항을 확인해야 한다.

테스트 실행 기록: 각 테스트 케이스가 실제로 실행되었는지, 실행 결과(통과/실패)가 기록되어 있는지를 확인한다. 계획만 있고 실행 기록이 없는 테스트는 제대로 수행되지 않은 것일 수 있다.

실패 원인 분석: 실패한 테스트 케이스에 대해 결함의 원인이 분석되어야 한다. 단순히 테스트 케이스의 오류인지, 실제 시스템의 결함인지를 구분해야 한다.

재테스트 확인: 결함 수정 후 해당 테스트 케이스가再度実行되어 통과되었는지를 확인해야 한다. 수정된 부분으로 인해 다른 기능에 regression이 발생하지 않았는지도検証해야 한다.

3.3 결함 관리 적절성 검토

발견된 결함의 관리 과정이 적절했는지를 평가해야 한다.

결함 분류 적절성: 발견된 결함이 적절한 기준(severity, priority)에 따라 분류되어야 한다. 일반적으로 Critical(시스템 동작 불가), Major(주요 기능 장애), Minor(경미한 문제) 등으로 분류한다.

수정 조치 적절성: 결함에 대한 수정 조치가 적절히 이루어졌는지를 확인한다. 특히 Critical이나 Major 결함은 반드시 수정되어야 하며, 해당 결함이 발견된 테스트 케이스가修正 후 통과되었는지를 확인해야 한다.

잔존 결함 평가: 모든 결함이 수정되지 않고 인도되는 경우도 있다. 이때 잔존 결함의 목록과 그 결함이 시스템 운영에 미치는 영향을 분석하여, 인수 전 결함의容許 범위에 포함되는지를 판단해야 한다.

3.4 테스트 커버리지 분석

테스트 커버리지는 테스트가 요구사항이나 코드를얼마나 포괄적으로 검증하였는지를 나타내는 지표이다.

요구사항 커버리지: 테스트 케이스가 요구사항 정의서의 각 요구사항을얼마나 커버하고 있는지를 분석한다. 요구사항 대비 테스트 케이스의 추적 매트릭스를 통해 누락된 요구사항이 없는지를 확인해야 한다.

코드 커버리지: 가능하다면 코드 수준의 커버리지를 分析한다. 구문 커버리지(Statement Coverage), 결정 커버리지(Branch Coverage) 등이 활용되며, 이를 통해 테스트되지 않은 코드 영역을 식별할 수 있다.

오류 처리 커버리지: 다양한 오류 상황에 대한 테스트가 이루어졌는지도 중요하다. 예를 들어, 네트워크 단절, 데이터베이스 연결 실패, 입력값 오류 등에 대한 처리가 적절한지를 테스트해야 한다.

3.5 인수 테스트 특별 고려사항

인수 테스트는 사용자가 수행하는 테스트로, 시스템이 실제 업무 시나리오에서 사용될 수 있는지를 확인하는 단계이다.

업무 시나리오 기반 테스트: 인수 테스트는 실제 업무 처리 흐름을 시뮬레이션하는 시나리오 기반으로 수행되어야 한다. 단위 기능 테스트가 아닌 종단 간(E2E) 업무 처리가 제대로 이루어지는지를 확인해야 한다.

사용자 참여 및 확인: 가능하다면 실제 최종 사용자가 인수 테스트에 참여하여 system's 사용 적합성을 확인해야 한다. 개발자나 테스터만으로는 놓치기 쉬운 사용 편의성 문제를 발견할 수 있다.

인수 테스트 통과 기준: 인수 테스트의 통과 기준에는 일반적으로 모든 Critical/Major 결함의 해결, 주요 업무 시나리오의 100% 성공, 사용자로부터의 서면 승인이 포함된다.

4. 핵심 용어 정리

5. analogies 📢

테스트 계획 및 결과서 확인은 자동차 工廠出厂検査와 같다. 자동차 공장에서 차량이 완성되면，出庫 전 다양한檢查를 수행한다. 엔진 출력,刹车性能, 조향操作性, 안전 장치 작동, 도장 품질 등을逐一 점검하고, 그 결과를検査記録에 기록한다. 만약検査에서 결함이 발견되면修理 후再検査를実施한다.すべての檢查 항목이 기준을 충족해야 出庫를 허가한다. Likewise, 정보시스템도 개발 완료 후 인수 테스트를 통해 모든 要求사항이 충족되는지를 확인하고, 결함이 발견되면修改 후再테스트를実施해야 한다.検査記録은 나중에問題가 발생했을 때 해당 결함이 인도 시 있었는지, 사후에 발생했는지를 판단하는依據가 된다. 감리자는 出庫検査의 적절性与否를検証하는 제3자的角色을 수행하며, 이를 통해 최종 사용자에게 인도되는 시스템의品質을担保한다.