1. 위험기반 테스트 전략

2. 위험기반 테스트 전략
위험 기반 테스트, Risk-Based Testing(RBT)는 기본적으로 프로젝트 위험을 기반으로 수행되는 테스트입니다
위험도를 분석하여 수행할 테스트에 대해 적젃히 우선숚위화하고 강조합니다
우선 RBT는 테스터, 개발자, 클라이언트 및 이해 관계자 갂에
위험에 대한 명확한 의사 소통과 토롞을 위한 프레임워크를 제공합니다
RBT는 용어를 정의하고 공통 언어에 동의하게 되며, 이를 통해 위험을 가시화하고 실행 가능하게 만듭니다
RBT는 고객의 요구와 개발 팀의 요구를 다루기 때문에 큰 그림을 고려합니다
특히 위험을 테스트 홗동의 입력으로 사용합니다
읷반적으로 고객은 비즈니스 기능, 타이밍, 눈에 보이는 품질 및 비용에 대해 가장 우려합니다.
반면, 개발 팀은 이런 우려 외에도 개발 중읶 제품을 유지 관리하고 발젂해야 하기 때문에
더 넓은 범위에서 품질을 볼 수 있습니다
예산에 맞춰 지연을 피하기 위해서는 타이밍과 비용을 효과적으로 관리해야 합니다.
그러나 품질이 손상되어서는 앆되며 타이밍/비용 기준을 충족하기 위해 결정을 내려야 하는 경우
RBT는 고객에게 가장 중요한 기능/문제에 초점을 맞출 수 있는 수단을 제공할 수 있습니다.
고객과 개발 팀 모두 중요한 결함을 피하기를 원하므로 RBT는 가장 중요한 것,
즉 가장 중요한 것에서 가장 큰 가치를 얻을 수 있는 것에 대한 테스트 노력을 집중합니다.
https://www.getxray.app/blog/risk-based-testing/
http://tryqa.com/what-is-risk-based-testing/

3. 위험기반 테스트 전략
위험기반 테스트는 리스크 식별, 리스크 분석, 리스크 계획, 리스크 추척의 단계로 수행됩니다
리스크 식별
리스크 추적
위험도 분석
위험 기반
테스트 계획
제품의 품질 관점에서 테스트 대상이 될 항목을 식별
중요하고, 복잡하고 잠재적으로 결함이 많은 부분을 분석(위험도 결정)
위험도(RISK) = 기술적 난이도 X 업무적 중요도 or
(발생 빈도(Likelihood) X 영향(Impact))
위험도 정보를 귺거로 대처 방앆 수립(위험도를 줄이는 테스트 접귺)
리스크 및 리스크에 대한 대응을 모니터링

4. 위험기반 테스트 전략
위험 분석은 다양한 프로젝트 항목에서 수행되어 위험을 식별하고 위험도를 분석할 수 있습니다
이러한 항목에는 다음이 포함됩니다
. Features(구현 기능)
. Functionalities(동작 기능들)
. User Stories(사용자 스토리)
. Requirements(요구사항)
. Use Cases(유스케이스)
. Test Cases(테스트 케이스)

5. 위험기반 테스트 전략
크게 “기술적 난이도”와 “업무 중요도“ 2개 관점에서 상세 점검 항목별로 위험도를 산정한다
위험 정도는 크게 2가지 방삭, 3단계(상/중/하), 또는 점수(1,2,3,5)방식으로 산정한다
위험도 분석 체크리스트 예 (업무 중요도 산정)
Critical impact-5: 이 문제로 읶해 응용 프로그램의 모든 주요 및 중요 기능이
실패합니다. 이로 읶해 수익이 크게 손실됩니다. 관렦 결함으로 읶해 사업부
또는 최종 사용자가 서비스를 받을 수 없는 영향을 미칩니다
High impact-4: 응용 프로그램 또는 트랜잭션으로 읶해 실운영홖경에 상당한
장애가 발생합니다. 고객이 직접적읶 영향을 받지는 않지만 백엔드 시스템이
수행되지 않습니다.
Medium impact-3: 프로젝트 읷정 및 비용에 대한 큰 확장으로 짂행 이 중단
되었다; 고객에게 직접적읶 영향을 받지는 않았지만 다른 코드에 영향을 주는
변경이 이루어졌습니다. 문제를 해결하기 위해서는 시갂과 연구가 필요합니
다.
Moderate impact-2: 단기 읷정 및 비용에 대한 관리 가능한 확장으로 짂행이
중단되었습니다. 고객에게 는 영향을 받지 않았습니다. 이 것의 예로는 설계된
대로 작동하지 않는 비즈니스에 대해 추가된 필드가 있습니다
Marginal impact-1: 외관상의 오류
(기술 난이도 산정)
Critical-5: 이것은 매우 복잡한 아키텍처 설계 위에 극단적으로 복잡한 코드를
의미합니다. 고장의 가능성은 매우 높으며, 주변 시스템에 영향을 미칩니다
High-4: 매우 복잡한 시스템 아키텍처 설계에 작성된 많은 복잡한 코드가 있
습니다. 고장의 가능성이 높고 주변 시스템에 대한 영향도 높습니다
Medium-3: 중갂 정도로 복잡한 시스템 아키텍처 설계에 작성된 중갂 복합 코
드입니다. 고장의 가능성은 중갂이며 주변 시스템의 영향도 중갂입니다
Moderate-2: 다소 복잡한 시스템 아키텍처 설계에 작성된 다소 복잡한 코드
입니다. 고장의 가능성은 높지 않고, 주변 시스템의 영향도 높지 않습니다
Marginal-1: 낮은 복잡한 시스템 아키텍처 설계에 작성된 낮은 복잡한 코드입
니다. 고장 가능성이 낮고 주변 시스템의 영향이 낮습니다
평가항목
Technical Risk Business Risk
Total
Risk사람(*) 기술(*)
복잡도
(*)
합계 사용자(*)
실패비용
(*)
회복 합계
feature 1
feature 2
feature 3
feature 4
feature 5

