소프트웨어 수동 테스팅

**소프트웨어 수동 테스팅**(영어: Software Manual Testing)은 자동화된 도구를 사용하지 않고 사람이 직접 소프트웨어 애플리케이션을 테스트하여 결함을 찾아내는 프로세스이다. 테스터는 최종 사용자의 입장에서 기능, 사용성, 성능 등을 검증하며, 테스트 케이스를 기반으로 하거나 탐색적 테스팅과 같은 비정형적인 기법을 사용하기도 한다. 이는 소프트웨어 품질 보증의 핵심 활동 중 하나이다.
# 개요
수동 테스팅의 주요 목적은 소프트웨어가 요구사항 명세서에 따라 정확하게 동작하는지 확인하고, 자동화 테스트로는 발견하기 어려운 사용자 경험(UX) 및 사용성 관련 문제를 식별하는 것이다. 특히, 시각적인 부분(UI), 직관성, 조작의 용이성, 디자인의 일관성 등은 인간의 주관적인 인지와 판단이 중요하기 때문에 수동 테스팅이 필수적이다. 자동화 테스트가 *기능이 명세대로 동작하는가*를 검증한다면, 수동 테스팅은 *사용자가 만족스럽게 사용할 수 있는가*라는 질적인 측면까지 다룬다.
# 수동 테스팅과 자동화 테스팅의 비교
수동 테스팅은 자동화 테스팅과 상호 보완적인 관계이며, 프로젝트의 특성과 단계에 따라 적절한 비중으로 활용된다. {| class="wikitable" |+수동 테스팅과 자동화 테스팅의 비교 !구분 !수동 테스팅 (Manual Testing) !자동화 테스팅 (Automated Testing) |- !**인간의 판단** |UI/UX, 디자인, 직관성 등 주관적 요소 평가에 절대적으로 필요하다. |시각적 요소나 사용자의 만족도와 같은 질적 측면을 평가할 수 없다. |- !**테스트 범위 및 유연성** |탐색적 접근을 통해 예상치 못한 시나리오와 결함을 발견할 수 있어 유연성이 매우 높다. |사전에 정의된 스크립트 내에서만 테스트가 가능하여 범위가 제한적이다. |- !**비용** |초기 투자 비용은 낮으나, 반복 수행 시 인건비로 인해 장기적인 비용이 증가한다. |테스트 도구 도입 및 스크립트 개발로 초기 비용이 높지만, 재사용성이 높아 장기적으로 비용 효율적이다. |- !**속도 및 효율성** |테스트 실행 속도가 느리고, 사람이 직접 수행하므로 피로에 의한 실수가 발생할 수 있다. |대규모 테스트 케이스를 빠르고 일관되게 실행할 수 있어 회귀 테스트에 매우 효율적이다. |- !**적합한 테스트 유형** |사용성 테스트, 탐색적 테스트, 애드혹 테스트, 신규 기능 검증 |회귀 테스트, 성능 테스트, 부하 테스트, 데이터 기반 테스트 |}
# 테스팅 단계별 역할
소프트웨어 개발 생명주기(SDLC)의 각 단계에서 수동 테스팅은 중요한 역할을 수행한다. * **단위 테스팅**: 주로 개발자가 화이트박스 기법을 이용해 코드 단위(함수, 메서드)를 검증하지만, 때로는 GUI 컴포넌트의 시각적 요소를 확인하기 위해 수동으로 수행되기도 한다. * **통합 테스팅**: 모듈 간의 인터페이스와 데이터 흐름을 검증하는 단계. 시스템의 복잡한 워크플로우를 따라가며 상호작용을 확인하는 시나리오 기반 테스트는 수동으로 수행하는 것이 효과적이다. * **시스템 테스팅**: 완전히 통합된 시스템 전체를 대상으로 기능적/비기능적 요구사항을 검증한다. 최종 사용자의 환경과 가장 유사한 상태에서 실제 시나리오를 수행하므로 수동 테스팅의 비중이 매우 높다. * **인수 테스팅**: 사용자가 직접 소프트웨어를 사용해보며 요구사항이 충족되었는지 최종 확인하는 단계이다. 알파 및 베타 테스트가 대표적인 수동 인수 테스팅에 해당한다.
# 수동 테스팅의 유형
테스트 대상에 대한 이해 수준과 접근 방식에 따라 다음과 같이 분류된다.
## 블랙박스 테스팅
내부 구조나 소스 코드를 참조하지 않고, 오직 입력과 출력 값에만 집중하여 시스템의 기능적 요구사항을 검증하는 기법이다. * **동등 분할**: 유사한 결과를 도출하는 입력 값의 집합을 그룹으로 묶어, 각 그룹에서 하나의 대표 값만 테스트하는 기법. * **경계값 분석**: 입력 값의 경계(예: 최솟값, 최댓값, null)에서 오류가 발생할 확률이 높다는 점에 착안하여 경계값을 집중적으로 테스트하는 기법. * **결정 테이블 테스팅**: 복잡한 비즈니스 로직이나 규칙을 테이블 형태로 정리하여, 모든 조건의 조합을 체계적으로 테스트하는 기법. * **상태 전이 테스팅**: 시스템의 상태가 특정 입력이나 이벤트에 따라 어떻게 변하는지를 다이어그램으로 그리고, 모든 상태 전이 경로를 테스트하는 기법. * **사용자 케이스 테스팅**: 사용자 관점의 시나리오를 기반으로 시스템의 상호작용이 정상적으로 이루어지는지 검증한다.
## 화이트박스 테스팅
소프트웨어의 내부 코드 구조, 제어 흐름, 데이터 흐름을 이해하고 이를 기반으로 테스트 케이스를 설계하는 기법이다. 주로 개발자가 수행한다. * **구문 커버리지**: 코드의 모든 실행문이 한 번 이상 실행되도록 테스트한다. * **결정 커버리지**: 코드 내 모든 조건문(if, switch 등)이 참과 거짓 결과를 모두 갖도록 테스트한다. * **경로 커버리지**: 프로그램 내에서 실행 가능한 모든 경로를 테스트하는 가장 강력한 수준의 커버리지 기법이다.
## 그레이박스 테스팅
블랙박스와 화이트박스 테스팅을 결합한 형태로, 시스템의 내부 구조(예: 데이터베이스 스키마, API 명세)에 대해 일부만 알고 있는 상태에서 테스트를 수행한다. 주로 통합 테스트 단계에서 컴포넌트 간의 인터페이스 오류를 발견하는 데 효과적이다.
# 수동 테스팅 프로세스
체계적인 수동 테스팅은 다음과 같은 단계를 거쳐 수행된다. # **테스트 계획 수립**: 테스트의 목표, 범위, 일정, 리소스, 사용할 방법론, 성공/실패 기준 등을 정의하는 단계. # **테스트 케이스 설계**: 계획을 바탕으로 구체적인 테스트 시나리오와 절차, 예상 결과를 포함하는 테스트 케이스를 작성한다. # **테스트 환경 구축**: 테스트를 수행할 하드웨어, 소프트웨어, 네트워크 환경을 실제 운영 환경과 유사하게 구성한다. # **테스트 실행**: 설계된 테스트 케이스에 따라 테스터가 직접 소프트웨어를 실행하고, 실제 결과를 예상 결과와 비교하여 기록한다. # **결함 보고 및 관리**: 예상 결과와 다른 동작(버그)이 발견되면, 재현 경로, 스크린샷, 로그 등을 첨부하여 결함 추적 시스템(예: Jira, Bugzilla)에 보고한다. # **테스트 결과 분석 및 보고**: 테스트 활동이 종료되면, 테스트 커버리지, 발견된 결함, 잔여 리스크 등을 분석하여 최종 보고서를 작성하고 이해관계자들과 공유한다.
# 산업 동향 및 적용 분야
자동화가 대세인 시대에도 수동 테스팅의 중요성은 여전히 강조되며, 특정 분야에서는 필수불가결하다. * **게임 산업**: 게임의 재미, 밸런스, 조작감, 그래픽 품질 등은 플레이어의 주관적인 경험에 의존하므로 100% 수동 테스팅으로 검증된다. * **금융 및 의료 시스템**: 사용자의 오작동을 유발할 수 있는 미묘한 UI 결함이 치명적인 결과를 낳을 수 있으므로, 복잡한 비즈니스 로직과 워크플로우를 사람이 직접 검증해야 한다. * **단기 프로젝트 및 스타트업**: UI가 자주 변경되고 개발 주기가 짧은 환경에서는 자동화 스크립트 작성 및 유지보수 비용보다 수동 테스트가 더 경제적이고 신속하다. * **복잡한 ERP 시스템**: 수많은 모듈과 사용자 권한이 얽혀있는 대규모 시스템은 모든 시나리오를 자동화하기 불가능하여, 핵심 비즈니스 프로세스는 숙련된 테스터가 수동으로 검증한다.
# 관련 학술 연구 및 이론
소프트웨어 테스팅 분야의 권위자인 **켐 케이너**, **제임스 바흐** 등은 **상황 주도 테스팅 학파**를 주창하며 수동 테스팅의 지적 활동 측면을 강조했다. 이들은 "좋은 테스팅은 정해진 규칙을 따르는 것이 아니라, 특정 상황(Context)에 맞춰 기술과 휴리스틱을 창의적으로 적용하는 것"이라고 주장하며, 탐색적 테스팅의 중요성을 이론적으로 정립했다.Cem Kaner, James Bach, Bret Pettichord (2002). *Lessons Learned in Software Testing*. Wiley. ISBN 978-0471081128. 또한, 플로리다 공과대학교(Florida Institute of Technology)의 연구에 따르면, 탐색적 테스팅은 스크립트 기반 테스팅에 비해 특정 유형의 결함을 더 빠르고 효율적으로 발견할 수 있으며, 특히 시간적 제약이 있는 프로젝트에서 효과적임이 입증되었다.Itkonen, J., & Rautiainen, K. (2005). Exploratory testing: A multiple case study. *Proceedings of the International Symposium on Empirical Software Engineering (ISESE)*.