1️⃣ Core Concepts of Test Execution
2️⃣ Test Defect Management
3️⃣ Core Concepts for Test Evaluation/Improvement

소프트웨어 테스팅(Software Testing): 테스트 수행, 결함 관리, 평가와 개선

오늘은 테스트를 수행하고, 그 결과를 평가하며, 문제점을 개선하는 과정에 대해 학습한다. 이번 강의에서 이해해야 할 학습 목표는 크게 세 가지이다.

첫 번째는 **테스트 수행(Test Execution)**이 무엇인지 이해하는 것이다. 테스트 수행이란 실제로 테스트를 진행하는 활동을 의미하며, 이 과정에서 어떤 주요 활동들이 이루어지는지 설명할 수 있어야 한다.

두 번째는 **테스트 결함 관리(Test Defect Management)**에 대해 이해하는 것이다. 테스트를 수행하면 결함(Defect)이 발견될 수 있는데, 이러한 결함을 체계적으로 관리하는 과정이 필요하다. 따라서 테스트 결함 관리가 무엇인지, 그리고 왜 필요한지 그 필요성까지 설명할 수 있어야 한다.

마지막으로 테스트 과정에 대한 **평가와 개선(Evaluation and Improvement)**을 이해해야 한다. 테스트가 제대로 수행되었는지는 정기적으로 평가되어야 하며, 평가 결과 발견된 문제점은 개선되어야 한다. 이를 위해 테스트 과정을 평가하는 방법과, 문제점을 개선하는 활동이 무엇인지 알아야 한다.

정리하면, 이번 강의의 목표는 테스트 수행(Test Execution)의 의미와 주요 활동을 이해하고, 테스트 결함 관리(Test Defect Management)의 필요성을 파악하며, 테스트 과정의 평가와 개선(Evaluation and Improvement) 활동을 설명할 수 있도록 하는 것이다.

1️⃣ Core Concepts of Test Execution

테스트 계획과 설계 기반의 테스트 수행(Test Execution Based on Test Planning and Design)

테스트(Test)는 실제 수행에 들어가기 전에 반드시 선행되어야 할 과정이 있다. 입력값(Input)에 대해 결과(Output)가 적절한지 확인하기 전에, 먼저 테스트를 계획(Test Planning)하고 설계(Test Design)하는 과정이 필요하다.

테스트를 하나의 프로세스(Process)로 볼 때, 우리는 PDCA 관점에서 테스트를 체계적으로 수행해야 한다고 배웠다. 여기서 D에 해당하는 단계가 바로 테스트 수행(Test Execution)이다. 테스트 수행이란 테스트 케이스(Test Case)를 바탕으로 테스트 절차(Test Procedure)에 따라 실제 테스트 환경(Test Environment)에서 테스트를 실행하는 활동이다. 이때 테스트는 사람이 직접 수동(Manual)으로 수행할 수도 있고, 자동화 도구(Automation Tool)를 사용하여 수행할 수도 있다. 중요한 것은 테스트 케이스를 실행한 뒤, 그 결과가 기대한 결과와 일치하는지를 판단하는 것이다.

하지만 테스트 수행이 제대로 이루어지기 위해서는 그 이전 단계가 탄탄하게 준비되어 있어야 한다. 특히 테스트 계획(Test Plan)과 테스트 설계(Test Design)가 기반이 되어야 한다. 이 부분은 V-Model을 학습할 때도 강조되었다. V-Model에서 왼쪽은 개발 활동(Development Activity), 오른쪽은 테스트 활동(Test Activity)을 의미한다. 오른쪽의 테스트 활동에서는 실제 테스트를 수행하지만, 왼쪽의 개발 활동이 진행되는 동안 이미 테스트 계획과 테스트 설계가 충분히 이루어져 있어야 한다.

그 이유는 명확하다. 테스트 계획 수립(Test Planning), 테스트 케이스 개발(Test Case Development), 테스트 절차 정의(Test Procedure Definition), 테스트 환경 준비(Test Environment Setup)와 같은 사전 과정이 모두 준비되어야 실제 테스트 수행 단계에서 체계적인 테스트가 가능하기 때문이다. 이러한 준비가 되어 있으면 입력값을 넣고 출력 결과가 적절한지 확인할 때 시간에 쫓기지 않고, 충분히 준비된 상태에서 안정적으로 테스트를 진행할 수 있다.

다시 말해 테스트 수행(Test Execution)이란 입력에 대해 결과가 적절한지를 확인하는 활동이다. 그러나 이 수행이 제대로 이루어지기 위해서는 그 이전 과정인 테스트 계획(Test Planning)과 테스트 설계(Test Design)가 제대로 수립되어 있어야 한다. 이것이 체계적인 테스트 수행에서 가장 중요한 부분이다.

ISO/IEC/IEEE 29119의 테스트 수행(Test Execution)

ISO/IEC/IEEE 29119는 소프트웨어 테스트와 관련된 국제 표준(International Standard)이다. 이 표준에서 테스트 수행(Test Execution)은 동적 테스트 프로세스(Dynamic Test Process) 안에 포함된다.

동적 테스트 프로세스 안에는 여러 세부 활동이 있다. 먼저 테스트 설계 및 구현(Test Design and Implementation), 테스트 환경 구성 및 유지(Test Environment Setup and Maintenance)는 테스트 수행 전에 이루어지는 테스트 설계(Test Design) 관련 활동에 해당한다. 이러한 활동을 통해 테스트에 필요한 준비가 완료되면, 그 결과를 바탕으로 실제 테스트를 수행하고, 수행 결과가 적절한지 판단한 뒤 테스트 결과를 보고(Test Result Reporting)하게 된다. 이 부분이 테스트 수행(Test Execution)에 해당한다.

이 국제 표준에서도 테스트 수행은 사전 준비가 완료된 상태에서 진행된다는 점을 강조한다. 테스트 수행을 위해서는 테스트 명세서(Test Specification)와 테스트 환경(Test Environment)이 이미 준비되어 있어야 한다. 즉, 테스트 수행 단계에서 테스트 케이스(Test Case)를 새로 만드는 것이 아니라, 앞 단계에서 테스트 계획과 설계가 충분히 이루어진 상태에서 테스트를 실행하는 것이다.

따라서 테스트 수행(Test Execution)은 단독으로 이루어지는 활동이 아니라, 테스트 명세서(Test Specification), 테스트 환경(Test Environment), 테스트 설계(Test Design)와 같은 사전 준비를 기반으로 진행된다. 이러한 준비가 충분히 되어 있을 때 테스트 수행은 보다 체계적이고 안정적으로 이루어질 수 있다. 이 점을 잘 기억해야 한다.

테스트 수행과 테스트 결과 보고(Test Execution and Test Result Reporting)

