Software Testing End-of-Semester Review Notes: Quality, V-Model, Test Process, Test Techniques, and AI Testing

Software Testing Course Review

이번 강의는 새로운 소프트웨어 테스트(Software Testing) 내용을 배우는 시간이 아니라, 한 학기 동안 학습한 핵심 내용을 키워드 중심으로 정리하고 점검하는 시간이다. 지난 시간에는 AI 소프트웨어 테스트(AI Software Testing)의 정의와 필요성을 살펴보았다. 특히 일반 소프트웨어와 달리 AI 소프트웨어(AI Software)는 데이터(Data)와 모델(Model)에 크게 의존하기 때문에, AI 소프트웨어의 특성을 반영한 별도의 테스트 기법(Test Techniques)이 필요하다는 점을 학습했다.

AI 소프트웨어 테스트에서는 기존 소프트웨어 테스트와 마찬가지로 블랙박스 테스트(Black-box Testing)와 화이트박스 테스트(White-box Testing)의 개념이 적용된다. 블랙박스 테스트는 AI 모델 내부 구조를 직접 보지 않고 입력값(Input)과 출력값(Output)의 관계를 중심으로 검증하는 방식이다. 반면 화이트박스 테스트는 AI 모델의 내부 구조, 특히 신경망(Neural Network)이나 뉴런 커버리지(Neuron Coverage)와 같은 요소를 고려하여 테스트하는 방식이다.

또한 AI 소프트웨어를 안전하게 테스트하기 위해 가상 기반 테스트 환경(Virtual-based Testing Environment)과 디지털 트윈(Digital Twin)을 활용하는 방법도 학습했다. 현실 환경에서는 위험한 상황이나 예외적인 상황을 직접 재현하기 어렵기 때문에, 시뮬레이션 환경(Simulation Environment)을 통해 다양한 시나리오(Scenario)를 안전하게 반복 테스트할 수 있다. 특히 자율주행(Autonomous Driving), 드론(Drone), 물류 시스템(Logistics System)처럼 실제 테스트 비용과 위험이 큰 분야에서 이러한 방식이 중요하게 사용된다.

이번 정리 강의의 목표는 전체 수업의 목표와도 연결된다.

첫 번째 목표는 소프트웨어 품질 확보(Software Quality Assurance)의 중요성을 인식하는 것이다. 소프트웨어 테스트는 단순히 오류를 찾는 활동이 아니라, 소프트웨어가 요구사항(Requirements)을 충족하고 안정적으로 동작하는지 확인함으로써 품질을 확보하는 중요한 활동이다. 따라서 테스트는 개발의 마지막 단계에서만 수행되는 부가적인 작업이 아니라, 소프트웨어 품질을 보장하기 위한 핵심 프로세스라고 볼 수 있다.

두 번째 목표는 소프트웨어 테스트 프로세스(Software Testing Process)를 설명할 수 있는 것이다. 소프트웨어 테스트는 단순히 테스트를 실행하는 것만을 의미하지 않는다. 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution), 테스트 평가(Test Evaluation), 테스트 개선(Test Improvement)과 같은 단계가 포함된다. 이러한 과정은 PDCA(Plan-Do-Check-Act) 관점에서도 이해할 수 있다. 즉, 테스트를 계획하고 실행한 뒤 결과를 확인하고, 문제점을 개선하는 반복적인 품질 관리 활동이다.

세 번째 목표는 다양한 소프트웨어 테스트 기법(Software Test Techniques)을 설명할 수 있는 것이다. 수업에서는 블랙박스 테스트와 화이트박스 테스트를 중심으로 여러 테스트 방법을 학습했다. 블랙박스 테스트에는 동등 분할 테스트(Equivalence Partitioning), 경계값 분석(Boundary Value Analysis), 조합 테스트(Combinatorial Testing), 변성 테스트(Metamorphic Testing), 탐색적 테스트(Exploratory Testing) 등이 포함될 수 있다. 화이트박스 테스트에서는 코드 구조나 내부 로직을 기반으로 문장 커버리지(Statement Coverage), 분기 커버리지(Branch Coverage), 그리고 AI 모델의 경우 뉴런 커버리지(Neuron Coverage)와 같은 개념을 활용할 수 있다.

정리하면, 이번 강의는 한 학기 동안 배운 소프트웨어 품질(Software Quality), V-모델(V-Model), 테스트 프로세스(Test Process), 테스트 기법(Test Techniques), AI 소프트웨어 테스트(AI Software Testing)를 전체적으로 복습하는 시간이다. 이 내용을 통해 소프트웨어 테스트가 품질 확보를 위한 핵심 활동이며, 테스트는 계획부터 설계, 수행, 평가, 개선까지 이어지는 체계적인 프로세스라는 점을 다시 확인할 수 있게 될 것이다.

Software Quality and V-Model

소프트웨어 품질(Software Quality)과 V-모델(V-Model)에서 가장 중요한 출발점은 소프트웨어(Software)의 정의를 이해하는 것이다. 소프트웨어는 단순히 프로그램 코드만을 의미하는 것이 아니라, 사용자의 요구사항(Requirements)을 만족시키기 위해 만들어진 프로그램, 데이터, 문서, 절차 등을 포함하는 개념이다. 이러한 소프트웨어는 하드웨어처럼 눈에 보이는 물리적 제품은 아니지만, 자동차, 항공기, 의료기기, 금융 시스템 등 다양한 실제 제품과 서비스의 동작에 큰 영향을 준다.

소프트웨어는 변경이 쉽고 복잡도가 높으며, 개발 과정에서 사람이 직접 논리와 구조를 설계한다는 특징을 가진다. 이러한 특징 때문에 요구사항이 잘못 정의되거나, 설계가 부정확하거나, 구현 과정에서 실수가 발생하면 소프트웨어 결함(Software Defect)이 생길 수 있다. 결함은 단순한 프로그램 오류로 끝나는 것이 아니라, 실제 제품의 오작동이나 서비스 장애로 이어질 수 있다. 특히 자동차나 항공기처럼 안전이 중요한 분야에서는 소프트웨어 결함이 큰 사고로 연결될 수 있기 때문에 품질 확보가 매우 중요하다.

이러한 문제를 줄이기 위해 수업에서는 제품 품질(Product Quality)뿐만 아니라 프로세스 품질(Process Quality)의 중요성을 강조했다. 제품 품질은 최종적으로 만들어진 소프트웨어가 요구사항을 만족하고 안정적으로 동작하는지를 의미한다. 반면 프로세스 품질은 소프트웨어를 개발하고 유지보수하는 과정이 체계적이고 적절하게 수행되었는지를 의미한다. 좋은 개발 프로세스를 갖추면 결함을 줄이고, 결과적으로 더 나은 제품 품질을 확보할 수 있다.

이때 중요한 개발 및 테스트 관점으로 V-모델(V-Model)이 등장한다. V-모델은 요구사항 분석(Requirements Analysis), 설계(Design), 구현(Implementation), 테스트(Test)의 관계를 체계적으로 보여주는 모델이다. 개발 단계에서 정의한 요구사항과 설계 내용은 이후 테스트 단계에서 검증되어야 한다. 즉, 요구사항을 기준으로 인수 테스트(Acceptance Testing)를 수행하고, 설계를 기준으로 시스템 테스트(System Testing), 통합 테스트(Integration Testing), 단위 테스트(Unit Testing)를 수행하는 방식으로 연결된다.

정리하면, 소프트웨어 품질과 V-모델의 핵심 흐름은 하나의 시나리오로 이해할 수 있다. 먼저 소프트웨어의 정의와 특징을 이해하고, 이러한 특징 때문에 품질 문제가 발생할 수 있음을 파악한다. 품질 문제는 소프트웨어 결함으로 이어지고, 결함은 실제 제품이나 서비스에 영향을 줄 수 있다. 따라서 소프트웨어 품질을 확보하기 위해 제품 품질과 프로세스 품질을 함께 관리해야 하며, 이를 체계적으로 수행하기 위한 방법으로 V-모델을 적용할 수 있다.

