일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 세니티테스트
- 버그수명주기
- ISTQB
- 리그레이션
- BugLifeCycle
- 구조기반 테스트
- defect
- 웹성능
- severity
- QA Manager
- Test Summary Report
- Software Testing Life Cycle
- Retest
- Sanity Testing
- 테스트 시나리오
- QA Engineer
- 결함심각도
- Wepublic
- SQA
- Test Scenario
- 결함우선순위
- Risk Based Testing
- bug
- Airbridge
- RESRful
- STLC
- 리스크기반테스트
- 테스트 요약 보고서
- Shift Left Testing
- 테스트 프로세스 개선
- Today
- Total
Software Quality
리스크 기반 테스트(Risk Based Testing) 본문
리스크 기반 테스트를 진행하는 이유는 사용자가 제품에서 버그를 발견하더라도 소프트웨어 사용을 중단하지 않게하고 비즈니스에 심각한 영향을 미치지 않도록 하기 위함입니다.
따라서 위험 기반 테스트는 제품이나 소프트웨어의 특징, 모듈 및 기능에 대한 테스트 우선 순위를 매기는 원칙이 필요합니다. 우선 순위는 장애 가능성(기능이 잘못 동작할 가능성)과 장애로 인한 영향(잘못된 기능이 고객에게 미치는 영향)에 따라 결정됩니다.
리스크 기반 테스트는 언제 사용되어야 할까요?
- 프로젝트의 시간, 비용, 자원에 제한이 있거나 제약이 있거나 자원을 최적화할 필요가 있을 때 사용할 수 있습니다.
- 프로그램에 더 복잡하고 새로운 기술이 적용되어 많은 문제가 발생할 때 사용됩니다.
- 프로그램 R&D 프로젝트이고 처음으로 시도하는 유형이라 알려지지 않은 부분과 위험이 많은 경우에 사용합니다.
리스크 분석은 어떻게 진행되어야 할까요?
- 리스크 분석에는 제품의 소유자, 제품 관리자, 비즈니스 분석가, 설계자, 테스터 및 고객 담당자를 포함하는 기술 및 비즈니스 에 관련된 모든 이해 관계자가 참여합니다.
- 이해 관계자들이 참여하는 브레인스토밍 세션에서는 제품의 각 기능의 중요성을 파악하고 장애 위험 및 장애가 소비자에 미치는 영향에 따라 제품의 우선순위를 결정합니다.
- 요구사항 문서, 기술 사양 문서, 설계 문서, 비즈니스 프로세스 문서, 사용 사례 문서 등 다양한 프로젝트 문서가 브레인스토밍 세션의 입력 자료가 됩니다.
리스크 기반 테스트는 어떻게 적용해야 할까요?
1. 3X3 그리드 사용
위험 분석은 3X3 그리드를 사용하여 수행됩니다.
여기서 기능, 비기능 및 관련 테스트 케이스의 장애 발생 가능성 및 장애로 인한 영향을 이해관계자 팀이 평가합니다.
제품 사용 중 장애 발생의 가능성은 일반적으로 기술 전문가 그룹에 의해 확인되며 그리드의 수직 축을 따라
발생 가능성이 높음, 꽤 높음, 가능성 없음으로 분류됩니다.
마찬가지로, 제품의 사용 과정에서 장애로 인한 영향은 최종 고객이 경험하게 됩니다.
해당 부분은 비즈니스 전문가 그룹에 의해 평가되며 그리드의 수평축을 따라 사소함(Minor), 가시적(Visible), 중단(Interruption) 카테고리로 분류됩니다.
2. 장애 발생 가능성 및 영향
모든 테스트 케이스는 확인된 장애 발생 가능성 및 장애로 인한 영향의 값에 따라 아래 그림에 점으로 표시되고 3 X 3 그리드의 사분면에 배치됩니다.
장애 발생 가능성 및 장애로 인한 영향이 큰 테스트가 그리드의 오른쪽 상단 모서리에 그룹화되어 있고 발생 가능성이 낮고 장애로 인한 영향이 사소한 테스트가 왼쪽 하단 모서리에 그룹화되어 있습니다.
3. 테스트 우선 순위
그리드에서의 위치를 기반으로 시험의 우선순위가 결정되며 1,2,3,4,5 로 라벨이 부착되어 각각의 우선순위에 대해 표시합니다. 모든 테스트 케이스는 우선 순위 번호를 기준으로 정렬되며 우선 순위에 따라 테스트를 진행합니다. 우선 순위가 낮은 것은 테스트 대상에서 제외될 수 있습니다.
- Low-Level(유닛테스트 등) 테스트 진행하는 경우 - 기술적 리스크에 더 초점을 맞춤
- High-Level(시스템테스트 등) 테스트 진행하는 경우 - 사업적 리스트에 더 초첨을 맞춤
4. 세부 테스트 내용
이 단계는 세부적으로 얼마나 깊게 테스트 해야하는지 결정하는 단계입니다.
테스트 범위의 깊이는 아래 그리드에 따라 테스트 우선 순위를 기준으로 결정할 수 있습니다.
1위를 차지하는 우선 순위가 높은 테스트는 매우 철저하게 테스트되며, 따라서 전문가를 배치하여 이러한 높은 중요도 기능과 관련 테스트 사례를 테스트합니다. 마찬가지로 우선 순위가 2, 3, 4인 경우 순서따라 강력하게 테스트합니다. 사용 가능한 시간과 리소스에 따라 우선 순위 5의 기능은 테스트 범위에서 제외할 수 있습니다.
기능 및 테스트 케이스의 우선 순위를 지정하는 테스트 세부 수준 접근 방식은 테스터가 고부가가치 테스트를 식별하는 데 도움이 되고 우선 순위 테스트 사례를 기반으로 세부 테스트 수준을 결정하도록 도와줍니다. 이러한 최적화 프로세스를 통해 더 나은 테스트를 수행하고 테스트 비용을 절감할 수 있습니다.
참고 사이트
https://www.softwaretestinghelp.com/risk-management-during-test-planning-risk-based-testing/
'SQA > 이론' 카테고리의 다른 글
E2E 테스트 (0) | 2023.09.29 |
---|---|
결함/버그(Defect/Bug) 라이프 사이클 (0) | 2023.09.28 |
테스트 케이스(Test Case) 구성 요소 (0) | 2023.09.24 |
테스트 시나리오(Test Scenario)와 테스트 케이스(Test Case) (0) | 2023.09.24 |
PDCA 모델을 이용한 테스트 프로세스 개선 (0) | 2023.09.24 |