테스트 수행(Test Execution)이란 테스트 절차(Test Procedure)를 실제로 실행하고, 그 테스트 실행 결과(Test Execution Result)를 기록하는 활동이다. 테스트 수행은 테스트 케이스(Test Case)에 기반하여 정해진 절차대로 진행된다.

예를 들어 로그인 기능(Login Function)을 테스트한다고 하면, 사용자는 먼저 로그인 화면을 표시하고, 아이디(ID)를 입력한 뒤, 탭(Tab) 키를 눌러 비밀번호 입력 칸으로 이동한다. 이후 비밀번호(Password)를 입력하고 엔터(Enter)를 누르는 식으로 일련의 절차를 수행한다. 이러한 과정은 임의로 진행되는 것이 아니라, 미리 작성된 테스트 케이스와 테스트 절차에 따라 실행된다.

테스트를 수행한 뒤에는 그 결과를 테스트 케이스에 기록한다. 실제 결과가 기대한 결과와 일치하는지 확인하고, 해당 테스트가 통과(Pass)했는지 또는 실패(Fail)했는지를 명확히 남긴다.

그 다음 단계는 테스트 결과 보고(Test Result Reporting)이다. 테스트 결과 보고란 테스트 실행 결과를 분석한 내용을 바탕으로 결함(Defect)을 식별하고, 그 결함에 대한 상세 정보를 기록하는 과정이다. 즉, 테스트 수행을 통해 얻은 결과를 정리하고, 발견된 문제를 체계적으로 보고하는 활동이라고 할 수 있다.

테스트 수행의 주요 활동(Main Activities of Test Execution)

테스트 수행(Test Execution)의 주요 활동 중 하나는 테스트 케이스 실행(Test Case Execution)이다. 테스트 케이스 실행이란 정의된 테스트 절차(Test Procedure)와 테스트 환경(Test Environment)에 따라 단위 테스트(Unit Test), 통합 테스트(Integration Test), 시스템 테스트(System Test), 인수 테스트(Acceptance Test) 등의 테스트 케이스(Test Case)를 실제로 실행하고, 그 결과를 기록하는 활동이다.

테스트 케이스는 테스트 수행 단계에서 새로 만드는 것이 아니라, 앞선 테스트 설계(Test Design) 단계에서 이미 작성되어 있어야 한다. V-Model 관점에서도 개발 활동이 진행되는 동안 테스트 설계가 함께 이루어지고, 그 과정에서 테스트 케이스가 만들어진다. 따라서 테스트 수행 단계에서는 이미 준비된 테스트 케이스를 바탕으로 실제 실행을 진행한다.

테스트는 사람이 직접 수동(Manual)으로 수행할 수도 있고, 자동화 도구(Automation Tool)를 사용하여 수행할 수도 있다. 중요한 것은 어떤 방식으로 실행하든 테스트 케이스에 정의된 입력값(Input)과 예상 출력값(Expected Output)을 기준으로 실제 실행 결과(Actual Result)를 확인하고 기록하는 것이다.

테스트 케이스 양식을 보면 보통 TC_1, TC_2와 같이 테스트 케이스 ID(Test Case ID)가 구분되어 있고, 입력값(Input), 예상 출력값(Expected Output), 실행 결과(Actual Result), 조치사항(Action Item), 조치결과(Action Result) 등을 기록하는 칸이 있다. 이 중 테스트 케이스 ID, 입력값, 예상 출력값과 같은 항목은 테스트 설계 단계에서 이미 작성되어 있어야 한다. 테스트 케이스는 요구사항 문서(Requirements Document)를 바탕으로 만들 수도 있고, 코드(Code)를 기준으로 만들 수도 있다. 또한 화이트박스 테스트(White-box Test)인지 블랙박스 테스트(Black-box Test)인지에 따라 테스트 케이스를 만드는 방식도 달라질 수 있다.

예를 들어 로그인 기능(Login Function)을 테스트한다고 할 때, 테스트 케이스의 목적이 “로그인 시 아이디와 비밀번호의 대소문자를 구분하여 처리한다”라고 되어 있다고 하자. 이때 TC_1의 입력값이 CUK/korea라면, 예상 출력값은 “아이디 없음” 경고가 되어야 한다. 아이디의 대소문자를 구분해야 하기 때문에, 등록된 아이디와 대소문자가 다르면 정상 로그인이 되면 안 되기 때문이다.

그런데 실제 실행 결과(Actual Result)에 “정상 로그인”이라고 나온다면, 이는 예상 출력값과 다르므로 문제가 있는 것이다. 이 경우 조치사항(Action Item)에는 “디버깅 필요(Debugging Required)”와 같은 내용이 기록될 수 있다. 이후 문제가 수정되면 조치결과(Action Result)에 “아이디 없음 경고 표시”와 같이 해결된 내용을 기록한다.

정리하면, 테스트 수행 단계에서는 이미 설계된 테스트 케이스를 실제로 실행하고 그 결과를 기록한다. 이 과정에서 실행 결과(Actual Result), 조치사항(Action Item), 조치결과(Action Result)는 테스트 수행 중에 작성되지만, 그 외의 테스트 케이스 ID(Test Case ID), 입력값(Input), 예상 출력값(Expected Output), 테스트 목적(Test Objective) 등은 테스트 설계 단계에서 미리 준비되어 있어야 한다.

테스트 수행의 주요 활동: 테스트 결과 판정(Main Activities of Test Execution: Test Result Evaluation)

테스트 수행(Test Execution)의 주요 활동 중 하나는 테스트 결과 판정(Test Result Evaluation)이다. 테스트 결과 판정이란 테스트 수행 결과를 분석하여 결함(Defect) 여부를 판단하고, 결함으로 확인된 경우 그 상세 내용을 기록하는 활동이다.

테스트 케이스(Test Case)에 맞게 테스트를 정상적으로 수행했더라도, 그 결과가 반드시 결함이라고 단정할 수는 없다. 테스트 결과가 실제 결함일 수도 있지만, 결함이 아닐 수도 있기 때문이다. 따라서 테스트 결과를 다시 확인하고 분석하여, 해당 결과가 결함인지 아닌지를 판단하는 과정이 필요하다. 결함으로 판단될 경우에는 그 내용을 상세하게 기록해야 한다.

결함을 상세하게 기록해야 하는 이유는 커뮤니케이션(Communication) 때문이다. V-Model을 기준으로 보면 왼쪽은 개발 활동(Development Activity), 오른쪽은 테스트 활동(Test Activity)에 해당한다. 테스트는 개발자가 작성한 코드(Code)를 대상으로 수행되지만, 테스터(Tester)가 직접 그 코드를 개발한 것은 아니기 때문에 테스트 결과가 성공인지 실패인지는 알 수 있어도, 내부적으로 왜 그런 결과가 발생했는지까지는 정확히 알기 어려울 수 있다. 따라서 개발자가 결함 내용을 충분히 이해할 수 있도록 테스트 결과를 구체적이고 명확하게 작성해야 한다.