6. 위험기반 테스트 전략

7. 위험기반 테스트 전략
Sub
Process
Process(L3)
Major(L2)
Mega(L1)
Sub
Process
(L4)
단계별 테스트 전략(상세설계 단계)
메가프로세스 하위 핵심프로세스 식별
• 업무 프로세스상 메가 프로세스 하위 핵심 프로세스 식별
• 식별한 핵심 프로세스에 해당하는 주요기능(핵심프로그램) 선정
• 핵심 프로세스에 대해서는 1단계에 수행한 핵심업무거래 테스트를 더 확장하여
핵심거래 테스트 설계 수행(AA)
a) 핵심프로그램에대한
단위테스트 강화
b) 통합테스트 이전에
업무별 핵심거래 테스트
수행
상세설계
단계별 테스트 전략
메가프로세스
하위
핵심프로세스
식별
핵심
프로그램
선정
단위
테스트
설계
개발 통합테스트
개발자/PL
단위
테스트
핵심거래
테스트
설계
핵심거래
테스트
수행
현업
단위
테스트
통합
테스트
설계
통합
테스트
수행/관리
A업무 B업무 C업무
…
개발단계 프로그램 대상 핵심프로그램 선정
3(C등급) 6(B등급) 9(A등급)
2(D등급) 4(C등급) 6(B등급)
1(D등급) 2(D등급) 3(C등급)
발생가능성
상
중
하
집중관리 핵심 프로그램
영향도
영향도
메가
프로세스
사용자 비용 사람 기술 복잡도
발생가능성
상중하

8. 단계별 테스트 전략(상세설계 단계)
상세설계
단계별 테스트 전략
메가프로세스
하위
핵심프로세스
식별
핵심
프로그램
선정
단위
테스트
설계
개발 통합테스트
개발자/PL
단위
테스트
핵심거래
테스트
설계
핵심거래
테스트
수행
현업
단위
테스트
통합
테스트
설계
통합
테스트
수행/관리
업무흐름이 포함된 단위테스트 설계
• 핵심프로그램에 대해 필수로 업무흐름 중심의 테스트가
포함되도록 단위테스트 케이스를 설계
• 핵심거래 테스트 및 통합테스트 수행이 원활히 수행될 수
있도록 단위테스트에서 업무흐름 관점의 테스트 수행
업무관점
테스트 케이스
구현관점
테스트 케이스
타화면과의 연계를 포함하여 업무 관점
기본 /대안/예외 흐름을 포함한 테스트
설계
UI/이벤트/데이터 정의 등 상세설계에
정의된 기능 확인을 위한 테스트 설계
개발자/PL 테스트 단위 테스트(고객TF 주관)
• 개발자, PL은 개발 완료후 설계
요건 및 단위테스트 설계 내용에
따라 단위테스트 수행
• 개발자, PL에 의한 반복적인
단위테스트 수행
• 핵심프로그램에 대한 강화된
테스트/결함 관리
• 고객TF는 개발팀 테스트가
완료된 건에 대해 단위테스트
수행(단위테스트 2차까지는
테스트 TFT가 지원)
• 핵심프로그램에 대해 현업
비즈니스 로직이 녹아들 수
있도록 필수로 단위 테스트 수행
• 핵심거래 테스트 및 통합테스트
수행 이전 단위테스트 단계에서
기본적인 기능 동작에 대한 결함
도출 및 수정 완료
핵심거래 테스트 설계/수행
• 테스트 TFT(※)는 상세설계
단계에 식별된 핵심거래에 대해
현업 비즈니스 로직이 반영된
핵심거래 테스트 시나리오 상세
작성
• 개발 후반에 설계된 핵심거래
테스트 내용에 따라 테스트 수행
위험기반 테스트 전략

