위험 기반 테스트: 접근 방식, 매트릭스, 프로세스 및 예
위험 기반 테스트
위험 기반 테스트(RBT) 위험의 확률에 기반한 소프트웨어 테스트 유형입니다. 여기에는 소프트웨어 복잡성, 비즈니스의 중요성, 사용 빈도, 가능한 영역 등을 기반으로 위험을 평가하는 것이 포함됩니다. 결함 등. 위험 기반 테스트는 더 영향력이 있고 결함이 있을 가능성이 있는 소프트웨어 응용 프로그램의 기능을 테스트하는 데 우선 순위를 둡니다.
위험은 프로젝트의 측정 가능한 성공 기준에 긍정적 또는 부정적인 영향을 미치는 불확실한 사건의 발생입니다. 그것은 과거에 일어났던 사건일 수도 있고, 현재 일어난 사건일 수도 있고, 미래에 일어날 수 있는 사건일 수도 있습니다. 이러한 불확실한 사건은 프로젝트의 비용, 비즈니스, 기술 및 품질 목표에 영향을 미칠 수 있습니다.
위험은 긍정적일 수도 있고 부정적일 수도 있습니다.
- 긍정적인 위험 비즈니스 지속 가능성에 대한 기회이자 도움이라고 합니다. 예를 들어 새 프로젝트 투자, 비즈니스 프로세스 변경, 신제품 개발 등이 있습니다.
- 부정적인 위험 프로젝트 성공을 위해서는 위협을 최소화하거나 제거하기 위한 권장 사항을 구현해야 합니다.
위험 기반 테스트를 구현해야 하는 경우
위험 기반 테스트는 다음에서 구현될 수 있습니다.
- 시간, 자원, 예산 등의 제약이 있는 프로젝트
- 위험 기반 분석을 사용하여 취약점을 탐지할 수 있는 프로젝트 SQL 주입 공격.
- 클라우드 컴퓨팅 환경의 보안 테스트.
- 사용된 기술에 대한 경험 부족, 비즈니스 도메인 지식 부족 등 위험 요소가 높은 신규 프로젝트.
- 증분 및 반복 모델 등
리스크 관리 프로세스
이제 위험 관리 프로세스와 관련된 단계를 이해해 보겠습니다.
위험 식별
위험 식별은 위험 워크숍, 체크리스트, 브레인스토밍, 인터뷰, 델파이 기법, 원인 및 결과 다이어그램, 이전 프로젝트에서 얻은 교훈, 근본 원인 분석, 도메인 전문가 및 주제 전문가와의 접촉을 통해 이루어질 수 있습니다.
위험 등록 식별된 위험, 잠재적 대응 및 근본 원인 목록이 포함된 스프레드시트입니다. 이는 프로젝트 기간 동안 위험(위협과 기회 모두)을 모니터링하고 추적하는 데 사용됩니다. 위험 대응 전략은 긍정적인 위험과 부정적인 위험을 관리하는 데 사용될 수 있습니다.
위험 분석 구조는 위험 계획에서 중요한 역할을 합니다. 위험 분석 구조는 위험이 발생하기 쉬운 영역을 식별하는 데 도움이 되며 프로젝트 과정에서 효과적인 평가 및 위험 모니터링에 도움이 됩니다. 이는 위험 관리 활동에 충분한 시간과 자원을 제공하는 데 도움이 됩니다. 또한 프로젝트 위험이 발생할 수 있는 다양한 소스를 분류하는 데 도움이 됩니다.
위험 분석 구조 샘플
위험 분석(정량적, 정성적 분석 포함)
잠재적 위험 목록이 식별되면 다음 단계는 이를 분석하고 중요성에 따라 위험을 필터링하는 것입니다. 정성적 위험 분석 기술 중 하나는 위험 매트릭스(다음 섹션에서 다룸)를 사용하는 것입니다. 이 기술은 위험의 확률과 영향을 결정하는 데 사용됩니다.
리스크 대응 계획
분석을 바탕으로 위험에 대응이 필요한지 결정할 수 있습니다. 예를 들어, 일부 위험은 프로젝트 계획에서 응답이 필요한 반면 일부 위험은 프로젝트 모니터링에서 응답이 필요하며 일부 위험은 전혀 응답이 필요하지 않습니다.
위험 소유자는 할당된 위험의 가능성과 영향을 줄이기 위한 옵션을 식별할 책임이 있습니다.
위험 완화 가능한 위협의 부정적인 영향을 줄이기 위해 사용되는 위험 대응 방법입니다. 이는 위험을 제거하거나 허용 가능한 수준으로 줄임으로써 수행될 수 있습니다.
비상 위험
우발상황은 불확실한 사건의 가능성으로 설명될 수 있지만 그 영향은 알려지지 않았거나 예측할 수 없습니다. 비상 계획은 최악의 시나리오에 대한 조치 계획/백업 계획이라고도 합니다. 즉, 예측할 수 없는 사건이 발생했을 때 어떤 조치를 취할 수 있는지를 결정합니다.
위험 모니터링 및 제어
위험 통제 및 모니터링 프로세스는 식별된 위험 추적, 잔여 위험 모니터링, 새로운 위험 식별, 위험 등록 업데이트, 변경 이유 분석, 위험 대응 계획 실행 및 위험 유발 요인 모니터링 등을 수행하는 데 사용됩니다. 위험 감소 효과를 평가합니다. .
이는 위험 재평가, 위험 감사, 차이 및 추세 분석, 기술 성과 측정, 상태 업데이트 회의 및 회고 회의를 통해 달성할 수 있습니다.
아래 표는 에 대한 정보를 제공합니다.
위험 모니터링 및 통제에 대한 입력 | 위험 모니터링 및 제어를 위한 도구 및 기술 | 위험 모니터링 및 통제의 결과 |
---|---|---|
리스크 관리 계획 | 프로젝트 위험 대응 감사 | 해결 계획 |
리스크 대응 계획 | 정기적인 프로젝트 위험 검토 | 시정 조치 |
프로젝트 커뮤니케이션 계획 | 수익가치 분석 | 프로젝트 변경 요청 |
추가 위험 식별 및 분석 | 기술적 성능 측정 | 위험 대응 계획 및 위험 식별 체크리스트 업데이트 |
범위 변경 | 추가 위험 대응 계획 | 위험 데이터베이스 |
기술의 변화, 프로젝트 규모, 프로젝트 기간(프로젝트 기간 연장), 후원 기관 수, 프로젝트 견적, 노력 및 적절한 기술 부족에 따라 위험이 증가한다는 점을 기억해야 합니다.
위험 기반 테스트 접근 방식
- 요구 사항을 분석합니다.
- 문서(SRS, FRS, Usecases)가 검토됩니다. 이 활동은 오류와 모호성을 찾아서 제거하기 위해 수행됩니다.
- 요구 사항 승인은 프로젝트에 늦은 변경 사항이 도입되는 것을 방지하기 위한 위험 감소 기술 중 하나입니다. 문서의 기준을 정한 후 요구 사항을 변경하려면 변경 제어 프로세스와 후속 승인이 필요합니다.
- 정의된 기준(비용, 일정, 리소스, 범위, 기술적 성능, 안전성, 신뢰성, 복잡성 등)을 고려하여 각 요구 사항이 프로젝트에 미칠 수 있는 가능성과 영향을 계산하여 위험을 평가합니다.
- 실패 가능성과 위험도가 높은 영역을 식별합니다. 이는 위험 평가 매트릭스를 사용하여 수행할 수 있습니다.
- 식별된 위험 세트를 나열하려면 위험 등록부를 사용하십시오. 정기적으로 위험을 업데이트, 모니터링 및 추적합니다.
- 위험 수용력과 위험 허용 수준을 이해하려면 이 단계에서 위험 프로파일링을 수행해야 합니다.
- 등급에 따라 요구 사항의 우선 순위를 지정합니다.
- 위험 기반 테스트 프로세스가 정의됩니다.
- 완화 계획, 구현, 진행 상황 모니터링을 위해 매우 중요하고 중간 정도의 위험을 고려할 수 있습니다. 낮은 위험은 감시 목록에서 고려될 수 있습니다.
- 데이터의 품질을 분석하기 위해 위험 데이터 품질 평가가 수행됩니다.
- 등급에 따라 테스트를 계획하고 정의합니다.
- 적절한 테스트 접근 방식과 테스트 설계 기법을 적용하여 위험도가 가장 높은 항목을 먼저 테스트하는 방식으로 테스트 케이스를 설계합니다. 고위험 항목은 해당 분야 지식 경험이 풍부한 리소스를 통해 테스트할 수 있습니다.
- 예를 들어 고위험 테스트 항목에 대한 의사결정 테이블 기술을 사용하고 저위험 테스트 항목에 대해 '유일한' 등가 분할을 사용하는 등 다양한 테스트 설계 기술을 사용할 수 있습니다.
- 테스트 케이스는 또한 다양한 기능과 엔드투엔드 비즈니스 시나리오를 포괄하도록 설계되었습니다.
- 테스트 데이터와 테스트 조건, 테스트베드를 준비합니다.
- Rev테스트 계획, 테스트 전략, 테스트 케이스, 테스트 보고서 또는 테스트 팀이 작성한 기타 문서를 살펴보십시오.
- 동료 검토는 결함 식별 및 위험 감소에 있어 중요한 단계입니다.
- 결과에 대한 테스트 실행 및 품질 검사를 수행합니다.
- 위험 항목의 우선순위에 따라 테스트 케이스가 실행됩니다.
- 위험 항목, 이를 다루는 테스트, 해당 테스트 결과, 테스트 중에 발견된 결함 간의 추적성을 유지합니다. 올바르게 실행되는 모든 테스트 전략은 품질 위험을 줄여줍니다.
- 위험 기반 테스트는 구성 요소, 통합, 시스템 및 승인 테스트 등 모든 테스트 수준에서 사용할 수 있습니다.
- 시스템 수준에서는 애플리케이션에서 가장 중요한 것이 무엇인지에 집중해야 합니다. 이는 기능의 가시성, 사용 빈도 및 가능한 실패 비용을 살펴봄으로써 결정할 수 있습니다.
- 종료 기준 평가. 모든 고위험 영역은 완벽하게 테스트되었으며 사소한 잔여 위험만 남아 있습니다.
- 위험 기반 테스트 결과 보고 및 지표 분석.
- 핵심 위험 지표를 기반으로 기존 위험 이벤트와 새로운 위험 이벤트를 재평가합니다.
- 위험 등록 업데이트.
- 비상 계획 - 이는 높은 노출 위험에 대한 대체 계획/비상 계획으로 작동합니다.
- 결함을 제거하기 위한 결함 분석 및 결함 예방.
- 사전 계산된 위험 분석 및 고위험 영역을 기반으로 결함 수정을 검증하기 위한 재테스트 및 회귀 테스트가 가장 집중적으로 다루어져야 합니다.
- 위험 기반 자동화 테스트(가능한 경우)
- 잔여 위험 계산
- 위험 모니터링 및 제어
- 다양한 위험 수준에 대해 종료 기준 또는 완료 기준을 사용할 수 있습니다. 모든 주요 위험은 적절한 조치 또는 비상 계획을 통해 해결되었습니다. 위험 노출은 프로젝트에 허용되는 것으로 합의된 수준 이하입니다.
- 위험 프로파일링 재평가 및 고객 피드백.
시스템 테스트에 대한 위험 기반 테스트 접근 방식
- 기술 시스템 테스트 – 이를 환경 테스트, 통합 테스트라고 합니다. 환경 테스트에는 개발 환경, 테스트 환경, 프로덕션 환경에서의 테스트가 포함됩니다.
- 기능 시스템 테스트– 모든 기능, 특징, 프로그램, 모듈을 테스트합니다. 이 테스트의 목적은 시스템이 지정된 요구 사항을 충족하는지 평가하는 것입니다.
- 비기능적 시스템 테스트- 비기능적 요구 사항 성능 테스트, 부하 테스트, 스트레스 테스트, 구성 테스트, 보안 테스트, 백업 및 복구 절차와 문서화(시스템, 운영 및 설치 문서)를 테스트합니다.
아래 다이어그램은 위에서 언급한 프로세스에 대한 명확한 개요를 제공합니다.
시스템 테스트에는 기능 테스트와 비기능 테스트가 모두 포함됩니다.
기능 테스트는 제품/애플리케이션이 고객 및 비즈니스 요구 사항을 충족하는지 확인합니다. 반면, 비기능 테스트는 제품이 품질, 신뢰성, 사용성, 성능, 호환성 등의 측면에서 고객의 기대에 부응하는지 확인하기 위해 수행됩니다.
위험 기반 테스트 수행 방법: 전체 프로세스
이 섹션에서는 위험 기반 테스트 프로세스를 다룹니다.
- 위험 식별
- 위험 분석
- 리스크 대응
- 테스트 범위 지정
- 테스트 프로세스 정의
- 이 프로세스에서는 위험을 식별 및 분류하고, 위험 목록 초안을 작성하고, 중요한 위험을 식별하기 위해 위험 분류를 수행합니다.
- 위험 대응에는 위험으로부터 테스트 목표를 공식화하고 테스트 목표를 충족하기 위한 테스트 활동/테스트 기술을 입증하기 위한 적절한 기술을 선택하는 것이 포함됩니다.
- 문서 종속성, 요구 사항, 비용, 소프트웨어 테스트에 필요한 시간 등을 고려하여 테스트 효과 점수를 계산합니다.
- 테스트 범위 지정은 모든 이해관계자와 기술 직원의 참여가 필요한 검토 활동입니다. 합의된 위험 범위를 준수하는 것이 중요합니다. 이러한 위험은 테스트를 통해 해결되어야 하며 모든 구성원은 자신에게 할당된 책임과 이러한 활동에 할당된 예산에 동의합니다.
- 테스트 범위가 확정된 후 각 테스트 단계에 대한 테스트 목표, 가정, 종속성을 표준 형식으로 컴파일해야 합니다.
기능적 요구사항 F1, F2, F3 및 비기능적 요구사항 N1 및 N2를 고려해 보겠습니다.
F1-기능적 요구 사항, F1과 관련된 R1-위험
- 테스트 목표 1 - 시스템의 예상 기능이 제대로 작동하고 위험 R1이 기능 테스트를 통해 해결될 수 있음을 테스트를 사용하여 시연합니다.
- Test - 브라우저 페이지 테스트는 중요한 사용자 작업을 실행하고 R1(F1과 관련된 위험)이 다양한 시나리오에서 해결될 수 있는지 확인하기 위해 수행됩니다.
F2-기능적 요구 사항, F2과 관련된 R2-위험
- 테스트 목표 2 - 다음을 사용하여 시연합니다. Test 시스템의 예상되는 기능이 제대로 작동하고 위험 R2가 기능 테스트를 통해 해결될 수 있는지
- Test - 중요한 사용자 작업을 실행하고 다양한 시나리오에서 R2가 해결될 수 있는지 확인하기 위해 브라우저 페이지 테스트가 수행됩니다.
F3-기능적 요구 사항, F3과 관련된 R3-위험
- 테스트 목표 3 - 다음을 사용하여 시연합니다. Test 시스템의 예상되는 기능이 제대로 작동하고 위험 R3가 기능 테스트를 통해 해결될 수 있는지
- Test - 브라우저 페이지 테스트는 중요한 사용자 작업을 실행하고 R3가 다양한 시나리오에서 해결될 수 있는지 확인하기 위해 수행됩니다.
N1- 비기능적 요구 사항, N1과 관련된 NR1-위험
- 테스트 목표 N1 - 다음을 사용하여 시연합니다. Test 시스템의 운영 특성이 정상적으로 작동하고 위험 NR1은 비기능 테스트를 통해 해결할 수 있습니다.
- Test -사용성 테스트는 사용자 인터페이스가 얼마나 쉬운지 평가하고 사용성 테스트를 통해 NR1을 해결할 수 있는지 확인하는 데 사용되는 기술입니다.
N2- 비기능적 요구 사항, N2과 관련된 NR2-위험
- 테스트 목표 N.2 - 테스트를 사용하여 시스템의 운영 특성이 정상적으로 작동하고 위험 NR2가 비기능 테스트를 통해 해결될 수 있음을 입증합니다.
- 테스트-보안 테스트는 애플리케이션이 보안되는지, 공격에 취약한지, 정보 유출이 있는지 확인하고 보안 테스트를 통해 NR2를 해결할 수 있는지 확인하는 기술입니다.
특정 테스트 목표: 나열된 위험 및 테스트 목표는 테스트 유형에 따라 다릅니다.
위험 기반 테스트 프로세스를 설계하는 절차
- 위험 등록부를 준비합니다. 일반 위험 목록, 기존 체크리스트, 브레인스토밍 세션에서 파생된 위험을 기록합니다.
- 시스템 기능 및 비기능 요구사항(사용성, 보안, 성능)과 관련된 위험을 포함합니다.
- 각 위험에는 고유 식별자가 할당됩니다.
열 번호 | 열 제목 | 상품 설명 |
---|---|---|
3 | 있을 법한 일 | 시스템이 이러한 실패 모드에 취약할 가능성 |
4 | 결과 | 이 실패 모드의 영향 |
5 | 노출 시간 | 확률과 결과의 곱(3&4열) |
6 | 테스트 효과 | 테스터는 이 위험을 해결할 수 있다고 얼마나 확신합니까? |
7 | 테스트 우선순위 번호 | 확률, 결과 및 테스트 효율성의 곱(3,4 6열) |
8 | 테스트 목표 | 이 위험을 해결하기 위해 어떤 테스트 목표를 사용할 것인가 |
9 | 테스트 기술 | 어떤 방법이나 기법을 사용하는가? |
10 | 종속성 | 테스터는 무엇을 가정하고 의존합니까? |
11 | 노력 | 이 테스트에는 얼마나 많은 노력이 필요합니까? |
12 | 시간대 | 이 테스트를 수행하는 데 얼마나 많은 시간이 필요합니까? |
13 | 테스트 단계 A-유닛 테스트테스트 단계 B-통합 테스트테스트 단계 C-시스템 테스트 | 이 활동을 수행하는 사람 또는 그룹의 이름 |
각 위험의 확률(1 낮음 -5 높음)과 결과(1 낮음 -5 높음)를 평가합니다.
- 테스트 노출이 계산됩니다.
- 테스터는 각 위험을 분석하고 위험이 테스트 가능한지 여부를 평가합니다.
- 테스트 가능한 위험에 대해 테스트 목표가 정의됩니다.
- 테스터는 테스트 목표를 달성하기 위해 계획된 방식으로 수행되어야 하는 테스트 활동(정적 검토, 검사, 시스템 테스트, 통합 테스트, 승인 테스트, HTML 유효성 검사, 현지화 테스트 등)을 지정합니다.
- 이러한 테스트 활동은 여러 단계로 분류될 수 있습니다(구성 요소 테스트/단위 테스트, 통합 테스트, 시스템 테스트, 승인 테스트)
- 때때로 위험은 하나 이상의 테스트 단계에서 해결될 수 있습니다.
- 종속성 및 가정 식별(기술, 도구, 테스트 환경, 리소스의 가용성)
- 테스트 효율성이 계산됩니다. 테스트 효과는 테스트를 통해 위험이 확실하게 해결될 것이라는 테스터의 신뢰 수준과 관련됩니다. 테스트 유효성 점수는 5에서 1 사이의 숫자입니다.(XNUMX-높은 신뢰도, XNUMX-낮은 신뢰도)
- 이러한 테스트를 준비하고 실행하는 데 드는 노력, 필요한 시간, 비용을 추정합니다.
- 테스트 우선순위 번호가 계산됩니다. 확률, 결과, 테스트 유효성 점수의 곱입니다.
- 125-Maximumà테스트를 통해 감지할 수 있는 매우 심각한 위험
- 1-최소 à 테스트를 통해 감지되지 않는 매우 낮은 위험
- 테스트 우선순위 번호에 따라 테스트 중요도는 높음(빨간색), 중간(노란색) 및 낮음(녹색)으로 분류될 수 있습니다. 위험도가 가장 높은 항목이 먼저 테스트됩니다.
- 테스트 활동을 테스트 단계에 할당합니다. 다양한 테스트 단계(단위 테스트, 통합 테스트, 시스템 테스트, 승인 테스트)에서 각 목표에 대한 테스트를 수행할 그룹을 지정합니다.
- 테스트 범위 내 및 범위 밖은 테스트 범위 지정 단계에서 결정됩니다.
- 각 단계의 테스트 목표에 대해 테스트 중인 구성 요소, 책임, 환경, 진입 기준, 종료 기준, 도구, 기술, 결과물이 정의됩니다.
일반 테스트 목표 - 이러한 일반 목표는 여러 프로젝트 및 애플리케이션에 적용 가능합니다.
- 구성 요소가 요구 사항을 충족하고 더 큰 하위 시스템에서 사용할 준비가 되었습니다.
- 특정 테스트 유형과 관련된 위험이 해결되고 테스트 목표가 달성됩니다.
- 통합 구성요소가 올바르게 조립되었습니다. 구성 요소 간의 인터페이스 호환성을 보장합니다.
- 시스템은 지정된 기능적 및 비기능적 요구 사항을 충족합니다.
- 제품 구성 요소는 의도된 운영 환경에서 최종 사용자의 요구를 충족합니다.
- 위험 관리 전략은 위험을 식별, 분석 및 완화하는 데 사용됩니다.
- 시스템은 산업 규정 요구 사항을 충족합니다.
- 시스템은 계약상의 의무를 충족합니다.
- 비용, 일정, 품질 목표 등 확립된 기타 특정 목표의 제도화 및 달성.
- 시스템, 프로세스 및 인력이 비즈니스 요구 사항을 충족합니다.
다양한 테스트 단계에 대해 일반 테스트 목표를 정의할 수 있습니다.
- 구성 요소 테스트
- 통합 테스팅
- 시스템 테스트
- 수락 테스트
시스템 테스트 단계를 생각해 봅시다
- G4 & G5는 시스템이 기능적 요구사항(F1,F2,F3)과 비기능적 요구사항(N1,N2)을 충족함을 보여줍니다.
- 시스템의 예상 기능이 제대로 작동하고 F1, F2, F3과 관련된 위험이 기능 테스트를 통해 해결될 수 있음을 테스트를 통해 시연합니다.
- 시스템의 운영 특성이 정상적으로 작동하고 N1, N2와 관련된 위험이 비기능 테스트를 통해 해결될 수 있음을 테스트를 사용하여 입증합니다.
- 테스트 우선순위 번호에 따라 테스트 중요도는 높음(빨간색), 중간(노란색) 및 낮음(녹색)으로 분류될 수 있습니다.
우선순위 지정 및 위험 평가 매트릭스
위험 평가 매트릭스는 확률 영향 매트릭스입니다. 이를 통해 프로젝트 팀은 위험과 각 위험을 해결해야 하는 우선순위를 빠르게 확인할 수 있습니다.
Risk rating = Probability x Severity
확률은 불확실한 사건이 발생할 확률을 측정한 것입니다. 시간, 근접성 및 반복 측면에서 노출됩니다. 백분율로 표시됩니다.
이는 빈번함(A), 가능성 있음(B), 비정기적(C), 원격(D), 불가능함(E), 제거됨(F)으로 분류될 수 있습니다.
- 빈번함 - 대부분의 상황에서 여러 번 발생할 것으로 예상됩니다(91 – 100%).
- 가능성 있음: 대부분의 상황에서 여러 번 발생할 가능성이 있음(61 – 90%)
- 가끔 발생함: 언젠가 발생할 수 있음(41 – 60%)
- 원격 – 발생 가능성이 낮음/언젠가 발생할 수 있음(11 – 40%)
- 가능성 없음 - 드물고 예외적인 상황에서 발생할 수 있음(0 -10%)
- 제거-발생불가능(0%)
심각도는 불확실한 사건으로 인해 발생하는 피해 또는 손실의 영향 정도입니다. 1~4점으로 분류되며 심각=1, 심각=2, 한계=3, 무시할 수 있음=4로 분류될 수 있습니다.
- 치명적인 – 프로젝트를 완전히 비생산적으로 만들고 심지어 프로젝트 종료로 이어질 수도 있는 가혹한 결과. 이는 위험 관리 시 최우선 순위가 되어야 합니다.
- 결정적인– 큰 손실로 이어질 수 있는 큰 결과. 프로젝트가 심각한 위협을 받고 있습니다.
- 가장자리 가의 – 단기 손상은 복원 활동을 통해 되돌릴 수 있습니다.
- 무시할 만하다.– 손상이나 손실이 거의 또는 최소한입니다. 이는 일상적인 절차를 통해 모니터링하고 관리할 수 있습니다.
우선 순위는 XNUMX가지 범주로 분류되며 아래 이미지와 같이 위험의 심각도 및 확률에 대해 매핑됩니다.
심각한: 이 범주에 속하는 위험은 황색으로 표시됩니다. 활동을 중지하고 위험을 격리하기 위한 즉각적인 조치를 취해야 합니다. 효과적인 통제를 식별하고 구현해야 합니다. 또한 위험이 낮거나 중간 수준으로 감소되지 않는 한 활동을 진행해서는 안 됩니다.
높음 : 이 범주에 속하는 위험은 빨간색으로 표시된 조치 또는 위험 관리 전략으로 표시됩니다. 위험을 격리, 제거, 대체하고 효과적인 위험 통제를 구현하기 위해 즉각적인 조치를 취해야 합니다. 이러한 문제를 즉시 해결할 수 없는 경우 이러한 문제를 해결하기 위해 엄격한 일정을 정의해야 합니다.
매체 : 이 범주에 속하는 위험은 노란색으로 표시됩니다. 위험을 최소화하려면 합리적이고 실용적인 조치를 취해야 합니다.
낮은: 이 범주에 속하는 위험은 녹색으로 표시됨) 일반적으로 심각한 문제를 일으키지 않으므로 무시할 수 있습니다. 통제가 유효한지 확인하려면 정기적인 검토가 필수입니다.
위험 기반 테스트를 위한 일반 체크리스트
위험 기반 테스트에서 고려해야 할 중요한 사항의 종합 목록
- 프로젝트의 중요한 기능.
- 프로젝트에서 사용자에게 표시되는 기능
- 안전에 가장 큰 영향을 미치는 기능
- 사용자에게 가장 큰 재정적 영향을 미치는 기능
- 매우 복잡한 소스 코드 영역 및 오류가 발생하기 쉬운 코드
- 개발 주기 초기에 테스트할 수 있는 기능입니다.
- 마지막 순간에 제품 디자인에 특징이나 기능이 추가되었습니다.
- 문제/문제를 일으킨 유사/관련 이전 프로젝트의 중요한 요소입니다.
- 운영 및 유지 관리 비용에 큰 영향을 미친 유사/관련 프로젝트의 주요 요인 또는 문제점입니다.
- 열악한 요구 사항으로 인해 프로젝트 목표와 결과물에 영향을 미칠 수 있는 열악한 설계 및 테스트가 발생합니다.
- 최악의 경우, 제품에 결함이 너무 많아서 재작업이 불가능하고 완전히 폐기해야 할 수도 있으며, 이로 인해 회사의 평판이 심각하게 훼손될 수 있습니다. 제품 목표에 어떤 종류의 문제가 중요한지 식별하십시오.
- 지속적인 고객 서비스 불만을 야기할 수 있는 상황이나 문제.
- 엔드투엔드 테스트는 시스템의 다양한 기능에 쉽게 집중할 수 있습니다.
- 위험 범위를 극대화할 수 있는 최적의 테스트 세트
- 어떤 테스트가 가장 높은 위험 범위 대 시간 소요 비율을 갖습니까?
위험 기반 테스트 결과 보고 및 지표
- 시험 성적서 작성테스트 상태 보고는 테스트 결과를 프로젝트 이해관계자에게 효과적으로 전달하는 것입니다. 그리고 명확한 이해를 제공하고 테스트 결과와 테스트 목표의 비교를 보여줍니다.
- 계획된 테스트 케이스 수와 실행된 테스트 케이스 수
- 통과/실패한 테스트 사례 수
- 확인된 결함 수와 상태 및 심각도
- 결함 수 및 상태
- 심각한 결함 수 - 아직 미해결 상태
- 환경 가동 중지 시간 – 해당되는 경우
- Showstoppers – 테스트 요약 보고서, 테스트 적용 범위 보고서가 있는 경우
- 측정항목 준비지표는 소프트웨어 프로세스, 프로젝트 및 제품을 비교하는 데 사용되는 두 개 이상의 측정값의 조합입니다.
- 노력과 일정의 변화
- 테스트 케이스 준비 생산성
- 테스트 설계 범위
- 테스트 케이스 실행 생산성
- 위험 식별 효율성 %
- 위험 완화 효율성 %
- 테스트 효과 %
- 테스트 실행 범위
- 테스트 실행 생산성
- 결함 누출 %
- 결함 감지 효율성
- 요구사항 안정성 지수
- 품질 비용
- 위험과의 관계를 바탕으로 결함 상태 및 테스트 합격/불합격 횟수를 기준으로 비기능 범주(성능, 신뢰성, 유용성)의 위험을 분석합니다.
- 위험과의 관계를 기반으로 테스트, 결함 상태 및 테스트 통과/실패 상태의 기능적 범주 지표에서 위험을 분석합니다.
- 주요 선행 및 지연 지표를 식별하고 조기 경고 지표를 생성합니다.
- 데이터 패턴, 추세, 상호의존성을 분석하여 선두 및 지연 위험 지표(핵심 위험 지표)를 모니터링하고 보고합니다.
고유 위험과 잔여 위험 평가
위험 식별 및 분석에는 고유 위험, 잔여 위험, XNUMX차 위험 및 재발 위험도 포함되어야 합니다.
- 내재된 위험: 통제 및 대응이 구현되기 전에 시스템에서 식별되었거나 이미 존재하는 위험입니다. 고유 위험은 총 위험이라고도 알려져 있습니다.
- 잔류 위험: 통제와 대응이 구현된 후에도 남는 리스크입니다. 잔여 위험은 순 위험으로 알려져 있습니다.
- XNUMX차 위험: 리스크 대응계획 시행으로 인한 새로운 리스크
- 반복되는 위험: 초기 위험이 발생할 가능성.
위험을 기반으로 한 테스트 결과 측정은 조직이 테스트 실행 중 품질 위험의 잔여 수준을 파악하고 현명한 릴리스 결정을 내리는 데 도움이 됩니다.
위험 프로파일링 및 고객 피드백
리스크 프로파일링은 요구되는 리스크, 리스크 수용능력, 리스크 허용도 등을 고려하여 고객이 투자할 수 있는 최적의 리스크 수준을 찾아내는 과정입니다.
- 요구되는 위험은 고객이 만족스러운 수익을 얻기 위해 감수해야 하는 위험 수준입니다.
- 위험 수용력은 고객이 감당할 수 있는 재정적 위험의 수준입니다.
- 위험 허용도는 고객이 선호하는 위험 수준입니다.
고객 의견
비즈니스, 제품, 서비스 및 경험을 개선하기 위해 고객 피드백과 리뷰를 수집합니다.
위험 기반 테스트의 이점
위험 기반 테스트의 이점은 다음과 같습니다.
- 생산성 향상 및 비용 절감
- 시장 기회 개선(시장 출시 기간) 및 정시 납품.
- 향상된 서비스 성능
- 애플리케이션의 모든 중요한 기능을 테스트하여 품질이 향상되었습니다.
- 테스트 범위에 대한 명확한 정보를 제공합니다. 이 접근 방식을 사용하면 테스트된 항목과 테스트되지 않은 항목이 무엇인지 알 수 있습니다.
- 위험 평가를 기반으로 한 테스트 노력 할당은 릴리스 시 잔여 위험을 최소화하는 가장 효율적이고 효과적인 방법입니다.
- 위험 분석을 기반으로 한 테스트 결과 측정을 통해 조직은 테스트 실행 중 품질 위험의 잔여 수준을 식별하고 현명한 릴리스 결정을 내릴 수 있습니다.
- 고도로 정의된 위험 평가 방법을 사용하여 최적화된 테스트입니다.
- 고객 만족도 향상 – 고객 참여, 우수한 보고 및 진행 상황 추적으로 인해 발생합니다.
- 잠재적인 문제 영역을 조기에 발견합니다. 이러한 문제를 극복하기 위해 효과적인 예방 조치를 취할 수 있습니다.
- 프로젝트의 전체 라이프사이클에 걸친 지속적인 위험 모니터링 및 평가는 위험을 식별 및 해결하는 데 도움이 되며 전체 프로젝트 목표 및 목표 달성을 위험에 빠뜨릴 수 있는 문제를 해결하는 데 도움이 됩니다.
요약
소프트웨어 엔지니어링에서 위험 기반 테스트는 위험을 기반으로 프로젝트를 안내하는 가장 효율적인 방법입니다.
테스트 노력이 효과적으로 구성되고 각 위험 항목의 우선 순위가 평가됩니다. 그런 다음 각 위험은 적절한 테스트 활동과 연관됩니다. 여기서 단일 테스트에는 둘 이상의 위험 항목이 있으며 해당 테스트는 가장 높은 위험으로 지정됩니다.
위험 우선 순위에 따라 테스트가 실행됩니다. 위험 모니터링 프로세스는 식별된 위험을 추적하고 잔여 위험의 영향을 줄이는 데 도움이 됩니다.