즉, 테스트 결과는 단순히 성공(Pass) 또는 실패(Fail)로만 기록해서는 부족하다. 왜 실패했는지, 어떤 상황에서 문제가 발생했는지, 어떤 부분을 조치해야 하는지를 분석하고 기록해야 한다. 이 과정에서 테스트와 개발 사이의 커뮤니케이션이 매우 중요해진다.

예를 들어 결함 ID(Defect ID)가 Defect 001이고, 대상 기능(Target Function)이 로그인(Login) 기능이라고 하자. 테스터(Tester)는 고려인이며, 테스트 일자(Test Date)도 함께 기록되어 있다. 결함 제목(Defect Title)은 “아이디 대소문자 처리 결함”이다.

앞서 로그인 테스트에서 아이디를 대문자 CUK로 입력했을 때, 예상 결과(Expected Result)는 “아이디 없음 경고”가 표시되는 것이었다. 그러나 실제 결과(Actual Result)는 정상 로그인으로 나타났다. 이 경우 상세 설명(Description)에는 아이디의 대소문자를 구분해야 함에도 불구하고, 대문자로 입력한 아이디가 정상적으로 로그인 처리되었다는 내용을 구체적으로 작성해야 한다.

조치사항(Action Item)에는 login() 함수의 대소문자 처리 로직(Case-sensitive Logic)에 대한 디버깅(Debugging)이 필요하다고 기록할 수 있다. 또한 결함의 심각도(Severity)도 함께 분석하여 기록한다. 이 예시에서는 심각도를 “매우 심각(Critical)”으로 판단할 수 있다. 로그인 기능은 사용자가 시스템을 사용할 때 가장 먼저 접하는 기능이므로, 이 기능에 결함이 있으면 전체 시스템 사용에 미치는 영향이 클 수 있기 때문이다.

정리하면, 테스트 수행(Test Execution)이란 앞서 준비된 테스트 케이스(Test Case)를 실제로 실행하고, 그 결과로 나타난 문제점이나 이상 현상이 결함(Defect)에 해당하는지 판단하는 과정이다. 그리고 결함으로 판단된 경우에는 개발자가 이해하고 조치할 수 있도록 결함의 상세 내용을 명확하게 기록해야 한다.

Java-based Source Code Coverage Tools: JUnit, EclEmma

테스트를 사람이 직접 수동(Manual)으로 수행하는 데에는 한계가 있을 수밖에 없다. 특히 소스코드(Source Code)를 기반으로 화이트박스 테스트(White-box Test)를 수행할 때 중요한 개념 중 하나가 커버리지(Coverage)이다. 커버리지란 코드가 테스트를 통해 얼마나 실행되었는지를 나타내는 기준이다.

이러한 커버리지 측정을 도와주는 도구들도 존재한다. 대표적으로 Eclipse 환경에서 사용할 수 있는 JUnit과 EclEmma가 있다. 이들은 Java 기반 테스트에서 활용할 수 있는 도구로, 플러그인(Plugin) 형태로 제공된다.

JUnit은 Java 프로그램에서 테스트 코드를 작성하고 실행할 때 사용할 수 있는 도구이다. Eclipse 환경에서 JUnit을 사용하면 클래스(Class)별로 테스트 결과를 확인할 수 있고, Line Coverage와 Branch Coverage를 통해 코드가 얼마나 테스트되었는지 볼 수 있다. Line Coverage는 문장 또는 코드 라인이 얼마나 실행되었는지를 의미하고, Branch Coverage는 조건문이나 분기문이 얼마나 테스트되었는지를 의미한다. 테스트가 완료된 부분은 녹색으로, 테스트가 수행되지 않은 부분은 빨간색으로 표시되어 시각적으로 확인할 수 있다.

EclEmma 역시 Eclipse 환경에서 커버리지 측정(Coverage Measurement)에 사용되는 도구이다. EclEmma를 사용하면 소스코드가 테스트된 정도를 색상으로 확인할 수 있다. 녹색은 테스트가 완료된 부분을 의미하고, 노란색은 일부만 테스트된 부분을 의미하며, 빨간색은 테스트가 수행되지 않은 부분을 의미한다. 이를 통해 개발자나 테스터는 어떤 코드가 충분히 테스트되었고, 어떤 부분이 아직 테스트되지 않았는지 쉽게 파악할 수 있다.

이처럼 JUnit과 EclEmma 같은 도구를 활용하면 사람이 직접 모든 테스트 결과를 확인하는 것보다 훨씬 효율적으로 테스트 수행 결과와 코드 커버리지(Code Coverage)를 확인할 수 있다. Java 프로그램을 테스트할 때 이러한 플러그인을 설치하여 활용해 보는 것도 좋은 방법이다.

지금까지는 테스트 수행(Test Execution)이라는 프로세스(Process)에 대해 살펴보았다.

2️⃣ Test Defect Management

다음은 테스트 결함관리 부분이다. 결함관리가 무엇인지, 왜 필요한지 위주로 살펴보도록할것이다. 테스트를 하고 나면 결함들이 나오게 된다. 그 결함을 관리하는 과정을 '테스트 결함 관리'라고한다.

테스트 결함 관리 정의(Test Defect Management)

앞서 테스트 수행(Test Execution) 과정을 통해 단위 테스트(Unit Test), 통합 테스트(Integration Test), 인수 테스트(Acceptance Test) 등 여러 테스트 활동을 진행하였다. 이러한 테스트 단계에서 발생한 결함(Defect)을 식별하고, 결함을 해결하기 위해 조치하는 일련의 프로세스를 테스트 결함 관리(Test Defect Management) 또는 결함 관리 프로세스(Defect Management Process)라고 한다.

결함 관리는 테스트 과정에서 발견된 결함을 체계적으로 관리하기 위해 사용된다. 테스트를 통해 어떤 결함이 발견되었는지, 결함이 몇 개 존재하는지, 그중 몇 개가 해결되었는지 등을 관리 관점에서 측정할 수 있어야 한다. 이러한 측정 결과를 바탕으로 테스트 활동의 상태를 파악할 수 있으며, 이후 테스트 측정(Test Measurement), 테스트 조정(Test Control), 품질 관리(Quality Management)와 같은 관리 프로세스의 기반이 된다.

결함 관리 프로세스(Defect Management Process)의 흐름을 살펴보면, 먼저 테스트를 수행한 뒤 예상 결과(Expected Result)와 실제 결과(Actual Result)를 비교한다. 만약 두 결과가 일치하면 정상적으로 테스트가 수행된 것이고, 불일치가 발생하면 결함 가능성이 있는 상황으로 본다.

