예어
구성 관리, 결함 관리, 결함 보고서, 진입 기준, 종료 기준, 제품 위험, 프로젝트 위험, 위험 위험, 위험 수준, 위험 기반 테스트, 테스트 접근 방식, 테스트 제어, 테스트 추정, 테스트 관리자, 테스트 테스트 모니터링, 테스트 계획 , 테스트 계획, 테스트 진행 보고서, 테스트 전략, 테스트 요약 보고서, 테스터
5.1 시험 조직
5.1.1 독립 테스트
테스트 작업은 특정 테스트 역할이 지정된 사람이나 다른 역할(예: 고객)의 사람이 수행할 수 있습니다. 작성자와 테스터의 인지 편향이 다르기 때문에(섹션 1.5 참조) 테스터는 어느 정도의 독립성을 통해 버그를 보다 효과적으로 찾을 수 있습니다.
테스트 독립성의 잠재적 이점
- 독립적인 테스터는 다양한 배경, 기술적 관점 및 성향을 가지고 있으며 개발자와는 다른 유형의 버그를 발견할 수 있습니다.
- 독립적인 테스터는 시스템 사양을 정의하고 구현할 때 이해 관계자의 가정을 확인, 도전 및 반박할 수 있습니다.
- 제조업체의 독립적인 테스터는 테스트할 시스템을 사용하는 회사의 (정치적) 압력 없이 직접적이고 객관적으로 보고할 수 있습니다.
테스트 독립성의 가능한 단점
- 개발팀과의 격리는 협업을 어렵게 만들고 개발팀에 대한 피드백 전달을 지연시키며 개발팀과 적대적인 관계를 형성할 수 있습니다.
- 개발자는 품질에 대한 책임을 잃을 수 있습니다.
- 독립 테스터는 병목 현상으로 볼 수 있습니다.
- 독립적인 테스터에게 중요한 정보(예: 테스트 대상에 대한 정보)를 알려주어서는 안 됩니다.
5.1.2 테스트 관리자 및 테스터의 의무
테스트 관리자의 임무는 테스트 프로세스에 대한 전반적인 책임을 지고 테스트 활동을 성공적으로 이끄는 것입니다. 테스트 관리자는 전문 테스트 관리자, 프로젝트 관리자, 개발 관리자 및 품질 보증 관리자의 역할을 맡을 수 있습니다.
일반적으로 테스트 관리자 역할작업은 다음과 같습니다.
- 조직의 테스트 정책 및 테스트 전략 개발 및 검토
- 테스트 목표 및 위험에 대한 컨텍스트 및 이해를 기반으로 테스트 활동을 계획합니다.
예를 들어 계획에는 테스트 접근 방식 선택, 테스트 추정(테스트 시간, 노력, 비용), 리소스 소싱, 테스트 수준 및 테스트 주기 정의, 결함 관리가 포함될 수 있습니다. - 테스트 계획 생성 및 업데이트
- 테스트 계획에 대해 프로젝트 관리자, 제품 소유자 및 기타 이해 관계자와 협의
- 다음과 같은 다른 프로젝트 활동과 테스트 관점 공유 B. 통합 계획
- 테스트 분석, 설계, 구현 및 실행 활동 시작, 테스트 진행 및 결과 모니터링, 종료 조건(또는 종료 조건 정의) 상태 검토 및 테스트 완료 활동 촉진
- 수집된 정보를 기반으로 테스트 진행 보고서 및 테스트 요약 보고서를 생성 및 배포합니다.
- 테스트 결과 및 진행 상황(테스트 진행 보고서 또는 이미 완료된 다른 테스트 프로젝트의 테스트 요약 보고서에 문서화됨)에 따라 계획을 조정하고 필요한 테스트 제어 조치를 취합니다.
- 오류 관리 시스템 및 테스트웨어에 적합한 형상 관리 시스템 구축 지원
- 테스트 진행 상황을 측정하고 제품 품질을 테스트하고 평가하기 위한 적절한 메트릭을 설정합니다.
- 테스트 프로세스를 지원하기 위한 도구 선택 및 구현 지원. 예를 들면 도구 선택을 위한 예산 추천(경우에 따라 취득 및 지원 비용까지 포함), 파일럿 프로젝트에 시간과 노력 할당, 도구 사용에 대한 지속적인 지원 제공 등이 있습니다.
- 테스트 환경 설정에 대한 결정
- 테스터, 테스트 팀 및 테스트 활동에 대한 지원을 위해 조직을 격려하고 간청합니다.
- 테스터의 역량 및 경력 개발(예: 교육 계획, 성과 평가, 코칭 등)
일반적으로 테스터의 역할과 책임다음과 같다:
- 테스트 계획 검토 및 계획 작성에 참여
- 요구 사항, 사용자 사례 및 수용 기준, 사양 및 모델(예: 테스트 기반)의 테스트 가능성을 분석, 확인 및 평가합니다.
- 테스트 조건을 식별 및 기록하고 테스트 사례, 테스트 조건 및 테스트 기준 간의 추적성을 설정합니다.
- 필요에 따라 시스템 관리자 및 네트워크 관리자와 협력하여 테스트 환경을 설계, 구축 및 검증합니다.
- 테스트 케이스 및 테스트 절차 설계 및 구현
- 테스트 데이터 준비 및 수집
- 세부 테스트 실행 계획
- 테스트를 실행하고 예상 결과와의 차이를 기록하여 결과를 평가합니다.
- 테스트 프로세스에 적합한 도구 사용
- 주문형 테스트 자동화(개발자 또는 테스트 자동화 전문가의 도움을 받을 수 있음)
- 성능, 신뢰성, 사용성, 보안성, 호환성, 휴대성 등 비기능적 품질 특성 평가
- 테스트 아티팩트 검토
테스트 분석, 테스트 설계, 특정 테스트 유형 또는 테스트 자동화 작업을 하는 개인은 해당 역할의 전문가일 수 있습니다. 제품 및 프로젝트 위험 또는 선택한 소프트웨어 개발 수명 주기 모델에 따라 테스터의 역할은 각 테스트 수준마다 다를 수 있습니다.
5.2 테스트 계획 및 추정
5.2.1 테스트 계획의 목적 및 내용
테스트 계획에는 개발 및 유지 관리 프로젝트의 테스트 활동에 대한 전반적인 내용이 포함됩니다. 테스트 계획 활동은 제품 수명 주기 전반에 걸쳐 진행되는 활동입니다.
테스트 계획에는 다음과 같은 활동이 있습니다.
- 테스트의 범위, 목적 및 위험 정의
- 전체 테스트 접근 방식 정의
- 테스트 활동을 소프트웨어 라이프사이클 활동과 통합 및 조정
- 테스트할 다양한 테스트 활동에 필요한 인력 및 기타 리소스를 결정하고 테스트 활동을 수행할 방법을 결정합니다.
- 테스트 분석, 설계, 구현, 실행 및 평가 활동 계획. 일정은 특정 날짜(예: 순차적 개발) 또는 반복 단위(예: 반복 개발)를 기준으로 구성할 수 있습니다.
- 테스트 모니터링 및 제어에 사용할 측정항목 선택
- 테스트 활동 예산 결정
- 테스트 문서의 구조 및 세부 수준 결정(예: 템플릿 또는 예제 문서 제공)
5.2.2 테스트 전략 및 테스트 접근 방식
테스트 전략테스트 프로세스의 일반적인 모양을 반영합니다.
- 분석적으로:
- 특정 항목(예: 요구 사항 또는 위험) 분석을 기반으로 하는 테스트 전략입니다.
- 위험 수준에 따라 테스트가 설계되고 우선 순위가 지정되는 위험 기반 테스트는 분석적 접근 방식의 한 예입니다.
- 모델 기반:
- 테스트는 수요가 있는 제품의 특정 측면에 대한 모델을 기반으로 생성됩니다.
- 특정 측면은 기능, 비즈니스 프로세스, 내부 구조 및 비기능적 속성(예: 신뢰성)입니다.
- 모델에는 비즈니스 프로세스 모델, 상태 모델 및 안정성 성장 모델이 포함됩니다.
- 체계적으로:
- 이 테스트 전략은 미리 정의된 테스트 세트 또는 테스트 조건의 체계적인 사용을 기반으로 합니다.
- 공정 준수(또는 표준 준수):
- 테스트 전략은 외부 규정 또는 표준을 기반으로 테스트를 분석, 설계 및 구현합니다.
- 전문가 조언(가이드라인 또는 조언):
- 이 테스트 전략은 주로 이해 관계자, 주제 전문가 및 기술 전문가의 조언, 지침 및 지침을 기반으로 합니다.
- 회귀에 대한 혐오:
- 목표는 기존 함수의 회귀 테스트를 피하는 것입니다.
- 여기에는 기존 테스트웨어(특히 테스트 사례 및 테스트 데이터) 재사용, 회귀 테스트 자동화 확장 및 테스트 스위트 표준화가 포함됩니다.
- 반응성:
- 테스트 중인 구성 요소 또는 시스템에 따라 반응하고 테스트 실행 중에 발생하는 이벤트에 따라 반응적으로 작동하는 테스트 접근 방식입니다.
- 이전 테스트 결과의 통찰력을 기반으로 즉석에서 테스트를 설계, 구현 및 실행합니다. 탐색적 테스트는 반응 전략에서 일반적으로 사용되는 기술입니다.
테스트 전략은 테스트 프로세스의 종합 및 개요인 반면 테스트 접근 방식은 특정 프로젝트 또는 릴리스에 대한 테스트 전략의 적응입니다.
테스트 접근법테스트 기술, 테스트 수준 및 테스트 유형을 선택하고 시작 및 종료 조건을 정의하기 위한 시작점입니다(시작 및 종료 조건은 준비 정의 및 완료 정의라고도 함).
테스트 접근 방식은 위험, 보안 고려 사항, 사용 가능한 리소스 및 기술, 기술, 시스템 특성(예: 맞춤형 개발 대 상용 소프트웨어), 테스트 목표 및 규정과 같은 요소를 고려하여 상황에 따라 선택됩니다.
5.2.3 시작 및 종료 조건(준비의 정의 및 종료의 정의)
진입 기준 및 종료 기준(준비의 정의 및 완료의 정의)
소프트웨어 품질 및 테스트를 효과적으로 제어하려면 특정 테스트 활동의 시작 및 완료 조건을 정의하는 것이 좋습니다.
보통 초기 상태다음과 같다:
- 테스트 가능한 요구 사항, 사용자 스토리 또는 모델의 가용성(예: 모델 기반 테스트 전략을 추구하는 경우)
- 이전 테스트 수준의 종료 조건을 충족한 테스트 항목의 가용성
- 테스트 환경의 가용성
- 필요한 테스트 도구의 가용성
- 테스트 데이터 및 기타 필수 리소스의 가용성
보통 최종 상태다음과 같다:
- 예정된 시운전 완료
- 정의된 적용 범위 달성(예: 요구 사항, 사용자 스토리, 수용 조건, 위험, 코드 등)
- 수정되지 않은 결함의 수가 합의된 수보다 적습니다.
- 추정된 잔차 오차의 수가 충분히 작습니다.
- 신뢰성, 전력 효율성, 사용 용이성, 보안 및 기타 관련 품질 특성의 수준이 원하는 수준에 도달합니다.
5.2.4 테스트 실행 일정
테스트 사례 및 테스트 절차(일부는 가능한 경우 자동화할 수 있음)를 작성하고 테스트 절차와 테스트 사례를 결합하여 테스트 스위트를 생성한 다음 테스트 스위트의 순서를 지정하여 실행 일정을 생성할 수 있습니다.
테스트 실행 일정을 만들 때 우선 순위, 종속성, 유효성 검사 테스트, 회귀 테스트 및 가장 효율적인 테스트 실행 순서를 고려하십시오.
테스트 케이스가 서로 종속되어 있으면 우선 순위에 관계없이 필요에 따라 배치해야 합니다. 확인 및 회귀 테스트도 개정에 대한 피드백의 중요성에 따라 우선 순위를 지정해야 하며 여기에도 종속성을 적용할 수 있습니다.
5.2.5 테스트 노력에 영향을 미치는 요인
테스트 노력 추정은 주어진 프로젝트, 릴리스 또는 반복 주기에서 테스트 목표를 달성하는 데 필요한 테스트 관련 작업에 필요한 노력을 추정하는 활동입니다.
테스트 노력에 영향을 미치는 요인은 다음과 같습니다.
- 제품 속성
- 개발 프로세스의 특징
- 사람들의 특성
- 시험 결과
5.2.6 테스트 추정 기법
충분한 테스트를 수행하는 데 필요한 노력을 추정하기 위한 몇 가지 예측 기술이 있습니다.
- 메트릭 기반 기술
- 기존 유사한 프로젝트의 메트릭 또는 공통 값을 기반으로 하는 테스트 노력 예측
- 전문가 기반 기법
- 테스트 작업의 담당자 또는 전문가의 경험을 기반으로 테스트 노력 추정
5.3 테스트 모니터링 및 제어
테스트 모니터링그 목적은 정보를 수집하고 테스트 활동에 대한 피드백과 통찰력을 제공하는 것입니다. 모니터링할 정보는 수동 또는 자동으로 수집할 수 있으며 테스트 진행 상황을 평가하는 데 사용됩니다.
테스트 컨트롤수집 및 보고된 정보 및 지표의 결과로 취해진 모든 시정 조치 또는 지침을 의미합니다.
5.3.1 테스트에 사용되는 메트릭
다음을 평가하기 위해 테스트 활동 중 또는 종료 시 메트릭을 수집할 수 있습니다.
- 계획된 일정 및 진행 대 예산
- 테스트 개체의 현재 품질
- 테스트 접근 방식의 유효성
- 목적에 대한 테스트 활동의 영향
보통 테스트 메트릭다음과 같다:
- 테스트 케이스 준비 작업 대 계획의 완료율(또는 테스트 케이스 작성 비율 대 계획)
- 계획 대비 테스트 환경 준비 작업 완료율
- 테스트 사례 실행률(예: 수행/실패한 테스트 사례 수, 통과/실패한 테스트 사례 수, 통과/실패한 테스트 조건 수)
- 오류 정보(예: 오류 밀도, 발견된 오류, 수정된 오류, 실패율, 검증 테스트 결과)
- 요구사항 커버리지, 사용자 스토리 커버리지, 수락 기준 커버리지, 위험 커버리지, 코드 커버리지
- 작업 완료, 리소스 할당 및 사용, 노력
- 다음 버그를 찾는 비용 효율성 또는 테스트를 계속하는 비용 효율성을 포함하는 테스트 비용.
5.3.2 테스트 보고서의 목적, 내용 및 대상
테스트 보고의 목적은 테스트 활동 중 또는 테스트 활동(예: 테스트 수준) 및 마지막에 테스트 활동 정보를 요약하고 공유하는 것입니다.
테스트 활동 중에 생성된 테스트 보고서는 테스트 진행 보고서,
테스트 활동이 끝나면 테스트 보고서가 있습니다. 요약 테스트 보고서이라고도 불리는
테스트 진행 보고서
- 테스트 계획에 대한 테스트 활동 및 진행 상황
- 진행을 방해하는 요인
- 다음 보고 기간에 예정된 테스트
- 테스트 개체의 품질
요약 테스트 보고서
- 테스트 성능 요약
- 테스트 기간 동안 일어난 일에 대한 정보
- 계획과의 편차(예: 일정, 기간, 테스트 활동 노력)
- 종료 조건 및 완료 정의에 대한 테스트 상태 및 제품 품질
- 진행을 방해했거나 계속 방해하는 요인
- 지표(버그, 테스트 사례, 테스트 범위, 활동 진행률, 5.3.1에 설명된 대로 소비된 리소스)
- 잔여 위험(섹션 5.5 참조)
- 재사용 가능한(제조된) 테스트 작업 제품
5.4 구성 관리
구성 관리의 목적은 구성 요소, 시스템 및 테스트웨어의 무결성과 프로젝트 및 제품 수명 주기 전반에 걸쳐 상호 관계를 설정하고 유지하는 것입니다.
구성 관리는 테스트를 적절하게 지원하기 위해 다음을 확인합니다.
- 모든 테스트 개체에 고유 식별 번호를 할당하고 버전을 관리하며 변경 이력을 기록합니다. 구성 관리에서 테스트 개체는 서로 관련되어 있습니다.
- 모든 테스트웨어 항목에는 고유 식별 번호가 부여되고 버전이 관리되며 변경 사항이 추적되고 테스트 항목 버전에 연결되어 테스트 프로세스 전반에 걸쳐 추적 가능성이 유지됩니다.
- 식별된 모든 문서 및 소프트웨어 요소는 테스트 문서 내에서 명확하게 상호 참조됩니다.
테스트 계획이 개발되면 구성 관리 절차 및 인프라(도구)를 식별하고 구현해야 합니다.
5.5 위험 및 테스트
5.5.1 위험 정의
위험은 미래에 부정적인 결과를 가져올 사건의 확률입니다. 위험 수준은 이벤트 발생 확률과 이벤트로 인한 영향(손상)의 크기에 따라 결정됩니다.
5.5.2 제품 및 프로젝트 위험
제품 위험작업 제품(예: 사양, 구성 요소, 시스템, 테스트 등)이 사용자 또는 이해 관계자의 정당한 요구를 충족하지 못할 가능성입니다. 제품 위험은 제품의 특정 품질 특성(예: 기능적 안전성, 신뢰성, 성능, 유용성, 안전성, 호환성, 유지보수성, 휴대성)과 관련될 때 품질 위험이라고 합니다.
- 소프트웨어가 사양에서 의도한 기능을 수행하지 않습니다.
- 특정 상황에서 특정 계산이 올바르게 수행되지 않습니다.
- 루프 제어 구조의 잘못된 코딩
- 강력한 트랜잭션 처리 시스템의 응답 시간이 충분하지 않습니다.
- 사용자 경험(UX, User eXperience) 피드백이 제품 기대치를 충족하지 못함
프로젝트 위험발생하는 경우 프로젝트 목표를 달성하는 능력에 영향을 미칠 수 있는 상황입니다.
- 프로젝트 문제
- 릴리스, 주문 완료 또는 취소 조건이 충족되지 않거나 완료 정의가 지연됩니다.
- 예산 격차는 부정확한 추정, 우선 순위가 높은 프로젝트에 대한 예산 재할당 또는 조직 전체의 예산 삭감으로 인해 발생할 수 있습니다.
- 프로젝트 후반에 발생하는 변경 사항으로 인해 상당한 재작업이 발생할 수 있습니다.
- 조직 문제
- 정치적 문제
- 기술적 문제
- 요구 사항이 잘 정의되어 있지 않을 수 있습니다.
- 필요할 때 테스트 환경이 준비되지 않을 수 있습니다.
- 공급자 문제
5.5.3 위험 기반 테스트 및 제품 품질
위험은 테스트 노력에 집중하는 데 사용됩니다. 위험은 언제 어디서 테스트를 시작할지 결정하고 더 많은 주의가 필요한 영역을 식별하는 데 사용됩니다.
위험 기반 테스트에는 제품 위험을 식별하고 제품 위험을 분석하여 위험 가능성과 영향을 평가하는 작업이 포함됩니다.
초기 제품 위험 평가는 프로젝트의 성공에 기여합니다.
5.6 결함 관리
테스트의 목적 중 하나가 버그를 찾는 것이므로 테스트 중에 발견된 버그를 문서화하는 것이 중요합니다.
발견된 버그는 발견에서 버그 분류까지 조사하고 추적해야 합니다(예: 버그 수정 및 버그 수정 확인 테스트 완료, 다음 릴리스로 이동, 영구적인 제품 제한으로 인식 등).
해결, 조직에 대한 모든 결함 관리 불량관리 프로세스(워크플로 및 오류 분류 규칙)이 정의됩니다. 일반적인 버그 보고서의 목적은 다음과 같습니다.
- 특정 영향을 식별하고, 재테스트를 통해 문제를 격리하고, 잠재적인 버그를 해결하고, 필요한 경우 문제를 해결할 다른 방법을 찾기 위해 발생한 부작용에 대한 정보를 개발자 및 기타 이해 관계자에게 제공합니다.
- 테스트 관리자에게 작업 산출물의 품질과 테스트의 영향을 추적할 수 있는 기능을 제공합니다.
(예: 많은 버그를 보고하면 테스터가 테스트를 실행하는 데 시간을 소비하는 대신 버그를 보고하는 데 더 많은 시간을 할애해야 하며 필요한 확인 테스트의 양이 증가합니다.) - 개발 및 테스트 프로세스를 개선하기 위한 아이디어를 제공합니다.
버그 관리 도구를 사용하면 버그 보고서 내용의 일부를 자동으로 생성할 수 있습니다.