Software의 정의

소프트웨어(Software)는 단순히 하드웨어(Hardware)를 제어하는 프로그래밍 명령어(Programming Instructions)나 소스 코드(Source Code)의 집합만을 의미하지 않는다. 물론 소스 프로그램(Source Program)이나 실행 가능한 프로그램(Executable Program)은 소프트웨어의 중요한 구성 요소이다. 하지만 소프트웨어를 더 넓게 보면, 개발 과정에서 만들어지는 다양한 산출물(Artifacts)까지 포함하는 개념이다.

소프트웨어는 고객 요구사항 분석(Requirements Analysis), 설계(Design), 구현(Implementation), 테스트(Testing), 배포(Deployment)와 같은 일련의 소프트웨어 개발 프로세스(Software Development Process)를 통해 만들어진다. 이 과정에서 단순히 코드만 생성되는 것이 아니라, 요구사항 명세서(Requirements Specification), 아키텍처 설계서(Architecture Design Document), 상세 설계서(Detailed Design Document), 테스트 결과서(Test Result Report), 배포 문서(Deployment Document), 데이터(Data) 등 다양한 결과물이 함께 만들어진다.

따라서 소프트웨어는 프로그램 코드만을 가리키는 좁은 개념이 아니라, 프로그램을 포함하여 소프트웨어 개발과 유지보수 과정에서 생성되는 모든 관련 산출물의 집합이라고 이해할 수 있다. 즉, 소프트웨어는 소스 코드(Source Code), 문서(Document), 데이터(Data), 테스트 결과(Test Results), 프로세스(Process)와 같은 요소들을 포함하는 종합적인 개념이다.

이러한 정의가 중요한 이유는 소프트웨어 품질(Software Quality)을 평가할 때 코드만 보면 충분하지 않기 때문이다. 요구사항이 잘못 작성되었거나, 설계 문서가 부정확하거나, 테스트 결과가 제대로 관리되지 않으면 최종 프로그램이 정상적으로 동작하더라도 품질 문제가 발생할 수 있다. 따라서 소프트웨어를 이해할 때는 구현 단계에서 나온 코드뿐만 아니라, 개발 전 과정에서 만들어지는 산출물까지 함께 고려해야 한다.

정리하면, 소프트웨어는 하드웨어를 제어하는 명령어 집합만이 아니라, 소스 프로그램을 포함하여 요구사항 분석, 설계, 구현, 테스트, 배포 과정에서 생성되는 문서와 데이터, 테스트 결과 등 모든 산출물을 포함하는 개념이 된다.

Software의 특징

소프트웨어(Software)는 대표적으로 네 가지 특징을 가진다. 이러한 특징들은 소프트웨어 품질 문제(Software Quality Issue)와 결함(Defect)이 발생하는 원인이 될 수 있으며, 최종적으로는 소프트웨어가 탑재된 자동차, 항공기, 의료기기와 같은 실제 제품에도 영향을 줄 수 있다.

첫 번째 특징은 비가시성(Invisibility)이다. 소프트웨어는 하드웨어처럼 눈으로 구조를 직접 확인하기 어렵다. 작은 프로그램은 코드의 흐름을 비교적 쉽게 파악할 수 있지만, 수천 줄, 수만 줄, 수십만 줄 이상의 대형 소프트웨어가 되면 내부 구성 요소와 전체 구조를 한눈에 이해하기 어렵다. 이 때문에 소프트웨어의 구조적 문제나 결함을 발견하기가 쉽지 않다.

두 번째 특징은 비선형적이고 복잡한 구조(Nonlinear and Complex Structure)이다. 소프트웨어는 여러 모듈(Module)로 구성되며, 각 모듈은 독립적으로 존재하면서도 서로 데이터를 주고받고 기능적으로 연결된다. 이러한 관계가 많아질수록 소프트웨어는 단순한 선형 구조로 이해하기 어려워지고, 하나의 변경이 다른 부분에 예상하지 못한 영향을 줄 수 있다.

세 번째 특징은 닳아 없어지지 않지만 계속 변경된다는 점(Does Not Wear Out but Changes)이다. 하드웨어(Hardware)는 시간이 지나면 물리적으로 마모되거나 고장날 수 있지만, 소프트웨어 자체는 물리적으로 닳지 않는다. 대신 사용자의 요구 변화, 운영 환경 변화, 기능 추가, 결함 수정 등에 따라 계속 변경된다. 이러한 변경은 소프트웨어가 탑재된 제품이나 서비스가 사용되는 동안 지속될 수 있으며, 변경 과정에서 새로운 결함이 발생할 가능성도 있다.

네 번째 특징은 사람 중심의 작업(Human-centered Work)이라는 점이다. 소프트웨어 개발은 요구사항 분석(Requirements Analysis), 설계(Design), 구현(Implementation), 테스트(Testing) 등 많은 단계에서 사람의 판단과 작업에 의존한다. 따라서 개발 과정에는 항상 휴먼 에러(Human Error)가 포함될 가능성이 있다. 이러한 오류가 소프트웨어 결함으로 이어지고, 결함이 실제 시스템의 고장(Failure)이나 사고(Accident)로 연결될 수 있다.

결국 소프트웨어의 비가시성, 복잡성, 지속적인 변경, 사람 중심의 개발 과정은 모두 소프트웨어 품질을 저해할 수 있는 요인이 된다. 그래서 소프트웨어 개발이 포함된 IT 프로젝트(IT Project)의 성공률을 높이기 위해서는 단순히 프로그래밍(Programming)만 잘하는 것이 아니라, 요구사항 분석, 설계, 구현, 테스트를 체계적으로 수행하는 프로세스(Process)가 필요하다. 즉, 소프트웨어 품질을 확보하기 위해서는 개발 프로세스를 체계적으로 적용하고, 각 단계에서 품질을 점검하는 노력이 중요하다.

Impact of Software Defects

소프트웨어(Software)는 사람이 직접 분석하고 설계하며 구현하는 결과물이기 때문에, 개발 과정에서 휴먼 에러(Human Error)가 발생할 수 있다. 요구사항을 잘못 이해하거나, 설계 단계에서 논리적 오류가 생기거나, 구현 과정에서 잘못된 코드를 작성하는 것이 모두 휴먼 에러의 예가 될 수 있다.

이러한 휴먼 에러는 단순한 실수로 끝나지 않고, 소프트웨어 내부의 결함(Fault)으로 남을 수 있다. 이후 결함이 실제 실행 과정에서 드러나면 고장(Failure)으로 이어질 수 있다. 즉, 소프트웨어 문제는 error → fault → failure의 흐름으로 전파될 수 있다.

여기서 에러(Error)는 사람이 저지른 실수나 잘못된 판단을 의미하고, 결함(Fault)은 그 실수가 소프트웨어 산출물 안에 남은 상태를 의미한다. 고장(Failure)은 소프트웨어가 실행되었을 때 요구된 기능을 제대로 수행하지 못하는 실제 현상을 의미한다. 작은 실수나 결함이라도 시스템 안에서 전파되면 예상보다 큰 문제로 발전할 수 있다.

특히 소프트웨어가 자동차, 항공기, 의료기기, 금융 시스템, 원자력 시스템과 같은 안전 중요 시스템(Safety-critical System)에 사용될 경우, 결함의 영향은 매우 심각해질 수 있다. 단순한 프로그램 오류가 사람의 생명, 경제적 손실, 환경 피해와 연결될 수 있기 때문이다. 따라서 소프트웨어 결함은 단순히 개발자의 실수나 프로그램 오류로만 볼 것이 아니라, 실제 사회적 피해로 이어질 수 있는 중요한 품질 문제로 이해해야 한다.