이후 해당 문제를 결함으로 식별(Identification)하고 분석(Analysis)한다. 분석 결과 실제 결함이 아니거나 잘못된 테스트로 판단되면 해당 테스트는 종료된다. 반면 실제 결함으로 판단되면 결함을 등록(Defect Registration)하고, 누가 수정할 것인지 담당자를 지정하여 결함 조치(Defect Action)를 진행한다.

결함 조치가 완료되었다고 해서 바로 끝나는 것은 아니다. 수정된 결함이 실제로 해결되었는지 확인하기 위해 반드시 재테스트(Retest)를 수행해야 한다. 재테스트를 통해 결함이 정상적으로 해결되었는지 다시 확인한 뒤, 문제가 없다고 판단되면 테스트 종료(Test Closure)를 확인하게 된다.

따라서 결함 관리 프로세스는 단순히 테스트를 수행하고 결함을 해결하는 것으로 끝나는 과정이 아니다. 결함을 식별하고, 분석하고, 등록하고, 조치한 뒤, 재테스트를 통해 실제 해결 여부를 확인하는 전체 과정을 의미한다.

이러한 과정을 거치면서 결함의 상태(Defect Status)는 계속 변화한다. 예를 들어 결함이 새롭게 등록된 상태는 오픈(Open), 수정이 진행 중인 상태는 진행 중(In Progress), 조치가 완료된 상태는 해결(Resolved)로 관리될 수 있다. 이렇게 결함 상태를 데이터로 측정하고 관리함으로써, 테스트 과정뿐만 아니라 근본적인 품질 관리(Quality Management)까지 이루어질 수 있다.

테스트 결함 관리의 필요성 (Necessity of Test Defect Management)

일반적으로 관리(Management)란 데이터를 수집하고, 그 데이터를 기반으로 일이 제대로 실행될 수 있도록 모니터링(Monitoring)하고 통제(Control)하는 활동을 의미한다. 결함 관리(Defect Management)도 마찬가지이다. 테스트 과정에서 발견된 결함을 체계적으로 수집하고 관리함으로써 소프트웨어의 품질(Quality)을 확보하는 것이 목적이다.

결함은 결국 품질 관리(Quality Management)와 연결된다. 개발 과정에서 개발자들은 실수로 인해 여러 가지 결함(Defect)을 만들 수 있다. 만약 이러한 결함이 해결되지 않은 채 사용자에게 배포되고 운영된다면, 그때부터는 큰 품질 문제가 될 수 있다. 사용자 클레임(Claim)이 발생할 수 있고, 문제를 해결하기 위해 더 큰 비용을 치러야 할 수도 있다.

따라서 결함 관리는 실제 사용자에게 소프트웨어가 배포되기 전에 개발 영역에서 결함을 찾아내고, 이를 체계적으로 관리하여 개발 단계의 품질을 최대한 확보하기 위한 목적으로 수행된다.

테스트 결함 관리(Test Defect Management)의 필요성은 크게 세 가지로 정리할 수 있다.

첫 번째는 결함 상태(Defect Status)를 기반으로 결함 조치 현황을 모니터링하는 데 활용된다는 점이다. 결함은 처음 식별(Identification)된 뒤 등록(Registration), 분석(Analysis), 평가(Evaluation), 처리(Handling), 해결(Resolution), 재확인(Recheck)과 같은 여러 상태를 거친다. 이러한 상태를 기준으로 현재 결함이 어느 단계에 있는지, 조치가 제대로 이루어지고 있는지를 모니터링할 수 있다.

두 번째는 결함 관련 지표(Defect Metrics)를 기반으로 품질 현황을 정량적으로 관리하는 데 활용된다는 점이다. 단순히 품질이 좋다거나 나쁘다고 판단하는 것이 아니라, 데이터를 지표화하여 정량적으로 관리하는 것이 중요하다. 예를 들어 결함 조치율(Defect Resolution Rate), 테스트 케이스 실패율(Test Case Failure Rate)과 같은 지표를 통해 품질 상태를 객관적으로 파악할 수 있다. 이를 통해 현재 소프트웨어의 품질 수준을 보다 명확하게 관리할 수 있다.

세 번째는 결함 유형(Defect Type)을 파악하고 원인 분석(Cause Analysis)에 활용할 수 있다는 점이다. 한 번 발생한 결함은 이후 다른 유사한 프로젝트에서도 다시 발생할 가능성이 있다. 따라서 같은 문제가 반복되지 않도록 결함의 유형을 파악하고, 그 원인이 사람의 문제인지, 도구(Tool)의 문제인지, 절차(Process)의 문제인지 등을 분석해야 한다. 이러한 분석은 향후 결함을 예방하고 품질을 개선하는 데 중요한 기반이 된다.

정리하면, 테스트 결함 관리(Test Defect Management)는 결함을 단순히 기록하는 활동이 아니라, 결함 상태를 모니터링하고, 품질 현황을 정량적으로 관리하며, 결함의 원인을 분석해 향후 품질 개선(Quality Improvement)에 활용하기 위한 중요한 관리 활동이다.

결함 상태 기반의 결함 조치 현황 모니터링

(Monitoring Defect Handling Status Based on Defect Status)

결함 상태(Defect Status)는 결함이 현재 어떤 단계에 있는지를 나타내는 기준이다. 결함이 처음 생성(Create Defect)되면 오픈(Open) 상태가 된다. 이후 담당자가 지정되고, 담당자가 해당 결함을 처리하기 시작하면 진행 중(In Progress) 상태가 된다. 담당자가 결함을 모두 해결하면 해결됨(Resolved) 상태가 된다.

그러나 결함이 해결되었다고 해서 바로 종료되는 것은 아니다. 이후 제3자가 해당 결함이 실제로 해결되었는지 확인하는 과정을 거치게 된다. 이 확인 작업까지 완료되어야 비로소 종료(Closed) 상태가 된다.

결함은 중간에 다시 열릴 수도 있다. 예를 들어 결함이 해결된 뒤 재테스트(Retest)를 수행했을 때 문제가 다시 발견되면 재오픈(Reopened) 상태가 된다. 심지어 몇 달 전에 완전히 해결되었다고 판단한 결함이라도, 이후 유사한 문제가 다시 발생하면서 기존 결함이 완전히 해결된 것이 아니었다고 판단될 수 있다. 이 경우에도 결함은 다시 Reopened 상태가 될 수 있다.

이처럼 결함은 Open, In Progress, Resolved, Closed, Reopened와 같은 상태를 거치며 관리된다. 이러한 흐름을 결함 워크플로우(Defect Workflow)라고 한다.

관리자, 특히 품질 관리자(Quality Manager)는 이러한 결함 상태를 바탕으로 프로젝트의 결함 조치 현황을 모니터링한다. 예를 들어 현재 프로젝트에서 Open 상태의 결함이 10개, In Progress 상태의 결함이 5개, Resolved 상태의 결함이 3개, Closed 상태의 결함이 5개라는 식으로 결함의 상태를 파악할 수 있다. 이를 통해 결함이 제대로 조치되고 있는지, 아직 해결되지 않은 결함이 얼마나 남아 있는지, 최종적으로 종료된 결함은 얼마나 되는지를 확인할 수 있다.