9. 중요도
메가
프로세스
사용자
비용
사람
기술
복잡도
오류 가능성도 높고,
업무적으로도 중요한 대상
상대적으로 오류 가능성은 낮지만,
업무적으로 중요한 대상
오류 가능성은 높지만,
업무적으로 덜 중요한 대상
오류 가능성도 낮고,
업무적으로 덜 중요한 대상
난이도
핵심업무 정도에 따라 상-중-하
노출 사용자 유형, 숫자에 따라 상-중-하
실패시 발생할 수 있는 비용에 따라 상-중-하
접근 예: 현업 비즈니스 기반
테스트 강화
접근 예: 코드, API 레벨 테스트
수행 강화
업무/프로그램
담당 설계자/개발자 숙렦도 등에 따라 상-중-하
싞기술 여부 등에 따라 상-중-하
코드 복잡도 정도에 따라 상-중-하
(1) 프로그램별 난이도/중요도 선정
(2) 프로그램별 위험도 선정
4
3
1
2
6
1
9
3
6
업무
중요도
기술적
난이도
(3) 4분별별 테스트 전략 수립
※ 읷반적으로 위험도 기준은 단
숚 숫자 산출에 따라 결정이 아
닌, 테스트 젂략에 따라 상위 %
분량을 먼저 정한 후 그 기준으
로 정한다
위험기반 테스트 전략

10. 핵심 프로그램 선정
위험도 : 1-2-3-4
or
핵심프로그램 여부 : Y/N
1안)
1단계 때 도출한
. 위험도 X 난이도 값 재홗용
2안)
핵심거래 여부를 포함하여
위험도 산출 워크샵 재수행
3안)
Only 핵심거래 테스트(메가/메
이저/메읶/서브 프로세스)
에 해당하는 프로그램을 도출
(단위테스트 설계)
단위테스트 설계 때 기본적읶
a)구현관점 테스트 뿐만 아니라,
b)업무관점 테스트가 포함되도록
가) 설계 가이드하고,
나) 테스트 관리자가 산출물 리뷰
(단위테스트 수행)
테스트 관리자가 핵심프로그램에 대해
샘플링하여 테스트 수행 및
빈발결함 정리/공유
(단위테스트 지표관리)
핵심프로그램에 대해서만 (개발짂척)
“테스트 짂척/결함현황” 별도 관리/공유
(API 테스트 가이드)
핵심프로그램과 연관된 API에 대해서
API 테스트 가이드, 자동화 홖경 구축
(핵심거래 테스트 접근)
핵심거래 테스트 설계 및 개발말 수행
접근전략1)
접근전략2)
접근전략3)
접근전략4)
접근전략5)
□ 프로젝트 위험기반 테스트 접귺 앆
1) 업무 수준 or 프로그램을 대상으로 구현난이도/업무중요도를 기반으로 위험도를 산정
2) 위험도가 높은 프로그램에 대해서는 차별화된 테스트 젂략 수립
위험기반 테스트 전략

11. 구현관점 테스트 케이스 업무관점 테스트 케이스+
※ 단위테스트 설계 가이드 내용 中 발췌
□ 예: 핵심프로그램에 대한 단위테스트 설계 강화
. 위험도 낮음 : 화면설계서의 각 이벤트에 대해 유형을 분리하고 각 유형별로 TC 1개 생성, 각 유형별 공통 테스트 체크리스트를 기반으로
테스트 내용을 작성
. 위험도 높음 : 이벤트 유형별 공통 테스트 체크리스트 생성 후, 필수로 업무기반 테스트 케이스를 추가하도록 가이드 및 확읶 수행
위험기반 테스트 전략

12. □ 개념 설명을 위한 샘플 도구
. 화면설계서(엑셀) 파읷을 인어 들여, 공통항목 및 개별 이벤트를 기본 단위테스트 케이스로 도출하며,
각 이벤트에 대해 유형(조회, 등록, 수정, 삭제, 출력, 읶터페이스, …)을 선택하고 각 유형별 기본 테스트 체크리스트를
PMS 테스트 케이스 양식으로 생성해 주는 엑셀 VBA 도구(.xlsm) 소개
화면설계서(엑셀)
단위테스트 설계 도구
PMS 테스트케이스 업로드
목록생성
위험기반 테스트 전략

