SMALL
테스트 프로세스 필요성
성공적인 테스트를 위해서
효과적인 테스트접근 방법 뿐 아닌
체계적인 테스트 수행을 위한 계획 수립과
관리가 필요하다.
또한, 수행한 테스트를 평가하고
테스트 활동의 효과 및 효율성을
개선하는 노력도 필요하다.
소프트웨어 테스트는 테스트 설계 기법,
테스트 수행 시기, 테스트 유형 등에 따라서
다양하게 수행된다.
즉, 테스트 설계 기법에 따라
정적 테스트, 동적 테스트를 수행하며,
테스트 수행 시기에 따라 컴포넌트 테스트,
통합 테스트, 시스템 테스트,
인수 테스트를 수행한다.
또한, 피처에 따라 성능 테스트,
신뢰성 테스트, 안전성 테스트 등
다양한 테스트 유형이 존재한다.
소프트웨어 테스터
규모가 크고 복잡한 소프트웨어를 테스트하기 위해
소프트웨어 테 스트 기술을 효과적으로 적용해야 한다.
더보기
ex)
테스트 케이스를 생성하기 위하여
명세 기반 테스트를 사용할지
구조 기반 테스트를 사용할지 결정해야 하며,
컴포넌트 테스트를 어떤 기준에 따라서
종료하고 통합 테스트를 시작할지 결정해야 한다.
또한, 전체 소프트웨어 개발 프로젝트에서
테스트가 자치하는 비중이 상당하므로
테스트의 효과성과 효율성을 위한
테스트 관리의 중요성이 더욱 부각되고 있다.
시스템의 규모와 유형에 따라서 차이가 있지만,
전체 소프트웨어 개발 비용 중에서
대략 30%~50% 정도를 테스트가
차지하는 것이 현실이다.
그러므로
주어진 시간과 비용이라는 제약하에
기대하는 테스트의 효과를 달성하려면
테스트를 체계적인 방식으로 수행할 필요가 있다.
그뿐만 아니라,
수행된 테스트 활동 자체에 대한 평가를 바탕으로
테스트 활동을 개선할 필요도 있다.
즉, 테스트에 소요된 비용과 테스트를 통하여
성취한 소프트웨어의 품질 개선 정도를 측정하여
수행된 테스트 활동이 얼마나 효과적이고
효율적인지 평가해야 한다.
그리고
평가를 통해 발견한 미비점을 바탕으로
기존 테스트 활동을 개선하여
테스트의 효과 와 효율을 높여야 한다.
테스트 프로세스 개요
테스트를 효과적으로 그리고 효율적으로 수행하고
지속적으로 테스트 역량을 개선하기 위해서는
명확하게 정의된 프로세스를 바탕으로
테스트를 수행해야 한다.
ISO/IEC/IEEE 29119에서는
테스트 프로세스를 조직 테스트 프로세스,
테스트 관리 프로세스, 동적 테스트 프로세스로 분류한다.
조직 테스트 프로세스
특정한 테스트 프로젝트가 아닌
조직 전체에 공통적으로 적용되는
조직 테스트 명세서를 개발하고
관리하는 것을 목적으로 한다.
조직 테스트 명세서
조직 테스트 정책 명세서와
조직 테스트 전략 명세서로 구분된다.
조직 테스트 명세서(조직 테스트 정책 명세서와
조직 테스트 전략 명세서)를 개발하고
이 명세서가 테스트 관리 프로세스 및
동적 테스트 프로세스에서
올바르게 적용되는지 모니터링하고 제어한다.
그리고
테스트 관리 프로세스 및 동적 테스트 프로세스의
수행 성과를 바탕으로 조직 테스트 명세서를 갱신한다.
테스트 관리 프로세스
조직 테스트 프로세스를 기반으로
테스트 프로젝트의 수행을 관리하기 위한 프로세스이다.
즉, 테스트 수행 계획을 수립하고,
계획에 따른 테스트 수행을 모니터링하고 제어하며,
테스트 종료 활동을 수행한다.
테스트 계획 활동
테스트 계획서를 작성하며,
테스트 모니터링 및 제어 활동에서는
테스트 현황 보고서를 작성하고
테스트 종료 활동에서는
테스트 종료 보고서를 작성 한다.
동적 테스트 프로세스
테스트 계획서에 따라서
동적 테스트를 수행하기 위한 활동으로 구성된다.
즉, 테스트에 대한 설계 및 구현 활동을 수행하고,
테스트 환경을 구축하여 테스트를 실행하고
검출된 결함을 등록하고 관리한다.
테스트 설계 및 구현 활동에서는
테스트 설계 명세서, 테스트 케이스 명세서,
테스트 절차 명세서, 테스트 환경 요건 명세서
그리고
테스트 데이터 요건 명세서를 작성한다.
그리고 테스트 환경 구축 및 관리 활동에서는
테스트 환경 준비 보고서와
테스트 데이터 준비 보고서를 작성한다.
테스트 실행 활동과 결함 보고 활동
각각 테스트 실행 로그 및 결함 보고서와
결함 추적 보고서를 작성한다.
조직 테스트 프로세스
특정 테스트 프로젝트 수준이 아니라
조직 전체에서 수행될 모든 테스트 프로젝트의
공통적인 사항을 정의하는 데 초점을 둔다.
즉, 조직 테스트 프로세스의 결과물을 바탕으로
실제 수행되는 개별 테스트에 대한 관리가 수행된다.
조직 테스트 프로세스
조직 테스트 명세(즉, 조직 테스트 정책 명세와
조직 테스트 전략 명서) 개발 활동,
조직 테스트 명세의 활용에 대한
모니터링 및 제어 활동 그리고 조직 테스트
명세 갱신 활동으로 구성된다.
개발된 조직 테스트 명세서
테스트 관리 프로세스에 적용된다.
즉, 조직 테스트 정책 명세서 및
조직 테스트 전략 명세서는
테스트 관리 프로세스의
테스트 계획 활동에서 활용된다.
더보기
ex)
조직 테스트 정책 명세서의 항목인 테스트 목적은
테스트 계획을 수립할 때 테스트 컨텍스트, 위험 목록,
테스트 전략 등에서 고려된다.
마찬가지로
조직 테스트 전략 명세서의 항목인
테스트 설계 기법, 테스트 환경 등은
테스트 계획을 수립할 때 활용된다.
조직 테스트 명세서는 실제 수행된
테스트 프로젝트의 수행 성과를 바탕으로 갱신된다.
즉, 테스트 프로젝트 수행을 통해서
기존 정책 및 전략의 부족한 점이 발견되면 이에 대한
보완을 위해 조직 테스트 정책 명세서 및
조직 테스트 전략 명세서를 갱신한다.
조직 테스트 프로세스 활동
조직 테스트 프로세스는 조직 테스트 명세서를 개발, 적용
그리고 유지하기 위한 3가지 활 동으로 구성된다.
아래 표는 조직 테스트 프로세스를 구성하는 활동을 보여 준다.
| 항목 | 설명 |
| 조직 테스트 명세 개발 |
조직의 테스트 목표를 바탕으로 조직 테스트 정책 명세서 및 조직 테스트 전략 명세 서를 개발한다. |
| 조직 테스트 명세 활용 모니터링 및 제어 |
조직 테스트 명세서가 조직 내에서 효과적으로 활용되는지를 모니터링 하고 필요 하면 테스트 관리 활동을 제어한다. |
| 조직 테스트 명세 갱신 |
조직 테스트 명세서의 활용에 대한 피드백을 바탕으로 조직 테스트 명세서를 개선한다. |
(조직 테스트 프로세스 활동)
조직 테스트 명세 개발
조직 테스트 명세서는
조직 테스트 정책 명세서와
조직 테스트 전략 명세서로 분류된다.
조직 테스트 정책 명세서는
최상위 수준의 명세로서
조직 차원의 테스트 목적과 원칙을 정의하며
테스트를 수행하는 구체적인 방법은
언급하지 않는다.
조직 테스트 정책에서 다루는 항목
테스트 목적, 테스트 프로세스,
테스트 조직 및 역할, 테스트 표준,
테스트 자산 관리 그리고 테스트 프로세스 개선이 있다.
조직 테스트 전략 명세
조직에서 수행할 테스트 프로젝트에 대한
기본적인 지침을 정의한다.
즉, 테스트 정책 명세서에 제시된
테스트 목적, 테스트 프로세스,
테스트 조직 및 역할, 테스트 표준 등을 바탕으로
테스트를 수행하기 위한 구체적인 방법을 정의한다.
규모가 작은 조직이거나
유사한 방식으로 테스트를 수행하는 조직은
하나의 조직 테스트 전략 명세서로 충분할 수 있다.
하지만, 다양한 개발 방법론 또는
생명 주기를 사용하는 조직은
각 방법론 또는 생명 주기에 적합한
고유의 조직 테스트 전략 명세서를
정의해야 할 필요성이 있다.
더보기
ex)
V-모델 방식으로 수행하는 프로젝트와
애자일 방식으로 수행하는 프로젝트에
적합한 별도의 조직 테스트 전략 명세서를
정의할 수 있고,
자동차, 의료, 무기체계 같은
안전 필수 소프트웨어 개발 프로젝트의 경우
별도의 조직 테스트 전략 명세서를 정의할 수도 있다.
조직 테스트 전략
프로젝트 수준의 전략과
개별 테스트 수준의 전략으로 구성된다.
프로젝트 수준의 전략
컴포넌트 테스트, 통합 테스트,
시스템 테스트 등의 특정 테스트 레벨과
성능 테스트, 신뢰성 테스트 등의
특정한 유형 테스트에 국한되지 않는
여러 개별 테스트에 공통적으로 적용될 수 있는
항목을 정의한다.
더보기
ex)
위험 관리, 테스트 선택 및 우선순위,
테스트 문서화, 형상 관리,
결함 관리, 자동화 도구 등은
프로젝트 수준의 테스트 전략에 해당된다.
반면,
개별 테스트 수준의 전략은
프로젝트 테스트를 구성하는
각각의 구체적인 테스트에 적용하는
전략을 의미한다.
개별 테스트는 레벨 테스트와
유형 테스트로 분류될 수 있다.
레벨 테스트
컴포넌트 테스트, 통합 테스트,
시스템 테스트, 인수 테스트 등과 같이
소프트웨어 개발 단계와 대응하여
수행되는 테스트를 의미한다.
유형 테스트
성능 테스트, 신뢰성 테스트,
보안 테스트 등과 같이
품질 속성별로 수행되는 테스트를
의미한다.
테스트 시작 및 종료 조건
컴포넌트 테스트, 통합 테스트,
시스템 테스트 등의 레벨 테스트 및
성능 테스트, 신뢰성 테스트 등의
유형 테스트에 대하여 각 테스트를
시작할 수 있는 조건과
종료할 수 있는 조건을 정의할 수 있다.
개별 테스트 수준의 전략
테스트 시작 및 종료 조건을 포함하여
테스트 독립성, 테스 트 문서화,
테스트 설계 기법, 테스트 환경 및 테스트 데이터,
재테스팅 및 리그레션 테스팅, 테스트 메트릭,
그리고 테스트 완료 기준이 있다.
조직 테스트 명세 활용 모니터링 및 제어
개발된 조직 테스트 명세서는
실제 수행되는 테스트 프로세스에서 활용하며,
해당 테스트 프로세스 수행의
기본 지침으로써 사용된다.
더보기
ex)
조직 테스트 정책 명세서에서 정의된
테스트 조직 및 역할, 테스트 자산 관리 등은
테스트 관리 프로세스의 테스트 계획 활동의
지침으로 사용된다.
그리고
조직 테스트 전략은
테스트 관리 프로세스의 테스트 계획 뿐 아닌
테스트 설계 및 구현, 테스트 환경 구축 및 관리,
테스트 실행. 결함 보고 등
동적 테스트 프로세스에서도 지침으로 사용된다.
따라서
테스트 관리 프로세스 및
동적 테스트 프로세스는
조직 테스트 명세서의 내용을 바탕으로
수행되어야 한다.
그리고 테스트 관리 및 동적 테스트 프로세스의
수행이 조직 테스트 명세서와
일치된 방식으로 진행되고 있는지
모니터링할 필요가 있으며
조직 테스트 명세와 일치하도록
필요하다면 테스트 관리 프로세스 및
동적 테스트 프로세스를 적절히 수정/보완한다.
조직 테스트 명세 갱신
조직 테스트 명세서는 조직에서 수행하는
전체 테스트에 대한 공통적인 지침이므로
모든 테스트의 효과 및 효율성에 영향을 미친다.
그러므로
효과적이고 효율적인 테스트를 수행 할 수 있도록
조직 테스트 명세서를 지속적으로 갱신해야 한다.
우선, 실제 조직 테스트 명세서를 지침으로 하여
수행된 개별 테스트 프로젝트의 성과를 바탕으로
조직 테스트 명세서를 갱신할 수 있다.
더보기
ex)
위험 관리 방법을 개선하거나
새로운 테스트 레벨을 추가하는 등
프로젝트 수준의 조직 테스트 전략을
갱신할 수 있다.
또한, 변화하는 테스트 기술을
조직 테스트 명세서에 반영하여
최신 방식으로 테스트가
수행되도록 할 필요도 있다.
예로, 신규로 도입되는 테스트 자동화 도구나
형상 관리 도구를 조직 테스트 전략에 반영하는 등이
이에 해당한다.
조직 테스트 정책
조직 테스트 정책은 조직 차원의
테스트 목적과 원칙을 정의한다.
조직 테스트 정책은 최상위 수준에서
테스트 명세를 정의하는 것이며
테스트를 수행하는 구체적인 방법은
조직 테스트 전략에서 정의된다.
조직 테스트 정책에서는
테스트를 수행하는 목적,
테스트 수행을 위한 표준 프로세스,
테스 트를 수행할 조직과 역할,
적용하는 테스트 표준,
테스트 자산 관리
그리고
테스트 프로세스 개선 방법을 정의한다.
아래 표는 조직 테스트 정책 명세서에
기술되는 항목을 보여 준다.
조직 테스트 정책 항목
| 항목 | 설명 |
| 테스트 목적 | 조직에서의 테스트에 대한 목적, 목표 그리고 테스트의 범위를 기술한다. |
| 테스트 프로세스 | 조직에서 테스트를 수행할 때 준수할 테스트 프로세스를 명시한다. |
| 테스트 조직 및 역할 | 테스트 활동을 수행하는 테스트 조직의 구조와 역할을 정의한다. |
| 테스트 표준 | 테스트를 수행하면서 참고하고 준수해야 할 표준을 정의한다. |
| 테스트 자산 관리 | 테스트의 결과물을 축적하고 이후 재사용하는 방법을 정의한다. |
| 테스트 프로세스 개선 | 테스트 프로세스를 평가하고 개선하는 방법을 정의한다. |
테스트 목적
조직 수준의 텍스트에 대한 정책으로 조직 내에서
테스트를 수행하는 목적과 범위를 기술한다.
그장에서 설명한 것처럼 테스트는
1) 결합 검출을 통한 제품 품질 개선,
2) 품질 영가 이 창한 의사 결정 지원,
3) 개발 프로세스 개선 지원을 목적으로 할 수 있으며,
현재 조치 에서 어떤 목적에 초점을 두고 있는지 기술한다.
어떤 테스트 목적에 비중을 두느나에 따라서
테스트 프로세스, 조직 및 역할, 테스트 표준,
테스트 자산 관리, 테스트 프로세스 개선 등의
다른 조직 테스트 정책 항목이 달라질 수 있다.
그리고
이러한 조직 테스트 정책을 바탕으로
조직 테스트 전략도 영향을 받게 된다.
그리고 조직 내에서 테스트에 기대하는 역할을 기술한다.
조직 내에는 설정된 테스트 목적 을 달성하는 데
함께 사용될 수 있는 다양한 활동이 있다.
더보기
ex)
정형적 방법, 시뮬레이션 등은
결함 검출을 통한 품질 개선이라는 목적을 달성하기 위해
테스트와 함께 사용될 수 있는 방법이다.
품질 개선이라는 목표을 달성하기 위해 정형적 방법,
시뮬레이션, 테스트를 함께 수행하는 조직 내에서
테스트에 바라는 역할과 기대를 설정하도록 한다.
테스트 프로세스
조직에서 테스트를 수행할 때
준수할 테스트 프로세스를 명시한다.
조직 차원의 표준적인 테스트 프로세스를 정의함으로써
모든 테스트 프로젝트가 일관성 있고
효과적인 방식으로 수행될 수 있도록 한다.
대표적으로 테스트 관리 프로세스,
동적 테스트 프로세스,
정적 테스트 프로세스가 명시될 수 있다.
테스트 관리 프로세스
테스트 활동에 대한 관리 프로세스를 명시한다.
즉 테스트 계획을 수립하고,
계획에 따라 동적 테스트 및
정적 테스트가 수행되는지 모니터링하며
테스트 활동이 종료되면 테스트 결과를 기록하고
테스트 자산이 추후 재사용될 수 있도록
관리 하는 프로세스를 정의한다.
동적 테스트 프로세스
동적 테스트를 수행하기 위한 프로세스를 명시한다.
즉, 동적 테 스트를 수행하기 위한 테스트 설계 및 구현,
테스트 환경 구축, 테스트 실행 및 결함 보고 등의 활동을
수행하는 프로세스를 정의한다.
정적 테스트 프로세스
정적 테스트를 수행하기 위한 프로세스를 명시한다.
즉, 정적 테 스트의 유형을 명시하고
정적 테스트를 수행하는 역할과 그 절차를 정의한다.
각 프로세스는 프로세스를 구성하는 활동과
활동의 하위 작업을 구체적으로 정의해야 한다.
그리고 각 활동 및 작업을 수행할 역할, 활동 및
작업의 결과물에 대한 양식과 작성 방 법도 정의될 필요가 있다.
각 테스트 프로세스에 대한 명세는 별도의 문서로 기술하고
여기서는 해당 문서를 참조한다.
테스트 조직 및 역할
테스트 활동을 수행하는 테스트 조직의 구조와 역할을 정의한다.
즉, 조직 차원의 테스트 정책과 전략을 수립하고 관리하는 역할과
이러한 테스트 정책과 전략을 준수하여 테스트에 대한 계획을 수립하고
모니터링하는 역할, 그리고 계획된 방식대로
동적 테스트 프로세스를 수행하는 역할을 정의한다.
테스트 조직의 구조를 다이어그램으로 표현하면
효과적으로 나타낼 수 있다.
테스트 조직
테스트 전략가와 여러 팀으로 구성된다.
각 테스트팀은 컴포넌트 테스트, 통합 테스트,
시스템 테스트, 인수 테스트 등의 레벨 테스트를 담당하거나
성능 테스트, 신 뢰성 테스트 등의 유형 테스트를 담당할 수 있다.
또는, 레벨 테스트와 유형 테스트의 조합도 담당할 수 있다.
텍스트림에는 팀에 부여된 테스트를
관할하고 책임지는 테스트 관리자가 있다.
그리고
테스트 관리자 하위에는 테스트 리더가 있고,
테스트 리더는 테스트 분석가, 테스트 설계자,
테스트 확정 전문가, 그리고 테스트 수행자를 관리한다.
아래 표는 각 역할별로 담당하는
테스트 작업을 요약하여 보여 준다.
| 역할 | 담당 작업 |
| 테스트 전략가 | 조직 수준의 테스트 정책과 전략을 수립하고 관리한다. |
| 테스트 관리자 | 테스트 관리 프로세스의 수행을 관리한다. 즉, 테스트 계획 수립, 모니터링 및 제어 그리고 테스트 종료 활동의 수행을 관리한다. |
| 테스트 리더 | 테스트 계획을 수립하고 테스트 모니터링 및 제어 활동을 수행한다. |
| 테스트 분석가 | 테스트 컨텍스트를 바탕으로 테스트 전략을 수립한다. |
| 테스트 설계자 | 테스트 전략에 따라서 테스트 케이스 및 테스트 절차를 개발한다. |
| 테스트 환경 전문가 | 테스트 환경 요건을 충족하는 테스트 환경을 구축하고 관리한다. |
| 테스트 수행자 | 개발된 테스트 절차에 따라 테스트를 수행하고 테스트 결과를 기록하며 결함 보고 서를 작성한다. |
(테스트 조직 구성원 역할)
성공적으로 테스트 활동을 수행하기 위해서는
각 역할을 맡은 담당자가
해당 역할을 올바르게 수행할 수 있는
역량을 가지고 있어야 한다.
따라서
각 역할별로 해당 역할에 필요한 역량 확보를
보증할 수 있는 객관적인 기준을 정의할 필요가 있다.
그리고 각 역할을 수행 할 담당자가
해당 역량을 확보하는 데
필요한 교육/훈련도 정의한다.
테스트 표준
테스트를 수행하면서
참고하고 준수해야 할 표준을 정의한다.
ISO, IEEE 등의 기관에서는
테스트 프로세스, 테스트 프로세스 평가,
소프트웨어 품질 모델 및 품질 평가,
형상 관리, 결함 관리, 위험 관리 등에 대한
표준을 정의하고 있다.
또한 자동차, 항공기, 열차 등의 도메인별로
테스트 관련 표준이 존재하므로 테스트 대상이
이러한 도메인에 해당된다면
도메인별 표준도 준수할 필요가 있다.
아래 표는 테스트 관련 기본적인 표준으로서
테스트 관리, 동적 테스트, 정적 테스트,
그리고 테스트 프로세스 평가에 대한 표준을 보여 준다.
| 구분 | 관련 표준 |
| 테스트 관리 |
• ISO/IEC/IEEE 29119 Part 2 Test Processes • ISO/IEC/IEEE 29119 Part 3 Test Documentation |
| 동적 테스트 |
• ISO/IEC/IEEE 29119 Part 2 Test Processes • ISO/IEC/IEEE 29119 Part 3 Test Documentation • ISO/TEC/IEEE 29119 Part 4 Test Techniques |
| 정적 테스트 |
• IEEE Std. 1028-2008 Standard for Software Reviews and Audits • ISO/IEC 20246 Work Product Reviews |
| 테스트 프로세스 평가 |
• ISO/IEC 33063:2015 Information Technology - Process Assessment - Process Assessment Model for Software Testing |
(테스트 관련 기본적인 표준)
아래 표는 자동차, 항공기, 철도 등
도메인별로 요구되는 대표적인
테스트 관련 표준을 보여 준다.
| 도메인 | 관련 표준 |
| 자동차 | • ISO 26262-6:2018 Road vehicles - Functional Safety - Part 6: Producti Development at the Software Level |
| 항공기 | • DO-178C Software Considerations in Airborne Systems and quipment Certification |
| 철도 | • IEC 62279: 2015 Railway applications - Communication, Signalling and Processing Systems - Software for Railway Control and Protection Systems |
(도메인별 테스트 관련 표준)
아래 표는 품질 모델, 품질 측정, 중질 보증,
V&V, 위원 관리, 결합 관리, 행상 관리
등에 대한 관련 표준도 참고하도록 한다.
| 구분 | 관련 표준 |
| 품질 모델 | • ISO/IEC 25010:2011 Systems and Software Engineering - Systems and Software Quality Requirements and Evaluation (SQuaRE) - System and Software Quality Models |
| 품질 측정 | • ISO/IEC 25023:2016 Systems and Software Engineering - Systems and Software Quality Requirements and Evaluation (SQuaRE) - Measurement of System and Software Product Quality |
| 품질 보증 | • IEEE Std. 730-2014 IEEE Standard for Software Quality Assurance Processes • IEEE Std. 1012-2012 IEEE Standard for System and Software Verification and Validation |
| 위험 관리 | • ISO/IEC 16085:2006 Systems and Software Engineering - Life Cycle Processes - Risk Management |
| 형상 관리 | • ISO 10007:2017 Quality Management - Guidelines for Configuration Management |
| 결함 관리 | • IEEE Std. 1044-2009 Standard Classification for Software Anomalies • ISO/IEC 20000-1:2011 Information Technology - Service Management - Part1: Service Management System Requirements |
(그 외 관련 표준)
품질 모델 및 측정: ISO/IEC 25010은
소프트웨어 품질에 대한 표준 모델을 정의한다.
그리고
ISO/IEC 25025는 25010의 품질 특성을
정량적으로 측정하기 위한 척도를 정의한다.
품질 보증
IEEE 730과 IEEE 1012는
각각 품질 보증 프로세스와
V&V에 대한 표준을 정의한다.
위험 관리
ISO/IEC 16085는
위험 관리를 수행하는 절차를 정의한다.
형상 관리
IS0 10007은 형상 식별,
형상 제어, 형상 상태 보고,
형상 감사 등의 형상 관리 활동을
수행하는 절차를 정의한다.
결합 관리
IEEE 1044는 소프트웨어 결함을 기술하는
다양한 항목과 결함을 분류하는 방법을 정의한다.
ISO/IBC 20000-1은
"8.2 Problem management" 절에서 문제(Proolem)를
식별하고 기록하며 해결하고 종결하는 절차를 다룬다.
ISO/LEC 12207은 "6 3.8 gualty assurance process" 절에서
식별된 문제를 기록하고 해결하여 종결하는 절차를 다룬다.
테스트 자산 관리(Asset)
테스트 프로젝트를 수행하면서 산출된 결과물 중에서
이후의 테스트를 위하여 재사용될 수 있는 결과물을 말한다.
더보기
ex)
테스트 계획서, 테스트 설계 명세서,
테스트 케이스 명세서, 테스트 절차 명세서 등의
테스트 산출물은 재사용될 수 있다.
뿐만 아닌 테스트를 수행하기 위하여
구축된 테스트 환경과 준비된 테스트 데이터도
테스트 자산에 해당된다.
이러한 테스트 자산을
체계적으로 저장하고 관리하여
이후의 테스트 프로젝트를 효율적으로
수행할 수 있도록 지원해야 한다.
그러므로
테스트 프로젝트가 종료되면
추후 재사용이 가능한 테스트 자산을
정리하여 저장하고
이를 테스트 종료 보고서에 기록한다.
특히,
리그레션 테스팅을 수행할 때
테스트 자산의 재사용은
중요한 역할을 한다.
리그레션 테스팅의 목적
소프트웨어가 수정된 후에 변경이
올바르게 되었는지를 확인하는 것이다.
이때 기존 테스트에서 적용되었던
테스트 환경은 그대로 사용될 수 있다.
뿐만 아닌 기존의 테스트 케이스,
테스트 절차 중에서
수정 후의 소프트웨어에도
그대로 적용 가능한 것들이 있다.
그러므로
테스트를 수행할 때 마련한 테스트 환경,
테스트 케이스, 테스트 절차 등은
리그레션 테스팅을 수행할 때
재사용될 수 있도록 자산으로 관리하는 것이
바람직하다.
테스트 프로세스 개선
테스트 활동을 수행한 이후에는
수행된 테스트 프로세스를 평가하고
지속적으로 개선하기 위해 노력해야 한다.
조직 테스트 정책에서는 테스트 프로세스를
평가하는 방법과 테스트 프로세스를
개선하는 방법을 정의한다.
테스트 프로세스는
소프트웨어에 존재하는 결함을
효과적, 효율적으로 검출하는 것을
목적으로 한다.
그러므로
더 많은 수의 결함을 적은 비용으로
검출할수록 테스트 프로세스가 우수하다고 볼 수 있다.
테스트 프로세스는 다음과 같은
2가지 방법으로 평가될 수 있다.
테스트 케이스 기반 평가
개발된 테스트 케이스가 결합을 검출하면
테스트 프로세스는 우수하다고 판단할 수 있다.
결과 기반 평가
테스트를 통해서 많은 수의 결함을 검출하면
테스트 프로세스는 우수해 다고 판단할 수 있다.
테스트 활동에 대한 평가를 바탕으로
테스트 프로세스를 구성하는
각 테스트 활동을 개선 할 수 있다.
즉, 테스트 계획 활동을 개선하여
테스트 대상과 테스트 범위를
더욱 정확하고 세밀하게 설정할 수 있으며,
테스트 설계 및 구현 활동을 개선하여
더욱 효과적이면서 엄격한 방식으로
테스트 케이스와 테스트 절차를 개발할 수도 있다.
테스트 프로세스 개선은
테스트 종료 보고서에 기재되는
"교훈"을 바탕으로 수행될 수도 있다.
즉, 각 테스트 종료 보고서는
해당 테스트를 수행하면서
인지한 테스트 프로세스의 약점과
이에 대한 개선 방법을 "교훈"으로 기술한다.
그러므로 테스트 종료 보고서의 "교훈" 부분은
테스트 프로세스를 개선하는 방향으로 활용될 수 있다.
그리고
ISO/IEC 33063:2015는
소프트웨어 테스트 프로세스 평가 모델을 정의한다.
이 표준은 3개의 테스트 프로세스(조직 테스트 프로세스,
테스트 관리 프로세스, 동적 테스트 프로세스)를 정의하며,
여기에 더하여 정적 테스트 프로세스를 대상으로
테스트 프로세스의 역량을 레벨 0(미완료 수준)부터
레벨 5(혁신 수준)까지 평가하는 모델도 담고 있다.
그러므로
이러한 테스트 프로세스 평가 모델을 활용하여
현재 조직의 테스트 역량을 평가하고
개선 방향을 설정할 수도 있다.
프로젝트 수준의 조직 테스트 전략
다양한 개별 테스트에
공통적으로 적용될 수 있는
전략을 의미한다.
더보기
ex)
개별 테스트를 수행할 때 적용할 위험 관리 방안,
테스트 선택과 우선순위 방안, 테스트 문서화 등은
여러 개별 테스트에 공통적인 전략이다.
| 항목 | 설명 |
| 위험 관리 | 테스트를 진행하면서 수행할 위험 관리 방법을 명시한다. |
| 테스트 선택 및 우선순위 | 우선순위를 부여하고 이를 바탕으로 테스트를 선택하는 방법을 명시한다. |
| 테스트 문서화 | 테스트를 수행하면서 작성할 산출물을 명시한다. |
| 형상 관리 | 테스트 산출물에 대한 형상 관리 방법을 명시한다. |
| 결함 관리 | 검출된 결함을 종결시킬 때까지의 관리 방법을 명시한다. |
| 자동화 도구 | 테스트 활동을 자동화하기 위한 도구들을 명시한다. |
| 수행 개별 테스트 | 레벨 테스트 및 유형 테스트 등 수행할 개별 테스트를 명시한다. |
(프로젝트 수준의 조직 테스트 전략 항목)
위험 관리
시간과 비용이 한정된 상황에서
최대의 성과를 달성하기 위해서는
효율적인 방식으로 테스트를 수행해야 한다.
더보기
ex)
컴포넌트 레벨의 테스트를 수행할 때
전체 컴포넌트를 대상으로 하는 대신에
결함이 존재할 가능성과 해당 결함이 발생 시
미칠 수 있는 영향의 크기를 고려하여
일부 컴포넌트를 대상으로
테스트를 수행하는 편이 바람직하다.
마찬가지로 테스트 대상의 모든 요구사항이 아니라
문제가 있을 가능성이 큰 일부 기능을 대상으로
테스트를 수행하는 것이 바람직할 수도 있다.
이와 같이 한정된 자원이 가용한 상황에서
테스트의 효과를 높이기 위하여
위험 분석을 바탕으로 테스트의 대상과 피처를 선별하고
테스트 설계 기법의 수준 등을 결정할 필요가 있으며,
이러한 테스트 방법을 위험 기반 테스트라고 한다.
위험 기반 테스트를 수행하려면
각 테스트 대상 또는 피처를 중심으로
위험 분석이 선행되어야 한다.
ISO/IEC 16085:2006에는
위험 관리 프로세스가 정의되어 있다.
위험 관리 프 로세스를 구성하는 대표적인 활동으로는
위험 분석, 위험 조치 수행, 위험 모니터링이 있다.
위험 분석(Risk analysis)
위험 요소 식별(Identification), 위험도 산정(Estimation),
그리고 위험 평가(Bral uation)를 통해서 수행된다.
프로젝트 수준의 조직 테스트 전략에서는
위험 기반 테스트를 수행할 때 적용되는
위험 분석 방법을 정의한다.
식별된 위험에 대하여 위험 평가를 바탕으로
적절한 조치 방안을 수립한다.
더보기
ex)
위험도가 낮은 위험은 수용할 수도 있고,
높은 수준의 위험 요소는 위험을 회피하거나,
완화하거나 외부에 전가할 수 있다.
또한, 각 위험에 대한 비상 계획(Contingency plan)이
필요할 수도 있다.
위험 분석은 프로젝트 초기에만 수행되는 것이 아니라,
프로젝트 전 과정에 걸쳐서 지속적으로 수행되어야 한다.
초기에 분석된 위험뿐만 아니라
프로젝트가 진행되면서 새로운 유형이 발견될 수도 있다.
그리고 계획된 위험 조치가 실제로 수행되는지,
위험 조치에 따라서 위험도에 변화가 발생하는지 등을
지속적으로 모니터링할 필요가 있다.
테스트 프로젝트를 수행할 때는
테스트 프로세스에 위험 관리 활동이
포함되도록 해야 한다.
테스트 계획 활동
위험 요소 분석과 위럽 요소의
유형 및 내용에 따라서 적절한 조치 계획을 수립한다.
특히, 제품 유형의 위험에 대해서는
위험 분석 결과를 바당으로 테스트 대상의 선정,
테스트 범위의 결정, 그리고 테스트 설계 기법,
테스트 완료 기준 등 테스트 전략을 수립하여
테스트 계획서에 반영한다.
테스트 모니터링 및 제어 활동
계획된 위험 조치 작업에 대한 모니터링과
기존 위협의 상태 변화 및 신규 위험 발견 등을 살피는
위험 모니터링도 함께 수행하여 위험 목록을 갱신하고
이를 테스트 현황 보고서에 포함한다.
테스트 종료 활동
테스트 활동을 요약할 때 테스트가 종료될 때까지
해소되지 않 은 위험에 대하여 해소되지 않은 이유와
소프트웨어 품질 등에 미치는 영향을 파악하여
테스트 종료 보고서에 포함한다.
위험 분석
먼저 위험 요소를 식별하고
각 위험 요소에 대하여
발생 가능성과 영향도를 바탕으로
위험도를 산정한다.
그리고 각 위험 요소의 위험 수준과
위험 조치 계획을 수립한다.
위험 요소 식별
일반적으로 위험 요소 식별은 시스템 또는
조직의 목적 달성에 영향을 줄 수 있는
이벤트 및 상황을 식별하는 것이 목표이다.
위협 요소는 체크리스트 또는
과거 데이터 검토와 같은 기존사례를 바탕으로
식별될 수 있다.
또한,
전문가팀이 설문지, 브레인스토 명,
델파이, 시나리오 분석 등의 체계적인 방법으로
식별할 수도 있다.
그리고
PHA(Prelininary Hazard Analysis),
HAZOP(Hazard and Operability Studies) 등과 같은
귀납적 주로 방법을 이용할 수도 있다.
위험도 산정
식별된 각 위험 요소에 대한 위험도를 산정한다.
각 위험 요소의 위험도는 발생 가능성 (Likelibood)과
영향도(Impact)를 통해서 산정된다.
각 위험 요소별 발생 가능성은
정량적인 수치로 또는 정성적으로 산정될 수 있다.
그 방법으로는
1) 과거 사례 분석,
2) 폴트 트리 분석, 이벤트 트리 분석 등의 예측 방법,
3) 체계적 인 전문가 의견 등이 있다.
영향도는 해당 위험 요소가 발생하였을 때
미치는 영향의 크기를 산정하는데,
발생 후의 결과에 대한 간단한 설명 또는
상세한 정량적인 분석을 통해서 산정될 수 있다.
영향도를 분석할 때는 위험 요소가 발생하였을 때의
즉각적인 영향뿐만 아니라
일정 시간이 흐른 후의 영향도까지 고려해야 하며,
위험이 직접적으로 발생 가능한 시스템 요소뿐만 아니라
인접한 다른 요소에서 발생할 수 있는
위험도도 고려하도록 한다.
위험 평가
위험 평가는 앞서 수행된
위험도 분석 결과를 바탕으로
개별 위험의 수준을 결정하고
이에 따른 조치 작업의 수행 여부를 결정한다.
위험 수준은 앞서 분석된 위험도 산정치와
조치 작업의 수행 여부 기준치(Threshold)를
비교하여 결정된다.
가장 단순한 방법은 하나의 기준치를 이용하여
각 위험 요소에 대한 조치 작업의 가부를 결정하는 것이다.
이 방법은 간단하게
조치 작업의 수행 필요성 여부를 평가 할 수는 있지만
위험도 산정치와 조치 작업 가부 결정에 내재되었을지 모르는
불확실성을 반영하지 못하는 문제가 있다.
일반적인 다른 방법으로는 비용과 효과를 고려하여
3가지 등급으로 각 위험 요소를 평가하기도 한다.
1) 비용이 얼마가 들던지 반드시 조치가 필요한 위험 요소는 상위 등급으로 분류되고,
2) 비용과 효과를 고려하여 조치 여부를 결정하는 위험은 중간 등급으로 분류된다.
3) 위험도가 낮아서 조치 작업을 수행하지 않아도 되는 위험 요소는 하위 등급으로 분류된다.
위험 조치 수행
무시할 수 없는 위험 요소 중 조치 작임이 필요하다고 평가된
각 위험 요소에 대해서는 적절한 조치 작업이 계획되고 수행되어야 한다.
위험 조지 작업
위험 회피(soange), 위험 완화(Mitigation),
위험 전가(Transfer), 위험 수용(Acceptance)으로 분류된다.
위험 요소의 발생 가능성을 낮추거나
영향도를 축소하는 방법으로
위험을 완화하는 조치를 수립할 수 도 있다.
뿐만 아닌 시스템의 범위를 조정하거나,
설계 및 구현을 통하여
아예 위험 요소를 제거할 수도 있다.
위험도가 낮거나 위험 회피 • 위험 완화를 하기에는
너무 많은 비용이 소요되는 경우
위험을 수용할 수도 있다.
또한. 위험에 대한 조치와 책임을
타 조직에 전가시킬 수도 있다.
또한, 조치 작업이 필요하다고 평가된
각 위험에 대해서는 비상 계획(Contingency plan)도
수립하도록 한다.
비상 계획은 위험 회피, 위험 완화,
위험 전가 조치가 불가능하거나 실패 하여
위험 요소가 발생하였을 경우에
취할 조치를 의미한다.
위험 모니터링
모든 위험 요소는 추적할 필요가 없을 때까지
지속적으로 모니터링되어야 한다.
프로젝트가 진행되면
각 위험 요소의 상태는 변경될 수 있다.
더보기
ex)
위험의 발생 가능성이 변하 거나,
위험 발생에 따른 영향도가 변할 수도 있다.
또한, 초기에 식별되지 않은 위험 요소가
새롭게 발견될 수도 있다.
뿐만 아니라 계획된 위험 조치 계획이 수행되고 있는지
그리고 위험 조치 계획의 결과로
위험 상태가 변경되었는지도
지속적으로 모니터링할 필요가 있다.
그러므로
위험 모니터 링에서는 프로젝트가 진행될 때
지속적으로 위험의 상태를 검토하고 갱신하며
새로운 위 험 요소를 식별하고 분석하도록 한다.
테스트 선택 및 우선순위
테스트 대상의 피처를 확인하기 위해
일반적으로 많은 수의 테스트 케이스 및
테스트 절차가 개발되고 실행된다.
테스트를 효과적, 효율적으로 수행하기 위해서
수많은 테스트 케이스 및
테스트 절차의 중요도를 바탕으로
우선순위를 부여하고
우선순위에 따라 테스트 케이스 및
테스트 절차를 선택할 필요가 있다.
테스트에 대한 우선순위 전략
피처 집합의 우선순위
피처 집합은 유사한 피처이면서
동일한 방법으로 테스트 될 수 있는
피처의 그룹을 의미한다.
피처 집합
테스트 설계 및 실행의 단위이다.
그러므로
피처 집합별로 우선순위를 부여하고,
이를 바탕으로 피처 집합별 테스트 케이스 및
테스트 절차를 개발하고,
실제 테스트 실행을 수행하는
순서를 결정할 수 있다.
테스트 케이스의 우선순위
피처 집합을 구성하는 각 피처에 대하여
많은 테스트 케이스가 개발된다.
따라서
각 테스트 케이스를 통해서 확인되는
구체적인 기능 등의 중요도를 고려하여
각 테스트 케이스에 우선순위를
부여할 필요가 있다.
테스트 절차의 우선순위
각 테스트 절차는 중요도에 따라서
우선순위가 부여되어 있다.
테스트 실행 활동을 수행할 때는
이 우선순위를 이용하여
먼저 수행할 테스트를 결정할 수 있다.
테스트 문서화
프로젝트 수준에서
수행하는 테스트 활동에서 작성해야 하는
테스트 문서를 식별한다.
각 테스트 문서별로 작성되는 시점과
승인 절차도 정의하도록 한다.
프로젝트 수준의 테스트 문서
프로젝트 테스트에 대한 계획서와
프로젝트 테스트에 대한
종료 보고서가 해당된다.
즉, 프로젝트 테스트 계획서는
컴포넌트 테스트, 성능 테스트, 인수 테스트 등의
개별 테스트에 대한 공통적인 계획을 포함하며,
각 개별 테스트의 수행 결과를 바탕으로
프로젝트 수준의 테스트 종료 보고서가 작성된다.
텍스트 프로젝트를 구성하는 개별 테스트의 문서화
개별 테스트의 수행 부분에서 결정 된다.
그리고 개별 테스트 수준에서 작성하는
테스트 문서는 개별 테스트 수준의
테스트 문서화 전략에서 정의한다.
형상 관리
테스트 프로세스를 수행하면
다양한 산출물이 작성된다.
이러한 테스트 산출물은
테스트 를 수행하는 테스트팀을 포함하여
여러 이해관계자가 공유해야 한다.
그러므로
소프트웨어 개발 산출물에 대하여
형상 관리를 수행하듯이
각종 테스트 산출물의
적합성과 무결성을 유지하기 위하여
형상 관리가 수행되어야 하며,
형상 관리 작업에 대한 계획을 수립하고
이를 형상 관리 계획서에 기록한다.
형상 관리 활동은 형상 식별,
형상 통제, 형상 상태 보고,
형상 감사로 구성된다.
형상 식별에서는 산출물 중에서 형상 관리의 대상
즉 변경 통제의 대상이 되는 산출물을 정의하고,
각 형상에 대한 식별자 규칙을 정의한다.
그리고 각 형상에 대한 베이스라인 기준을 정의한다.
형상 관리 대상으로 식별된 형상 항목 즉 산출물
베이스라인으로 간주된 이후부터는
형상 통제를 받게 된다.
즉, 베이스라인으로 설정된 산출물의 변경은
변경 요청을 바탕으로
변경 승인 여부를 검토한다.
승인된 변경 요청에 대해서만
산출물에 대한 변경을 수행할 수 있다.
형상 상태 보고
형상 항목에 대한 형상 관리 상태를
기록하고 보고하는 계획을 수립한다.
즉, 형상 관리 활동 및 각 형상 항목의
베이스라인에 대한 변경 이력과
각 변경 요청에 대한 처리 상태를
기록/보고하는 계획을 수립한다.
형상 감사
형상관리 계획에 따라서
형상 관리가 진행되어
형상 항목의 무결성이 유지되고 있는지를
확인하기 위한 계획을 기술한다.
결함 관리
테스터는 테스트 절차를 실행하여
결함을 검출하는데,
테스트 대상의 실행 결과가
테스트 케이스 및
테스트 절차에 정의된 예상 결과와 상이하면
이를 근거로 결함이 존재한다고 판단한다.
결함은 시스템의 장애를 유발하고
결국, 시스템의 품질을
악화시키는 근본 원인이므로
식별된 결함은 디버깅을 수행하여
제거해야 한다.
테스트 조직 내에서 일관성이 있고
효율적인 방식으로 결함을 검출하고
해결하기 위해 다음 항목에 대한
전략을 정의할 필요가 있다.
결함 기록
식별된 결함에 대한 명확한 정보는
효율적인 디버깅을 위해서 필수적이다.
따라서
식별된 결함에 대하여
어떤 정보를 어느 수준으로 기술하고
이해관계자와 어떻게 공유할지에 대한
방법이 정의되어야 한다.
일반적으로 식별된 결함에 대해서는
결함이 검출된 상황, 발생한 문제, 심각도,
우선순위, 위험 분석 등을 결함 보고서에 기록한다.
결함 추적
결함은 시스템의 장애를 유발하므로
식별된 결함에 대한 적절한 조치가 필요하다.
즉, 각 결함은 개발자를 통해서 수정되고,
올바르게 수정이 되었는지 확인이 필요하다.
이와 같이 결함의 검출부터 수정, 확인
그리고 결함을 종결하는
전체 과정을 관리해야 한다.
더보기
ex)
상황에 따라 새로운 결함의 상태를 추가하거나
어떤 기준으로 결함의 상태가
변경되는지 등도 정의가 필요하다.
자동화 도구
테스트 관리 프로세스 및 동적 테스트 프로세스 등을
효과적, 효율적으로 수행하기 위해서는
테스트 활동 수행을 지원하는
자동화 도구를 도입해야 한다.
테스트 프로젝트를 수행할 때
테스터가 사용할 수 있는
다양한 테스트 자동화 도구를
검토하여 결정한다.
아래 표는 테스트 활동을 수행할 때
사용 가능한 자동화 도구의 유형과
대표적인 기능을 보여 준다.
테스트 관리, 요구사항 관리, 결함 관리,
형상 관리 등을 지원하는 도구들은
테스트 관리 도구로 분류된다.
그리고
리뷰 및 정적 분석을 지원하는
정적 테스트 도구와 테스트 케이스 및
테스트 절차와 테스트 데이터를
자동으로 생성하는 동적 테스트 도구가 있다.
테스트 절차의 실행, 단위 테스트 프레임워크,
테스트 결과 비교, 커버리지 측정 등을 지원하는
테스트 실행 도구도 있다.
| 도구 유형 | 도구 기능 |
| 테스트 관리 |
테스트 관리 도구, 요구사항 관리, 결함 관리(이슈 추적), 형상 관리 |
| 정적 테스트 |
리뷰 프로세스 지원, 정적 분석, 모델링 |
| 동적 테스트 |
테스트 설계, 테스트 데이터 준비 |
| 테스트 실행 |
테스트 실행. 테스트 하네스(harness)/단위 테스트 프레임워크, 테스트 비교기, 커버리지 측정 |
(테스트 자동화 도구 유형)
수행 개별 테스트
테스트 프로젝트를 수행하면서
포함해야 하는 개별 테스트,
즉, 수행할 컴포넌트 테스트, 통합 테스트,
시스템 테스트, 인수 테스트 등의
레벨 테스트와 성능 테스트, 신뢰성 테스트,
보안 테스트 등의 유형 테스트를 나열한다.
개별 테스트 선정 작업을 할 때
조직이 개발하는 소프트웨어의 규모와
특성을 고려해야 한다.
또한, 소프트웨어의 성능, 신뢰성, 보안 등
특성의 중요도에 따라
품질 특성별로 유형 테스트를
별도로 수행할 수 있다.
| 순서 | 개별 테스트 | 목적 |
| 1 | 컴포넌트 테스트 | 시스템을 구성하는 각 컴포넌트의 기능에 대한 테스트를 수행 |
| 2 | 통합 테스트 | 컴포넌트 간의 연결에 대한 테스트를 수행 |
| 3 | 시스템 테스트 | 요구사항 명세서를 바탕으로 시스템 전체의 기능에 대한 테스트를 수행함 |
| 4 | 신뢰성 테스트 | 컴포넌트, 통합, 시스템 수준에서 신뢰성에 초점을 둔 테스트를 수행 |
| 5 | 성능 테스트 | 컴포넌트, 통합, 시스템 수준에서 성능에 초점을 둔 테스트를 수행 |
| 6 | 보안 테스트 | 시스템 수준에서 보안에 초점을 테스트를 수행 |
| 7 | 인수 테스트 | 사용자 환경에서 사용자 중심으로 기능, 성능, 신뢰성, 보안에 초점을 둔 테스트를 수행 |
(수행 개별 테스트 예시)
개별 테스트 수준의 조직 테스트 전략
프로젝트 수준의 조직 테스트 전략에 명시된
개별 테스트(레벨 테스트 및 유형 테스트)별로
수립될 전략을 의미한다.
| 항목 | 설명 |
| 테스트 독립성 | 기술적, 관리적, 재정적 측면에서 테스트 활동의 독립성을 기술한다. |
| 테스트 문서화 | 개별 테스트 수준에서 수행되는 테스트 활동을 통하여 생성되는 산출물을 정의한다. |
| 테스트 시작 및 종료 조건 |
동적 테스트 활동을 시작하기 위하여 만족되어야 하는 조건과 테스트 활동의 수행을 종료할 수 있는 조건을 정의한다. |
| 테스트 설계 기법 |
개별 테스트에 적용할 테스트 설계 기법을 결정한다. |
| 테스트 환경 및 테스트 데이터 |
개별 테스트 수행을 위하여 필요한 테스트 환경과 테스트 데이터를 기술한다. |
| 재테스팅 및 리그레션 테스팅 |
재테스팅 및 리그레션 테스트를 수행하는 방법을 정의한다. |
| 테스트 메트릭 | 개별 테스트 수형 현망을 모니터링하기 위하여 측정할 메트리운 정의하다. |
| 테스트 완료 기준 | 테스트 대상에 대한 테스트 완료 여부를 한단할 수 있는 좌관적인 기준을 정의한다. |
(개별 테스트 수준의 조직 테스트 전략 항목)
테스트 독립성
테스트는 독립적으로 수행될수록
결함이 쉽게 발견된다고 알려져 있다.
더보기
ex)
소스 코드와 무관한 테스터에 비해
소스 코드를 작성한 개발자가
결함을 찾는 것은 더욱 어렵다는 것이다.
테스트 독립성 전략에서는
테스트 활동을 소프트웨어 개발과
어느 정도 독립적으로 수행할지
그 수준을 정의한다.
IEEE Std. 1012-2012
Standard for System and
Software Verification and Validation에 따르면
테스트를 포함한 V&V 활동이
개발 조직과 기술적 측면,
관리적 측면, 그리고 재정적 측면에서
독립적으로 수행되는 것이 바람직하다.
| 관점 | 설명 |
| 기술적 독립성 |
개발에 참여하지 않은 인력이 테스트를 수행하며, 개발 조직과 다른 테스트 조직 고유의 도구 를 사용한다. 개발 조직과 도구를 공유하는 경우 Qualification 테스트를 수행한다. |
| 관리적 독립성 |
테스트 대상, 범위, 전략, 일정 등을 개발 조직 및 프로그램 관리 조직의 영향 없이 독자적으로 수립하고 진행 상황을 아무 제약 없이 프로그램 관리 조직에 보고할 수 있다. |
| 재정적 독립성 |
개발 조직과 독립적으로 테스트에 예산이 투입될 수 있다. 즉, 개발 예산 부족이 테스트 활동의 수행에 영향을 주지 않는다. |
(테스트 독립성의 3가지 관점)
기술적, 관리적, 재정적 측면의 독립성
다양한 수준에서 결정될 수 있다.
표준에서는 독립적 V&V의 대표적인 형태로서
1) 최고 수준(Classical)의 형태,
2) 변형된(Modified) 형태,
3) 통합(Integrated) 형태,
4) 내부적(Internal) 형태,
5) 내장된(Bmbedded) 형태를 소개하고 있다.
| 독립성 형태 | 기술적 측면 | 관리적 측면 | 재정적 측면 |
| 최고 수준의 형태 | R | R | R |
| 변형된 형태 | R | C | R |
| 통합된 형태 | C | R | R |
| 내부적 형태 | C | C | C |
| 내장된 형태 | M | M | M |
(독립적 V&V의 형태)
R, C, M
R(Rigorous) - 철저한 독립성
C(Conditional) - 조건적 독립성
M(Minimized) - 최소의 독립성
최고 수준(Classica)의 형태
기술적, 관리적, 재정적 측면에서
모두 철저한 수준의 독립성을 가진다.
일반적으로 외부의 다른 회사가 개발을 하고
제공자가 V&V를 할 때의 형태이다.
이 형태의 V&V는 시스템의 장애로 인한
피해가 심각(생명 위협, 미션 실패,
심각 한 사회적 또는 경제적 손실 등)할 경우에
요구될 수 있다.
변형된(Mocliied) 형태
기술적, 재정적 측면에서는
철저하게 독립적이지만,
관리적 측면에서는 조건적으로
독립적인 형태이다.
이 형태는 대규모 시스템을 구축할 때
1 차 통합사(Prime integrator)가
v&v를 포함한 전체 개발을
관리하는 경우에 나타날 수 있다.
V&V 활동에 대한 보고가
1차 통합사에게 제공되므로
관리적 측면의 독립성은 약화된다.
통합된(Integrated) 형태
기술적 측면에서 조건적인 독립성을 가진다.
이 형태는 V&V의 결과를
개발 프로세스에 신속하게
제공하는 것에 초점을 둔다.
즉, 개발 조직과 V&V 조직이 협력하여
개발 중 산출물에 대한 리뷰를 수행하며,
개발 조직에서 수행한 인스펙션 및
워크쓰루 등의 리뷰에 대해서도
피드백을 제공한다.
그러므로
개발 조직과 V&V 조직의 성공 여부는
서로 의존적이다.
내부적(Internal) 형태
기술적, 관리적, 재정적 측면에서
모두 조건적인 형태이다.
이 형태는 개발 산출물에
직접적으로 관여하지 않을 수도 있지만,
개발 조직에 속한 개발자가
V&V 활동을 수행한다.
개발자와 동일한 환경에서
동일한 가정을 할 수 있으므로
결함을 간과할 가능성이 있다.
개발 조직에 속하므로
VBV 활동을 엄격하게 수행하는 데
부정적인 영향도 받을 수 있다.
또한, 개발 조직이 V&V 예산도 통제하므로
재정적인 측면에서도 독립성은 약화된다.
내장된(Enedes) 형태
내부적 형태와 마찬가지로
개발에 직접적으로 참여하지 않은
개발 조직의 인력이 V&V 활동을 수행한다.
이 형태에서는 개발 절차 및
프로세스의 부원성에 초점을 둔다.
개발 조직이 수행하는 인스펙션,
워크스루 등의 리뷰에 직접 참여하는 등
개발 조직과 병행하여 V&V 작업을 수행한다.
이 형태에서는 산출물에 대한
독립적인 테스트를 명시적으로 수행하지 않는다.
시간, 비용. 유형, 목표로 하는
품질 수준 등을 고려하여
각 독립성 측면의 수준 및
전체적인 독립성 행태를 적절히 결정하도록 한다.
일반적으로 높은 수준의 독립성으로
테스트를 수행하는 것은
시간과 비용을 많이 필요로 하지만
위험 해소와 품질 확보 측면에서는
더 효과적일 수 있다.
위험 분석을 바탕으로
독립성 수준을 정할수도 있는데,
높은 위험도에 대한 테스트를 수행 할 때는
더 높은 수준의 독립성으로 수행하는 것이
바람직하다.
더보기
ex)
성능 및 신뢰성 관련한 심각한 위험 요소가 있다면
성능 테스트와 신뢰성 테스트는 최고 수준 또는
변형된 형태의 독립성으로 수행하는 것을 고려해야 한다.
반대로 낮은 위험도에 대해서는
위험의 심각성과 함께 일정과 비용을 고려하여
통합된 형태, 내부적 형태, 그리고 내장된 형태를
적절하게 선택하여 수행하도록 한다.
테스트 문서화
개별 테스트 수준에서 수행되는
테스트 활동을 통하여
생성되는 산출물을 정의한다.
각 테스트 산출물에 대한 검토 및
승인 절차를 정의한다.
| 프로세스 | 산출물 |
| 테스트 관리 프로세스 |
테스트 계획서 테스트 현황 보고서 테스트 종료 보고서 |
| 동적 테스트 프로세스 |
테스트 설계 명세서 테스트 케이스 명세서 테스트 절차 명세서 테스트 환경 요건 명세서 테스트 데이터 요건 명세서 테스트 환경 준비 보고서 테스트 데이터 준비 보고서 테스트 실행 로그 결함 보고서 결함 추적 보고서 |
| 정적 테스트 프로세스 |
리뷰 보고서 정적 분석 보고서 |
(개별 테스트 수준에서의 문서화 전략)
각 테스트 산출물은 수행되는 개별 테스트 별로 작성된다.
더보기
ex)
컴포넌트 테스트에 대해서
컴포넌트 테스트 계획서, 컴포넌트 테스트 설계서, ···,
컴포넌트 테스트 결함 보고서,
컴포넌트 테스트 종료 보고서를 작성한다.
마찬가지로
성능 테스트 및 인수 테스트가 수행된다면
각 성능 테스트와 인수 테스트에 대해서도
동일한 유형의 테스트 문서를 작성한다.
프로젝트 테스트 계획서를 바탕으로
컴포넌트 테스트, 성능 테스트, 인수 테스트 등의
개별 테스트에 대한 계획을 수립한다.
각 개별 테스트별로 동적 테스트를 수행하고
그 결과물을 작성한다.
각 개별 동적 테스트가 종료되면
컴포넌트 테스트 종료 보고서,
성능 테스트 종료 보고서,
인수 테스트 종료 보고서 등과 같이
개별 테스트에 대한 종료 보고서를 작성한다.
그리고
개별 테스트에 대한 종료 보고서들을 바탕으로
프로젝트 테스트 종료 보고서를 작성한다.
테스트 시작 및 종료 조건
동적 테스트 활동을 시작하기 위해
만족되야 하는 조건과 테스트 활동의
수행을 중료할 수 있는 조건을 말한다.
즉, 컴포넌트 테스트, 통합 테스트 등의
개별 텍스트를 모호한 기준이 아니라
여기서 정의한 시작 조건이 충족될 때
개별 테스트를 시작하고
종료 조건이 충족될 때
테스트를 중료한다.
각 테스트 활동의 시작 및 종료 조건과
개별 테스트 프로세스의 시작 및
종료 조건으로 분류된다.
테스트 활동의 시작 및 종료 조건
동적 테스트 프로세스를 구성하는
각 활동별로 시작 조건과
종료 조건을 기술한다.
더보기
ex)
테스트 설계 및 구현 활동의
시작 조건 및 종료 조건,
테스트 한경 구축 및 관리 활동의
시작 조건 및 종료 조건 등을 정의할 수 있다.
이러한 테스트 활동의 시작 및 종료 조건은
테스트 관리 프로세스의
테스트 모니터링 및 제어 활동에서 이용된다.
즉, 시작 조건이 충족되면
해당 활동의 시작을 허용하고
종료 조건이 충족되면
해당 활동의 종료를 허용한다.
테스트 활동의 시작 조건
각 테스트 활동에 따라서 달라질 수 있다.
테스트 설계 및 구현 활동의 경우
피처 집합, 테스트 케이스 및
테스트 절차를 개발하기 위하여
필요한 개발 산출물(테스트 베이시스)이
준비되어 있음이 확인되어야 한다.
더보기
ex)
컴포넌트 테스트는 승인된 상세 설계서가
테스트 베이시스로서 준비되어 있어야 한다.
그리고
통합 테스트는 승인된 구조 설계서가 필요하며,
시스템 테스트는 승인된 소프트웨어 요구사항 명세서가
시작 조건으로 필요하다.
테스트 환경 구축 및 관리,
테스트 실행, 결함 보고 활동의 경우
직전 수행 활동의 종료 조건이
해당 활동의 시작 조건에 해당된다.
더보기
ex)
테스트 환경 구축 및 관리 활동이
시작될 수 있는 조건으로는
테스트 환경과 테스트 데이터에 대한 요건이
정의되어 있어야 하며,
이는 테스트 설계 및 구현 활동을
종료하는 조건에 해당된다.
테스트 실행 활동
테스트 구축 및 개발과
테스트 환경 구축 및 관리 활동의
결과물 뿐 아니라
테스트 대상이 빌드되어
실행 가능한 상태로 존재해야
시작 조건을 만족할 수 있다.
그리고
결함 보고 활동이 시작되려면
테스트 실행 활동을 통해서
테스트 실행 로그가 준비되어 있어야 한다.
테스트 활동의 종료 조건
기본적으로 해당 활동에서 목표로 하는
결과물의 완료가 포함 된다.
더보기
ex)
테스트 설계 및 개발 활동의 종료 조건으로
테스트 설계 명세서, 테스트 케이스 명세서,
테스트 절차 명세서, 테스트 환경 요건 명세서,
테스트 데이터 요건 명세서가 작성 완료되어야 한다.
또한,
테스트 활동별 산출물 완료뿐 아니라
테스트 완료 기준도 테스트 종료 기준으로 포함될 수 있다.
더보기
ex)
컴포넌트 테스트에 테스트 완료 기준으로
"문장 커버리지 90% 이상이 되어야 한다."가 있다면
문장 커버리지를 충족시킬 수 있는
테스트 케이스 및 테스트 절차 개발이
테스트 설계 및 구현 활동의 종료 조건으로
고려될 필요가 있다.
마찬가지로
테스트 실행 및 결함 보고 활동에서도
문장 커버리지 90% 이상 달성을
종료 조건으로 고려할 수 있다.
개별 테스트 프로세스의 시작 및 종료 조건
프로젝트 수준의 조직 테스트 전략에서
테스트 프로젝트에서 수행해야 할
개별 테스트를 명시하였다.
더보기
ex)
컴포넌트 테스트
↓
통합 테스트
↓
시스템 테스트
↓
신뢰성 테스트
↓
성능 테스트
↓
인수 테스트
위 순서대로 테스트를 수행한다고 할 때,
각 개별 테스트를 시작 할 수 있는 조건과
종료할 수 있는 조건을 정의해야 한다.
개별 테스트를 수행하는 순서에 따라
이전 개별 테스트의 종료 조건은
이후 개별 테스트의 시작 조건과 관계가 있다.
즉, 이전 개별 테스트의 종료 조건은
이후 개별 테스트의
시작 조건을 포함하여야 한다.
더보기
ex)
통합 테스트의 시작 조건에는
통합 테스트 대상에 포함된
각 컴포넌트에 대한 테스트 종료가
포함되어야 한다.
테스트 시작 조건
각 테스트 레벨에 따라서
구체화될 수 있다.
| 테스트 레벨 | 테스트 시작 조건 |
| 컴포넌트 테스트 | 승인된 버전의 각 컴포넌트에 대한 상세 설계 명세서 각 컴포넌트의 승인된 빌드 |
| 통합 테스트 | 승인된 버전의 구조 설계 명세서 통합 대상에 포함된 컴포넌트에 대한 컴포넌트 테스트 완료 컴포넌트 테스트 종료 보고서 |
| 시스템 테스트 | 승인된 버전의 소프트웨어 요구사항 명세서 통합 테스트 완료 통합 테스트 종료 보고서 |
| 인수 테스트 | 시스템 테스트 완료 시스템 테스트 종료 보고서 |
(테스트 레벨별 테스트 시작 조건 예)
테스트 종료 조건
각 테스트 레벨에 따라서
구체화될 수 있다.
| 테스트 레벨 | 테스트 종료 조건 |
| 컴포넌트 테스트 | 90% 이상 컴포넌트에 대한 테스트 완료 승인된 버전의 컴포넌트 테스트 종료 보고서 |
| 통합 테스트 | 90% 이상의 설계 단위 호출 커버리지 승인된 버전의 통합 테스트 종료 보고서 |
| 시스템 테스트 | 유스케이스 커버리지 100% 유스케이스 시나리오 커버리지 90% 이상 승인된 버전의 시스템 테스트 종료 보고서 |
| 인수 테스트 | 예측 신뢰도 99% 이상 예측된 미해결 결함 5개 이하 승인된 버전의 인수 테스트 종료 보고 |
(테스트 레벨별 테스트 종료 조건 예)
테스트 프로세스의 종료 조건이 충족될 때
테스트 관리 프로세스의 테스트 종료 활동이 시작된다.
그리고
다음 개별 테스트의 시작 조건이 충족되면
다음 개별 테스트가 시작된다.
이 때,
테스트 시작 조건 및 종료 조건의
충족 여부를 판단하는 것은
테스트 관리 프로세스의
테스트 모니터링 및 제어 활동에 해당된다.
테스트 설계 기법
개별 테스트별로 적용할
테스트 설계 기법을 결정한다.
테스트 설계 기법은 정적 테스트와
동적 테스트로 분류된다.
수행할 개별 테스트에 따라
효과적인 테스트 설계 기법을 결정해야 한다.
더보기
ex)
성능, 신뢰성과 같은 비기능 테스트는
시스템을 동작시켜 확인할 수 있으므로
정적 테스트보다는 동적 테스트가
보다 적합하다.
반면, 유지보수성은
소스 코드의 구조와 밀접하므로
동적 테스트보다는
정적 테스트를 통해서
확인될 수 있다.
| 유형 | 장점 | 단점 |
| 정적 테스트 |
• 구현물이 완성되기 전에 적용 가능함 • 실행을 위한 환경을 필요로 하지 않음 • 결함의 위치를 직접적으로 결정함 |
• 동적 특성(성능, 신뢰성, 가용성 등)을 확인하기 어려움 |
| 동적 테스트 |
• 동적 특성(성능, 신뢰성, 가용성 등)을 확인할 수 있음 | • 구현물이 완성된 후에 적용 가능함 • 테스트 환경 및 데이터 등이 준비되어야 함 • 장애 확인 후에 결함의 위치는 분석이 필요함 |
(테스트 설계 기법 비교)
위 표에서 볼 수 있듯이 정적 테스트와 동적 테스트는
각각 장단점이 있으므로 테스트 목적을 달성하면서
효율적으로 테스트를 수행하기 위해서는
정적 테스트와 동적 테스트를
모두 사용할 필요가 있다.
더보기
ex)
소스 코드 등의 구현물이 완성되어
실행될 준비가 되기전까지는
정적 테스트를 통하여
소프트웨어 산출물을 확인하고
구현물이 완성된 후에 동적 테스트를
추가 적용하여 실행을 통한 확인이
필수적인 품질 특성(성능, 신뢰성, 가용 성 등)을 테스트한다.
| 동적 테스트 유형 | 설계 기법 |
| 명세 기반 테스트 | • 동등 분할 • 분류 트리 기법 • 경곗값 분석 • 신택스 테스트 • 조합 테스트 • 상태 전이 테스트 • 인과 그래핑 • 결정표 테스트 • 시나리오 테스트 |
| 구조 기반 테스트 | • 문장 테스트 • 결정 테스트 • 조건 테스트 • 결정/조건 테스트 • 다중 조건 테스트 • 변형 조건/결정 테스트(MCDC) • 기본 경로 테스트 |
| 경험 기반 테스트 | • 오류 추정 • 탐색적 테스트 |
(동적 테스트 설계 기법)
이와 같은 3가지 유형의 동적 테스트 방법은
테스트 프로젝트의 상황에 따라서
병행하여 사용될 수 있다.
만약, 테스트 케이스 및 테스트 절차를 개발하고
문서화할 충분한 시간이 확보되지 않았거나
재테스팅 및 리그레션 테스트를
추가적으로 수행할 가능성이 적다면
경험 기반 테스트를 우선 고려할 필요가 있다.
충분한 시간이 확보되었다면
경험 기반 테스트와 함께
명세 기반 테스트, 구조 기반 테스트를
함께 적용한다.
명세 기반 테스트와
구조 기반 테스트도 장점과
단점이 있으므로
테스트 프로젝트의 상황에 따라서
적절하게 선정해
적용하는 것이 바람직하다.
더보기
ex)
명세 기반 테스트와 구조 기반 테스트 기법은
테스트 케이스를 설계할 때
참고하는 정보가 무엇이냐에 따라서 분류되며
이 특성은 각 테스트 설계 방법이
검출할 수 있는 결함의 유형에 영향을 미친다.
명세 기반 테스트
명세 정보를 바탕으로 하므로
명세는 되었지만(소스 코드로 구현을 해야 하지만)
실제로 구현되지 않은 결함을
검출할 수 있다는 장점이 있다.
반면,
명세 되지 않은 기능을
소스 코드가 가지고 있는지를
확인할 수는 없다.
구조 기반 테스트
명세 기반 테스트와 반대로,
소스 코드를 바탕으로 하기 때문에
불필요 하지만 구현되어 있는 기능을
검출할 수 있다.
그러나
요구 명세에 언급되어 있는 기능이
누락되지 않고 구현되었는지
확인할 수는 없다.
그러므로
테스트 케이스를 설계할 때는
명세 기반 테스트와 구조 기반 테스트를
함께 사용함으로써
누락 결함과 비관련 결함도
검출할 수 있도록 해야 한다.
| 테스트 설계 기법 |
활용 정보 | 적용 테스트 레벨 | 결함 유형 | |||||
| 컴포넌트 | 통합 | 시스템 | 인수 | 누락 | 부정확 | 비관련 | ||
| 구조 기반 테스트 |
소스 코드 | O | O |
O |
||||
| 명세 기반 테스트 |
요구명세/ 구조 설계/ 상세 설계 |
O | O |
O |
O | O |
O | |
(명세 기반 테스트와 구조 기반 테스트 요약)
구조기반 테스트는 소스 코드와
관련된 정보를 바탕으로 한다.
그러므로
규모와 복잡도가
작은 컴포넌트/모듈 등을 대상으로
수행하는 것이 일반적이다.
즉, 구조 기반 테스트는
컴포넌트 레벨의 테스트에서
일반적으로 적용된다.
명세 기반 테스트는
소스 코드를 참조하지 않고
명세를 바탕으로 한다.
그러므로
상세 설계, 구조 설계,
요구분석 등의 명세를 바탕으로
테스트 케이스를 설계하므로
컴포넌트 테스트, 통합 테스트,
시스템 테스트, 인수 테스트에서
모두 활용 가능하다.
테스트 환경 및 테스트 데이터
테스트 환경
테스트를 수행하기 위하여
필요한 모든 요소를 의미한다.
동적 테스트를 수행하기 위해서는
테스트 대상이 실행되어야 하며,
테스트 대상이 실행되려면
하드웨어, 운영체제 등의 시스템 소프트웨어,
외부 연동 시스템, 공존하는 응용 소프트웨어,
테스트 도구 등이 필요하다.
| 테스트 환경 유형 | 설명 |
| 하드웨어 | 테스트 대상이 실행되기 위하여 필요한 하드웨어들 |
| 시스템 소프트웨어 | 테스트 대상이 실행되기 위하여 필요한 운영체제, 미들웨어 등의 시스템 소프트웨어 |
| 외부 연동 시스템 | 테스트 대상과 연동하는 외부의 시스템 및 장치들 |
| 공존 응용 소프트웨어 |
테스트 대상과 동일한 하드웨어 및 시스템 소프트웨어상에서 수행되는 응용 소프 트웨어들 |
| 테스트 도구 | 테스트 실행 시 활용되는 자동화 도구들 |
(테스트 환경 유형)
본 절에서는 개별 테스트 수준에서 필요한
테스트 환경 요소를 식별하고 정의한다.
수행하고자 하는
개별 테스트의 유형에 따라서
테스트 환경 요소는 달라진다.
더보기
ex)
컴포넌트 테스트는
테스트 대상이 실행될 때 이용하는
다른 컴포넌트가 있을 수 있다.
컴포넌트 테스트이므로 해당 의존 컴포넌트는
실제가 아니라 스팁으로 대체되어야 한다.
또한,
테스트 대상 컴포넌트를 실행시키기 위한
드라이버 프로그램이 필요할 수도 있다.
따라서
컴포넌트 테스트의 경우에는
드라이버와 스텝도 테스트 환경에 해당된다.
성능 테스트를 수행하는 경우
테스트 대상에 큰 규모의
부하를 생성하려는 목적으로
클라우드를 이용할 수도 있다.
그리고
가상의 대규모 부하를 생성하기 위한
테스트 도구를 사용할 수도 있다.
이러한 모든 것은 성능 테스트를 수행하기 위한
환경에 해당된다.
테스트를 수행할 때는
테스트 환경과 더불어 테스트 데이터가 필요하다.
테스트 데이터는
테스트 환경을 구성하거나
테스트 대상의 상태 및
입력값을 정의할 때 필요하다.
테스트 데이터가
단순한 하나의 값인 경우도 있지만,
대규모이거나 이미지, 동영상
또는, 분포를 가지지만
불확실한 특성을 가진 데이터일 수도 있다.
따라서
테스트를 수행하기 위하여
테스트 환경과 더불어
필요한 테스트 데이터도
명확히 정의되고 준비되어야 한다.
재테스팅 및 리그레션 테스팅
동적 테스트 프로세스 수행과 더불어
재테스팅 및 리그레션 테스팅에 대한
전략을 수립한다.
즉,
소프트웨어가 수정되었을 때
어떤 방식으로 테스팅을 수행할지에 대한
전략을 수립한다.
재테스팅과 리그레션 테스팅은
목적과 방법상에 다소 차이가 있지만,
소프트웨어가 변경된 후에
수행된다는 측면에서는 동일하다.
재테스팅
변경이 발생한 후에 재스팅을 수행할
개별 테스트를 선정하는 전략이 필요하다.
즉,
컴포넌트 테스트, 통합 테스트, 시스템 테스트,
성능 테스트, 신뢰성 테스트 등과 같은
전체 개별 테스트 수준에서
재테스팅을 수행할지, 아니면
일부 개별 테스트에서 수행할지
전략을 정의하도록 한다.
리그레션 테스팅도 마찬가지로
리그레션 테스트를 적용할
개별 테스트를 선정하는 전략이 요구된다.
즉,
컴포넌트에 대한 기능 추가,
결함 수정 등으로 소스 코드가 변경되었을 때
컴포넌트, 통합, 시스템 등 어느 레벨에서
리그레션 테스트를 수행할지
기준을 정의할 필요가 있다.
또한,
각 개별 테스트에서
리그레션 테스트를 수행할 때
기존 테스트 절차를
어떤 방식으로 활용할지에 대한 전략도
정의할 필요가 있다.
즉,
Retest all 전략, 선택적 리그레션 테스트 전략,
테스트 최소화 전략, 테스트 우선순위화 전략을
적절히 선택하도록 한다.
재테스팅과 리그레션 테스팅은
모두 변경이 발생하였을 때
테스트를 반복적으로 수행하게 된다.
1회가 아니라 검출된 결함이 종결되었음을
확인할 때까지 반복적으로 수행한다.
게다가
컴포넌트 테스트, 통합 테스트, 시스템 테스트,
성능 테스트 등 여러 개별 테스트에서 수행한다.
그러므로
한정된 시간에 이러한 반복적 테스트를
효율적으로 수행하려면
테스트 자동화 도구의 적용이 중요하다.
즉,
테스트 자동화 도구를 이용하여
테스트 절차를 스크립트화하고
이를 자동으로 실행시키는 전략을 수립한다.
테스트 메트릭
테스트 현황을 정량적으로 파악하여
테스트의 진척도 및 시스템의 품질을 객관적으로 판단하기 위해
수집하는 측정 항목을 말한다.
더보기
ex)
설계된 테스트 케이스 중에서
실행된 테스트 케이스의 비율을 이용해서
테스트 실행 활동의 진척도를
파악 할 수 있다.
그리고
전체 문장 대비 통과된
테스트 케이스로
확인된 문장의 비율,
즉,
문장 커버리지로를 이용하면
테스트 관점에서 테스트 대상의
품질 수준을 파악할 수 있다.
뿐만 아니라 테스트 완료 기준으로도 사용된다.
더보기
ex)
문장 커버리지가 95% 이상이고
잔존 결함이 5개 이하라는 조건으로
테스트 완료 기준을 설정할 수 있다.
따라서
테스트 완료 기준에 사용되는 데이터는
테스트 메트릭에 포함되어야 한다.
테스트 활동 및 테스트 대상 소프트웨어를 평가하는데
각 테스트 활동별 메트릭을 사용할 수 있다.
아래 표는 테스트 활동의 수행을
객관적으로 모니터링하기 위하여
사용될 수 있 는 다양한 메트릭을
각 테스트 활동별로 요약해서 보여 준다.
자세한 설명은 테스트 계획을 참고하기 바란다.
| 테스트 활동 | 메트릭 예 |
| 테스트 계획 | • 테스트 대상 수 • 피처 수 |
| 테스트 설계 및 구현 | • 테스트 케이스 수 • 테스트 절차 수 |
| 테스트 환경 구축 및 관리 | • 테스트 환경 준비율 • 테스트 데이터 준비율 |
| 테스트 실행 | • 실행된 테스트 케이스(테스트 절차) 수 • 통과된 테스트 케이스(테스트 절차) 수 |
| 결함 보고 | • 검출된 결함 수 • 상태별 결함 수 |
(테스트 메트릭 유형)
테스트 완료 기준
테스트 대상에 대하여
충분한 테스트를 수행하였다고
판단할 수 있는 객관적인 기준을 의미한다.
동적 테스트 활동이 종료된 후
수행된 테스트 활동에 대한
테스트 종료 보고서가 작성될 때
설정된 테스트 완료 기준에 따라서
테스트에 대한 완료 여부를 평가한다.
아래 표는 대표적인 테스트 완료 기준을 보여 준다.
테스트 완료 기준은 테스트 케이스(테스트 절차),
커버리지, 결함 등의 정보를 바탕으로 한
기본 유형의 완료 기준이 있으며
또한,
신뢰도 예측, 결함 탐침,
복수 테스트 팀 등을 활용하는
분석 유형의 완료 기준이 있다.
| 유형 | 완료 기준 예 |
| 기본 유형 | • 테스트 케이스(테스트 절차) 기반 방법 • 테스트 커버리지 기반 방법 • 결함 기반 방법 |
| 분석 유형 | • 신뢰도 예측 방법 • 결함 탐침 방법 • 복수 테스트팀 방법 |
(테스트 완료 기준)
테스트 완료 기준
수행되는 각 개별 테스트별로
구체적으로 설정한다.
더보기
ex)
컴포넌트 테스트를 수행할 때는
코드 커버리지가
테스트 완료 기준에 포함될 수 있다.
시스템 테스트의 경우에는
요구사항 커버리지 및 미해결 결함의 수가
테스트 완료 기준에 포함될 수 도 있다.
종료 조건과 테스트 완료 기준은
서로 다른 것이지만 혼동의 여지가 있다.
테스트 종료 조건과 테스트 완료 기준의 차이점
종료 조건
동적 테스트 프로세스의
종료 조건을 포함하여,
각 동적 테스트 활동 종료 시
충족해야 하는 조건을 의미하지만,
테스트 완료 기준은
동적 테스트 활동의
최종 종료 시에 평가되는
기준을 의미한다.
즉,
종료 조건은 테스트 설계 및 구현,
테스트 환경 구축 및 관리,
테스트 실행, 그리고 결함 보고 등의
각 테스트 활동을 종료할 때
충족해야 하는 조건을 의미한다.
반면,
테스트 완료 조건은
동적 테스트 프로세스의 개별 활동이 아니고
동적 테스트 프로세스 자체가
종료되는 시점에 적용되는 기준이다.
종료 조건은 해당 테스트 활동의
종료를 위해서 반드시
충족되어야 하는 조건이다.
다시 말하면 해당 조건이
충족되지 않으면
테스트 활동을 종료할 수 없으며,
조건이 충족될 때 까지
테스트 활동은 지속된다.
더보기
ex)
컴포넌트 동적 테스트를수행할 때
테스트 실행의 종료 조건으로
"모든 테스트 절차가 실행되어야 한다."가 있다면
모든 테스트 절차가 실행될 때까지
테스트 실행 활동은 지속된다.
반면,
테스트 완료 조건은
동적 테스트 프로세스가 종료된 후에
수행된 테스트가 얼마나 충분한지를
평가하기 위한 조건으로서
이 완료 조건이 충족될 수도 있고
그렇지 않을 수도 있다.
더보기
ex)
컴포넌트 테스트에 대한
완료 조건으로 "문장 커버리지가
90% 이상이어야 한다."라고 한다면
테스트 종료 조건(모든 테스트 절차의 실행)은 충족되지만,
문장 커 버리지는 90% 이하가 될 수도 있다.
산출물 요약
조직 테스트 프로세스에서는
조직 테스트 정책 명세서와
조직 테스트 전략 명세서를 작성 한다.
아래 표는 각 산출물을 구성하는
항목을 보여 준다.
| 산출물 | 주요 항목 |
| 조직 테스트 정책 명세서 | • 테스트 목적 • 테스트 프로세스 • 테스트 조직 및 역할 • 테스트 표준 • 테스트 자산 관리 • 테스트 프로세스 개선 |
| 조직 테스트 전략 명세서 |
• 프로젝트 수준의 전략 |
| • 위험 관리 • 테스트 선택 및 우선순위 • 테스트 문서화 • 형상 관리 • 결함 관리 • 자동화 도구 • 수행 개별 테스트 |
|
| • 개별 테스트 수준의 전략 | |
| • 테스트 독립성 • 테스트 문서화 • 테스트 시작 및 종료 조건 • 테스트 설계 기법 • 테스트 환경 및 테스트 데이터 • 재테스팅 및 리그레션 테스팅 • 테스트 메트릭 • 테스트 완료 기준 |
(조직 테스트 프로세스 산출물)
테스트 관리 프로세스
프로젝트 테스트 및 프로젝트 테스트를 구성하는
레벨 테스트(컴포 넌트 테스트, 통합 테스트 등)와
유형 테스트(성능 테스트, 신뢰성 테스트 등)의
수행을 관리 하는 것이 목적이다.
자세한 내용은 테스트 관리 프로세스 그림 11.17을 찾아보면 된다. (CSTS 가이드 p.290)
테스트 계획
테스트 대상과 범위를 식별하고
조직 테스트 프로세스를 참고하여
테스트 전략을 수립한다.
테스트 모니터링 및 제어
동적 테스트 프로세스의 수행을 모니터링하여
테스트 현황을 파악하고 테스트 활동을
적절하게 제어한다.
테스트 종료
테스트가 종료되면
생성된 산출물을 관리하고
테스트 환경을 정리하며
테스트 종료 보고를 한다.
텍스트 관리 프로세스
프로젝트 전체의 테스트 관리 뿐만 아니라
프로젝트 테스트를 구성하는
개별 테스트 관리에도 적용된다.
즉,
컴포넌트 테스트, 통합 테스트,
시스템 테스트, 인수 텍스트 등의
레벨 테스트와 성능 테스트,
신뢰성 데스트, 보안 테스트 등의
유형 테스트에 대한 관리도 적용된다.
자세한 내용은 프로젝트 테스트 및 개별 테스트 관리 그림 11.18을 찾아보면 된다. (CSTS 가이드 p.291)
프로젝트 테스트 계획
프로젝트 수준의 테스트 계획으로서
프로젝트 테스트를 구성하는
개별 테스트를 결정한다.
그리고
프로젝트 테스트 계획을 바탕으로
컴포넌트, 통합, 성능, 인수 등의
각 개별 테스트 계획이 수립된다.
여러 개별 테스트에서
동일한 계획 내용을 정의하고
이를 개별 테스트 계획에서 참조하도록 한다.
계획 이후에는 각 개별적인 테스트에 대한
동적 테스트 프로세스가 수행된다.
각 개별 테스트 프로세스에 대한
테스트 모니터링 및 제어 활동이 수행된다.
각 개별 테스트의 수행이 끝나면
개별 테스트에 대한
테스트 종료 활동이 수행되고
프로젝트 테스트에 대한 종료 활동이 수행된다.
테스트 활동
테스트 계획
테스트 관리 프로세스의 시작 활동으로서
동적 테스트를 효과, 효율적으로 수행하기 위한
계획 수립을 목적으로 한다.
즉,
조직 테스트 정책 명세에 설정된
테스트 목적을 달성하기 위한
테스트 컨텍스트 설정, 위험 분석 수행,
다양한 측면에서 적절한 테스트 전략 수립,
테스트 수행 계획 수립을 목표로 한다.
아래 표는 테스트 계획 활동을 통해서
결정되는 계획 항목을 보여 준다.
그리고
테스트 계획서는 이들 테스트 계획 항목들로 구성된다.
| 상위 계획 항목 | 세부 계획 항목 |
| 테스트 컨텍스트 |
|
| 위험 분석 |
|
| 테스트 전략 |
|
| 테스트 수행 계획 |
|
(테스트 계획서 요약)
테스트 모니터링 및 제어
테스트 계획서에 준하여
동적 테스트 프로세스가 수행될 수 있도록
각 테스트 활동을 모니터링하고
테스트 활동의 수행을 제어한다.
동적 테스트 프로세스의 수행에 대한
모니터링 결과와 이에 따른 제어 결과는
추가적으로 베스트 현황 보고서에 기록된다.
아래 표는 테스트 현황 보고 항목을 보여 준다.
| 산출물 | 주요 항목 |
| 테스트 현황 보고서 | • 보고 대상 기간 • 계획 대비 진척도 • 테스트 메트릭 • 신규 및 변경 위험 • 이후 테스트 계획 |
(테스트 모니터링 및 제어 활동 산출물 요약)
대표적 테스트 활동 제어
• 테스트 프로세스의 시작 및 테스트 활동의 시작
• 계획 대비 진척도 점검에 따른 테스트 활동 제어
• 위험 변동에 따른 테스트 활동의 제어
• 테스트 활동의 종료 및 테스트 프로세스의 종료
테스트 종료
테스트 활동이 종료되면
테스트 프로젝트에서 생성된 결과물을
테스트 자산으로 관리한다.
그리고
테스트 프로젝트에서 사용되었던
다양한 테스트 환경 요소를 정리한다.
마지막으로 수행된 테스트 작업과
그 결과를 테스트 종료 보고서에 기록한다.
아래 표는 테스트 종료 보고서에 기록되는
종료 보고 항목을 보여 준다.
| 산출물 | 주요 항목 |
| 테스트 종료 보고서 | • 테스팅 요약 • 계획 대비 차이점 • 테스트 메트릭 • 테스트 방해 요인 • 테스트 완료 평가 • 잔존 위험 • 테스트 산출물 • 재사용 가능한 테스트 자산 • 교훈 |
(테스트 종료 활동 산출물 항목)
산출물 요약
테스트 관리 프로세스를 수행하면서
작성되는 산출물을 보여 준다.
테스트 계획 활동에서는
테스트 계획서를 작성하며,
테스트 계획서에는
테스트 컨텍스트, 위험 분석, 테스트 전략,
테스트 수행 계획이 포함된다.
테스트 모니터링 및 제어 활동에서는
테스트 현황 보고서를 작성하며
계획 대비 진척도, 신규 및 위험 변경과
이후 테스트 계획 등이 포함된다.
테스트 종료 활동에서는
테스트 종료 보고서를 작성하며
테스팅 요약, 테스트 완료 평가,
잔존 위험 등이 포함된다.
| 활동 | 산출물 | 주요 항복 |
| 테스트 계획 | 테스트 계획서 | • 테스트 컨텍스트 • 위험 분석 • 테스트 전략 • 테스트 수행 계획 |
| 테스트 모니터링 및 제어 |
테스트 현황 보고서 | • 보고 대상 기간 • 계획 대비 진척도 • 테스트 메트릭 • 신규 및 변경 위험 • 이후 테스트 계획 |
| 테스트 종료 | 테스트 종료 보고서 | • 테스팅 요약 • 계획 대비 차이점 • 테스트 메트릭 • 테스트 방해 요인 • 테스트 완료 평가 • 잔존 위험 • 테스트 산출물 • 재사용 가능한 테스트 자산 • 교훈 |
(테스트 관리 프로세스 산출물 요약)
동적 테스트 프로세스
테스트 계획에서 정의된 테스트 대상,
테스트 범위, 테스트 전략을 바탕으로
동적 테스트 프로세스가 수행된다.
자세한 내용은 동적 테스트 프로세스 그림 11.19을 찾아보면 된다. (CSTS 가이드 p.296)
테스트 관리 프로세스와의 관계를 포함
동적 테스트 프로세스를 구성하는
4개의 활동과 산출물
테스트 설계 및 구현
테스트 계획에서 식별된 테스트 범위와
테스트 전략에 따라 테스트 케이스,
테스트 절차 등을 개발한다.
테스트 환경 구축 및 관리
테스트 실행을 위한 테스트 환경과
테스트 데이터를 준비한다.
테스트 실행
테스트 절차를 실행하고
테스트 실행 결과를 기록한다.
결함 보고
테스트 실행 결과에 대한 분석을 바탕으로
결함을 식별하고 기록한다.
테스트 활동
테스트 설계 및 구현
테스트 계획에 정의된
테스트 대상과 피처를 바탕으로
피쳐 집합을 식별하고 피처 집합에 포함된
각 피처를 세분화한다.
그리고
테스트 계획에서 수립된
테스트 전략을 구체화한다.
이어서
구체화된 테스트 전략에 따라서
테스트 케이스 및 테스트 절차를 개발한다.
또한,
테스트 실행에 필요한 테스트 환경과
테스트 데이터에 대한 요건을 정의한다.
아래 표는 테스트 설계 및 구현 활동의 산출물인
테스트 설계 명세서, 테스트 케이스 명세서,
테스트 절차 명세서, 테스트 환경 요건 명세서,
테스트 데이터 요건 명세서의
구성 항목을 보여 준다.
| 산출물 | 주요 항목 |
| 테스트 설계 명세서 | • 각 피처 집합에 대하여 - 목적 - 우선순위 - 피처 목록 - 구체적 테스트 전략 |
| 테스트 케이스 명세서 | • 각 테스트 케이스에 대하여 - 목적 - 추적성 - 우선순위 - 선행 조건 - 입력 - 예상 결과 |
| •각 테스트 절차에 대하여 - 목적 - 우선순위 |
|
| 테스트 절차 명세서 | - 시작 작업 - 실행 테스트케이스 목록 - 종료 및 정리 작업 - 다른 테스트 절차와의 관계 |
| 테스트 환경 요건 명세서 | • 각 테스트 환경 항목에 대하여 - 테스트 환경 항목명 - 설명 - 요구사항 - 필요 시기 - 담당자 |
| 테스트 데이터 요건 명세서 | • 각 테스트 데이터에 대하여 - 테스트 데이터명 - 설명 - 요구사항 - 초기화 필요 여부 - 보관 필요 여부 - 담당자 |
(테스트 설계 및 구현 활동 산출물 요약)
테스트 환경 구축 및 관리
주어진 테스트 환경 요건과
테스트 데이터 요건을 바탕으로
테스트 환경을 구축하고
테스트 데이터를 준비하여
테스트 실행이 진행되도록 지원한다.
아래 표는 테스트 환경 구축 및
관리 활동의 산출물로서
테스트 환경 준비 보고서와
테스트 데이터 준비 보고서의
주요 항목을 보여 준다.
| 산출물 | 주요 항목 |
| 테스트 환경 준비 보고서 | • 요약 • 각 테스트 환경 항목별 준비 상태 |
| 테스트 데이터 준비 보고서 | • 요약 • 각 테스트 데이터별 준비 상태 |
(테스트 환경 구축 및 관리 산출물 요약)
테스트 실행
테스트 실행 활동은
테스트 설계 및 구현 활동에서
개발된 테스트 절차를 실행함으로써 수행된다.
테스트 절차를 실행하였을 때
테스트 대상의 실제 수행 결과와
예상 결과를 비교하여 테스트 결과를 기록한다.
아래 표는 테스트 실행 활동의 산출물인
테스트 실행 로그를 보여 준다.
테스트 실행 로그는 테스트 실행 상황에 대한
설명과 함께 테스트를 수행하기 위한
작업과 발생한 이벤트를 나열한다.
| 산출물 | 주요 항목 |
| 테스트 실행 로그 | • 설명 • 테스트 작업과 이벤트 목록 |
(테스트 실행 활동 산출물 요약)
결함 보고
테스트 실행을 해서 발견되어
적절한 조치가 필요한 이슈에 대해서는
결합으로 보고했다.
즉,
테스트 실행의 결과물인
테스트 실행 로그를 분석하여
결함이라고 판단이 되면
결함 보고서를 작성한다.
결함에 대한 효과, 효율적인 디버깅을 위하여
결함을 구체화하고 고립화하고, 일반화하여
결함 보고서를 작성한다.
또한,
검출된 결함이 디버킹 되어
해결되고 종결되는 과정을
결함 추적 보고서에 기록한다.
아래 표는 결함 보고 활동의 산출물인
결함 보고서와 결함 추적 보고서의
주요 항목을 보여 준다.
| 산출물 | 주요 항목 |
| 결함 보고서 | • 결함 컨텍스트 • 문제 설명 • 심각도 • 우선순위 • 위험 분석 • 결함 상태 |
| 결함 추적 보고서 | • 결함 검토 정보 • 결함 해결 정보 • 결함 해결 검증 정보 |
(결함 보고 활동 산출물)
산출물 요약
아래 표는 동적 테스트 프로세스를 수행하면서
작성되는 산출물을 보여 준다.
테스트 설계 및 구현 활동을 통해서
테스트 설계 명세서, 테스트 케이스 명세서,
테스트 절차 명세서, 테스트 환경 요건 명세서,
테스트 데이터 요건 명세서가 작성된다.
테스트 환경 구축 및 관리 활동에서는
테스트 환경 준비 보고서와
테스트 데이터 준비 보고서가 작성된다.
테스트 실행 활동에서는
테스트 실행 로그, 그리고 결함 보고 활동에서는
결함 보고서와 결함 추적 보고서를 작성한다.
| 활동 | 산출물 | 주요 항목 |
| 테스트 설계 및 구현 |
테스트 설계 명세서 |
• 목적 • 우선순위 • 피처 목록 • 구체적 테스트 전략 |
| 테스트 케이스 명세서 |
• 목적 • 추적성 • 우선순위 • 선행 조건 • 입력 • 예상 결과 |
|
| 테스트 절차 명세서 |
• 목적 • 우선순위 • 시작 작업 • 테스트 케이스 목록 • 종료 및 정리 작업 • 다른 테스트 절차와의 관계 |
|
| 테스트 환경 요건 명세서 |
• 테스트 환경 항목명 • 설명 • 요구사항 • 필요 시기 • 담당자 |
|
| 테스트 데이터 요건 명세서 | • 테스트 데이터명 • 설명 • 요구사항 • 초기화 필요 여부 • 보관 필요 여부 • 담당자 |
|
| 테스트 환경 구축 및 관리 |
테스트 환경 준비 보고서 |
• 요약 • 각테스트 환경 항목별 준비 상태 |
| 테스트 데이터 준비 보고서 | • 요약 •각테스트 데이터별 준비 상태 |
|
| 테스트 실행 | 테스트 실행 로그 |
• 설명 • 테스트 작업과 이벤트 목록 |
| 결함 보고 |
결함 보고서 | • 결함 컨텍스트 • 결함 설명 • 심각도 • 우선순위 • 위험 분석 • 결함 상태 |
| 결함 추적 보고서 |
• 결함 검토 정보 • 결합 해결 정보 • 결함 해결 검증 정보 |
(동적 테스트 프로세스 산출물)
테스트 산출물
산출물 요약
아래 표는 전체 테스트 프로세스의 산출물을 보여준다.
조직 테스트 프로세스에서는 조직 테스트 정책 명세서와
조직 테스트 전략 명세서를 작성한다.
테스트 관리 프로세스에서는
테스트 계획서, 테스트 환경 보고서,
테스트 종료 보고서를 작성한다.
동적 테스트 프로세스에서는
테스트 설계 및 구현 활동에서
테스트 설계 명세서, 테스트 케이스 명세서,
테스트 절차 명세서 등을
테스트 환경 구축 및 관리 활동에서
테스트 환경 준비 보고서,
테스트 데이터 준비 보고서를 작성한다.
테스트 실행 활동에서는 테스트 실행 로그를 작성하고
결함 보고 활동에서는 결함 보고서와
결함 추적 보고서를 작성한다.
| 테스트 프로세스 | 산출물 |
| 조직 테스트 프로세스 | • 조직 테스트 정책 명세서 • 조직 테스트 전략 명세서 |
| 테스트 관리 프로세스 | • 테스트 계획서 • 테스트 현황 보고서 • 테스트 종료 보고서 |
| 동적 테스트 프로세스 | • 테스트 설계 명세서 • 테스트 케이스 명세서 • 테스트 절차 명세서 • 테스트 환경 요건 명세서 • 테스트 데이터 요건 명세서 • 테스트 환경 준비 보고서 • 테스트 데이터 준비 보고서 • 테스트 실행 로그 • 결함 보고서 • 결함 추적 보고서 |
(테스트 프로세스 산출물 요약)
산출물 간의 관계
자세한 내용은 테스트 프로세스 산출문 간의 관계 그림 11.20을 찾아보면 된다. (CSTS 가이드 p.303)
조직 수준의 테스트에 대한
최상위 문서로 조직 테스트 정책 명세서가 개발된다.
그리고
조직 테스트 정책 명세서의 테스트 목적,
테스트 프로세스, 테스트 조직 및 역할 등을 바탕으로
조직 테스트 전략 명세서가 개발된다.
조직의 규모가 작거나 테스트 대상들의 성격이
유사한 경우에는 1개의 조직 테스트 전략 명세서로
충분할 수도 있지만,
테스트 대상의 성격이 다르거나
다양한 종류의 개발 프로세스를 보유한 조직은
적합한 복수 개의 조직 테스트 전략 명세서가
개발될 수 있다.
조직 테스트 전략 명세서를 바탕으로
동적 테스트 프로세스 수행을 위한
테스트 계획서를 개발한다.
테스트 계획서는 테스트 프로젝트 수준과
실제 수행될 개별 테스트 수준에서 개발된다.
개별 테스트 계획은 컴포넌트 테스트,
통합 테스트 등의 레벨 테스트 계획과
성능 테스트, 신뢰성 테스트 등의
유형 테스트 계획을 의미한다.
또한,
각 개별 테스트별로
동적 테스트 프로세스의 산출물이 작성된다.
테스트 설계 및 구현 활동을 통해서
테스트 명세서(테스트 설계 명세서, 테스트 케이스 명세서,
테스트 절차 명세서)를 작성하고,
테스트 환경 요건 명세서와
테스트 데이터 요건 명세서를 작성한다.
테스트 환경 구축 및 관리 활동을 통해서
테스트 환경 준비 보고서와
테스트 데이터 준비 보고서를 작성한다.
테스트 실행 활동에서는
테스트 절차를 실행하며 그 결과를
테스트 실행 로그에 기록한다.
결함 보고 활동에서는
테스트 실행 로그 분석을 통하여
결함을 식별하여 결함 보고서를 작성한다.
식별된 결함이 종결될 때까지의 작업 내용을
결함 추적 보고서에 기록한다.
동적 테스트 프로세스의
수행에 대한 상황을 모니터링하여
테스트 현황 보고서를 작성한다.
개별 테스트에 대한 종료 조건이 충족되면
테스트 관리 프로세스의 테스트 종료 활동을 수행하여
테스트 종료 보고서를 작성한다.
먼저 각 개별 테스트에 대한 종료 보고서를 작성하고
이를 바탕으로 프로젝트 테스트의
종료 보고서를 작성한다.
728x90
'CertiFicate-prepare > CSTS-Study' 카테고리의 다른 글
| [Study] CSTS 13장 - 테스트 설계/구현 및 테스트 환경 구축/관리 (0) | 2024.08.07 |
|---|---|
| [Study] CSTS 12장 - 테스트 계획 (0) | 2024.08.07 |
| [Study] CSTS 10장 - 명세 기반 테스트 (0) | 2024.08.07 |
| [Study] CSTS 9장 - 구조 기반 테스트 (0) | 2024.08.07 |
| [Study] CSTS 8장 - 정적 테스트 (0) | 2024.08.07 |