결국 소프트웨어 개발에서는 작은 에러와 결함을 가볍게 넘기지 않는 태도가 필요하다. 결함이 상위 단계로 전파되어 큰 사고를 일으키지 않도록, 요구사항 분석(Requirements Analysis), 설계(Design), 구현(Implementation), 테스트(Testing), 유지보수(Maintenance) 전 과정에서 체계적인 프로세스(Process)를 적용해야 한다. 철저한 소프트웨어 개발 프로세스와 테스트 활동은 결함을 조기에 발견하고, 고장과 사고로 이어지는 위험을 줄이기 위한 핵심 방법이라고 할 수 있다.

Process Quality & Product Quality

소프트웨어 품질(Software Quality)은 크게 프로세스 품질(Process Quality)과 제품 품질(Product Quality)로 나누어 볼 수 있다. 최종적으로 우리가 확보하고자 하는 것은 사용자가 실제로 사용하는 소프트웨어 제품(Software Product)이나 시스템(System)의 품질이다. 즉, 제품이 요구사항(Requirements)을 만족하고, 안정적으로 동작하며, 사용 목적에 맞게 기능을 수행해야 한다.

하지만 제품 품질을 높이기 위해서는 단순히 프로그램을 잘 구현하는 것만으로는 부족하다. 좋은 소프트웨어를 만들기 위해서는 소프트웨어를 개발하는 과정, 즉 프로세스(Process)가 체계적으로 관리되어야 한다. 요구사항 분석(Requirements Analysis), 설계(Design), 구현(Implementation), 테스트(Testing), 배포(Deployment), 유지보수(Maintenance) 과정이 명확하게 정의되고, 그 절차에 따라 수행되어야 최종 제품의 품질도 높아질 수 있다.

이때 프로세스 품질은 PDCA Cycle을 기반으로 이해할 수 있다. 먼저 Plan 단계에서는 프로세스의 목표를 달성하기 위한 계획과 절차가 정의되어야 한다. Do 단계에서는 정의된 프로세스에 따라 실제 개발과 테스트 활동을 수행한다. Check 단계에서는 계획대로 잘 진행되고 있는지 확인하고 통제(Control)한다. 마지막으로 Act 단계에서는 문제가 있거나 부족한 부분을 지속적으로 개선(Improvement)한다.

즉, 소프트웨어 품질 확보는 한 번의 테스트 수행으로 끝나는 것이 아니라, 계획하고 수행하고 점검하고 개선하는 반복적인 활동이다. 테스트 활동(Test Activities) 역시 PDCA 관점에서 이루어져야 한다. 테스트를 계획(Test Planning)하고, 테스트 케이스(Test Case)를 설계(Test Design)하고, 테스트를 수행(Test Execution)한 뒤, 결과를 평가(Test Evaluation)하고 개선(Test Improvement)하는 과정이 필요하다.

결국 프로세스 품질과 제품 품질은 서로 연결되어 있다. 체계적인 프로세스가 잘 운영되면 결함(Defect)을 조기에 발견하고 줄일 수 있으며, 이는 최종 제품의 품질 향상으로 이어진다. 따라서 소프트웨어 테스트(Software Testing)는 단순히 오류를 찾는 활동이 아니라, PDCA 기반의 품질 관리 활동(Quality Management Activity)으로 이해해야 한다.

V-Model 생명주기 프로세스

V-Model은 소프트웨어 개발 활동(Development Activities)과 테스트 활동(Test Activities)을 서로 대응시켜 품질을 확보하는 생명주기 모델(Life Cycle Model)이다. V-Model의 왼쪽은 요구사항 분석(Requirements Analysis), 아키텍처 설계(Architecture Design), 상세 설계(Detailed Design), 구현(Implementation)과 같은 개발 영역으로 구성된다. 오른쪽은 단위 테스트(Unit Testing), 통합 테스트(Integration Testing), 시스템 테스트(System Testing), 인수 테스트(Acceptance Testing)와 같은 테스트 영역으로 구성된다.

V-Model의 핵심은 개발 단계와 테스트 단계가 서로 연결되어 있다는 점이다. 고객 또는 사용자 요구사항(Customer/User Requirements)은 인수 테스트(Acceptance Testing)와 대응된다. 사용자가 요구한 기능과 조건을 최종 시스템이 만족하는지 확인하는 단계이기 때문이다. 요구사항 분석(Requirements Analysis)은 시스템 테스트(System Testing)와 대응된다. 시스템 전체가 분석된 요구사항을 충족하는지 검증하는 단계이다.

아키텍처 설계(Architecture Design)는 통합 테스트(Integration Testing)와 대응된다. 아키텍처 설계에서는 시스템을 구성하는 주요 컴포넌트(Component)와 모듈(Module) 간의 관계를 정의하므로, 통합 테스트에서는 이 구성요소들이 서로 올바르게 연동되는지 확인한다. 상세 설계(Detailed Design)는 단위 테스트(Unit Testing)와 대응된다. 상세 설계에서 정의한 개별 모듈이나 함수가 구현 후 올바르게 동작하는지 확인하는 단계가 단위 테스트이다.

V-Model에서 중요한 것은 단순히 개발이 끝난 뒤 테스트를 수행한다는 의미가 아니다. 왼쪽 개발 단계에서 만들어지는 산출물(Artifact)의 품질이 오른쪽 테스트 단계의 품질에 직접적인 영향을 준다는 점이다. 예를 들어 요구사항 분석서(Requirements Specification)의 품질이 낮거나 모호하면, 이를 기반으로 작성되는 시스템 테스트 케이스(System Test Case)의 품질도 낮아질 수밖에 없다. 따라서 테스트 품질을 높이기 위해서는 개발 산출물의 품질도 함께 높여야 한다.

이를 위해 V-Model에서는 검증(Verification)과 확인(Validation)을 강조한다. 검증은 개발 산출물이 정해진 기준과 명세에 맞게 만들어졌는지 확인하는 활동이고, 확인은 최종 제품이 사용자 요구와 실제 사용 목적을 만족하는지 확인하는 활동이다. 즉, V-Model은 개발 과정에서 만들어진 산출물을 계속 점검하고, 최종적으로 소프트웨어가 올바르게 만들어졌는지 확인하는 구조를 가진다.

또한 품질 확보를 위해서는 개발자가 자신의 산출물만 스스로 확인하는 것보다, 제3자의 관점에서 리뷰(Review)하고 점검하는 것이 중요하다. 예를 들어 요구사항 분석 단계에서 나온 분석서는 시스템 테스트 담당자나 품질 담당자가 함께 검토할 수 있다. 이렇게 테스트 담당자가 개발 초기 단계부터 참여하면, 요구사항이 테스트 가능한 형태로 작성되었는지 확인할 수 있고, 이후 테스트 케이스를 더 정확하게 설계할 수 있다.

결국 V-Model은 개발 영역과 테스트 영역을 분리해서 보는 모델이 아니라, 서로 병행하며 품질을 높여가는 모델이다. 왼쪽 개발 산출물의 품질이 좋아야 오른쪽 테스트 산출물의 품질도 좋아지고, 테스트 활동 역시 개발 초기 단계부터 함께 고려되어야 한다. 궁극적으로 V-Model의 목적은 개발과 테스트를 체계적으로 연결하여 소프트웨어 품질(Software Quality)을 확보하는 것이라고 할 수 있다.

Software Testing Process

