소프트웨어 테스팅이란 무엇인가? 왜 필요한가?

알고 있으면 이해하기 쉬운 용어들

커버리지(coverage), 디버깅(debugging), 결함(defect), 오류(error), 실패(failure), 품질(quality), 품질 보증(quality assurance), 근본 원인(root cause), 테스트 분석(test analysis), 테스트 베이시스(test basis), 테스트 케이스(test case), 테스트 완료(test completion), 테스트 조건(test condition), 테스트 관리(test control), 테스트 데이터(test data), 테스트 설계(test design), 테스트 실행(test execution), 테스트 구현(test implementation), 테스트 모니터링(test monitoring), 테스트 대상(test object), 테스트 목표(test objective), 테스트 계획(test planning), 테스트 절차(test procedure), 테스트 결과(test result), 테스트(testing), 테스트웨어(testware), 검증(validation), 확인(verification)

 

---

1. 소프트웨어 테스팅이란?

소프트웨어 시스템은 우리의 일상생활에서 필수적인 부분이다. 대부분의 사람들은 예상대로 작동하지 않는 소프트웨어를 경험한 적이 있을 것이다. 제대로 작동하지 않는 소프트웨어는 금전적 손실, 시간 낭비, 비즈니스 평판 손실과 같은 문제를 초래할 수 있으며, 극단적인 경우 해당 소프트웨어가 어디에 사용되고 있는지에 따라서 부상이나 사망에 이르기도 한다.
소프트웨어 테스트는 소프트웨어 품질을 평가하고, 운영 중 소프트웨어 실패의 위험을 줄이는 데 도움을 준다. 소프트웨어 테스트는 결함을 발견하고 소프트웨어 산출물의 품질을 평가하기 위한 활동들의 집합이다. 우리는 이 소프트웨어 선출물을 테스트 대상(test object)으로 인식하고 있다.
테스트에 대한 일반적인 오해는, 단순히 테스트를 실행하고(즉, 소프트웨어를 실행하고 결과를 확인하는 것) 끝내는 행위로 이해하는 것이다. 하지만 소프트웨어 테스트에는 다른 활동들도 포함되며, 소프트웨어 개발 생명주기(SDLC)와 정렬되어야 한다(2장에서 자세히 설명).
또한 테스트는 정상 동작여부에 대한 확인에만 초점이 맞춰져 있다는 오해도 있다. 테스트는 시스템이 명시된 요구사항을 충족하는지 확인(verification)하는 것 뿐만 아니라, 시스템이 운영 환경에서 사용자 및 기타 이해관계자의 요구를 충족하는지 확인하는 검증(validation)하는 것을 포함한다.
테스트는 동적(dynamic) 또는 정적(static)으로 수행될 수 있다. 동적 테스트는 소프트웨어 실행을 포함하며, 정적 테스트는 실행 없이 진행된다. 정적 테스트에는 리뷰(3장에서 자세히 설명)와 정적 분석이 포함된다. 동적 테스트는 다양한 테스트 기법과 접근 방식을 사용하여 테스트 케이스를 도출한다(4장에서 자세히 설명).
테스트는 기술적 활동에만 국한되지 않으며, 적절히 계획되고, 관리되고, 추정되고, 모니터링 및 통제되어야 한다(5장에서 자세히 설명).
테스터는 도구를 사용하지만(6장에서 자세히 설명), 테스트는 주로 지적 활동으로 테스터가 전문 지식을 보유하고 분석적 사고와 비판적 사고, 시스템 사고를 적용해야 한다.
ISO/IEC/IEEE 29119-1 표준은 소프트웨어 테스트 개념에 대한 추가 정보를 제공하고 있다.

---

1-1. 테스트 목표

일반적인 테스트 목표는 다음과 같다.

• 요구사항, 사용자 스토리, 설계 및 코드와 같은 작업 산출물을 평가한다.
• 실패를 유발하고 결함을 발견한다.
• 테스트 대상에 필요한 커버리지를 보장한다.
• 소프트웨어 품질 부족의 위험 수준을 줄인다.
• 명시된 요구사항 충족 여부를 검증한다.
• 테스트 대상이 계약적, 법적, 규제 요구사항을 준수하는지 확인한다.
• 이해관계자에게 정보를 제공하여 의사결정을 지원한다.
• 테스트 대상의 품질에 대한 신뢰를 구축한다.
• 테스트 대상이 완전하며 이해관계자의 기대에 부합하는지 검증한다.

테스트의 목표는 테스트 중인 작업 산출물, 테스트 레벨, 리스크, 따르는 SDLC, 그리고 기업 구조, 경쟁 요인, 시장 출시 시간과 같은 비즈니스 상황에 따라 달라질 수 있다.

---

1-2. 테스트와 디버깅

테스트와 디버깅은 별개의 활동이다. 테스트는 소프트웨어 결함으로 인한 실패를 유발할 수 있으며(동적 테스트), 테스트 대상에서 결함을 직접 발견할 수도 있다(정적 테스트).
동적 테스트(4장에서 설명)가 실패를 유발한 경우, 디버깅은 이러한 실패의 원인(결함)을 찾고 분석하며 이를 제거하는 활동이다. 일반적인 디버깅 프로세스는 다음과 같다.