결함 관리의 목표는 발견된 결함이 최종적으로 모두 Closed 상태가 되도록 관리하는 것이다. 하지만 실제 프로젝트에서는 결함이 수십 개, 수백 개씩 발생할 수 있고, 유사한 결함이 반복해서 나타날 수도 있다. 따라서 결함을 효과적으로 관리하기 위해서는 결함의 상태 관리(Defect Status Management)가 반드시 필요하다.

결함 관련 지표 기반의 품질 현황 관리

(Quality Status Management Based on Defect Metrics)

테스트를 수행하면 많은 결함(Defect)이 발견될 수 있다. 이때 테스트 결함과 관련된 여러 데이터를 수집하고, 그 데이터를 기반으로 품질(Quality)과 결함에 대한 지표(Metrics)를 만들 수 있다. 이러한 지표를 활용하면 품질 현황을 정량적으로 관리할 수 있다.

가장 쉽게 사용할 수 있는 지표 중 하나는 평균 결함 건수(Average Defect Count)이다. 평균 결함 건수는 결함 건수(Defect Count)를 테스트 대상 모듈 수(Number of Test Target Modules)로 나누어 계산할 수 있다. 예를 들어 10개의 모듈을 테스트했는데 20개의 결함이 발견되었다면, 하나의 모듈에서 평균적으로 2개의 결함이 발생한 것으로 볼 수 있다. 이를 통해 20개 또는 30개의 모듈을 테스트할 경우 어느 정도의 결함이 발생할 수 있는지 예측할 수 있고, 특정 모듈에서 결함이 많이 발생하는지도 파악할 수 있다.

또 다른 지표는 심각도별 결함 건수(Number of Defects by Severity)이다. 결함은 전체 시스템 품질에 미치는 영향에 따라 심각도(Severity)를 나눌 수 있다. 예를 들어 해킹 위험, 보안 위험, 오동작으로 인한 제품 운영 문제처럼 시스템 전체에 큰 영향을 미치는 결함은 높은 심각도로 분류될 수 있다. 반면 영향이 작은 결함은 낮은 심각도로 분류된다.

심각도별 결함 비율은 각 심각도별 결함 건수(Number of Defects by Each Severity)를 전체 결함 건수(Total Defect Count)로 나누어 파악할 수 있다. 예를 들어 전체 결함이 10개일 때, 마이너(Minor) 결함이 2개, 보통(Major) 결함이 5개, 매우 심각(Critical) 결함이 3개라면 각각 2/10, 5/10, 3/10의 비율로 나타낼 수 있다. 이를 통해 매우 심각한 결함이 3개 발생했다는 사실을 확인할 수 있고, 해당 결함들을 우선순위(Priority)에 따라 먼저 조치한 뒤 배포 여부를 결정할 수 있다.

결함의 유형별 분포 비율(Defect Distribution by Type)도 중요한 지표이다. 결함에는 여러 종류가 있다. 단순한 문법 오류(Syntax Error)일 수도 있고, 서로 다른 A와 B 두 인터페이스(Interface) 사이에서 발생하는 결함일 수도 있으며, 성능 문제(Performance Issue)와 관련된 결함일 수도 있다. 이러한 결함 유형을 분류하고 비율로 파악하면 어떤 종류의 문제가 자주 발생하는지 확인할 수 있다.

또한 결함 조치율(Defect Resolution Rate)과 같은 지표를 통해 결함이 얼마나 해결되고 있는지도 관리할 수 있다. 결함의 상태(Status)를 비율로 파악하면 현재 결함 처리 현황을 보다 명확하게 확인할 수 있다.

테스트 케이스 실패율(Test Case Failure Rate)도 결함 관리에서 활용할 수 있는 지표이다. 테스트 케이스(Test Case)를 수행하면 결과는 성공(Pass) 또는 실패(Fail)로 나뉜다. 여기서 실패란 처음에 예상한 결과(Expected Result)가 나오지 않았다는 의미이다. 테스트 케이스의 관점에서 보면 실패가 반드시 나쁜 것은 아니다. 오히려 실패한 테스트 케이스를 통해 결함을 발견할 수 있기 때문에, 테스트가 제대로 수행되었다고 볼 수도 있다.

테스트 케이스 실패율은 결함으로 식별된 테스트 케이스 수(Number of Test Cases Identified as Defects)를 전체 테스트 케이스 수(Total Number of Test Cases)로 나눈 뒤 100을 곱해 계산할 수 있다. 이를 통해 전체 테스트 케이스 중 어느 정도가 결함과 연결되었는지를 파악할 수 있다.

이 외에도 결함과 관련된 다양한 지표를 활용할 수 있다. 이러한 지표들은 단순히 결함을 기록하는 데 그치지 않고, 품질 현황을 정량적으로 파악하고 관리하는 데 사용된다. 궁극적으로 결함 관련 지표(Defect Metrics)를 활용하면 보다 체계적인 품질 관리(Quality Management)가 가능해진다.

결함 유형 파악 및 원인 분석에 활용

(Defect Type Identification and Cause Analysis)

결함(Defect)이 한 번 발생했다고 해서 다시 발생하지 않는다는 보장은 없다. 결함은 재발할 수 있기 때문에, 결함 관리(Defect Management)를 통해 현재 결함이 Open 상태인지, Closed 상태인지 지속적으로 파악하고 분석해야 한다.

결함을 관리할 때는 단순히 해결 여부만 확인하는 것이 아니라, 해당 결함이 어떤 유형의 결함이었는지도 함께 파악해야 한다. 결함 유형(Defect Type)에는 문법 문제(Syntax Issue), 논리 문제(Logic Issue), 할당 문제(Assignment Issue), 인터페이스 문제(Interface Issue), 성능 문제(Performance Issue), 검사 문제(Checking Issue), 데이터 문제(Data Issue) 등이 있을 수 있다.

이러한 결함 유형을 분석하면 어떤 결함이 많이 발생하는지 확인할 수 있다. 예를 들어 분석 결과 Syntax 결함이 가장 많이 발생하고, 그다음으로 Logic과 관련된 결함이 많이 발생했다면, 해당 유형의 결함을 중심으로 개선 활동을 진행할 수 있다.

많이 발생하는 결함은 우선적으로 해결해야 하며, 이후 같은 결함이 다시 발생하지 않도록 예방 활동도 함께 이루어져야 한다. 이를 위해 개발자 교육(Developer Training)을 진행하거나, 매뉴얼 및 지침서(Manual and Guideline)를 작성할 수 있다. 또한 정적 분석(Static Analysis)을 통해 개발 단계에서 결함을 사전에 확인할 수 있도록 가이드할 필요가 있다.