두 번째 챕터에서는 소프트웨어 테스트 프로세스(Software Testing Process)에 대해 학습한다. 이 챕터의 핵심은 테스트를 단순히 수행하는 활동으로만 보는 것이 아니라, 체계적인 프로세스(Process)로 이해하는 것이다.

먼저 중요한 키워드는 테스트의 정의(Definition of Testing)이다. 테스트는 소프트웨어가 요구사항(Requirements)을 만족하는지 확인하고, 결함(Defect)을 발견하기 위한 활동이다.

테스트를 체계적으로 수행하기 위해 PDCA 관점의 테스트 프로세스(PDCA-based Test Process)를 살펴보았다. 테스트는 계획(Plan), 수행(Do), 확인(Check), 개선(Act)의 흐름에 따라 반복적으로 관리되어야 한다.

또한 ISO/IEC/IEEE 29119의 테스트 프로세스(Test Process)도 중요한 내용으로 등장한다. 이는 소프트웨어 테스트를 체계적으로 수행하기 위한 표준 프로세스이다.

테스트를 제대로 수행하기 위해서는 먼저 테스트 계획(Test Planning)이 필요하다. 테스트 계획을 세울 때는 어떤 부분을 우선적으로 테스트할지 판단해야 하며, 이를 위해 위험 기반 테스트(Risk-based Testing)가 강조된다. 위험이 큰 부분을 먼저 고려하여 테스트 계획을 수립하는 것이 중요하다.

마지막으로 테스트 프로세스의 자동화(Test Process Automation)도 주요 키워드이다. 테스트 자동화는 테스트 활동을 더 효율적으로 수행하기 위한 방법이다.

정리하면, 이 챕터의 주요 키워드는 테스트의 정의(Definition of Testing), PDCA 기반 테스트 프로세스(PDCA-based Test Process), ISO/IEC/IEEE 29119 테스트 프로세스(Test Process), 테스트 계획(Test Planning), 위험 기반 테스트(Risk-based Testing), 테스트 프로세스 자동화(Test Process Automation)이다.

Definition of Testing

테스트(Testing)의 근본적인 목적은 소프트웨어에 결함이 없음을 증명하는 것이 아니라, 소프트웨어 안에 존재하는 결함(Defect)을 발견하는 것이다. 즉, 테스트를 잘 수행했다는 것은 단순히 프로그램이 실행되는 것을 확인했다는 뜻이 아니라, 숨어 있는 결함을 효과적으로 찾아냈다는 의미이다.

소프트웨어는 개발자가 직접 만들기 때문에, 만든 사람이 스스로 테스트할 경우 문제를 놓칠 가능성이 있다. 따라서 품질을 더 객관적으로 확인하기 위해서는 제3자 관점(Third-party Perspective)에서 테스트하는 것이 중요하다. 조직 내부에서도 개발자와는 다른 관점의 테스터(Tester)가 소프트웨어를 평가하면, 사용자가 실제로 겪을 수 있는 문제를 더 잘 발견할 수 있다.

또한 테스터는 소프트웨어를 실제 사용하는 사용자(User)의 관점도 고려해야 한다. 소프트웨어가 개발자의 PC에서는 잘 동작하더라도, 실제 사용자 환경(User Environment)에서도 항상 잘 동작한다고 보장할 수는 없다. 운영체제(Operating System), 하드웨어(Hardware), 네트워크(Network), 사용 방식 등 다양한 환경에 따라 문제가 발생할 수 있기 때문이다.

따라서 테스트는 다양한 사용자 환경을 구성하고, 체계적인 방법으로 수행되어야 한다. 결론적으로 테스트의 핵심 목적은 결함을 발견하는 것이며, 이를 위해 제3자 관점에서 사용자의 실제 환경을 고려하여 소프트웨어를 평가하는 것이 중요하다.

PDCA-based Test Process

PDCA 관점의 테스트 프로세스(PDCA-based Test Process)는 테스트를 단순히 입력값을 넣고, 실행하고, 결과를 확인하는 활동으로만 보지 않는다. 테스트를 제대로 수행하기 위해서는 테스트 수행 이전에 Plan, Do, Check, Act의 과정이 체계적으로 진행되어야 한다.

이 개념은 V-Model과도 연결된다. V-Model의 왼쪽 영역에서 요구사항 분석(Requirements Analysis), 설계(Design)와 같은 개발 활동이 진행될 때, 오른쪽 테스트 활동도 함께 계획되고 설계되어야 한다. 즉, 개발이 모두 끝난 뒤에 테스트를 생각하는 것이 아니라, 개발 초기 단계부터 어떤 테스트를 수행할지 함께 고려해야 한다. 이렇게 개발 담당자와 테스트 담당자가 함께 소통하면 산출물(Artifacts)의 품질도 자연스럽게 높아지게 된다.

테스트 계획 단계(Test Planning)에서는 전체 테스트 계획을 수립한다. 이때 어떤 기능(Feature)을 테스트할지, 테스트 범위는 어디까지인지, 어떤 방식으로 테스트할지 등을 정한다. 테스트 설계 단계(Test Design)에서는 테스트 케이스(Test Case)를 개발하고, 테스트 절차(Test Procedure)를 정의하며, 테스트 환경(Test Environment)을 준비한다. 이러한 활동들은 실제 테스트를 수행하기 전에 먼저 진행되어야 한다.

그 다음 실제 테스트 수행(Test Execution)이 이루어진다. 테스트는 사람이 직접 수행할 수도 있고, 자동화 도구(Test Automation Tool)를 활용하여 수행할 수도 있다. 테스트 수행 후에는 결과를 확인하고 평가해야 한다. 발견된 문제가 실제 결함(Defect)인지, 테스트 프로세스(Process)의 문제인지, 또는 자동화 도구가 잘못 판단한 것인지 분석해야 한다.

이후에는 평가 결과를 바탕으로 개선(Improvement)을 수행한다. 테스트 과정에서 부족했던 부분이나 잘못된 절차가 있다면 수정하고, 더 나은 테스트 프로세스로 개선해 나가야 한다. 즉, 테스트는 한 번 수행하고 끝나는 것이 아니라, Plan, Do, Check, Act의 흐름에 따라 반복적으로 관리되어야 한다.

정리하면, PDCA 기반 테스트 프로세스는 테스트 활동을 체계적으로 계획하고, 수행하고, 평가하고, 개선하는 과정이다. 이를 통해 테스트 프로세스의 품질(Process Quality)을 높일 수 있고, 결과적으로 소프트웨어 제품의 품질(Product Quality)도 향상될 수 있게 된다.

ISO/IEC/IEEE 29119 Test Process

ISO/IEC/IEEE 29119는 소프트웨어 테스트 프로세스(Software Test Process)를 국제 표준으로 정의한 문서이다. 이 표준은 수업에서 여러 번 다루어진 중요한 내용이며, 테스트를 체계적으로 수행하기 위한 기준을 제시한다.

ISO/IEC/IEEE 29119의 테스트 프로세스는 크게 세 가지로 나눌 수 있다. 첫 번째는 조직 차원의 테스트 프로세스(Organizational Test Process), 두 번째는 테스트 관리 프로세스(Test Management Process), 세 번째는 동적 테스트 프로세스(Dynamic Test Process)이다.

조직 차원의 테스트 프로세스는 조직 전체에서 테스트를 어떻게 수행할 것인지에 대한 정책(Test Policy)과 전략(Test Strategy)을 수립하는 단계이다. 테스트가 개인이나 프로젝트마다 제각각 수행되는 것이 아니라, 조직 차원에서 일관된 기준과 방향을 가지고 수행될 수 있도록 기반을 마련하는 역할을 한다.

