Software Test Planning and Risk Management
1️⃣ Core Concepts of Test Planning
2️⃣ Risk Management Overview
3️⃣ Risk-based testing strategy
1️⃣ Core Concepts of Test Planning
What is a Test Plan?
To perform software testing systematically, prior planning is essential. Regardless of what is being managed, proceeding without a plan leads to losing direction, and testing is no exception. This is why we have consistently emphasized from previous weeks that a Test Plan must be established before testing begins.
A concept studied alongside this is the PDCA cycle. A continuous loop of Plan → Do → Check → Act. The test plan corresponds to the Plan phase, which is the starting point of this cycle. In this phase, we clearly define what to test, how far to test, and what goals we aim to achieve through testing at a high level.
The reason a test plan goes beyond mere preparation is that all subsequent activities; test design, execution, evaluation, and improvement; are carried out based on this plan. In other words, the test plan serves as the foundation that sets the direction and criteria for all downstream activities.
In summary, the test plan is the compass of the entire test process. The clearer the plan, the more consistently and efficiently all subsequent testing activities can be carried out.
테스트 계획(Test Plan)이란?
소프트웨어 테스트를 체계적으로 수행하기 위해서는 반드시 사전 계획이 필요하다. 어떤 대상을 관리하든 계획 없이 진행하면 방향을 잃기 쉽고, 테스트도 마찬가지다. 그래서 우리는 테스트를 시작하기 전에 반드시 테스트 계획(Test Plan) 을 세워야 한다는 점을 이전 주차부터 꾸준히 강조해왔다.
이와 관련하여 함께 학습한 개념이 바로 PDCA 사이클이다. PDCA란 Plan(계획) → Do(실행) → Check(평가) → Act(개선)의 순환 구조를 말하며, 테스트 계획은 이 사이클의 출발점인 Plan 단계에 해당한다. 이 단계에서는 무엇을 테스트할 것인지, 어디까지 테스트할 것인지, 그리고 상위 수준에서 테스트를 통해 달성하고자 하는 목표가 무엇인지를 명확하게 정의한다.
테스트 계획이 단순한 준비 작업에 그치지 않는 이유는, 이후에 이루어지는 테스트 설계, 수행, 평가 및 개선의 모든 활동이 바로 이 계획을 기준으로 전개되기 때문이다. 즉, 테스트 계획은 다음 작업들의 방향과 기준을 잡아주는 토대 역할을 한다.
정리하자면, 테스트 계획은 테스트 전체 프로세스의 나침반이다. 계획이 명확할수록 이후의 모든 테스트 활동이 더 일관성 있고 효율적으로 이루어질 수 있다.
Test Planning in the ISO/IEC/IEEE 29119 Standard
ISO/IEC/IEEE 29119 is an international standard covering software testing as a whole, structured into three layers. At the top is the Organizational Test Process, which establishes test policies and strategies applicable across the entire organization. Below that is the Test Management Process, responsible for planning and managing testing at the individual project level. Finally, the Dynamic Test Process is where actual test design, execution, and result processing take place. The test plan corresponds to the first activity within the Test Management Process.
There is one important principle to note here. A test plan is not created independently without context ; it must reflect the test policies and strategies established in the Organizational Test Process. Only when the direction of the higher layer is naturally embedded into the lower-level plan can consistent testing be achieved throughout the project.
So what exactly should a test plan document contain? First, the scope and test items must be clearly identified, defining what and how far to test. Next, the test objectives must be set, defining what the testing aims to achieve. Finally, a test strategy must be developed based on the Organizational Test Process, outlining how to achieve those objectives.
Throughout this process, the word strategy appears frequently. This refers not simply to "what to do," but to the specific methodology for "how to proceed systematically." Without a strategy, testing can easily lose its direction. Therefore, strategy is a core component that must be included in the test plan document.
Ultimately, the 29119 standard positions the test plan within a hierarchical flow of Organizational Policy → Test Strategy → Execution, and the test plan document is the tangible output that formalizes this flow.
ISO/IEC/IEEE 29119 표준에서의 테스트 계획
ISO/IEC/IEEE 29119는 소프트웨어 테스트 전반을 다루는 국제 표준으로, 크게 세 개의 계층으로 구성되어 있다. 가장 상위에는 조직 전체에 적용되는 테스트 정책과 전략을 수립하는 조직 차원의 테스트 프로세스가 있고, 그 아래에는 개별 프로젝트 수준에서 테스트를 계획하고 관리하는 테스트 관리 프로세스, 그리고 실제 테스트 설계와 실행, 결과 처리가 이루어지는 동적 테스트 프로세스가 순서대로 위치한다. 테스트 계획은 이 중 테스트 관리 프로세스의 첫 번째 활동에 해당한다.
여기서 한 가지 중요한 원칙이 있다. 테스트 계획은 아무런 맥락 없이 독립적으로 세워지는 것이 아니라, 반드시 상위 계층인 조직 차원의 테스트 프로세스에서 만들어진 테스트 정책과 전략을 반영해야 한다는 점이다. 상위 계층의 방향성이 하위 계획에 자연스럽게 녹아들어야만 프로젝트 전반에 걸쳐 일관성 있는 테스트가 가능하기 때문이다.
그렇다면 테스트 계획서에는 구체적으로 무엇이 담겨야 할까. 먼저 무엇을 어디까지 테스트할 것인지 대상과 범위를 명확히 식별해야 하고, 이번 테스트를 통해 달성하고자 하는 바를 테스트 목표로 설정해야 한다. 그리고 조직 차원의 테스트 프로세스를 기반으로 그 목표를 달성하기 위한 테스트 전략을 수립해야 한다.
이 과정에서 유독 전략(Strategy) 이라는 단어가 자주 등장하는데, 이는 단순히 "무엇을 할 것인가"에 머무르지 않고 "어떻게 체계적으로 해나갈 것인가"에 대한 구체적인 방법론을 의미한다. 목표만 있고 전략이 없다면 테스트는 쉽게 방향을 잃을 수 있기 때문에, 전략은 테스트 계획서의 핵심 구성 요소로 반드시 포함되어야 한다.
결국 29119 표준은 테스트 계획을 조직의 정책 → 테스트 전략 → 실행으로 이어지는 계층적 흐름 속에 위치시키고 있으며, 테스트 계획서는 바로 이 흐름을 하나의 문서로 구체화한 결과물이라고 할 수 있다.
Detailed Process of Test Planning in 29119
To develop a test plan, the process begins with understanding the project context. Only by grasping the overall picture; including the development scope and overall schedule - can the test scope be defined and a high-level test concept be formed. This concept then shapes the rough outline of the test plan and development schedule.
Once the schedule takes shape, the next step is risk identification and analysis; identifying and analyzing potential risk factors across the project. The methods identified to mitigate these risks are then incorporated into the test strategy design. Afterward, specific human resources and schedules are determined; who will perform the testing, what resources will be used, when and how; and these are documented in the test plan document. The completed document goes through consensus with stakeholders and is shared, completing the test planning process.
The most critical part of this entire flow is the three-step sequence of risk identification and analysis → risk mitigation identification → test strategy design. Planning is fundamentally an act of preparing for future events in advance. Therefore, risks that could affect test execution must always be included in the test plan. Ultimately, the core principle emphasized by the 29119 standard is that test planning must be risk-based.
29119 테스트 계획의 세부 프로세스
테스트 계획을 수립하기 위해서는 가장 먼저 프로젝트의 컨텍스트를 이해하는 것에서 출발한다. 개발하고자 하는 범위나 전체 일정 등 프로젝트의 전반적인 맥락을 파악해야 비로소 테스트의 범위가 정해지고, 테스트에 대한 전체적인 구상이 가능해진다. 이 구상을 바탕으로 테스트 계획과 개발 일정의 큰 틀이 만들어진다.
일정의 윤곽이 잡히면 그 다음으로는 위험 식별 및 분석 단계가 이어진다. 프로젝트 전반에 걸쳐 어떤 위험 요소가 존재하는지 찾아내고 이를 분석하는 과정이다. 이렇게 분석된 위험을 완화하기 위한 방법을 도출하고, 그 방법을 반영하여 테스트 전략을 설계하게 된다. 이후 누가 수행할 것인지, 어떤 자원을 사용할 것인지, 언제 어떻게 진행할 것인지와 같은 구체적인 인적 자원과 일정을 결정하여 테스트 계획서로 문서화한다. 완성된 계획서는 관련자들과 합의를 거쳐 공유되며 테스트 계획 수립이 마무리된다.
이 전체 흐름에서 가장 중요하게 짚어야 할 부분은 위험 식별 및 분석, 위험 완화 방법 식별, 테스트 전략 설계로 이어지는 세 단계다. 계획이란 본질적으로 미래에 일어날 일들을 미리 대비하는 행위다. 그렇기 때문에 테스트 계획을 세울 때도 앞으로의 테스트 수행에 영향을 미칠 수 있는 리스크를 반드시 계획 안에 포함시켜야 한다. 결국 테스트 계획은 위험을 기반으로 수립된다는 것이 29119 표준이 강조하는 핵심 원칙이다.
그렇다면 구체적으로 어떤 기준으로 위험을 식별하고 분석하는 것인지가 자연스러운 다음 질문이 된다. 다음 시간에는 바로 이 위험을 식별하고 분석하는 기준과 방법에 대해 자세히 살펴볼 예정이다.
Structure of the Test Plan Document; Master Test Plan and Level Test Plans
Once test planning is complete, the resulting artifact is the test plan document, which is divided into two types: the Master Test Plan and Level Test Plans.
The Master Test Plan is a comprehensive document that consolidates and manages all the subordinate level test plans. Its purpose is to oversee and control multiple test levels and non-functional testing from a holistic perspective — it is essentially the top-level plan that coordinates the entire testing effort.
Beneath the Master Test Plan are individual Level Test Plans, each specific to a particular test level. These detail the test strategy, specific activities, detailed schedule, test owners, execution methods, and tools for each test level. The test types covered correspond to the right side of the V-model; unit testing, integration testing, system testing, acceptance testing — as well as non-functional testing such as load and performance testing.
In summary, if the Master Test Plan is the big picture that provides an overview of all testing, then the Level Test Plans are the detailed blueprints that specify exactly how each test will be conducted within that big picture.
테스트 계획서의 구성; 총괄 테스트 계획과 단계별 테스트 계획
테스트 계획 수립이 완료되면 그 결과물로 테스트 계획서가 만들어진다. 테스트 계획서는 크게 총괄 테스트 계획과 단계별 테스트 계획 두 가지로 나뉜다.
먼저 총괄 테스트 계획은 하위에 존재하는 여러 단계별 테스트 계획들을 하나로 묶어 종합적으로 관리하는 계획서다. 여러 테스트 단계와 비기능 테스트 등을 전체적인 시각에서 관리하고 통제하는 것이 목적이며, 말 그대로 테스트 전반을 조율하는 최상위 계획서라고 볼 수 있다.
그리고 이 총괄 테스트 계획 아래에는 각 단계별로 세분화된 단계별 테스트 계획이 존재한다. 단계별 테스트 계획에서는 각 테스트 단계에서 수행할 테스트 전략, 구체적인 활동, 세부 일정, 테스트 담당자, 수행 방법, 사용 도구 등을 상세하게 계획한다. 대상이 되는 테스트 유형은 V 모델의 오른쪽에 해당하는 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트, 그리고 사용량이나 성능 등을 검증하는 비기능 테스트까지 포함된다.
정리하자면, 총괄 테스트 계획이 전체 테스트를 조망하는 큰 그림이라면, 단계별 테스트 계획은 그 큰 그림 안에서 각 테스트를 어떻게 실제로 수행할 것인지를 구체적으로 담아낸 세부 설계도라고 할 수 있다.
Contents of the Master Test Plan and Level Test Plans
Since the test plan document is divided into master and level plans, the depth and specificity of content in each naturally differs.
The Master Test Plan contains high-level content: the test purpose and scope explaining why testing is being conducted; the test item definition clarifying what will be tested; the test strategy and approach describing how testing will proceed; the overall schedule; the organizational structure and roles defining who is responsible for what; and assumptions and constraints that may affect test execution. In short, the Master Test Plan is a document capturing the big picture of all testing.
Based on this master plan, individual Level Test Plans are created — separate documents for each test level such as unit, integration, system, and acceptance testing. These contain much more specific content: the test scope and strategy for that level, the activities and objectives to be performed, the characteristics of the test items, test design methods, constraints during execution, input/output work products, test tools to be used, the detailed schedule, and the final deliverables.
Ultimately, while the Master Test Plan provides the overall direction and criteria, the Level Test Plans serve as detailed execution guides explaining exactly how each test level will be carried out. Only when the two documents are organically connected can systematic and consistent test execution be achieved.
[예시] 총괄 및 단계별 테스트 계획서의 구성 항목
테스트 계획서는 총괄과 단계별로 나뉘는 만큼, 각각에 담기는 내용의 수준과 세부성도 자연스럽게 달라진다.
총괄 테스트 계획서에는 상위 수준의 내용들이 담긴다. 테스트를 왜 수행하는지에 대한 테스트 목적 및 범위, 무엇을 테스트할 것인지를 정의하는 테스트 대상 시스템 정의, 테스트를 어떻게 진행할 것인지에 대한 테스트 전략과 수행 절차, 전체적인 일정, 누가 어떤 역할을 맡을 것인지에 대한 조직 구성 및 역할, 그리고 테스트 수행에 영향을 줄 수 있는 가정 및 제약사항 등이 포함된다. 즉, 총괄 테스트 계획서는 테스트 전반을 조망하는 큰 그림을 담은 문서라고 할 수 있다.
이 총괄 계획서를 기반으로 단계별 테스트 계획서가 만들어진다. 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트와 같이 각 테스트 단계별로 세분화된 계획서가 따로 작성되며, 여기에는 훨씬 구체적인 내용들이 담긴다. 해당 단계에서의 테스트 범위 및 전략, 수행해야 할 활동과 목적, 테스트 대상의 특성, 테스트 설계 방법, 수행 시의 제약사항, 테스트의 입출력 산출물, 활용할 테스트 도구, 세부 일정, 그리고 최종적으로 만들어지는 산출물 등이 해당된다.
결국 총괄 테스트 계획서가 전체 방향과 기준을 제시하는 문서라면, 단계별 테스트 계획서는 그 기준 아래에서 각 테스트 단계를 실제로 어떻게 수행할 것인지를 상세하게 풀어낸 실행 지침서라고 볼 수 있다. 두 문서가 유기적으로 연결될 때 비로소 체계적이고 일관성 있는 테스트 수행이 가능해진다.
Input/Output Work Products and Exit Criteria for Unit and System Test Plans
Let us examine how a Level Test Plan is structured in practice, using unit testing and system testing as examples.
Unit Test Plan
To conduct unit testing, the input work products required are the unit test plan and unit test cases. After executing the test cases, the output work product; the test results report; is produced. Tools such as JUnit, a Java-based testing framework, are used in this process.
A key aspect of unit testing is the exit criteria. Since unit testing involves directly examining the source code, coverage - a measure of how much code has been tested - is used as the exit criterion. The two most common types are statement coverage (the ratio of executed statements to total statements) and branch coverage (the ratio of tested branches or decision points). A target value is set based on these metrics, and the test is considered complete when the target is met.
System Test Plan
System testing is performed based on the results of requirements analysis in the V-model. Like unit testing, the input work products are the system test plan and test cases, and the output work product after execution is the test results report. Tools such as JMeter may be used at this level.
The exit criteria for system testing are based on requirements coverage — the percentage of total requirements for which testing has been performed. A target percentage is set and serves as the completion benchmark.
While detailed schedules, test owners, and specific execution methods are also included in the plan, even the input/output work products and exit criteria alone illustrate how concretely and measurably a Level Test Plan must be written.
[예시] 단위 테스트 및 시스템 테스트 계획서의 입/출력 산출물과 완료 기준
단계별 테스트 계획서가 실제로 어떻게 구성되는지를 단위 테스트와 시스템 테스트를 예시로 살펴보자.
단위 테스트 계획서
단위 테스트를 수행하기 위해서는 먼저 입력 산출물로 단위 테스트 계획서와 단위 테스트 케이스가 필요하다. 테스트 케이스를 기반으로 테스트를 수행하고 나면 출력 산출물인 테스트 결과서가 만들어진다. 이 과정에서는 Java 기반의 JUnit과 같은 테스트 도구가 활용된다.
단위 테스트에서 주목해야 할 부분은 완료 기준이다. 단위 테스트는 실제 코드를 직접 들여다보며 수행하기 때문에, 얼마나 많은 코드를 테스트했는지를 나타내는 커버리지(Coverage) 를 완료 기준으로 활용한다. 대표적으로 문장 커버리지와 분기 커버리지가 있는데, 문장 커버리지는 전체 문장 수 대비 테스트가 수행된 문장 수의 비율로, 분기 커버리지는 조건문이나 분기문이 얼마나 테스트되었는지의 비율로 산출된다. 이 수치를 기반으로 목표치를 설정하고, 그 목표를 달성했을 때 테스트가 완료된 것으로 판단한다.
시스템 테스트 계획서
시스템 테스트는 V 모델 기준으로 요구사항 분석 결과를 바탕으로 수행된다. 단위 테스트와 마찬가지로 테스트를 실제로 수행하기 위한 입력 산출물로 시스템 테스트 계획서와 테스트 케이스가 필요하며, 수행 후에는 출력 산출물인 테스트 결과서가 생성된다. 이 단계에서는 JMeter와 같은 도구가 활용될 수 있다.
시스템 테스트의 완료 기준은 요구사항 커버리지를 기반으로 한다. 전체 요구사항 중 실제로 테스트가 수행된 요구사항이 몇 퍼센트인지를 산출하여 목표치를 설정하고, 이를 완료 기준으로 삼는 것이다.
물론 이 외에도 테스트 수행을 위한 세부 일정, 담당자, 구체적인 수행 방법 등 다양한 요소들이 계획서에 포함되지만, 입출력 산출물과 완료 기준만 보더라도 단계별 테스트 계획서가 얼마나 구체적이고 측정 가능한 형태로 작성되어야 하는지를 잘 알 수 있다.
Why the Test Plan Matters
There is a clear reason why the test plan is developed so meticulously. A test plan is not merely about creating a document. It becomes the baseline for all test design and execution that follows. Testing is designed and executed based on the scope, strategy, and exit criteria defined in the plan, and the test plan also serves as the foundation for monitoring whether testing is proceeding as planned.
Without a plan, it is nearly impossible to judge whether testing is heading in the right direction. No matter how skilled the testers are, their efforts are unlikely to yield proper results without a clear plan. This is precisely why the importance of the Plan phase is repeatedly emphasized in software testing. The test plan is both the starting point and the backbone of successful testing.
테스트 계획, 왜 중요한가
테스트 계획을 이렇게 꼼꼼하게 수립하는 데는 분명한 이유가 있다. 테스트 계획은 단순히 문서를 만드는 작업에 그치는 것이 아니라, 이후에 이루어지는 테스트 설계와 수행 전반의 기준점이 되기 때문이다. 계획서에 정의된 범위, 전략, 완료 기준 등을 토대로 테스트가 설계되고 실행되며, 테스트가 계획대로 제대로 진행되고 있는지를 모니터링하는 기반 역할도 바로 테스트 계획이 담당한다.
결국 계획 없이는 테스트가 올바른 방향으로 가고 있는지조차 판단하기 어렵다. 아무리 뛰어난 테스터가 있더라도 명확한 계획이 없다면 그 노력이 제대로 된 결과로 이어지기 힘들다. 이것이 바로 소프트웨어 테스트에서 Plan의 중요성을 거듭 강조하는 이유이며, 테스트 계획은 성공적인 테스트의 시작이자 전체를 관통하는 근간이라고 할 수 있다.
2️⃣ Risk Management Overview
What is Risk?
Earlier, we learned that the ISO/IEC/IEEE 29119 standard emphasizes a risk-based test strategy in the test planning process. Let us now examine what risk management is and how its process unfolds.
First, what is Risk? It is actually a concept we encounter in everyday life ; "there is a risk of rain today," "this investment carries a high risk," "there are safety risks on a construction site." As these examples show, risk is not a special concept; it refers to an uncertain event or situation that may occur in the future.
The same applies to software testing. Unexpected events can occur during test execution, and such uncertainties can affect the quality and outcomes of testing. This is why identifying and managing risks in advance is a core element of test planning.
위험(Risk)이란 무엇인가
앞서 테스트 계획을 수립하는 과정에서 ISO/IEC/IEEE 29119 표준이 위험 기반의 테스트 전략을 강조한다는 것을 배웠다. 그렇다면 본격적으로 위험 관리란 무엇인지, 그리고 그 프로세스는 어떻게 진행되는지 살펴보자.
먼저 위험(Risk) 이란 무엇일까. 사실 위험이라는 단어는 우리가 일상생활에서도 흔하게 접하는 개념이다. 예를 들어 "오늘 비가 올 위험이 있다", "이 투자는 위험 부담이 크다", "공사 현장에는 안전 위험이 존재한다"와 같이, 우리는 이미 다양한 맥락에서 위험이라는 개념을 자연스럽게 사용하고 있다. 이처럼 위험은 특별한 개념이 아니라, 미래에 발생할 수 있는 불확실한 사건이나 상황을 가리키는 말이다.
소프트웨어 테스트에서도 마찬가지다. 테스트를 수행하는 과정에서도 예상치 못한 일들이 발생할 수 있고, 이러한 불확실성이 테스트의 품질과 결과에 영향을 미칠 수 있다. 그렇기 때문에 위험을 미리 파악하고 관리하는 것이 테스트 계획의 핵심이 되는 것이다. 이어서 위험 관리의 구체적인 프로세스를 살펴보도록 하자.
Risk vs. Issue. Potential Problem vs. Actual Problem
To understand risk more clearly, let us compare two contrasting concepts: Potential Problem and Actual Problem.
A Potential Problem is something that has not yet occurred but may happen in the future; this is Risk. An Actual Problem, on the other hand, is a problem that has already occurred; this is an Issue. Schedule delays, budget overruns, major scope changes, quality defects discovered in production, and customer complaints are all examples of Issues that have already materialized.
In practice, many organizations and individuals operate primarily in Issue mode; reacting to problems as they arise, only to be consumed by the next issue in an endless cycle. We see this pattern repeatedly in real-world disasters and accidents: countermeasures are developed only after the incident has occurred, after lives have been lost and economic damage has been done. This is the hallmark of Issue-driven work.
Working more systematically means operating in Risk mode; anticipating potential problems before they occur and preparing countermeasures in advance. As discussed, the act of planning is inherently about preparing for future events that have not yet happened, which means plans must always incorporate Risk.
Ultimately, risk-based planning is not a concept limited to testing. In any project or work environment, the key to systematic management is shifting from reacting to Issues after they erupt to proactively identifying and preparing for Risks.
Risk vs Issue, 잠재적 문제와 실제 문제
위험(Risk)을 좀 더 명확하게 이해하기 위해 상반되는 두 개념을 비교해보자. 바로 Potential Problem(잠재적 문제) 과 Actual Problem(실제 문제) 이다.
Potential Problem은 지금 당장 발생하지는 않았지만, 미래에 발생할 수도 있는 문제를 의미한다. 이것이 바로 Risk다. 반면 Actual Problem은 이미 발생한 문제, 즉 Issue를 가리킨다. 일정 지연, 예산 초과, 프로젝트의 대규모 변경, 품질 문제 발생, 고객 클레임 접수 등이 모두 이미 터진 Issue에 해당한다.
많은 조직과 개인이 실제로는 Issue 중심으로 일을 한다. 문제가 터지고 나서야 부랴부랴 대응하고, 또 다른 문제가 터지면 다시 그것을 처리하느라 바쁜 악순환이 반복되는 것이다. 우리 주변에서 일어나는 각종 재난이나 사고를 돌아봐도 마찬가지다. 사고가 발생하고 나서야 대책을 마련하고, 이미 소중한 생명과 막대한 경제적 손실이 발생한 뒤에야 제도가 바뀌는 모습을 우리는 너무나 자주 목격한다. 이것이 전형적인 Issue 중심의 일 처리 방식이다.
반면 보다 체계적으로 일을 한다는 것은 Risk 중심으로 일을 한다는 것을 의미한다. 문제가 터지기 전에 미리 잠재적인 위험을 예측하고, 그에 대한 대책을 사전에 마련하는 것이다. 앞서 배운 것처럼 계획을 세운다는 행위 자체가 아직 발생하지 않은 미래의 일들을 대비하는 것이기 때문에, 계획 안에는 반드시 Risk가 포함되어 있어야 한다.
결국 위험 기반으로 계획을 세우는 것은 단순히 테스트에만 국한된 이야기가 아니다. 어떤 프로젝트든, 어떤 업무든 체계적으로 관리하고자 한다면 Issue가 터난 후에 반응하는 방식에서 벗어나, Risk를 미리 식별하고 대비하는 방식으로 일하는 것이 핵심임을 반드시 기억하자.
프로젝트에서의 위험(Risk) 정의
프로젝트가 성공적으로 완료되기 위해서는 내외부 참여자, 예산, 시스템, 기술, 고객 등 수많은 구성 요소들이 유기적으로 잘 맞물려 돌아가야 한다. 그리고 일반적으로 프로젝트의 성공 여부는 품질(Quality), 비용(Cost), 납기(Delivery) 세 가지를 모두 만족했는지를 기준으로 판단한다.
여기서 위험(Risk)의 정의가 자연스럽게 도출된다. 이 세 가지 요소 중 적어도 하나에라도 영향을 줄 수 있는 잠재적인(Potential) 이벤트 또는 상태를 바로 위험, 즉 Risk라고 정의한다.
중요한 것은 "줄 수 있는"이라는 표현에 담긴 잠재성이다. 실제로 영향을 준 것이 아니라, 영향을 줄 수도 있는 가능성만으로도 Risk로 간주한다는 점이다. 예를 들어 핵심 개발자의 이탈 가능성, 기술적 난이도로 인한 일정 지연 가능성, 요구사항의 잦은 변경 가능성 등이 모두 Risk에 해당한다. 아직 아무 일도 일어나지 않았지만, 그것이 현실이 되었을 때 프로젝트의 품질, 비용, 납기에 영향을 미칠 수 있다면 그 자체로 Risk인 것이다.
결국 프로젝트에서 위험을 관리한다는 것은, 이처럼 프로젝트의 성공을 위협할 수 있는 잠재적 요소들을 미리 식별하고 대비하는 활동이라고 할 수 있다.
2. Risk Management Process
Definition of Risk in a Project Context
For a project to be completed successfully, numerous components, internal and external stakeholders, budget, systems, technology, and customers - must work together in harmony. Generally, the success of a project is judged by whether it satisfies all three of the following criteria: Quality (Q), Cost (C), and Delivery (D).
위험 관리 프로세스
위험 관리 프로세스란 소프트웨어 프로젝트의 목표인 품질, 비용, 일정을 성공적으로 만족시키기 위해, 프로젝트에 존재하는 위험을 미리 식별하고 분석하여 대비해나가는 일련의 활동을 말한다.
이 프로세스는 크게 세 단계로 진행된다.
Risk Identification
Risk identification is the activity of finding potential problems that could affect the achievement of project goals — quality, cost, and schedule. It involves continuously asking, "What risks could arise when performing this activity?" as the project plan is developed.
This is easier said than done, because without it being a habit, it is easy to skip over. Many people are accustomed to working through a to-do list and lack the practice of proactively looking for potential problems. However, failing to identify risks allows small risks to grow into Issues — what could have been contained at 1 grows into 10 and then 100.
Methods for Identifying Risks
There are three commonly used methods for systematically identifying risks.
The first is using a Risk Database. Organizations that manage risks well maintain a risk database containing records of past risks and how they were resolved. Referencing this database makes it easier to identify risks that could arise in the current project.
The second is using an Issue Database. Even organizations without a risk database typically have records of past issues — in the form of spreadsheets or meeting minutes. These past issues can recur in the next project, making them potential risks. An issue database alone can be sufficient for deriving current project risks.
The third is using a Risk Checklist. By reviewing a checklist item by item with Yes/No responses, potential risks for the project can be identified. Items marked "No" represent risk factors that could materialize.
Risk Examples in a Testing Project
To illustrate how risk identification works in practice, consider the following examples from a testing project.
The first is a sudden change in customer priorities. A situation may arise where, after a test strategy and test cases have already been developed, a customer suddenly requests that a specific feature be tested first. Although it has not happened yet, it is entirely plausible, and a response strategy should be prepared in advance.
The second is the risk associated with an external test outsourcing vendor. When an external vendor is contracted because internal resources are insufficient for testing, the vendor may go bankrupt or fail to fulfill the contract. This can lead to schedule delays and cost overruns, so contingency plans must be prepared.
The third is insufficient tester competency. A test team may include both experienced professionals and junior employees with limited testing experience. Testing performed without adequate competency can directly affect quality and must therefore be identified as a significant risk factor.
Risk Identification Must Become a Habit
Ultimately, the starting point of risk identification is simple: habitually asking "What risks could arise as I carry out this work?" whenever planning. By repeatedly leveraging past issue databases and checklists to uncover as many risks as possible, the capability to execute projects on a risk-based foundation will naturally develop over time.
위험 식별(Risk Identification)
위험 식별이란 프로젝트의 목표인 품질, 비용, 일정의 달성에 영향을 줄 수 있는 잠재적인 문제를 찾아내는 활동이다. 프로젝트 계획을 수립해나가면서 "이 활동을 할 때는 어떤 위험이 있을 수 있을까?"를 끊임없이 자문하는 과정이 바로 위험 식별이다.
이것이 말처럼 쉽지 않은 이유는 습관이 되어있지 않으면 자연스럽게 넘어가기 쉽기 때문이다. 많은 사람들이 해야 할 일의 목록만 생각하며 일을 처리하는 데 익숙하다 보니, 잠재적인 문제를 미리 찾는 연습이 부족한 경우가 많다. 하지만 위험 식별을 놓치면 작은 위험이 Issue로 번져 1로 막을 수 있었던 것이 10이 되고 100이 되는 상황을 맞이하게 된다.
위험을 찾아내는 방법
위험을 체계적으로 식별하기 위해 일반적으로 활용하는 방법은 크게 세 가지다.
첫 번째는 위험 DB 활용이다. 위험 관리를 잘 하는 조직이라면 과거에 발생했던 위험과 그 해결 방법이 기록된 위험 DB를 보유하고 있다. 이 DB를 참고하면 현재 프로젝트에서 발생할 수 있는 위험을 보다 수월하게 찾아낼 수 있다.
두 번째는 이슈 DB 활용이다. 위험 DB가 없는 조직이라도 과거에 발생한 문제들을 기록한 이슈 DB는 갖고 있는 경우가 많다. 엑셀 파일이나 회의록 형태로 남아있는 과거의 이슈들은 다음 프로젝트에서도 똑같이 발생할 수 있는 잠재적 위험이 된다. 즉, 이슈 DB만으로도 현재 프로젝트의 위험을 충분히 도출해낼 수 있다.
세 번째는 위험 체크리스트 활용이다. 체크리스트를 항목별로 Yes/No로 점검하며 이 프로젝트에서 발생 가능한 위험을 확인하는 방식이다. No로 표시된 항목들은 곧 발생할 수 있는 위험 요소가 된다.
실제 테스트 프로젝트에서의 위험 예시
위험 식별이 실제로 어떻게 이루어지는지 테스트 프로젝트를 예시로 살펴보자. 먼저 고객 우선순위의 갑작스러운 변경이다. 테스트 전략과 테스트 케이스를 이미 만들어 놓은 상황에서 고객이 갑자기 특정 기능을 먼저 테스트해달라고 요청하는 경우가 생길 수 있다. 아직 발생하지는 않았지만 충분히 일어날 수 있는 위험이며, 이에 대한 대응 전략을 미리 마련해두어야 한다.
다음으로 외부 테스트 아웃소싱 업체의 리스크다. 내부 인력만으로 테스트를 수행하기 어려워 외부 업체와 계약했을 때, 그 업체가 파산하거나 계약을 이행하지 못하는 상황이 발생할 수 있다. 이 경우 일정 지연과 비용 낭비로 이어질 수 있기 때문에 사전에 대처 방안을 준비해야 한다.
마지막으로 테스터의 역량 부족이다. 테스트 팀 안에는 전문가도 있지만 경험이 부족한 신입 직원도 있을 수 있다. 역량이 충분히 갖추어지지 않은 상태에서 테스트를 수행하면 품질에 직접적인 영향을 미칠 수 있으므로, 이 역시 중요한 위험 요소로 식별해야 한다.
위험 식별, 습관이 되어야 한다
결국 위험 식별의 출발점은 단순하다. 계획을 세울 때 "이 일을 수행하다 보면 어떤 위험이 생길 수 있을까?"라는 질문을 습관적으로 던지는 것이다. 과거의 이슈 DB나 체크리스트를 적극 활용하여 최대한 많은 위험을 찾아내려는 노력을 반복하다 보면, 자연스럽게 위험에 기반하여 프로젝트를 수행하는 역량이 갖추어지게 된다.
Risk Analysis
Once risk identification has produced a large number of risk factors, the next step is risk analysis. It is not feasible to prepare countermeasures for all 20–30 identified risks, given the constraints of cost, schedule, and resources that every project faces. The core of risk analysis is therefore evaluating the magnitude of each identified risk to determine which risks to prioritize for management.
Two Evaluation Criteria for Risk Analysis
Risk magnitude is measured using two factors: probability of occurrence and impact.
Probability of occurrence refers to the likelihood that the risk will actually materialize. It is typically scored as 1 (Low) for below 30%, 2 (Medium) for 30%–80%, and 3 (High) for above 80%. Impact refers to how significantly the risk would affect Quality, Cost, and Delivery if it occurred, and is similarly scored as 1 (Low) for below 10%, 2 (Medium) for 10%–20%, and 3 (High) for above 20%.
Deriving Risk Levels via a Risk Matrix
By quantifying both criteria, they can be represented in a Risk Matrix. Risk levels are derived by multiplying or combining the probability and impact scores. For instance, a probability of 1 (Low) and impact of 1 (Low) results in a low-level risk, while a probability of 2 (Medium) and impact of 2 (Medium) results in a level 4 (Medium) risk. The example from the risk identification phase — a sudden change in customer priorities — would be evaluated as probability 2 (Medium) and impact 3 (High), resulting in a level 6 (High) risk.
Why Risk Analysis is Essential
Once the risk level hierarchy is established, it becomes clear which of the 20 identified risks require priority management. High-level risks are managed first, followed by medium-level risks. While it would be ideal to address every risk if time, cost, and resources were unlimited, projects always operate within constraints. Risk analysis is therefore an essential activity in systematic project management, ensuring that limited resources are focused on the most critical risks.
위험 분석(Risk Analysis)
위험 식별을 통해 수많은 위험 요소들이 도출되고 나면, 그 다음 단계는 위험 분석이다. 20~30개에 달하는 위험 요소 모두에 대해 대책을 마련하는 것은 현실적으로 불가능하다. 프로젝트에는 항상 비용, 일정, 자원과 같은 제약이 존재하기 때문이다. 따라서 식별된 위험들의 크기를 평가하여 어떤 위험을 중점적으로 관리할 것인지 우선순위를 정하는 것이 위험 분석의 핵심이다.
위험 분석의 두 가지 평가 기준
위험의 크기를 측정하기 위해서는 두 가지 요소를 평가한다. 바로 발생 확률과 영향도다.
발생 확률은 해당 위험이 실제로 일어날 가능성을 의미하며, 일반적으로 30% 이하는 1(하), 30%80%는 2(중), 80% 이상은 3(상)과 같이 점수로 구분한다. 영향도는 위험이 발생했을 때 품질(Quality), 비용(Cost), 납기(Delivery)에 얼마나 큰 영향을 미치는지를 나타내며, 10% 이하는 1(하), 10%20%는 2(중), 20% 이상은 3(상)으로 동일하게 점수화한다.
위험 매트릭스를 통한 등급 산출
이렇게 두 가지 기준을 점수화하면 이를 매트릭스 형태로 표현할 수 있다. 발생 확률과 영향도를 곱하거나 조합하여 위험의 등급을 산출하는 방식이다. 예를 들어 발생 확률이 1(하)이고 영향도가 1(하)이면 전체적으로 낮은 수준의 위험이 되고, 발생 확률이 2(중)이고 영향도가 2(중)이면 4(중) 수준의 위험이 된다. 앞서 위험 식별 단계에서 예시로 들었던 고객 우선순위의 갑작스러운 변경의 경우, 발생 확률 2(중)에 영향도 3(상)으로 평가되어 6(상) 수준의 고위험에 해당한다.
위험 분석이 필수적인 이유
이와 같이 위험 등급 체계를 정하고 나면 20개의 위험 요소 중 어떤 것을 중점적으로 관리해야 할지가 명확해진다. 고수준으로 분류된 위험들을 최우선으로 관리하고, 그 다음 순위로 중간 수준의 위험들을 관리하는 방식이다. 시간과 비용, 자원이 충분하다면 모든 위험에 대응할 수 있겠지만, 현실적으로 프로젝트는 항상 한정된 자원 안에서 운영된다. 그렇기 때문에 위험 분석을 통해 우선순위를 정하고 한정된 자원을 가장 중요한 위험에 집중적으로 투입하는 이 과정은 체계적인 프로젝트 관리에 있어 필수적인 활동이라고 할 수 있다.
Risk Mitigation Identification
Having identified and prioritized risks, the final step is developing countermeasures. Risk mitigation means preparing responses that either reduce the probability of a risk occurring or minimize its impact if it does occur, bringing it down to an acceptable level. There are four categories of risk mitigation strategies.
1) Risk Avoidance
This approach completely eliminates the possibility of a risk occurring. For example, performing integration testing using the Big Bang approach; integrating dozens or hundreds of modules all at once; makes it extremely difficult to trace which module caused a defect. To eliminate this risk from the outset, adopting an incremental integration test strategy instead of Big Bang is a classic example of risk avoidance. The key is creating an environment where the risk cannot occur in the first place.
2) Risk Mitigation
Rather than eliminating a risk entirely, this approach reduces it to an acceptable level. For example, when there is a risk that customer requirement priorities may suddenly change, the goal is to reduce the probability of that change from 50% to 10–20%. This can be achieved by engaging the customer actively from the early stages of development to lock down requirements as much as possible, thereby reducing the probability of change at the source.
3) Risk Transference
This approach does not solve the risk directly but instead transfers the responsibility or impact to another party. It is most commonly used when the probability is low but the potential damage is high. For example, to guard against the possibility of a test outsourcing vendor failing to fulfill the contract, requiring the vendor to purchase performance bond insurance, even at additional cost; transfers the financial risk to a third party. In practice, many organizations mandate performance bond insurance for inter-agency contracts. This is not an evasion of responsibility but a rational strategy for reducing the impact of risks that are difficult to manage internally.
4) Risk Acceptance
This approach accepts risks that fall within a tolerable level. For example, if testers lack sufficient competency but must be included in order to complete testing successfully, the risk can be accepted by investing in test training to build their skills over time. If it is judged that they will be able to perform adequately once trained, then the risk is accepted and managed accordingly.
These four mitigation strategies must be selected appropriately based on the magnitude and nature of each risk identified and analyzed. Most importantly, the key is to understand what risk is, practice the three-phase risk management process of Identification → Analysis → Mitigation systematically, and use it to prevent small risks from becoming large Issues. The risk management concepts learned here will serve as a critical foundation when developing the risk-based test strategy covered in future sessions.
위험 완화 방안 식별(Risk Mitigation Identification)
위험을 식별하고 우선순위를 분석했다면, 이제 그 위험들에 대한 대책을 마련하는 단계가 남아있다. 위험 완화란 위험이 발생할 확률을 낮추거나, 발생하더라도 그 영향도를 최소화하여 허용 가능한 수준으로 낮추기 위한 대책을 마련하는 것이다. 위험 완화 방안은 크게 네 가지로 구분된다.
1) 위험 회피 (Avoidance)
위험이 발생할 가능성을 애초에 완전히 제거하는 방법이다. 예를 들어 통합 테스트를 빅뱅(Big Bang) 방식으로 진행하면, 수십~수백 개의 모듈을 한꺼번에 통합하기 때문에 문제가 발생했을 때 어느 모듈에서 비롯된 것인지 추적하기가 매우 어렵다. 이러한 위험을 처음부터 없애기 위해 빅뱅 방식 대신 점진적 통합 테스트 전략을 채택하는 것이 위험 회피의 대표적인 예다. 처음부터 위험이 발생할 수 없는 환경을 만드는 것이 핵심이다.
2) 위험 완화 (Mitigation)
위험을 완전히 없애는 것이 아니라, 허용 가능한 수준 이하로 낮추는 방법이다. 예를 들어 고객의 요구사항 우선순위가 갑자기 변경될 위험이 있을 때, 그 변경 가능성을 50%에서 10~20%로 줄이는 것을 목표로 한다. 이를 위해 개발 후반부가 아닌 초기 단계부터 고객을 적극적으로 참여시켜 요구사항을 최대한 확정짓는 방식으로 위험의 발생 확률 자체를 낮출 수 있다.
3) 위험 전이 (Transference)
위험을 내가 직접 해결하는 것이 아니라, 외부의 힘을 빌려 위험의 책임이나 영향을 다른 주체에게 이전하는 방법이다. 발생 확률은 낮지만 피해가 클 경우에 주로 활용된다. 예를 들어 테스트 아웃소싱 업체가 계약을 이행하지 못하는 상황에 대비하여, 비용이 다소 들더라도 업체가 이행보증보험에 가입하도록 하여 피해를 최소화하는 것이 대표적인 사례다. 실제 현업에서도 기관 간 계약 시 이행보증보험 가입을 의무화하는 경우가 많다. 이는 책임 회피가 아니라, 감당하기 어려운 위험의 영향도를 줄이기 위한 합리적인 선택이다.
4) 위험 수용 (Acceptance)
허용 가능한 수준의 위험을 그대로 받아들이는 방법이다. 예를 들어 테스터의 역량이 부족하더라도, 해당 인력을 포함하여 테스트를 성공적으로 수행해야 하는 상황이라면 테스트 교육을 통해 역량을 키우는 것을 선택할 수 있다. 당장은 부족하더라도 시간이 지나면 충분히 수행 가능하다고 판단한다면, 그 위험을 감내하고 수용하는 것이다.
이 네 가지 위험 완화 방안은 앞서 식별하고 분석한 위험의 크기와 성격에 따라 적절하게 선택되어야 한다. 무엇보다 중요한 것은 위험이 무엇인지 이해하고, 식별 → 분석 → 완화의 세 단계로 이루어진 위험 관리 프로세스를 체계적으로 실천하는 것이다. 이를 통해 나중에 큰 Issue로 번질 수 있는 문제들을 사전에 차단하고, 프로젝트를 안정적으로 이끌어 나갈 수 있다. 앞으로 학습할 위험 기반의 테스트 전략 수립에서도 오늘 배운 위험 관리의 개념과 프로세스가 핵심적인 토대로 활용될 것이다.
3️⃣ Risk-based testing strategy
What is Risk-Based Testing?
Risk-Based Testing is a strategy that identifies potential problems that could arise in a project and applies the risk management process; Risk Identification → Analysis → Mitigation; integrated into the testing effort.
Just as resources are constrained in a project, testing resources - cost, tools, equipment, and personnel — are always limited. In this environment, the essence of the risk-based test strategy is to invest available resources most efficiently based on risk, in order to achieve the testing objective of discovering as many defects as possible.
위험 기반 테스트(Risk-Based Test)란?
위험 기반 테스트란 프로젝트에서 발생할 수 있는 잠재적인 문제들을 찾아내고, 위험 관리 프로세스인 위험 식별 → 분석 → 완화의 과정을 테스트에 융합하여 적용하는 전략이다.
프로젝트에서 자원이 제한되어 있듯이, 테스트에서도 비용, 도구, 장비, 인원은 항상 제한되어 있다. 이러한 환경에서 가지고 있는 자원을 가장 효율적으로 활용하기 위해, 다양한 결함을 발견한다는 테스트의 목표를 달성하기 위해 위험에 기반하여 자원을 집중적으로 투입하는 것이 바로 위험 기반 테스트 전략의 본질이다.
Goals Achievable Through Risk-Based Testing
There are three key benefits expected from risk-based testing.
The first is improved software product quality. By identifying and analyzing risks and establishing priorities, the factors most likely to contribute to product defects are naturally surfaced. Focusing testing efforts on these factors naturally elevates product quality.
The second is improved overall test coverage. Concentrating on higher-priority areas means testing the features that customers and stakeholders care about most first. This ensures meaningful test coverage where it matters most.
The third is improved test efficiency. By directing limited resources toward high-risk areas, greater test effectiveness is achieved with the same resources. Risk-based testing is ultimately the most rational test strategy for achieving maximum quality impact with limited resources.
위험 기반 테스트를 통해 얻을 수 있는 목표
위험 기반 테스트를 통해 기대할 수 있는 효과는 크게 세 가지다.
첫 번째는 소프트웨어 제품 품질 향상이다. 위험을 식별하고 분석하여 우선순위를 정하다 보면 자연스럽게 제품의 결함에 가장 큰 영향을 미칠 수 있는 요소를 찾게 된다. 이 요소들을 중점적으로 테스트함으로써 제품의 품질이 자연스럽게 높아진다.
두 번째는 전체 테스트 커버리지 개선이다. 우선순위가 낮은 부분보다 높은 부분에 집중한다는 것은, 고객과 이해관계자들이 가장 중요하게 생각하는 영역을 먼저 충분히 테스트한다는 의미다. 이를 통해 실질적으로 의미 있는 테스트 커버리지를 확보할 수 있다.
세 번째는 테스트 효율성 향상이다. 한정된 자원을 위험 수준이 높은 영역에 집중 투입함으로써, 같은 자원으로 더 큰 테스트 효과를 얻을 수 있다. 결국 위험 기반 테스트는 "적은 자원으로 최대의 품질 효과를 내기 위한" 가장 합리적인 테스트 전략이라고 할 수 있다.
Risk Analysis Criteria from a Testing Perspective
Risk analysis involves evaluating the probability of occurrence and impact of identified risks to establish priorities. Let me examine how these two criteria are applied specifically from a testing perspective.
Probability of Occurrence; Likelihood of Defects
In a testing context, probability of occurrence refers to the likelihood that defects will arise during testing. The following factors contribute to this likelihood.
First is source code complexity. Code with nested loops inside conditionals, or so-called spaghetti code, is structurally complex and more prone to defects. Inter-module coupling complexity is also significant — the more tightly interdependent the modules, the more likely unexpected defects are to emerge. Implementation technology difficulty is another contributing factor. Lines of Code (LOC) also matter — the more lines of code, the greater the likelihood of defects. Finally, developer competency cannot be overlooked; the difference in skill between junior, mid-level, and senior developers directly affects defect probability.
Impact ; Effect on Business When a Defect Occurs
Impact refers to how significantly a functional failure would affect the business. The factors that compose impact include the following.
First is user criticality — how important the function is to the user determines the degree of impact. Economic and safety damage is also a key criterion; if a failure leads to financial loss or safety incidents, the impact is correspondingly high. Damage to the organization's reputation must also be considered — incidents involving hacking, payment failures, or authentication issues can severely undermine organizational credibility. Finally, frequency of use contributes to impact; the more frequently a function is used, the more people are affected when a defect occurs.
Risk Exposure
By comprehensively evaluating the factors composing probability and impact, the magnitude of each risk is classified as Low, Medium, or High. This is referred to as Risk Exposure, and it determines the priority of which areas to focus testing on. By concentrating test resources on areas with high Risk Exposure, the most effective testing possible is achieved within the constraints of available resources.
테스트 관점에서의 위험 분석 기준
위험 분석은 식별된 위험들에 대해 발생 확률과 영향도를 평가하여 우선순위를 정하는 과정이다. 테스트 측면에서 이 두 가지 기준을 어떻게 적용하는지 구체적으로 살펴보자.
발생 확률; 결함이 생길 가능성
테스트에서의 발생 확률이란 테스트를 수행할 때 결함이 발생할 가능성을 의미한다. 즉, 어떤 프로그램이나 모듈에서 결함이 많이 생길 것인가를 따져보는 것이다. 이에 영향을 미치는 요소들은 다음과 같다.
먼저 소스코드의 복잡성(Complexity) 이다. 분기문 안에 반복문이 중첩되어 있거나 이른바 스파게티 코드처럼 구조가 복잡할수록 결함이 발생할 가능성이 높아진다. 또한 모듈 간 상호 관계의 복잡성도 중요한 요소인데, 여러 모듈이 얽히고 설킨 구조일수록 예상치 못한 결함이 생기기 쉽다. 구현 기술의 난이도가 높은 경우도 마찬가지다. 그리고 코드의 규모(Lines of Code) 도 중요한데, 코드 라인이 많아질수록 그만큼 결함이 발생할 가능성도 함께 커진다. 마지막으로 개발자의 역량도 빼놓을 수 없다. 초급, 중급, 고급 개발자의 실력 차이는 결함 발생 확률에 직접적인 영향을 미친다.
영향도; 결함 발생 시 비즈니스에 미치는 영향
영향도란 기능 장애가 발생했을 때 비즈니스 전반에 얼마나 큰 영향을 미치는가를 평가하는 기준이다. 영향도를 구성하는 요소들도 다양하다.
먼저 사용자의 취급 중요도다. 사용자가 해당 기능을 얼마나 중요하게 여기는지에 따라 영향도가 달라진다. 경제적·안전적 피해 또한 중요한 기준이다. 기능 고장이 발생했을 때 금전적 손실이나 안전 문제로 이어진다면 그만큼 영향도가 높다. 조직의 대외 이미지 피해도 빼놓을 수 없는데, 해킹이나 결제·인증 문제가 발생하면 조직의 신뢰도에 큰 타격을 줄 수 있다. 마지막으로 기능 사용 빈도도 영향도에 기여한다. 사용자가 자주 쓰는 기능일수록 결함이 발생했을 때 더 많은 사람들에게 영향을 미치기 때문이다.
위험 노출도(Risk Exposure)
이처럼 발생 확률과 영향도를 구성하는 요소들을 종합적으로 평가하면, 각 위험 요소의 크기가 저, 중, 고 수준으로 산출된다. 이를 위험 노출도(Risk Exposure) 라고 하며, 이 수치를 기반으로 어떤 영역을 중점적으로 테스트할 것인지 우선순위가 결정된다. 결국 테스트 자원을 위험 노출도가 높은 영역에 집중 투입함으로써, 한정된 자원 안에서 가장 효과적인 테스트를 수행할 수 있게 되는 것이다.
Example: Risk Analysis; Vaccine Appointment System
Let me examine how risk analysis works in practice using a vaccine appointment booking system.
The main requirements of this system include functions such as member registration, member withdrawal, login, logout, and vaccine appointment booking. For each function, the probability of defects occurring and the impact on the business if they do are evaluated on a scale of 1–5, and the two values are multiplied to derive the risk magnitude. It is important to note that this evaluation must be performed by domain experts familiar with the system.
For example, the member registration function is evaluated with a probability of 3 and impact of 4, resulting in a risk magnitude of 12. The member withdrawal function scores a probability of 2 and impact of 1, yielding a risk magnitude of only 2. The login function, on the other hand, scores a probability of 4 and impact of 5, resulting in the highest risk magnitude of 20. This is because if login is unavailable, all core system functions — appointment booking, inquiry, and cancellation — become completely inaccessible, warranting the highest impact rating.
By deriving risk magnitudes for all requirements in this way, it becomes clearly apparent which functions are high-risk and which are low-risk. This enables the development of a differentiated test strategy — concentrating more test resources on high-risk functions and allocating relatively fewer resources to low-risk ones. Risk analysis is ultimately a rational decision-making tool for distributing limited test resources most effectively.
[예시] 위험 분석 - 백신 접종 예약 시스템
위험 분석이 실제로 어떻게 이루어지는지 백신 접종 예약 시스템을 예시로 살펴보자.
이 시스템의 주요 요구사항으로는 회원 가입, 회원 탈퇴, 로그인, 로그아웃, 접종 예약 등의 기능이 있다. 각 기능에 대해 결함이 발생할 확률과 발생 시 비즈니스에 미치는 영향도를 1~5점 척도로 평가하고, 두 값을 곱하여 위험의 크기를 산출한다. 이 평가는 반드시 해당 시스템과 관련된 전문가가 수행해야 한다는 점이 중요하다.
예를 들어 회원 가입 기능은 발생 확률 3, 영향도 4로 평가되어 위험의 크기가 12가 된다. 회원 탈퇴 기능은 발생 확률 2, 영향도 1로 위험의 크기가 2에 그친다. 반면 로그인 기능은 발생 확률 4, 영향도 5로 위험의 크기가 20으로 가장 높게 산출된다. 로그인이 불가능하면 예약, 조회, 취소 등 시스템의 모든 핵심 기능을 아예 사용할 수 없게 되기 때문에 영향도가 최고 수준으로 평가된 것이다.
이처럼 모든 요구사항 항목에 대해 동일한 방식으로 위험의 크기를 산출하면, 어떤 기능이 고위험이고 어떤 기능이 저위험인지가 명확하게 드러난다. 이를 토대로 위험의 크기가 큰 기능에는 더 많은 테스트 자원을 집중하고, 위험의 크기가 작은 기능에는 상대적으로 적은 자원을 투입하는 차별화된 테스트 전략을 수립할 수 있다. 결국 위험 분석은 한정된 테스트 자원을 가장 효과적으로 배분하기 위한 합리적인 의사결정 도구인 셈이다.
Example: Unit Test Planning Based on Risk Analysis
Let me examine how risk analysis results are applied to actual test planning, again using the vaccine appointment booking system.
Risk Level Classification
Requirements are classified into four risk levels based on the scores derived from risk analysis. Level 1 represents the highest risk area with both high probability and high impact. Level 2 has low probability but high impact. Level 3 has high probability but low impact. Level 4 has both low probability and low impact.
Applying this to the vaccine appointment system: login, vaccine appointment, member registration, and appointment inquiry are classified as Level 1 (High Risk) with both high probability and high impact. Appointment cancellation falls under Level 2, while member withdrawal and logout are classified as Level 3 due to their relatively low risk magnitude.
Exit Criteria by Risk Level
These risk classifications are directly used to differentiate the exit criteria and test methods when developing the test plan.
For Level 1 high-risk items, the strictest criteria are applied. To minimize the likelihood of defects and reduce their impact if they do occur, the most rigorous coverage criterion — MC/DC (Modified Condition/Decision Coverage) at 100% completion — is set as the exit criterion. The goal is to test as wide a range of code as possible, leaving no room for hidden defects.
For Level 2 items, while not as strict as MC/DC, branch and condition coverage at 100% completion is set as the exit criterion. Sufficient testing is performed given the high impact, but with somewhat more flexibility than Level 1.
For Level 3 low-risk items, since the impact is relatively limited, statement coverage at 100% completion is set as the exit criterion, allowing for efficient allocation of test resources.
Significance of Risk-Based Test Planning
By incorporating risk analysis results into the test plan, strict criteria are applied to critical functions while appropriate criteria are applied to less critical ones, enabling the most effective use of limited resources. For instance, if the login function has a defect, all core system functions are paralyzed, customers stop using the service, and the company faces significant losses. In contrast, defects in Level 3 functions such as member withdrawal or logout have relatively limited impact. Ultimately, a risk-based test plan is a rational approach that addresses the greatest risks first and most thoroughly, effectively enhancing software product quality.
Risk Factor-Based Risk Analysis Example
Going one step further from the risk analysis method discussed earlier, let me examine an approach that breaks down risk factors by requirement for more granular analysis.
The basic structure remains the same; probability and impact are evaluated per requirement ; but here, risk is broken down into the following sub-categories for more systematic analysis:
LOP (Loss of Power)
CFD (Corrupted File Data)
UUA (Unauthorised User Access)
DNS (Database Not Synchronized)
UUD (Unclear User Documentation)
ST (Slow Throughput)
Each requirement is assessed against these risk factors, scores are assigned, and all scores are summed to derive the final risk magnitude for that requirement. For example, comparing Requirement 1 and Requirement 2, Requirement 2 scores 67 points, indicating a higher overall risk. This leads to the conclusion that more test resources should be concentrated on functions related to Requirement 2.
This approach goes beyond simply evaluating probability and impact, by itemizing specific risk factors for systematic review, it enables a more rigorous and precise risk analysis.
This concludes our examination of what risk is, how the risk management process is structured, and why this analysis is indispensable for developing a test strategy. Ultimately, a risk-based test strategy is an approach that incorporates all of these processes into the test plan, focusing on the most critical risks within limited resources to effectively improve software quality. The risk management concepts learned here will continue to serve as a critical foundation in the upcoming phases of test design and execution.
[예시]위험 분석 기반의 단위 테스트 계획 수립 예시
위험 분석 결과를 실제 테스트 계획에 어떻게 반영하는지 백신 접종 예약 시스템을 통해 살펴보자.
위험 등급 분류
위험 분석을 통해 산출된 점수를 기반으로 요구사항들을 네 가지 등급으로 분류한다. 1등급은 발생 확률과 영향도가 모두 높은 최고위험 영역이고, 2등급은 발생 확률은 낮지만 영향도가 높은 영역이다. 3등급은 발생 확률은 높지만 영향도가 낮은 영역이며, 4등급은 발생 확률과 영향도가 모두 낮은 저위험 영역이다.
백신 접종 예약 시스템에 적용하면, 로그인, 접종 예약, 회원 가입, 예약 조회는 발생 확률과 영향도가 모두 높은 1등급 고위험 항목에 해당한다. 예약 취소는 2등급에 해당하며, 회원 탈퇴와 로그아웃은 위험의 크기가 상대적으로 작아 3등급으로 분류된다.
등급별 테스트 완료 기준
이렇게 분류된 위험 등급은 테스트 계획을 수립할 때 완료 기준과 테스트 방법을 차별화하는 데 직접적으로 활용된다.
1등급 고위험 항목에 대해서는 가장 엄격한 기준을 적용한다. 결함의 발생 가능성을 최대한 줄이고 결함이 발생하더라도 그 영향도를 낮추어야 하기 때문에, 가장 높은 수준의 커버리지 기준인 MCDC 커버리지 100% 완료를 완료 기준으로 삼는다. 최대한 넓은 범위의 코드를 빠짐없이 테스트하여 결함이 숨어있을 가능성을 철저히 차단하는 것이다.
2등급 항목에 대해서는 MCDC만큼 엄격하지는 않더라도, 분기 및 조건 커버리지 100% 완료를 완료 기준으로 설정한다. 영향도가 높은 만큼 충분한 수준의 테스트를 수행하되, 1등급보다는 다소 유연한 기준을 적용하는 것이다.
3등급 저위험 항목은 상대적으로 영향도가 작기 때문에 문장 커버리지 100% 완료 정도를 완료 기준으로 삼아 테스트 자원을 효율적으로 배분한다.
위험 기반 테스트 계획의 의의
이처럼 위험 분석 결과를 테스트 계획에 반영하면, 중요한 기능에는 타이트한 기준을 적용하고 그렇지 않은 기능에는 적절한 수준의 기준을 적용하여 한정된 자원을 가장 효과적으로 활용할 수 있다. 예를 들어 로그인 기능에 결함이 발생한다면 예약, 조회, 취소 등 시스템의 모든 핵심 기능이 마비되어 고객은 서비스 이용을 멈추게 되고, 회사 입장에서는 막대한 손실로 이어질 수 있다. 반면 회원 탈퇴나 로그아웃과 같은 3등급 기능에 결함이 발생하더라도 그 영향은 상대적으로 제한적이다. 결국 위험 기반 테스트 계획은 가장 큰 위험을 가장 먼저, 가장 철저하게 다루어 소프트웨어 제품의 품질을 효과적으로 높이는 합리적인 접근 방식이라고 할 수 있다.
위험 요인 기반의 위험 분석 예시
앞서 살펴본 위험 분석 방법에서 한 단계 더 나아가, 요구사항별 위험 요인(Risk Factor)을 세분화하여 분석하는 방법을 살펴보자.
기본적인 구조는 동일하다. 요구사항 항목별로 발생 확률과 영향도를 평가하되, 여기서는 위험을 보다 체계적으로 분석하기 위해 위험 요인을 아래와 같이 소분류로 세분화한다.
LOP (Loss of Power) — 전력 손실
CFD (Corrupted File Data) — 파일 데이터 손상
UUA (Unauthorised User Access) — 비인가 사용자 접근
DNS (Database Not Synchronized) — 데이터베이스 미동기화
UUD (Unclear User Documentation) — 불명확한 사용자 문서
ST (Slow Throughput) — 느린 처리 속도
각 요구사항에 대해 이 위험 요인들을 하나씩 점검하고 점수를 부여한 뒤, 모든 점수를 합산하여 해당 요구사항의 최종 위험 크기를 산출한다. 예를 들어 요구사항 1번과 2번을 비교했을 때, 요구사항 2번이 67점으로 더 높은 위험 크기를 가지고 있어 더 큰 위험을 내포하고 있음을 알 수 있다. 이를 통해 요구사항 2번과 관련된 기능에 더 많은 테스트 자원을 집중해야 한다는 판단을 내릴 수 있다.
이 방식은 단순히 발생 확률과 영향도만을 평가하는 것에서 벗어나, 구체적인 위험 요인을 항목화하여 빠짐없이 점검할 수 있다는 점에서 보다 체계적이고 정밀한 위험 분석이 가능하다.
여기까지 위험이 무엇인지, 위험 관리 프로세스가 어떻게 구성되는지, 그리고 왜 이 분석이 테스트 전략 수립에 반드시 필요한지를 살펴보았다. 결국 위험 기반 테스트 전략이란 이 모든 과정을 테스트 계획에 녹여내어, 한정된 자원 안에서 가장 중요한 위험에 집중함으로써 소프트웨어의 품질을 효과적으로 높이는 접근 방식이다. 앞으로 배울 테스트 설계와 수행 단계에서도 오늘 학습한 위험 관리의 개념이 핵심적인 기반으로 계속 활용될 것이다.