결함이 발생하면 수정하고 다시 확인하는 과정이 반복된다. 만약 같은 결함이 계속 발생한다면, 회사 입장에서는 시간과 비용의 낭비가 된다. 따라서 결함 관리는 단순히 결함을 해결하는 데 그치는 것이 아니라, 결함의 원인(Cause)을 분석하고 재발을 방지(Recurrence Prevention)하기 위한 목적으로도 활용된다.

[참고] 미국 소프트웨어 기업의 결함 조치율 현황

(Defect Resolution Rate in U.S. Software Companies)

미국 소프트웨어 기업의 평균 결함 조치율(Defect Resolution Rate)은 약 75~85% 수준이며, AT&T, IBM과 같은 기업들은 99% 수준의 결함 조치율을 달성하고 있다.

소프트웨어의 규모를 기능 점수(Function Point) 기준으로 판단할 때, 기능 점수당 결함 수(Number of Defects per Function Point)를 활용할 수 있다. 이는 소프트웨어 규모 대비 얼마나 많은 결함이 발생하는지를 나타내는 자료이다.

먼저 미흡한 조직의 경우, 품질(Quality)의 중요성에 대한 인식이 부족하다. 이러한 조직은 품질보다는 비용 절감(Cost Reduction)을 우선으로 하는 경향이 있다. 그 결과 기능 점수당 결함 수가 8~~10개로 매우 많고, 결함 조치율은 50~~55% 수준에 머무른다. 즉, 발견된 결함 중 약 40% 이상이 해결되지 않는 상태로 남아 있기 때문에 품질 수준이 매우 낮다고 볼 수 있다.

다음으로 평균적인 기업의 경우, 기능 점수당 결함 수는 약 4~~6개이며, 결함 조치율은 75~~85% 수준이다. 이 경우에도 여전히 약 20% 정도의 결함은 해결되지 않은 채 남아 있을 수 있다. 많은 소프트웨어 조직들이 이 평균 수준에 속한다고 볼 수 있다.

반면 최상위 기업들은 기능 점수당 결함 수가 1~~3개 수준으로 낮고, 결함 조치율은 90~~99%에 이른다. 이는 개발 단계에서 대부분의 결함이 해결되는 조직이라는 의미이며, 품질 수준이 매우 우수한 조직이라고 할 수 있다.

많은 조직들이 여전히 평균 수준에 머물러 있다. 하지만 오늘날은 소프트웨어의 중요성이 더욱 강조되는 소프트웨어 중심 시대이다. 그럴수록 품질의 중요성을 인식하고, 개발자로서 소프트웨어 품질을 높이기 위해 지속적으로 노력하는 자세가 중요하다.

테스트 평가와 개선(Test Evaluation and Improvement)

앞서 테스트 프로세스(Test Process)는 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution), 평가와 개선(Evaluation and Improvement)의 순서로 이루어진다고 배웠다. 또한 이 과정은 PDCA 사이클(PDCA Cycle)에 따라 진행된다.

테스트 평가와 개선(Test Evaluation and Improvement)은 PDCA에서 C와 A, 즉 확인(Check)과 조치(Act)에 해당한다. 앞 단계에서 테스트를 계획하고, 설계하고, 수행했다면, 이후에는 그 테스트가 얼마나 효과적으로 이루어졌는지를 평가해야 한다. 그리고 평가 결과 테스트가 효과적이지 않다고 판단되면, 테스트 프로세스를 개선해야 한다.

예를 들어 몇 시간 동안 수백 개의 테스트를 수행했는데 모든 결과가 성공(Pass)으로 나왔다고 하자. 이 경우 제품의 품질(Quality)이 좋다고 판단할 수도 있다. 하지만 반대로 테스트 케이스(Test Case)가 제대로 만들어지지 않았기 때문에 결함을 발견하지 못한 것이라고 판단할 수도 있다. 즉, 테스트 결과가 모두 성공이라고 해서 반드시 테스트가 효과적이었다고 단정할 수는 없다.

또한 테스트는 정해진 일정(Schedule)과 기간(Duration) 안에서 수행되어야 한다. 그런데 테스트 수행 시간이 지나치게 오래 걸린다면, 테스트 케이스가 효율적으로 설계되었는지, 테스트 도구(Test Tool)나 장비(Equipment)에 문제가 있는지, 또는 인력(Personnel) 측면에서 문제가 있는지를 확인해야 한다. 이처럼 테스트가 적절하게 수행되었는지를 평가하고, 필요한 경우 개선하는 과정이 중요하다.

따라서 테스트 평가와 개선(Test Evaluation and Improvement) 단계에서는 테스트 결과 분석 및 평가(Test Result Analysis and Evaluation)가 이루어진다. 그리고 분석 결과를 바탕으로 대책 수립(Countermeasure Planning)과 시정안 권고(Corrective Action Recommendation)가 진행된다.

참고: ISO/IEC 33063 Process Assessment Model for Software Testing

ISO/IEC 33063은 소프트웨어 테스팅(Software Testing) 프로세스를 평가하기 위한 표준이다. 앞서 테스트 프로세스(Test Process)는 여러 계층으로 구성되어 있다고 배웠다. 크게 조직 차원의 테스트 프로세스(Organizational Test Process), 테스트 관리 프로세스(Test Management Process), 동적 테스트 프로세스(Dynamic Test Process)로 나눌 수 있으며, 이러한 구조는 ISO/IEC/IEEE 29119 표준에서 다루는 내용이다.

다만 테스트 평가와 개선(Test Evaluation and Improvement)에 대해서는 ISO/IEC/IEEE 29119가 아니라, ISO/IEC 33063 표준을 참고한다. ISO/IEC 33063은 소프트웨어 테스팅 프로세스가 얼마나 적절하게 수행되고 있는지를 평가하기 위한 기준을 제시한다.

즉, ISO/IEC/IEEE 29119가 테스트 프로세스의 구조와 활동을 설명하는 표준이라면, ISO/IEC 33063은 그 테스트 프로세스를 평가하는 데 활용되는 표준이라고 볼 수 있다. 따라서 ISO/IEC 33063은 앞서 살펴본 ISO/IEC/IEEE 29119의 세 가지 테스트 프로세스를 평가하기 위한 기준으로 활용된다.

이 표준은 테스트 프로세스가 제대로 수행되고 있는지 확인하고, 개선이 필요한 부분을 찾는 데 참고할 수 있다.

참고: ISO/IEC 33063 Process Assessment Model for Software Testing

ISO/IEC 33063에서는 소프트웨어 테스팅(Software Testing) 프로세스를 평가한 뒤, 해당 프로젝트(Project) 또는 조직(Organization)의 능력과 역량을 등급으로 정의한다. 이 등급은 0부터 5까지의 능력 수준(Capability Level)으로 제시되며, 0이 가장 낮은 수준이고 5가 가장 우수한 수준이다.