테스트 관리 프로세스는 실제 테스트가 제대로 수행될 수 있도록 계획하고 관리하는 과정이다. 테스트 계획(Test Planning), 테스트 모니터링(Test Monitoring), 테스트 통제(Test Control), 테스트 완료 활동(Test Completion) 등이 여기에 포함될 수 있다. 즉, 동적 테스트를 수행하기 전에 무엇을 어떻게 테스트할지 관리하는 역할을 한다.

동적 테스트 프로세스는 실제로 소프트웨어를 실행하여 테스트하는 과정이다. 테스트 케이스(Test Case)를 설계하고, 테스트 절차(Test Procedure)를 만들고, 테스트 환경(Test Environment)을 준비한 뒤 실제 테스트를 수행한다. 이후 나온 결과를 확인하고 결함(Defect)을 보고하는 활동도 포함된다.

이 세 가지 프로세스는 서로 분리되어 있는 것이 아니라 연결되어 있다. 조직 차원의 테스트 프로세스에서 수립된 정책과 기준은 테스트 관리 프로세스로 전달되고, 테스트 관리 프로세스는 다시 동적 테스트 프로세스가 제대로 수행될 수 있도록 방향을 제공한다. 반대로 동적 테스트 프로세스에서 나온 결과는 테스트 관리 프로세스로 전달되어 평가되고, 다시 조직 차원의 테스트 프로세스 개선에도 활용된다.

즉, ISO/IEC/IEEE 29119 테스트 프로세스에는 PDCA(Plan-Do-Check-Act)의 개념이 반영되어 있다. 테스트를 계획하고 수행한 뒤, 결과를 평가하고 개선하는 흐름이 조직 차원, 관리 차원, 실제 테스트 수행 차원에서 반복적으로 이루어진다. 이를 통해 테스트 프로세스의 품질을 높이고, 궁극적으로 소프트웨어 제품 품질(Product Quality)을 향상시키는 것이 목적이다.

Flow of ISO/IEC/IEEE 29119 Test Process

ISO/IEC/IEEE 29119 테스트 프로세스(Test Process)는 테스트를 조직 관점, 프로젝트 관점, 실제 수행 관점으로 나누어 체계적으로 관리하는 구조이다. 이 프로세스 안에는 PDCA(Plan-Do-Check-Act)의 흐름이 반영되어 있다.

먼저 조직 차원의 테스트 프로세스(Organizational Test Process)에서는 조직 전체의 테스트 방향을 정한다. 테스트 조직(Test Organization)을 어떻게 구성할 것인지, 테스트 환경(Test Environment)을 어떻게 마련할 것인지, 어떤 기준과 원칙으로 테스트를 수행할 것인지와 같은 테스트 정책(Test Policy)을 수립한다. 이를 바탕으로 조직 차원의 테스트 전략(Test Strategy)이 만들어지고, 이 전략은 프로젝트 차원의 테스트 관리 프로세스(Test Management Process)로 전달된다.

테스트 관리 프로세스에서는 프로젝트 차원에서 테스트 계획(Test Planning)이 시작된다. 이는 PDCA의 Plan에 해당한다. 이 단계에서는 테스트 대상(Test Object), 테스트 목표(Test Objective), 테스트 범위(Test Scope) 등을 정한다. 즉, 무엇을 테스트할 것인지, 어떤 목적을 가지고 테스트할 것인지 계획하는 단계이다.

이후 테스트 계획은 동적 테스트 프로세스(Dynamic Test Process)로 전달된다. 동적 테스트 프로세스에서는 단위 테스트(Unit Testing), 통합 테스트(Integration Testing), 시스템 테스트(System Testing), 인수 테스트(Acceptance Testing) 또는 성능 테스트(Performance Testing), 보안 테스트(Security Testing) 등에 대한 테스트 설계(Test Design)와 구현(Test Implementation)이 이루어진다. 또한 실제 테스트를 수행하기 위한 테스트 환경(Test Environment)도 준비한다. 이 과정 역시 실제 테스트 실행 전에 수행되어야 하는 Plan 단계로 볼 수 있다.

그 다음에는 실제 테스트 수행(Test Execution)이 이루어진다. 테스트 명세(Test Specification)가 준비되고 테스트 환경이 구성된 상태에서, 입력값(Input)을 넣고 출력 결과(Output)가 기대한 대로 나오는지 확인한다. 이 단계는 PDCA의 Do에 해당한다.

테스트 수행 후에는 결과를 확인하고 평가(Test Evaluation)한다. 테스트 결과가 요구사항을 만족하는지, 결함(Defect)이 발견되었는지, 테스트 과정에 문제가 있었는지 확인한다. 이후 테스트 프로세스도 완벽하지 않기 때문에, 더 효율적으로 수행하기 위해 개선(Test Improvement)이 필요하다. 이 과정은 PDCA의 Check와 Act에 해당한다.

정리하면, ISO/IEC/IEEE 29119는 테스트를 조직 차원의 테스트 프로세스, 테스트 관리 프로세스, 동적 테스트 프로세스로 구분한다. 조직 차원의 정책과 전략이 프로젝트 테스트 계획으로 전달되고, 다시 실제 동적 테스트 설계와 수행으로 이어진다. 그리고 테스트 결과는 다시 평가와 개선으로 연결된다. 즉, 테스트 프로세스 전체가 PDCA 사이클을 기반으로 반복적으로 개선되는 구조이다.

Test Planning and Risk-based Test Strategy

테스트 계획(Test Planning)은 테스트 프로세스에서 가장 중요한 부분 중 하나이다. 테스트 계획이란 테스트하고자 하는 대상(Test Object)을 이해하고, 테스트 범위(Test Scope)를 정하며, 어떤 방식으로 테스트할지, 누가 수행할지, 어떤 도구(Test Tool)를 사용할지, 어떤 절차(Test Procedure)를 따를지를 미리 정하는 과정이다.

이때 특히 중요한 것은 위험 기반 테스트 계획(Risk-based Test Planning)을 수립하는 것이다. 위험(Risk)이란 아직 발생하지 않았지만 앞으로 문제가 될 수 있는 잠재적인 요소를 의미한다. 테스트 계획 단계에서는 아직 테스트를 수행하기 전이므로, 테스트 관점에서 어떤 문제가 발생할 수 있는지를 미리 생각해야 한다.

예를 들어 고객이 요구사항(Requirements)을 명확하게 제공하지 않았다면, 이를 기반으로 작성되는 테스트 케이스(Test Case)의 품질도 낮아질 수 있다. 또한 여러 요구사항 중에서 고객(Customer), 사용자(User), 이해관계자(Stakeholder) 입장에서 가장 중요한 요구사항이 무엇인지 파악하는 것도 필요하다. 이러한 과정을 통해 테스트 관점의 위험을 분석할 수 있다.

위험 기반 테스트 전략(Risk-based Test Strategy)이 필요한 이유는 프로젝트의 자원이 항상 제한되어 있기 때문이다. 일정(Schedule), 비용(Cost), 인력, 장소, 도구와 같은 자원은 무한하지 않다. 따라서 모든 요구사항을 동일한 수준으로 동시에 테스트하기는 어렵다. 이때 위험 분석(Risk Analysis)을 통해 중요한 요구사항과 위험도가 높은 부분을 우선적으로 테스트해야 한다.

즉, 위험 기반 테스트 전략은 고객, 사용자, 이해관계자 관점에서 중요한 요구사항을 찾아내고, 그 요구사항에서 발생할 수 있는 위험을 완화(Mitigation)하거나 해결할 수 있는 방법을 테스트 계획에 반영하는 것이다. 테스트 계획 단계에서는 반드시 이러한 위험 기반 관점을 고려해야 하며, 이를 통해 제한된 자원을 효율적으로 사용하고 테스트의 효과를 높일 수 있게된다.

Test Process Automation

