In fast-paced software development, testing teams face an almost impossible challenge: achieving comprehensive testing with limited time and resources.
With thousands of test cases, tight deadlines, and stakeholders demanding both speed and quality, the pressure on testing teams continues to grow.
Risk-Based Testing begins with a simple truth: the question isn’t whether you can test everything — it’s how you decide what to test first.
RBT scoring and prioritization can be supported by tools such as the RBT Calculator: https://testguild.com/tools/risk-scoring-calculator/
빠르게 변화하는 소프트웨어 개발 환경에서, 테스트 팀은 제한된 시간과 자원 속에서 완전한 테스트를 수행해야 하는 거의 불가능한 과제와 마주하게 된다.
수천 개의 테스트 케이스, 촉박한 일정, 그리고 속도와 품질을 동시에 요구하는 이해관계자들로 인해 테스트 팀이 받는 압박은 점점 더 커지고 있다.
리스크 기반 테스트(RBT)는 단순한 진리에서 출발한다: 문제는 모든 것을 테스트할 수 있는지가 아니라, 무엇을 먼저 테스트해야 하는가이다.
RBT 점수 산정과 우선순위 결정은 RBT Calculator 같은 도구를 활용해 지원할 수 있다. https://testguild.com/tools/risk-scoring-calculator/
1. What is RBT?
-
If you have 1,000 test cases but only limited time and resources, how do you decide which ones to execute first? Risk-Based Testing provides the answer to this question.
1,000개의 테스트 케이스가 있지만 시간과 자원이 제한되어 있다면, 어떤 테스트를 먼저 수행해야 할까? 리스크 기반 테스트는 바로 이 질문에 대한 답을 제공한다. -
Risk
Risk is something that might happen, whereas a problem is something we know will happen (or has already happened). If an event is associated with risk then there is a potential loss or impact associated with that event.
리스크는 발생할 가능성이 있는 상황이며, 문제(problem)는 발생할 것이 확실하거나 이미 발생한 상황이다. 어떤 사건이 리스크를 포함하고 있다면, 그 사건이 초래할 잠재적인 손실이나 영향이 존재한다는 의미이다.
- The Core Principle
Not all software components carry equal risk.
e.g., A cosmetic bug in a rarely-used admin panel poses minimal threat to your business, while a payment processing failure could cost thousands of dollars per hour and damage customer trust permanently.
Risk-based testing acknowledges this reality and provides a framework for making intelligent decisions about where to focus testing efforts.
예를 들어, 거의 사용되지 않는 관리자 패널의 단순 UI 오류는 비즈니스에 큰 영향을 주지 않는다. 반면, 결제 처리 기능의 장애는 시간당 수천 달러의 손실을 초래하고, 고객 신뢰를 심각하게 훼손할 수 있다.
Risk-Based Testing은 이러한 현실을 인정하고, 테스트 노력을 어디에 집중해야 할지 결정하기 위한 체계적인 방법을 제공한다.
2. Why we do RBT? (Real-World Benefits)
- Prioritized Testing Efforts Risk-based testing matches the level of test effort to the level of risk, ensuring higher-risk items receive more thorough testing. As Bob Crews emphasizes: “It's not just about coverage—it's about value.”
Risk-based testing은 테스트 노력을 리스크 수준에 맞춰 배분하여, 고위험 항목에 더 철저한 테스트가 수행되도록 한다.
Bob Crews가 강조하듯: “이것은 단순 테스트 커버리지의 문제가 아니라, 가치(Value)의 문제이다.” - Increased Software Quality By focusing on high-risk areas, teams prevent critical failures before they happen. This approach helps identify critical defects early in the development lifecycle and ensures thorough testing of important functions.
고위험 영역에 집중함으로써, 팀은 치명적인 장애를 사전에 예방할 수 있다.
이 접근법은 개발 초기 단계에서 중요한 결함을 발견하도록 돕고, 핵심 기능에 대한 충분한 검증을 보장한다. - Better Stakeholder Communication Risk scoring helps justify testing decisions to business and product teams. It provides a framework for clear communication about risks in language all stakeholders understand.
리스크 점수는 테스트 우선순위를 비즈니스 및 제품팀에게 설명할 때 근거를 제공한다. 이는 모든 이해관계자가 공통 언어로 리스크를 이해할 수 있도록 돕는다.
3. How we do RBT? (Steps)
- Risk Based testing Strategy - Steps
3.1. Risk Identification: 다양한 source(input)에서 잠재적 Product risk들을 수집하고 그룹화한다.
3.2. Risk Analysis: Probability(발생가능성)과 Consequence value(Damage or Impact) 을 통해 위험도를 계산한다.
3.3. Risk Response:
- 각 Risk에 Test Effectiveness(테스트 효과)를 부여, Test Priority Number(테스트 우선 순위)를 계산한다.
- 해당 리스크를 제거하거나 감소시키기 위해 무엇을 테스트해야 하는지(Test Objective) 정의한다.
e.g., UIP 2.0 적용 시 imaging latency 증가 리스크를 제거하기 위한 성능 테스트 수행. - 해당 Test objective-scenario에 어떤 test technique을 사용할지 정한다.
e.g., Exploratory Testing, Stress testing, Integration testing, Performance Testing - Depedencies(종속성), Prerequisities(전제조건)을 체크하여 테스트 실행 가능한 환경이 미리 준비되어야 합니다. (Skill, tools, enviroment)
3.4. Review & Decision:
Test scope(테스트 범위)를 정의 및 결정합니다.
Scope과 비용에 대한 프로젝트 이해관계자들과 합의
3.5. Test Planning & Test Allocation
Test level, 어떤 수준에서 테스트를 할 것인지 정의합니다. 각 테스트를 누가 수행할지 할당하고 responsible(책임자)를 정합니다.
4. Industry Specific
-
Medical Devices and Healthcare
Medical device risk assessment must consider:
FDA compliance requirements
Clinical risk scenarios
Validation in healthcare environments
Patient safety as the primary concern
의료기기 리스크 평가에서는 다음 요소를 고려해야 한다:
FDA 규제 요구사항
임상적 리스크 시나리오
의료 환경에서의 Validation
환자 안전(Patient Safety)을 최우선으로 고려 -
Financial Services
Financial applications require focus on:
Regulatory compliance (SOX, PCI DSS, GDPR)
Transaction integrity and audit trails
Real-time processing risks
Security and fraud prevention
E-commerce and Retail
E-commerce risk assessment emphasizes: -
Financial Services
금융 소프트웨어는 다음 영역에 주력한다:
규제 준수(SOX, PCI DSS, GDPR)
거래 무결성 및 감사 추적
실시간 처리 리스크
보안 및 사기 방지 -
E-commerce and Retail
Revenue impact of failures
Customer experience risks
Peak load and seasonal considerations
Payment processing security
전자상거래 리스크 평가는 다음을 강조한다:
장애 발생 시 매출 손실
고객 경험 리스크
성수기·피크 트래픽 시의 성능 문제
결제 보안 및 처리 안정성
5. Reference Material
- https://testguild.com/risk-based-testing/
- Risk-based testing:: Risk analysis fundamentals and metrics for software testing including a financial application case study