먼저 레벨 0(Level 0)은 불완전한 프로세스(Incomplete Process)에 해당한다. 테스트 프로세스(Test Process) 자체가 존재하지 않거나, 프로세스가 있더라도 실제 수행 결과가 거의 없는 상태이다. 체계적인 테스트 설계(Test Design) 없이 테스트 수행(Test Execution)에만 급급하고, 일부 테스트 결과만 남아 있는 매우 부족한 조직이라고 볼 수 있다.

레벨 1(Level 1)은 수행된 프로세스(Performed Process)에 해당한다. 이 수준의 조직은 테스트를 실제로 수행한다. 예를 들어 블랙박스 테스트(Black-box Test)나 화이트박스 테스트(White-box Test) 기법을 적용하여 테스트를 진행하고, 그 결과도 존재한다. 하지만 여전히 많은 조직들이 레벨 0과 레벨 1 사이에 머물러 있다.

우리가 지향해야 할 수준은 적어도 레벨 2(Level 2)이다. 레벨 2는 관리된 프로세스(Managed Process)를 의미한다. 이 수준에서는 PDCA Cycle에 기반하여 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution), 테스트 평가와 개선(Test Evaluation and Improvement) 과정이 지속적으로 운영된다. 즉, 테스트가 단순히 수행되는 것에 그치지 않고, 관리 관점에서 체계적으로 진행되는 조직이라고 할 수 있다.

레벨 3(Level 3)은 정립된 프로세스(Established Process)에 해당한다. 레벨 2와 레벨 3은 적용 범위에서 차이가 있다. 레벨 2가 개별 프로젝트(Project) 단위에서 테스트 프로세스를 관리하는 수준이라면, 레벨 3은 조직(Organization) 차원에서 표준 테스트 프로세스(Standard Test Process)가 정립되어 있는 수준이다. 즉, 특정 프로젝트에만 적용되는 것이 아니라 조직 전체에서 공통적으로 활용할 수 있는 테스트 프로세스가 마련되어 있는 단계이다.

레벨 4(Level 4)는 예측 가능한 프로세스(Predictable Process)에 해당한다. 이 수준에서는 한두 개의 테스트 케이스(Test Case) 결과만으로 품질을 판단하는 것이 아니라, 여러 유사 프로젝트에서 수집한 정량적 데이터(Quantitative Data)를 기반으로 품질을 예측한다. 예를 들어 20~30개 이상의 프로젝트 결과를 모아 표준화된 프로세스(Standardized Process)를 분석하고, 이를 통해 향후 프로젝트의 품질을 예측하는 방식이다.

레벨 5(Level 5)는 최적화된 프로세스(Optimizing Process)에 해당한다. 레벨 5에서는 레벨 4에서 예측한 결과를 바탕으로 문제점을 분석하고, 테스트 프로세스를 지속적으로 개선(Continuous Improvement)한다. 즉, 정량적 데이터와 예측 결과를 활용하여 조직의 테스트 역량을 계속 발전시키는 단계라고 볼 수 있다.

다만 레벨 4와 레벨 5는 매우 이상적인 수준에 가깝다. 따라서 모든 조직이 반드시 이 단계까지 도달해야 한다고 보기보다는, 실무에서는 우선 레벨 2를 목표로 하는 것이 현실적이다. 즉, 단순히 프로젝트를 수행하는 수준을 넘어 PDCA Cycle에 기반하여 테스트를 계획하고, 설계하고, 수행하고, 평가하고 개선하는 관리된 프로세스(Managed Process)를 갖추는 것이 중요하다.

이후 레벨 2가 안정적으로 이루어진다면, 조직 차원의 표준 테스트 프로세스를 정립하는 레벨 3(Level 3)까지 고려해볼 수 있다.

테스트 평가와 개선의 주요 활동: 테스트 결과 분석 및 평가

(Main Activities of Test Evaluation and Improvement: Test Result Analysis and Evaluation)

테스트 평가와 개선(Test Evaluation and Improvement)의 주요 활동 중 하나는 테스트 결과 분석 및 평가(Test Result Analysis and Evaluation)이다. 이는 수행된 테스트가 얼마나 효과적이었는지, 그리고 그 효과를 달성하기 위해 어느 정도의 비용이 소요되었는지를 평가하는 과정이다.

먼저 테스트 효과성(Test Effectiveness)은 테스트를 통해 얼마나 많은 결함(Defect)을 검출했는지를 기준으로 평가한다. 테스트의 목적은 결함을 찾는 데 있으므로, 좋은 테스트 케이스(Test Case)는 결함을 잘 발견할 수 있어야 한다. 테스트 케이스를 여러 개 작성했을 때, 테스트 결과가 성공(Pass)이라는 것은 예상 결과(Expected Result)와 실제 결과(Actual Result)가 일치했다는 의미이다. 반대로 실패(Fail)는 예상한 결과가 나오지 않았다는 뜻이며, 이 경우 결함을 발견했을 가능성이 있다.

따라서 테스트 케이스 실패율(Test Case Failure Rate)은 테스트 효과성을 평가하는 지표로 활용될 수 있다. 테스트 케이스 실패율은 실패한 테스트 케이스 수(Number of Failed Test Cases)를 전체 테스트 케이스 수(Total Number of Test Cases)로 나눈 뒤 100을 곱해 계산한다.

예를 들어 전체 테스트 케이스가 30개이고, 그중 실패한 테스트 케이스가 15개라면 테스트 케이스 실패율은 다음과 같다.

15개 / 30개 × 100% = 50%

이는 전체 테스트 케이스 중 50%가 실패했으며, 그만큼 결함 발견과 연결될 수 있음을 의미한다. 즉, 테스트 케이스 실패율은 테스트가 결함을 얼마나 찾아냈는지를 보여주는 효과성 지표로 볼 수 있다.

다음으로 테스트 효율성(Test Efficiency)은 테스트 효과를 달성하는 데 소요된 비용이나 공수(Effort)를 함께 고려하는 지표이다. 같은 효과를 얻더라도 더 적은 시간과 비용으로 수행했다면 더 효율적인 테스트라고 볼 수 있다.

예를 들어 테스트 효과성(Test Effectiveness), 즉 테스트 케이스 실패율이 50%이고, 테스트 소요 비용 또는 공수(Test Effort)가 5시간이라고 하자. 이때 테스트 효율성(Test Efficiency)은 테스트 효과성을 테스트 소요 비용으로 나누어 계산할 수 있다.

테스트 효율성(Test Efficiency) = 테스트 효과성(Test Effectiveness) / 테스트 소요 비용(Test Effort)

따라서 위 예시는 다음과 같이 계산된다.