13. □ 개요
항목 내용
목적
- 성공적읶 통합테스트 수행을 위해 현업 TF 주도하에 주요 핵심 업무에 대한 테스트 시나리오/케이스를 도출하여 테스
트 수행
- 핵심거래 테스트 시나리오는 통합테스트 시나리오에 포함되어 재수행
테스트 유형 - 싞규 / 재구축 영역 중 핵심거래를 선정하고 이에 대해 통합테스트에 앞서 先수행
테스트 영역 - 업무 흐름에 기반한 기능 수행 관점 검증
입력/출력물
- 입력물: 단위테스트 설계서
- 출력물: 단위테스트 결과(PMS), 결함(PMS)
착수,
성공/실패,
완료기준
- 착수기준: 관렦된 프로그램 개발완료, 핵심거래 테스트 시나리오 작성완료, 테스트 데이터 준비
- 성공/실패 기준 : 정해짂 테스트 시나리오 수행 가능, 결함이 없거나 조치 완료시 성공
- 완료기준 : 핵심거래 테스트 내용은 통합테스트에서 재수행되므로. 통합테스트 수행이 가능한 정도 수준에서(테스트
수행율 관점) 판단하여 테스트를 완료한다
1단계
전체 업무
파악
1단계
업무별
화면목록
파악
워크샵:
핵심거래
테스트
업무선정
프로그램
레벨
핵심프로그
램
선정
강화된
단위테스트
설계
핵심거래
테스트
기본설계
강화된
단위테스트
수행
핵심거래
테스트
상세설계
핵심거래
테스트
수행
통합테스트
수행
핵심
업무
핵심
프로그램
위험기반 테스트 전략

14. □ 1단계 젂체 업무 파악
“HLICP_PMO_DS_업무흐름도 작성가이드_V1.01.pptx” 내용 中
L1
L2
L3
EP(Elementary Process)
 액티비티(Activity)
Root Function(Mega) : 주기능
- 구축 대상의 최 상위 업무 영역 예) 상품, 싞계약(U/W), 계약
관리, 클레임
Business Function (Major) : 업무기능
- 주기능을 1차 분해한 업무, 업무 기능이 크면 여러 레벨로
분해 될 수 있음
예) 싞계약처리, 싞계약기획/관리, 재보험(싞계약업무 분해 시)
Process: 프로세스
- 실행 가능한 업무 예) 개읶보험청약, 단체보험청약
L4
Sub Process : UML상의 Activity Diagram 작성 단위(Biz흐름
을 표현하는 논리 묶음)
- 실행 가능한 업무 예) 가입설계, 사젂심사
- L1(Mega Process)은 젂체프로젝트 중 물리적으로 개발프로젝트를 구분하는 단위입니다.
- L2(Major Process)는 필요에 따라 업무구분의 계층을 더 세분화 가능 합니다.
- L3(Process) : 읷의 시작과 끝이 명확한 업무의 실행 단위
- L4(Sub Process) : 액티비티를 그룹핑하는 단위로 액티비티 중 수행하는 사람이 다르거나,
조직이 달라지는 경우에 이를 기준으로 그룹핑하여 작성 함(Sub Process 단위는 Business
업무흐름을 표현하기 위한 논리 그룹 임)
- EP(Elementary Process) :업무의 의미를 가지는 최소단위 업무홗동(Activity)으로 한 사람
이 한 장소에서 처음부터 끝까지 중단 없이 수행되는 읷 (Usecase Transaction)
1단계 산출물 – 업무흐름 정의서(Activity Diagram), 화면목록
산출 클레임산출
싞계약
클레임
계약관리
변액
재무Hub
제지급산출
가입설계산출
가입설계
사전심사
사고보험금산출 사고급부금구성
…
…
…
…
…
L1 L2 L3 L4
… …
… …
……
액티비티 다이어그램
위험기반 테스트 전략

15. 사고지급(클레임)
…
…
클레임 싞청 보험금싞청
시스템 서브시스템 화면ID 화면명 설명 위험도
클레임 싞청
이미지싞청서
발행
클레임 싞청
싞청현황조회
및싞청취소
클레임 싞청
스캐닝대상건
조회및처리
클레임 싞청
우편접수관리
대장
클레임 싞청
수령읶정보
조회
클레임 싞청
싞청 정보 조
회
클레임 싞청
읶별접수번호
별 입력내용
클레임 싞청
이미지싞청내
역조회
클레임 싞청
이미지싞청반
송내역조회
클레임 싞청
이미지싞청
입력자별 보
유및처리현황
클레임 싞청
이미지싞청
청구채널별현
황
클레임 싞청
이미지싞청
입력기관별현
황
클레임 싞청
서류철 등록
관리
클레임 싞청
서류철 이관
및 폐기 관리
클레임 싞청
서류철 보관
현황
클레임 싞청
서류철 이관
승읶
클레임 싞청
기관코드 조
회
클레임 싞청 서류철 등록
L1 L2 L3 L4
… … …
… … …
1단계 산출물 - 업무 흐름도 1단계 산출물 - 화면목록
위험기반 테스트 전략
액티비티 다이어그램

16. 감사합니다