• 실패 재현
• 진단(근본 원인 찾기)
• 원인 수정

수정 후 확인 테스트를 통해 문제가 해결되었는지 점검한다. 확인 테스트는 초기 테스트를 수행한 사람이 진행하는 것이 바람직하다. 이후 회귀 테스트를 통해 수정으로 인해 테스트 대상의 다른 부분에서 실패가 발생하지 않는지도 확인한다.
정적 테스트에서 결함을 발견한 경우, 디버깅은 이를 제거하는 활동을 말한다. 정적 테스트는 결함을 직접적으로 발견하기 때문에 실패를 유발하지 않으며, 따라서 실패 재현이나 진단이 필요하지 않다(3장에서 자세히 설명).

---

2. 왜 테스트가 필요한가?

테스트는 품질 관리(QC)의 한 형태로, 설정된 범위, 시간, 품질, 예산 제약 내에서 목표를 달성하는 데 도움을 준다. 테스트의 기여는 테스트 팀 활동에만 국한되지 않으며, 모든 이해관계자가 자신의 테스트 기술을 활용하여 프로젝트 성공에 기여할 수 있다. 테스트는 컴포넌트, 시스템 및 관련 문서를 통해 소프트웨어의 결함을 식별하도록 돕는다.

---

2-1. 테스트가 성공에 기여하는 방법

테스트는 결함을 감지하는 비용 효율적인 수단을 제공한다. 이후 디버깅(테스트 외 활동)을 통해 결함을 수정할 수 있으며, 이를 통해 테스트 대상의 품질이 간접적으로 향상된다.
테스트는 SDLC의 여러 단계에서 테스트 대상의 품질을 직접적으로 평가하는 수단을 제공한다. 이러한 평가는 프로젝트 관리 활동의 일부로 사용되며, 릴리스 결정 등 SDLC의 다음 단계로 넘어갈지 결정하는 데 기여한다.
테스트는 개발 프로젝트에서 사용자 요구를 간접적으로 대변한다. 테스터는 사용자 요구를 개발 생명주기 전반에 걸쳐 고려하도록 보장한다. 대표 사용자 집단을 직접 개발 프로젝트에 참여시키는 대안은 비용이 높고 적절한 사용자가 부족하기 때문에 일반적으로 가능하지 않다.
또한 테스트는 계약적, 법적 요구사항을 충족하거나 규제 표준을 준수하기 위해 필요할 수 있다.

---

2-2. 테스트와 품질 보증(QA)

"테스트"와 "품질 보증(QA)"이라는 용어는 현업에서도 종종 혼용되지만, 테스트와 QA는 동일하지 않다. 테스트는 품질 관리(QC)의 한 형태이다.
QC는 제품 지향적이며, 적절한 품질 수준 달성을 지원하는 활동에 초점을 맞춘 접근방식이다. 테스트는 주요 품질 관리 활동이며, 이외에도 공식적 방법(모델 검증 및 정확성 증명), 시뮬레이션, 프로토타이핑 등이 포함된다.
QA는 프로세스 지향적이며, 예방적 접근으로 프로세스의 구현과 개선에 중점을 둔다. QA는 올바른 프로세스를 올바르게 따르면 좋은 제품이 생성된다는 원리에 기반한다. QA는 개발 및 테스트 프로세스 모두에 적용되며, 프로젝트에 참여하는 모든 사람의 책임이다.
테스트 결과는 QA와 QC 모두에서 사용된다. QC에서는 결함 수정에 사용되며, QA에서는 개발 및 테스트 프로세스가 얼마나 잘 수행되고 있는지에 대한 피드백으로 사용된다.

---

2-3. 오류, 결함, 실패, 그리고 근본 원인

인간은 실수(오류)를 범하며, 이는 결함(버그)을 만들어내고, 결과적으로 실패를 유발할 수 있다. 인간이 오류를 범하는 이유는 시간 압박, 작업 산출물의 복잡성, 프로세스 또는 인프라의 문제, 피로, 적절한 교육 부족 등 다양한 요인에 기인한다.
결함은 요구사항 명세서, 테스트 스크립트 같은 문서, 소스 코드, 빌드 파일 등의 지원 산출물에서 발견될 수 있다. SDLC 초기에 생성된 결함이 발견되지 않으면 이후 단계에서 더 많은 결함으로 이어질 가능성이 크다. 코드 결함이 실행되면 시스템이 수행해야 할 작업을 수행하지 못하거나 불필요한 작업을 수행하여 실패를 유발할 수 있다.
일부 결함은 실행될 때 항상 실패를 유발하며, 특정 조건에서만 실패를 유발하거나 전혀 실패를 유발하지 않을 수도 있다.
실패는 오류와 결함뿐 아니라 환경 조건으로 인해 발생할 수도 있다는 것도 이해하고 있어야 한다. 예를 들어, 방사선이나 전자기장이 펌웨어의 결함을 유발할 수 있다.
근본 원인(Root Cause)은, 문제를 발생시킨 근본적인 이유를 말한다. 실패가 발생하거나 결함이 발견되었을 때 원인 분석을 통해 식별된다. 근본 원인을 해결함으로써 유사한 실패 방지하고 결함의 발생 빈도를 줄이는 것이 중요하다.