50% / 5시간 = 시간당 10%

이는 테스트를 수행할 때 시간당 약 10% 수준의 결함 발견 효과를 얻을 수 있는 테스트가 수행되었다고 해석할 수 있다.

이처럼 테스트 결과 분석 및 평가(Test Result Analysis and Evaluation)는 테스트 케이스 실패율(Test Case Failure Rate), 테스트 효과성(Test Effectiveness), 테스트 효율성(Test Efficiency)과 같은 지표를 기반으로 테스트 프로세스(Test Process)가 얼마나 적절하게 수행되었는지를 평가하는 과정이다. 지표를 활용하면 테스트 활동의 성과를 정량적으로 파악할 수 있고, 이후 테스트 프로세스를 개선하는 데 필요한 근거로 활용할 수 있다.

테스트 평가와 개선의 주요 활동: 대책 수립 및 시정안 권고

(Main Activities of Test Evaluation and Improvement: Countermeasure Planning and Corrective Action Recommendation)

테스트 평가와 개선(Test Evaluation and Improvement)의 주요 활동에는 대책 수립(Countermeasure Planning)과 시정안 권고(Corrective Action Recommendation)가 포함된다. 이는 테스트 효과성(Test Effectiveness)과 테스트 효율성(Test Efficiency)을 높이기 위해 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution) 등의 활동에 대한 개선 방안을 마련하고, 그에 따라 조치를 수행하는 과정이다.

먼저 테스트 계획(Test Planning)에 대한 개선 방안을 살펴볼 수 있다. 테스트 효과성 지표(Test Effectiveness Metric)에는 테스트 케이스 실패율(Test Case Failure Rate)이 있다. 테스트 케이스 실패율이 낮다는 것은 결함을 검출하지 못한 테스트 케이스가 많다는 의미로 볼 수 있다. 엄밀히 말하면 테스트 케이스(Test Case)가 결함을 잘 찾지 못하도록 만들어졌다는 뜻이므로, 테스트 케이스의 품질을 다시 검토해야 한다.

이 경우 개선 방안으로 위험 분석(Risk Analysis)을 철저히 수행할 수 있다. 결함이 발생할 가능성이 높은 기능이나 품질에 큰 영향을 미치는 기능을 중심으로 테스트하면 테스트의 효과성을 높일 수 있다. 따라서 기존에 위험 분석을 제대로 수행하지 않았던 조직이라면, 테스트 효과를 높이기 위해 테스트 계획 단계에서 위험 분석을 반드시 진행하도록 권고할 수 있다.

다음으로 테스트 설계(Test Design)에 대한 개선 방안을 살펴볼 수 있다. 테스트 소요 비용(Test Cost)이나 공수(Effort)가 크다는 것은 많은 시간과 인력을 들였음에도 테스트가 충분히 효과적이지 않을 수 있다는 의미이다. 그 원인을 분석해 보니 사람이 반복적인 테스트를 일일이 수동(Manual)으로 수행하고 있었다면, 테스트 자동화(Test Automation)를 개선 방안으로 제시할 수 있다.

테스트 자동화 도구(Test Automation Tool)를 도입하면 사람이 반복적으로 수행하던 부분을 도구 기반으로 실행할 수 있다. 이를 통해 반복 작업에 드는 시간과 비용을 줄이고, 사람은 더 창의적이고 생산적인 업무에 집중할 수 있다.

즉, 대책 수립과 시정안 권고는 테스트 평가 결과를 바탕으로 테스트 계획, 설계, 수행 활동의 문제점을 찾고, 테스트 효과성과 효율성을 높이기 위한 개선 방안을 제시하는 활동이다. 테스트 자동화(Test Automation)는 이러한 개선 방안 중 하나이며, 이후 주차에서 더 자세히 다룰 예정이다.

테스트 프로세스 전체 요약 (Summary of Test Process)

지금까지 테스트(Test)를 평가하고 개선하는 과정까지 살펴보았다. 전체 내용을 간략히 정리하면 다음과 같다.

테스트 표준(Test Standard)에서는 테스트 프로세스(Test Process)를 크게 세 가지 범주로 나눈다. 첫 번째는 조직 차원의 테스트 프로세스(Organizational Test Process), 두 번째는 테스트 관리 프로세스(Test Management Process), 세 번째는 동적 테스트 프로세스(Dynamic Test Process)이다.

먼저 조직 차원의 테스트 프로세스(Organizational Test Process)는 전체 조직 차원에서 테스트 정책(Test Policy)과 테스트 전략(Test Strategy)을 수립하는 활동이다. 하지만 처음 수립한 정책과 전략이 항상 완전한 것은 아니기 때문에, 실제 테스트를 수행하면서 얻은 피드백(Feedback)을 바탕으로 계속 업데이트하고 개선해야 한다.

다음으로 프로젝트 차원의 테스트 관리 프로세스(Test Management Process)는 테스트를 체계적으로 수행하기 위해 테스트 계획(Test Planning)을 세우는 과정이다. 프로젝트 단위에서 어떤 테스트를 어떻게 수행할 것인지 계획하고, 테스트가 일정과 목표에 맞게 진행될 수 있도록 관리한다.

실제로 테스트를 수행하는 부분은 동적 테스트 프로세스(Dynamic Test Process)에 해당한다. 동적 테스트 프로세스는 테스트 설계 및 구현(Test Design and Implementation), 테스트 환경 구성 및 유지(Test Environment Setup and Maintenance), 테스트 수행(Test Execution), 테스트 결과 보고(Test Result Reporting)로 이루어진다. 이 과정에서 테스트 케이스(Test Case)를 실행하고, 결과를 기록하며, 결함(Defect)을 식별하고 보고한다.

동적 테스트 프로세스에서 나온 결과와 데이터는 다시 테스트 관리 프로세스로 전달된다. 이후 테스트 관리 차원에서는 이 데이터를 측정(Measurement)하고, 모니터링(Monitoring)하며, 필요한 경우 제어(Control)한다. 테스트가 완료되면 그 결과는 다시 조직 차원으로 전달되어, 조직의 테스트 정책과 전략을 지속적으로 개선하는 데 활용된다.

즉, 테스트 프로세스는 단순히 테스트를 수행하고 끝나는 것이 아니라, 조직 차원의 정책과 전략, 프로젝트 차원의 계획과 관리, 실제 테스트 수행과 결과 보고가 서로 연결되어 순환하는 구조이다. 테스트를 통해 얻은 데이터와 피드백은 다시 상위 프로세스로 전달되고, 이를 기반으로 테스트 프로세스 전체가 지속적으로 개선된다.

이 내용은 그동안 여러 주차에 걸쳐 학습한 테스트 프로세스의 세부 내용을 종합적으로 정리한 요약 자료로 이해할 수 있다.

Test Process: Test Execution to Test Evaluation and Improvement