사용할 중간 산출물 및 각 중간 산출물의 사용법을 결정하십시오. 사용할 중간 산출물의 식별뿐만 아니라 각 중간 산출물을 프로젝트의 필요에 맞게 사용하도록 사용자 조정하는 것도 중요합니다.
아래 표는 권장되는 테스트 중간 산출물과 선택사항으로 간주되는 형상 및 변경 관리 중간 산출물(예: 특정 경우에만 사용될 수 있음)을 지정합니다. 추가 사용자 조정 고려사항은 중간 산출물 설명 페이지의 사용자 조정
섹션을 참조하십시오.
중간 산출물
|
목적
|
사용자 조정(선택사항, 권장사항)
|
테스트 평가 요약
|
일차적으로 테스트팀 외부의 이해 당사자 및 관리 팀에서 사용할 테스트 결과를 요약합니다.
|
대부분의 프로젝트에서 권장됩니다.
상대적으로 프로젝트 환경이 정보인 경우 정규 평가 요약을 작성하지 말고 단순히 테스트 결과를 기록하는 것이 적절합니다. 다른 경우 테스트 평가 요약은 반복 평가 또는 검토 레코드와 같이 기타 평가 중간 산출물의 섹션으로 포함될 수 있습니다.
|
테스트 결과
|
이 중간 산출물은 하나 이상의 테스트 로그에 있는 원시 데이터에서 판별되어 분석된 결과입니다.
|
권장사항입니다. 대부분의 테스트팀은 테스트 결과에 대한 적당히 자세한 레코드의 양식을 일부 보유하고 있습니다. 일반적으로 수동 테스트 결과는 여기에 직접 기록되고 자동화된 테스트를 통해
순화된 테스트 로그와 결합됩니다.
때때로 테스트팀이 테스트 로그에서 직접 테스트 평가 요약을 작성하기도 합니다.
|
테스트 로그
|
보통 테스트 실행 중 원시 데이터 산출물은 자동화된 테스트로 작성됩니다.
|
선택사항입니다.
자동화된 테스트를 수행하는 많은 프로젝트에는 몇 가지 양식의 테스트 로그가 있습니다. 테스트 결과를 판별한 후 테스트 로그를 보유하는지 또는 버리는지에 대해 프로젝트 사이에서
차이가 납니다.
특정 감사 요구사항을 만족해야 하는 경우, 시간에 따른 원시 테스트 산출물 데이터 변경 과정에 대한 분석을 수행할 경우 또는 제공해야 하는 모든 분석의 시작이 불확실한 경우
테스트 로그를 보유할 수 있습니다.
|
테스트 스위트
|
유용한 서브세트에서 개별 관련 테스트(테스트 스크립트)를 함께 그룹화할 때 사용합니다.
|
대부분의 프로젝트에서 권장됩니다.
테스트를 올바르게 수행할 때 필요한 테스트 스크립트 실행 시퀀스를 정의하는 경우에도 필요합니다.
|
테스트 아이디어 목록
|
이 목록은 수행할 유용한 테스트로 간주되는 아이디어를 나열한 목록입니다(종종 부분적으로 구성됨).
|
대부분의 프로젝트에서 권장됩니다.
때때로 이 목록은 비정규로 정의되어 이 목록에서 테스트 스크립트 또는 테스트 케이스를 정의한 후 버려집니다.
|
테스트 전략
|
하나 이상의 대상 시스템 측면에서 테스트 노력을 수행하는 방법에 대한 전략 계획을 정의합니다.
|
대부분의 프로젝트에서 권장됩니다.
대부분의 경우 프로젝트 또는 프로젝트 내 단계당 단일 테스트 전략이 권장됩니다. 선택적으로 적절한 경우 기존 전략을 재사용할 수 있습니다. 또는 수행할 테스트 유형에 따라 테스트
전략을 추가로 나눌 수 있습니다.
|
테스트 계획
|
반복을 제어하는 테스트 목적, 목표, 동기, 접근 방식, 자원, 스케줄 및 중간 산출물을 더 자세히 정의합니다.
|
대부분의 프로젝트에서 권장됩니다.
세분화된 특정 테스트 전략을 정의하려면 반복당 별도의 테스트 계획이 권장됩니다. 선택적으로 반복 계획의 섹션으로 테스트 계획을 포함할 수 있습니다.
|
테스트 계획
|
전체 라이프사이클 또는 단계를 제어하는 상위 레벨의 테스트 목적, 목표, 접근 방식, 자원, 스케줄 및 중간 산출물을 정의합니다.
|
선택사항입니다. 대부분의 프로젝트에서 유용합니다.
마스터 테스트 계획은 소프트웨어 개발 라이프사이클의 많은 파트에 적용되는 테스트 노력에 대한 상위 레벨 전략을 정의합니다. 선택적으로 소프트웨어 개발 계획의 섹션으로 테스트 계획을 포함할 수 있습니다.
"반복" 테스트 계획 이외에도 "마스터" 테스트 계획을 유지보수할 것인지 고려하십시오. 주로 마스터 테스트 계획은 전체 프로젝트 라이프사이클과 일반적으로 관련된 물류 및 프로세스 규정
정보를 다룹니다.
|
테스트 스크립트, 테스트 데이터
|
테스트 스크립트 및 테스트 데이터는 테스트의 구현 또는 실현(realization)에 해당합니다. 여기서 테스트 스크립트는 프로시저 측면을, 테스트 데이터는 정의 특성을 포괄합니다.
|
대부분의 프로젝트에서 권장됩니다.
프로젝트 간 차이는 이 중간 산출물을 처리하는 정규 방법에서 나타납니다. 때때로 비정규 및 임시적인 경우가 있습니다. 이때 테스트 팀은 다른 기준에 따라 판단을 내립니다. 다른 경우,
특히, 자동화된 테스트를 사용하는 경우 테스트 스크립트 및 연관된 테스트 데이터(또는 그것의 일정한 서브세트)는 테스트 노력의 주요 인도물로 간주됩니다.
|
테스트 케이스
|
테스트 입력, 실행 조건 및 예상 결과의 특정 세트를 정의합니다.
테스트 케이스를 문서화하면 완전성 및 정확성을 검토하고 구현 노력을 계획 및 소모하기 전에 이 사항을 고려할 수 있습니다.
특히 입력, 실행 조건 및 예상 결과가 복잡한 경우 가장 유용합니다.
|
대부분의 프로젝트에서 복잡하거나 광범위한 특정 테스트를 수행해야 하는 경우 테스트 케이스를 정의하는 것이 좋습니다. 또한 계약상 인도물이 필요한 경우 테스트 케이스를 문서화하는
것이 좋습니다.
대부분의 다른 경우 자세한 텍스트 형식의 테스트 케이스 대신 테스트 아이디어 목록 및 구현된 테스트 스크립트를 유지보수하는 것이 좋습니다.
일부 프로젝트는 상위 레벨에서 테스트 케이스의 아웃라인을 단순히 설명하고 테스트 스크립트에 대한 세부사항을 지연합니다. 공통적으로 사용되는 다른 스타일은 테스트 스크립트의
설명으로 테스트 케이스 정보를 문서화하는 것입니다.
|
워크로드 분석 모델
|
테스트 케이스의 특수 유형. 로드 하에서 시스템 운영과 연관된 품질 위험성을 평가할 수 있도록 대표 워크로드를 정의하는 데 사용합니다.
|
대부분의 시스템에서 권장사항입니다. 특히 로드 하에서 시스템 성능을 평가해야 하는 경우 또는 로드 하에서 시스템 오퍼레이션과 연관된 다른 중요한 품질 위험성이 있는 경우에
적합합니다.
일반적으로 독립형 대상 시스템에 배치될 시스템에는 필요하지 않습니다.
|
테스트 용이성 클래스(디자인 모델)
테스트 용이성 요소(구현 모델)
|
프로젝트에서 테스트를 사용자 조정하고 지원하도록 전문화된 중요한 추가 동작을 개발해야 하는 경우 구현 모델의 테스트 용이성 요소 및 디자인 모델의 테스트 용이성 클래스를 포함시켜
문제를 표시합니다.
|
필요한 경우.
스텁은 테스트 클래스 및 테스트 컴포넌트의 공통 카테고리입니다.
|
테스트 자동화 아키텍처
|
시스템의 다른 측면을 보여주기 위해 여러 다른 아키텍처 보기를 사용하여 테스트 자동 시스템의 아키텍처 개요를 제공합니다.
|
선택사항입니다.
테스트 아키텍처가 비교적 복잡한 경우, 자동화된 테스트를 빌드하는 데 많은 직원이 협업하는 경우 또는 장기간 테스트 자동 시스템을 유지보수할 경우 해당 프로젝트에서
권장사항입니다.
때때로 이해 관계자(interested party)들이 상의할 때 집중적으로 기록하는 단순한 화이트보드 다이어그램일 수 있습니다.
|
테스트 인터페이스 스펙
|
클래스류(특히, 클래스, 서브시스템 또는 컴포넌트)에서 테스트 목적(테스트 용이성)으로 필수 동작 세트를 정의합니다. 공통 유형으로 테스트 액세스, 스텁 동작, 진단 로깅 및
테스트 선언이 있습니다.
|
선택사항입니다.
대부분 프로젝트의 클래스, 사용자 인터페이스 등에서 표시되는 오퍼레이션에는 테스트에서 사용할 액세스 가능성이 충분히 들어 있습니다.
테스트 인터페이스 스펙을 작성하는 일부 공통 이유는 UI 확장을 통해, 특히 배치 프로세스에서 도구 및 진단 메세지 로깅 루틴과 GUI 테스트 도구가 상호작용할 수 있도록 하기
위해서입니다.
|
이 섹션에서는 중간 산출물 테스트를 검토하는 방법을 결정하는 데 도움이 되는 가이드라인을 제공합니다. 일반 가이드라인은 가이드라인: 검토 레벨을
참조하십시오.
결함
결함 검토 처리 방식은 컨텍스트에 따라 크게 다릅니다. 그러나 일반적으로 비정규, 정규-내부 또는 정규-외부로 처리됩니다. 종종 결함 추적 시스템의 워크플로우 관리를 통해 이
검토 프로세스가 강조되거나 최소한 지원되고 있습니다. 일반 설명으로, 검토 정규 레벨은 종종 결함의 인지된 심각도 또는 영향과 관련이 있습니다. 그러나 프로젝트 환경 및 의식(ceremony) 레벨과 같은 요소는
종종 검토 처리 방식의 선택사항에 영향을 줍니다.
결함(증상 또는 실패로도 알려짐) 처리를 오류(실제 오류 소스)에서 분리하는 방법을 고려해야 하는 경우도 있습니다. 작은 프로젝트에서는 보통 결함만 추적하여 관리하고 내재적으로 오류를 처리할 수 있습니다. 그러나
시스템의 복잡도가 증가하면 오류에서 결함 관리를 분리하는 것이 좋습니다. 예를 들어 동일한 오류에서 여러 가지 결함이 나타날 수 있습니다. 따라서 오류를 수정하면 보고된 결함을 찾고 결함을 제출한 사용자에게 이
사실을 알려야 합니다. 결함 및 오류가 별도로 식별될 수 있는 경우에만 가능합니다.
테스트 계획 및 테스트 전략
테스트가 중요한 모든 프로젝트에서는 일부 테스트 계획 또는 전략 양식이 필요합니다. 일반적으로 테스트 전략을 제어하는 몇 가지 양식 및 모든 반복에 테스트 계획이 필요합니다. 선택적으로 마스터 테스트 계획을 작성
및 유지보수할 수 있습니다. 대부분 이 중간 산출물은 비정규로 검토됩니다. 즉 검토는 되지만 정규로 승인되지 않습니다. 가시성 테스트가 테스트팀의 외부에 있는 이해 당사자에게 중요한 경우
정규-내부 또는 정규-외부로 처리해야 합니다.
테스트 스크립트
일반적으로 테스트 스크립트는 비정규로 처리됩니다. 즉, 테스트팀 내부 구성원에 의해 승인됩니다. 많은 테스터가 테스트 스크립트를 사용하고 다른 많은 테스트에서 테스트 스크립트가 공유되거나 재사용되는
경우 정규-외부로 처리해야 합니다.
테스트 케이스
테스트 케이스는 테스트 팀에서 작성됩니다. 컨텍스트에 따라 보통 테스트 케이스는 비정규 프로세스로 검토되거나 전혀 검토되지 않을 수도 있습니다. 상황에 따라 정규-내부로 처리할 수 있는
경우 테스트 케이스는 다른 팀 구성원이 승인할 수도 있습니다. 또는 정규-외부인 경우 외부 이해 당사자가 승인합니다.
일반적인 방법으로, 필요한 테스트 케이스를 공식적으로 검토하는 것이 좋습니다. 일반적으로 가장 중요한 테스트 케이스를 표시하는 작은 서브세트로 제한됩니다. 예를 들어 고객이 제품 릴리스 전에 제품의 유효성을
검증하려는 경우 몇 가지 테스트 케이스 서브세트를 해당 유효성 검증의 기초로 선택할 수 있습니다. 이 테스트 케이스는 정규-외부로 처리되어야 합니다.
테스트 중간 산출물(디자인 및 구현)
테스트 용이성 클래스는 디자인 모델에 있으며 테스트 용이성 요소는 구현 모델에 있습니다. 또한 (테스트에 특정하지 않지만) 서로 다른 두 개의 관련 중간 산출물이 있습니다. 디자인 모델의 패키지와 구현 모델의
서브시스템이 이에 해당합니다.
이 중간 산출물은 디자인 및 구현 중간 산출물입니다. 그러나 소프트웨어에서 테스트 기능을 지원하기 위해 작성되었습니다. 이 두 항목의 원래 보관 위치는 디자인 및 구현 중간 산출물 내부입니다. 이름 지정을
명심하십시오. 그렇지 않으면 코어 시스템의 디자인 및 구현에서 명확히 구별할 수 있는 방식으로 레이블을 지정하십시오. 디자인 및 구현 중간 산출물의 검토 프로시저에 따라 이 중간 산출물을 검토하십시오.
각 반복을 입력하는 경우 먼저 테스트 노력이 충분한지 판단하는 방법 및 판단을 내리는 기준을 명확히 정의하도록 노력하십시오. 승인 결정에 책임이 있는 개인 또는 그룹과 논의하여 정의하십시오.
다음은 반복 승인을 처리하는 방법에 대한 예제입니다.
-
프로젝트 관리 팀은 테스트 평가 요약을 검토하여 반복을 승인하고 테스트 노력을 평가합니다.
-
고객은 테스트 평가 요약을 검토하여 반복을 승인합니다.
-
고객은 총 테스트의 특정 서브세트를 활용하는 설명에 기반하여 반복을 승인합니다. 이 테스트의 서브세트는 미리(반복 초반이 바람직함) 정의 및 합의되어야 합니다. 이 테스트는 정규-외부로 처리되고
종종 적합성 테스트라고 합니다.
-
고객은 독립적인 테스트를 수행하여 시스템 품질을 승인합니다. 다시 이 테스트의 특성은 미리(반복 초반이 바람직함) 정의 및 합의되어야 합니다. 이 테스트는 정규-외부로 처리되고 종종 적합성
테스트라고 합니다.
중요한 결정입니다. 이 내용을 알지 못하면 목적을 달성할 수 없습니다.
|