테스트 프로세스 자동화(Test Process Automation)는 PDCA(Plan-Do-Check-Act)에 기반한 테스트 프로세스의 전체 또는 일부를 도구(Tool)를 활용해 수행하는 개념이다. 즉, 테스트 계획(Test Planning), 테스트 설계(Test Design), 테스트 수행(Test Execution), 결과 확인과 개선(Test Evaluation and Improvement) 중 필요한 부분을 자동화하여 테스트를 더 효율적으로 수행하려는 것이다.

하지만 테스트 프로세스 전체를 무조건 자동화하는 것이 항상 좋은 것은 아니다. 각 단계에 맞는 도구를 구축하고 운영하기 위해서는 많은 비용(Cost), 시간(Time), 인력(Resource)이 필요하다. 따라서 자동화는 모든 영역에 적용하기보다, 실제로 효과가 크고 반복적으로 수행되는 필요한 부분에 적용하는 것이 중요하다.

수업에서는 대표적으로 테스트 설계 자동화(Test Design Automation)와 테스트 수행 자동화(Test Execution Automation)를 살펴보았다. 테스트 설계 자동화는 테스트 케이스(Test Case)를 만들거나 조합하는 과정을 도구로 지원하는 것이고, 테스트 수행 자동화는 사람이 반복적으로 실행해야 하는 테스트를 도구를 통해 자동으로 수행하는 것이다.

정리하면, 테스트 프로세스 자동화는 테스트 활동을 더 효율적으로 수행하기 위한 방법이다. 다만 자동화에는 비용과 운영 부담이 따르기 때문에, 꼭 필요한 부분을 선택하여 적용해야 한다. 이번 챕터에서는 PDCA 관점의 테스트 프로세스와 ISO/IEC/IEEE 29119 국제표준을 함께 살펴보았으며, 테스트 자동화는 이러한 프로세스를 효율적으로 운영하기 위한 수단으로 이해할 수 있다.

📌Test Design Automation은 “어떤 테스트 케이스를 만들까?”를 도와주는 도구이다.
예: PICT로 입력값 조합을 자동 생성

📌Test Execution Automation은 “그 테스트를 자동으로 실행하자”에 가깝다.
예: Selenium이나 Katalon으로 웹사이트 동작을 자동 테스트

Software Test Techniques and AI Testing

세 번째 챕터에서는 소프트웨어 테스트 기법(Software Test Techniques)과 AI 테스트(AI Testing)에 대해 복습한다. 이 챕터의 핵심은 테스트 설계 기법(Test Design Techniques)을 어떻게 분류하고, 일반 소프트웨어와 AI 소프트웨어에 각각 어떤 방식으로 적용할 수 있는지 이해하는 것이다.

먼저 테스트 설계 기법 분류(Classification of Test Design Techniques)를 살펴본다. 테스트 기법은 크게 블랙박스 테스트(Black-box Testing)와 화이트박스 테스트(White-box Testing)로 나눌 수 있다. 블랙박스 테스트는 내부 구조를 보지 않고 요구사항(Requirements)이나 명세(Specification)를 기반으로 입력과 출력의 관계를 확인하는 방식이다. 반면 화이트박스 테스트는 소프트웨어 내부 구조(Internal Structure), 코드 로직(Code Logic), 제어 흐름(Control Flow) 등을 기반으로 테스트하는 방식이다.

이후에는 블랙박스 테스트 설계 기법(Black-box Test Design Techniques)의 종류를 살펴본다. 블랙박스 테스트에서는 동등 분할(Equivalence Partitioning), 경계값 분석(Boundary Value Analysis), 결정 테이블 테스트(Decision Table Testing), 상태 전이 테스트(State Transition Testing) 등 요구사항과 입력 조건을 기반으로 테스트 케이스(Test Case)를 설계하는 방법들이 포함된다.

다음으로 화이트박스 테스트 설계 기법(White-box Test Design Techniques)의 종류를 살펴본다. 화이트박스 테스트에서는 소스 코드(Source Code)의 구조를 기준으로 문장 커버리지(Statement Coverage), 분기 커버리지(Branch Coverage), 조건 커버리지(Condition Coverage) 등을 확인한다. 즉, 코드 내부가 얼마나 충분히 테스트되었는지를 평가하는 데 초점을 둔다.

또한 일반 소프트웨어 테스트 기법뿐만 아니라 AI 소프트웨어 테스트(AI Software Testing)의 품질 특성과 기법도 함께 복습한다. AI 소프트웨어는 데이터(Data)와 모델(Model)에 의존하며, 정확도(Accuracy), 편향성(Bias), 강건성(Robustness), 데이터 품질(Data Quality)과 같은 요소가 중요하다. 따라서 기존 테스트 기법을 그대로 적용하는 것에는 한계가 있을 수 있고, AI 소프트웨어의 특성을 반영한 테스트 기법이 필요하다.

정리하면, 이번 챕터의 주요 키워드는 테스트 설계 기법 분류(Classification of Test Design Techniques), 블랙박스 테스트(Black-box Testing), 화이트박스 테스트(White-box Testing), 일반 소프트웨어 테스트 기법(General Software Test Techniques), AI 소프트웨어 품질과 테스트(AI Software Quality and Testing)이 된다.

Test Design Techniques Classification

테스트 설계 기법(Test Design Techniques)은 크게 블랙박스 테스트(Black-box Testing)와 화이트박스 테스트(White-box Testing)로 분류할 수 있다. 두 기법의 차이는 테스트 대상 소프트웨어(Software)의 내부 로직을 보는지, 보지 않는지에 있다.

블랙박스 테스트(Black-box Testing)는 이름 그대로 소프트웨어 내부를 ‘검은 상자’처럼 보고, 내부 로직(Internal Logic)이나 소스 코드(Source Code)는 고려하지 않는 테스트 방법이다. 테스트하는 사람은 소프트웨어 안에서 어떤 코드가 실행되는지 직접 확인하지 않고, 입력값(Input)을 넣었을 때 출력값(Output)이 요구사항에 맞게 나오는지를 확인한다.

따라서 블랙박스 테스트에서는 테스트 케이스(Test Case)를 만들 때 요구사항 명세서(Requirements Specification), 설계서(Design Document)와 같은 스펙(Specification)을 기반으로 한다. 그래서 블랙박스 테스트는 명세 기반 테스트(Specification-based Testing) 또는 스펙 기반 테스트라고도 부른다.

반면 화이트박스 테스트(White-box Testing)는 소프트웨어 내부의 소스 코드를 직접 들여다보고 테스트하는 방법이다. 즉, 코드의 구조(Code Structure), 로직(Logic), 조건문, 반복문, 실행 경로(Path)를 고려하여 테스트 케이스를 설계한다. 목표는 소스 코드 안의 가능한 독립적인 경로(Independent Path)를 최대한 많이 테스트하는 것이다.

화이트박스 테스트에서는 테스트 케이스를 만들기 위해 소스 코드를 분석해야 한다. 전체 소스 코드의 구성 요소와 구조를 파악한 뒤, 어떤 부분이 실행되었고 어떤 경로가 테스트되었는지를 확인한다. 그래서 화이트박스 테스트는 구조 기반 테스트(Structure-based Testing)라고도 부른다.

정리하면, 블랙박스 테스트는 내부 코드를 보지 않고 요구사항과 출력 결과를 중심으로 테스트하는 방법이고, 화이트박스 테스트는 소스 코드의 내부 구조와 실행 경로를 분석하여 테스트하는 방법이다. 이 차이가 두 테스트 설계 기법을 구분하는 가장 중요한 기준이다.

📌위에서 배운 PICT는 페어와이즈 테스팅또는 조합 테스팅을 위한 도구로 블랙박스 테스트 설계 자동화(Test Design Automation) 도구와 관련이 있다.

예를 들어 로그인 기능을 테스트할 때:

브라우저: Chrome, Edge, Firefox
운영체제: Windows, macOS
계정 상태: 정상, 잠김, 만료

이런 입력 조건들을 조합해서 테스트 케이스를 자동으로 만들어주는 것이 PICT이라고 할 수 있다. 이 과정에서 소스 코드는 보지 않기 때문이다.

📌Selenium은 웹 애플리케이션을 자동으로 실행하고 테스트하는 도구이다. 예를 들어 사용자가 버튼을 클릭하고, 로그인하고, 페이지가 이동하고, 결과 메시지가 나타나는지를 자동으로 확인할 수 있다. 이것도 보통은 소스 코드 내부 구조를 직접 분석하지 않고, 사용자의 관점에서 입력과 출력, 화면 동작을 확인한다. 그래서 Selenium은 주로 블랙박스 테스트 수행 자동화(Test Execution Automation) 도구로 볼 수 있다.

예를 들어:

로그인 페이지에 아이디와 비밀번호 입력
로그인 버튼 클릭
메인 페이지로 이동하는지 확인
오류 메시지가 제대로 나오는지 확인

이런 테스트는 내부 코드가 아니라 사용자 화면과 결과를 기준으로 하므로 블랙박스 테스트에 가깝다.

Black-box Test Design Techniques

블랙박스 테스트(Black-box Testing)는 소프트웨어 내부의 소스 코드(Source Code)나 로직(Logic)을 직접 보지 않고, 요구사항(Requirements)이나 명세(Specification)를 기반으로 테스트 케이스(Test Case)를 설계하는 방법이다. 수업에서는 블랙박스 테스트 설계 기법으로 총 7가지를 학습했다.

첫 번째는 신택스 테스팅(Syntax Testing)이다. 입력값(Input)이 정해진 형식이나 규칙에 맞는지 확인하는 테스트 방식이다. 입력이 올바른 경우와 올바르지 않은 경우를 나누어, 시스템이 각각의 입력을 제대로 처리하는지 확인한다.

두 번째는 동등 분할(Equivalence Partitioning)이다. 입력값이 일정한 범위(Range)를 가질 때, 그 범위를 여러 구간으로 나누고 각 구간의 대표값을 선택하여 테스트하는 방법이다. 예를 들어 성적 관리 시스템에서 점수 구간을 나누고, 각 구간의 대표 점수를 입력하여 결과가 올바르게 나오는지 확인할 수 있다.

세 번째는 경계값 분석(Boundary Value Analysis)이다. 동등 분할에서 나눈 각 구간의 경계 부분을 중심으로 테스트하는 방법이다. 결함은 입력 범위의 중간보다 경계 부분에서 발생할 가능성이 높기 때문에, 구간의 시작값과 끝값 주변을 집중적으로 테스트한다.

네 번째는 결정 테이블 테스팅(Decision Table Testing)이다. 입력 조건(Input Condition)과 출력 결과(Output Result)가 true 또는 false처럼 나누어질 때, 그 조건들의 조합을 표로 정리하여 테스트하는 방법이다. 여러 조건이 함께 작용하여 결과가 달라지는 경우에 유용하다.

다섯 번째는 상태 전이 테스팅(State Transition Testing)이다. 시스템이 여러 상태(State)를 가지고 있고, 이벤트(Event)에 따라 다른 상태로 전이되는 경우에 사용하는 테스트 기법이다. 예를 들어 대기 상태(Waiting State), 실행 상태(Running State), 정지 상태(Stopped State)처럼 시스템의 상태를 정의하고, 이벤트 발생에 따라 상태가 올바르게 변하는지 확인한다. 이때 상태 머신(State Machine)이나 상태 전이 다이어그램(State Transition Diagram)을 활용할 수 있다.

여섯 번째는 시나리오 테스팅(Scenario Testing)이다. 사용자가 실제로 시스템을 사용하는 흐름을 시나리오(Scenario)로 정리하고, 그 흐름에 따라 테스트하는 방법이다. 수업에서는 ATM 현금 인출기(ATM Cash Withdrawal)를 예로 들었다. 정상적으로 현금을 인출하는 시나리오뿐만 아니라, 잘못된 입력, 오류 발생, 다른 기능 사용과 같은 다양한 상황도 함께 테스트할 수 있다.

일곱 번째는 페어와이즈 테스팅(Pairwise Testing)이다. 여러 입력값의 모든 조합을 테스트하기 어려울 때, 두 개의 입력값 쌍(Pair)을 중심으로 조합하여 테스트하는 방법이다. 예를 들어 A, B, C라는 입력 조건이 있을 때 A-B, A-C, B-C처럼 두 조건씩 조합하여 테스트한다. 수업에서는 이 부분을 도구(Tool) PICT를 사용하여 실습하기도 했다.

정리하면, 블랙박스 테스트 설계 기법에는 신택스 테스팅, 동등 분할, 경계값 분석, 결정 테이블 테스팅, 상태 전이 테스팅, 시나리오 테스팅, 페어와이즈 테스팅이 있다. 이 기법들의 공통점은 소스 코드 내부를 직접 분석하지 않고, 요구사항 명세서나 설계서와 같은 스펙을 기반으로 테스트 케이스를 만든다는 점이다.

White-box Test Design Techniques

화이트박스 테스트(White-box Testing)는 소스 코드(Source Code)의 내부 구조와 실행 경로를 분석하여 테스트 케이스(Test Case)를 설계하는 방법이다. 블랙박스 테스트가 요구사항이나 명세를 기반으로 테스트한다면, 화이트박스 테스트는 실제 소스 코드의 구조를 직접 확인하면서 테스트한다는 점이 특징이다.

수업에서는 화이트박스 테스트 설계 기법으로 크게 7가지를 살펴보았다. 여기서 가장 중요한 개념은 테스트 커버리지(Test Coverage)이다. 테스트 커버리지는 소스 코드의 전체 구조, 문장, 분기, 조건, 경로 중에서 얼마나 많은 부분이 테스트되었는지를 나타내는 기준이다. 예를 들어 문장 테스팅(Statement Testing)을 수행하면 문장 커버리지(Statement Coverage)를 확인하고, 분기 테스팅(Branch Testing)을 수행하면 분기 커버리지(Branch Coverage)를 확인한다.

첫 번째는 문장 테스팅(Statement Testing)이다. 문장 테스팅은 소스 코드 안의 실행 가능한 문장(Statement)이 얼마나 테스트되었는지를 확인하는 방법이다. 일반적으로 세미콜론(Semicolon)으로 끝나는 명령문 단위가 테스트 대상이 될 수 있으며, 전체 문장 중 몇 개가 실행되었는지를 기준으로 문장 커버리지를 계산한다.

두 번째는 분기 테스팅(Branch Testing)이다. 분기 테스팅은 if문과 같은 분기 구조에서 Yes/No 또는 True/False 경로가 모두 테스트되었는지를 확인하는 방법이다. 즉, 조건식 전체의 결과가 참인 경우와 거짓인 경우를 모두 확인하여 분기 커버리지를 높이는 것이 목적이다.

세 번째는 조건 테스팅(Condition Testing)이다. 조건 테스팅은 하나의 분기문 안에 여러 개의 개별 조건(Condition)이 있을 때, 각 조건이 참과 거짓을 모두 가질 수 있도록 테스트하는 방법이다. 분기 테스팅이 전체 분기 결과를 본다면, 조건 테스팅은 분기 안에 포함된 각각의 조건을 개별적으로 본다는 차이가 있다.

네 번째는 분기/조건 테스팅(Branch/Condition Testing)이다. 이는 분기 테스팅과 조건 테스팅을 함께 고려하는 방법이다. 전체 분기 결과도 확인하고, 동시에 분기 안에 있는 개별 조건들도 테스트한다.

다섯 번째는 변경 조건/결정 테스팅(Modified Condition/Decision Testing, MC/DC)이다. MC/DC는 분기/조건 테스팅을 더 강화한 방식으로, 각 개별 조건이 전체 결정 결과(Decision)에 독립적으로 영향을 주는지를 확인하는 테스트 기법이다. 조건이 여러 개인 복잡한 분기문에서 테스트 적합성을 높이기 위해 사용된다.

여섯 번째는 다중 조건 테스팅(Multiple Condition Testing)이다. 다중 조건 테스팅은 조건들의 모든 조합을 테스트하는 방법이다. 모든 조건 조합을 확인하기 때문에 커버리지는 높아질 수 있지만, 조건이 많아질수록 테스트 케이스 수가 크게 증가할 수 있다.

일곱 번째는 기본 경로 테스팅(Basis Path Testing)이다. 기본 경로 테스팅은 소스 코드의 독립적인 실행 경로(Independent Path)를 찾아 테스트하는 방법이다. 이때 순환 복잡도(Cyclomatic Complexity)를 활용하여 프로그램의 복잡도를 계산하고, 테스트해야 할 독립 경로의 수를 파악한다. 수업에서는 이 순환 복잡도를 구하는 방법도 함께 학습했다.

이러한 기법들은 문장 테스팅, 분기 테스팅, 조건 테스팅처럼 비교적 낮은 커버리지에서 시작하여, 분기/조건 테스팅, MC/DC, 다중 조건 테스팅으로 갈수록 더 높은 커버리지를 목표로 한다. 하지만 실제 프로젝트에서는 비용(Cost), 일정(Schedule), 자원(Resource)이 제한되어 있기 때문에 무조건 가장 높은 커버리지를 목표로 하기보다, 상황에 맞는 적절한 테스트 기법을 선택해야 한다.

정리하면, 화이트박스 테스트 설계 기법의 핵심은 소스 코드를 직접 분석하여 테스트 케이스를 만들고, 테스트 커버리지를 높이는 것이다. 문장, 분기, 조건, 경로가 얼마나 테스트되었는지를 확인하는 커버리지 개념을 잘 이해하는 것이 중요하다.

AI Software Quality Characteristics

AI 소프트웨어(AI Software)는 일반 소프트웨어가 가지는 품질 특성(Quality Characteristics)을 함께 가진다. 예를 들어 기능 적합성(Functional Suitability), 사용성(Usability), 호환성(Compatibility), 성능 효율성(Performance Efficiency)과 같은 특성은 일반 소프트웨어와 AI 소프트웨어 모두에서 중요하다.

하지만 AI 소프트웨어는 일반 소프트웨어와 구분되는 고유한 특성도 가진다. 대표적으로 적응성(Adaptability), 자율성(Autonomy), 진화(Evolution), 유연성(Flexibility), 편향성(Bias), 성능 메트릭(Performance Metrics), 투명성(Transparency), 복잡성(Complexity), 비결정성(Non-determinism) 등이 있다.

이러한 특성은 AI 소프트웨어가 데이터(Data)를 기반으로 동작하기 때문에 나타난다. AI 모델(AI Model)은 훈련 데이터(Training Data)를 학습하고, 그 학습 결과를 바탕으로 새로운 입력에 대한 예측(Prediction)이나 판단(Decision)을 수행한다. 따라서 더 많은 데이터나 새로운 데이터를 학습하면서 성능이 달라지거나, 환경 변화에 적응하는 모습을 보일 수 있다.

또한 AI 소프트웨어는 일정 수준의 자율성(Autonomy)을 가질 수 있다. 사람이 모든 규칙을 직접 코드로 작성하는 것이 아니라, 모델이 데이터에서 패턴(Pattern)을 학습하고 그에 따라 판단하기 때문이다. 이 과정에서 AI 모델은 유연하게 동작할 수 있지만, 동시에 훈련 데이터에 포함된 편향(Bias)을 함께 학습할 위험도 있다.

AI 소프트웨어의 또 다른 특징은 복잡성과 비결정성이다. AI 모델, 특히 신경망(Neural Network) 기반 모델은 내부 구조가 복잡하여 결과가 어떻게 도출되었는지 이해하기 어려울 수 있다. 또한 학습 방식, 실행 환경, 확률적 처리 방식 등에 따라 같은 입력에 대해서도 결과가 달라질 수 있다. 이러한 특성 때문에 AI 소프트웨어는 일반 소프트웨어보다 테스트하기 어려운 부분이 존재한다.

정리하면, AI 소프트웨어는 일반 소프트웨어의 품질 특성을 가지면서도 데이터 기반 동작으로 인해 적응성, 자율성, 진화, 편향성, 투명성, 복잡성, 비결정성과 같은 고유한 품질 특성을 가진다. 이러한 특성 때문에 AI 소프트웨어만을 위한 테스트 기법(AI Software Test Techniques)이 연구되고 적용되고 있다.

AI Software Test Technique Classification

AI 소프트웨어 테스트 기법(AI Software Test Techniques)은 크게 블랙박스 테스트(Black-box Testing)와 화이트박스 테스트(White-box Testing)로 나눌 수 있다. 일반 소프트웨어 테스트에서도 블랙박스와 화이트박스로 나누어 테스트 기법을 분류했듯이, AI 소프트웨어에서도 같은 기준을 적용할 수 있다.

블랙박스 테스트(Black-box Testing)는 AI 모델(AI Model)의 내부 구조나 동작 원리를 직접 고려하지 않고, 입력(Input)에 대한 출력(Output)이 적절한지만 확인하는 방법이다. 일반 소프트웨어에서는 내부 소스 코드 로직(Source Code Logic)을 보지 않고 테스트했다면, AI 소프트웨어에서는 AI 모델 내부를 보지 않고 입력 데이터에 대해 올바른 결과가 나오는지를 확인한다. 대표적인 AI 블랙박스 테스트 기법으로는 변성 테스트(Metamorphic Testing), 탐색적 테스트(Exploratory Testing) 등이 있다.

반면 화이트박스 테스트(White-box Testing)는 AI 모델 내부의 신경망 구조(Neural Network Structure)와 동작을 고려하여 테스트하는 방법이다. 즉, AI 모델이 어떤 구조로 구성되어 있고, 입력 데이터가 들어왔을 때 내부 뉴런(Neuron)들이 어떻게 활성화되는지를 확인하면서 테스트 케이스(Test Case)를 설계하고 수행한다. 이 점이 블랙박스 테스트와의 가장 큰 차이이다.

AI 소프트웨어의 화이트박스 테스트에서 중요한 개념은 커버리지(Coverage)이다. 일반 소프트웨어에서 소스 코드가 얼마나 테스트되었는지를 문장 커버리지(Statement Coverage), 분기 커버리지(Branch Coverage) 등으로 확인했던 것처럼, AI 소프트웨어에서는 신경망을 구성하는 뉴런들이 얼마나 많이 테스트되었는지를 확인한다. 수업에서는 이와 관련하여 뉴런 커버리지(Neuron Coverage)를 간단히 살펴보았다.

정리하면, AI 소프트웨어 테스트 기법도 일반 소프트웨어 테스트와 마찬가지로 블랙박스 테스트와 화이트박스 테스트로 나눌 수 있다. 블랙박스 테스트는 AI 모델 내부를 보지 않고 입력과 출력의 관계를 중심으로 테스트하는 방법이고, 화이트박스 테스트는 AI 모델 내부의 신경망 구조와 뉴런 커버리지를 고려하여 테스트하는 방법이다. AI 소프트웨어 테스트는 아직 활발히 연구가 진행 중인 분야이며, AI의 특성을 반영한 다양한 테스트 기법들이 계속 발전하고 있다.