완벽한 소프트웨어를 만들기 위해서는 목적에 따라 설계를 정확히 해야 하지만 한번에 완벽한 소프트웨어를 만들기는 거의 불가능하다. 요구사항을 분석하고 설계, 개발하는 일은 모두 쉽지 않지만, 그 중에서도 설계는 가장 어려운 것으로 알려져 있다. 실체가 없는 요구사항을 고객(사용자)과 개발팀이 알아볼 수 있도록 실체화 하는 작업이기 때문이다.
개발팀은 시행착오를 겪어가며 설계를 하고 설계 경험이 쌓여가면서 일반화된 설계 기법을 만들게 된다. 이번 공학트렌드에서는 이러한 설계 기법에 대해 4회에 걸쳐 살펴보고자 하며, 첫 번째로 테스트 설계에 대해 알아본다.
요구사항이 설계와 개발에 모두 반영되었는지 확인하고 소프트웨어가 제대로 동작하는지 확인하는 것이 테스트이다. 테스트의 역할이 확대되면서 상황과 목적에 맞는 테스트 설계가 필요하게 되었고 테스트 설계 기법도 만들어지기 시작했다. 최근에는 체계화된 테스트를 위한 자동화 도구가 개발되었고, 애자일 기반의 테스트까지 선보이고 있다.
이번 회에서는, 전통적으로 반드시 알아두어야 하는 테스트 설계의 종류와 테스트 종류에 따른 설계 기법에 대해 살펴보도록 한다.
개발팀은 시행착오를 겪어가며 설계를 하고 설계 경험이 쌓여가면서 일반화된 설계 기법을 만들게 된다. 이번 공학트렌드에서는 이러한 설계 기법에 대해 4회에 걸쳐 살펴보고자 하며, 첫 번째로 테스트 설계에 대해 알아본다.
요구사항이 설계와 개발에 모두 반영되었는지 확인하고 소프트웨어가 제대로 동작하는지 확인하는 것이 테스트이다. 테스트의 역할이 확대되면서 상황과 목적에 맞는 테스트 설계가 필요하게 되었고 테스트 설계 기법도 만들어지기 시작했다. 최근에는 체계화된 테스트를 위한 자동화 도구가 개발되었고, 애자일 기반의 테스트까지 선보이고 있다.
이번 회에서는, 전통적으로 반드시 알아두어야 하는 테스트 설계의 종류와 테스트 종류에 따른 설계 기법에 대해 살펴보도록 한다.
테스트 설계의 종류
테스트는 일반적으로 코딩의 오류(error)를 잡는 것이라고 알려져 있지만 의도대로 올바르게 동작하지 않는 결함(defect)과 이로 인해 발생하는 장애(failure) 여부를 확인하고 개발에서 일어나는 모든 과정과 문서까지도 테스트 범위에 포함된다.
최상의 소프트웨어 품질을 위해서는 테스트를 반드시 거쳐야 하지만 테스트 결과가 완벽하다고 해서 소프트웨어가 우수하다고 볼 수는 없다. 테스트는 요구한 소프트웨어의 기능이 정확히 갖추어졌는지 확인하는 것이기 때문이다(표 1 참조).
<표 1> 품질 관점의 테스트 범위
테스트의 기본적인 형태는 비실행 기반 테스팅과 실행 기반 테스팅으로 나뉘어 진다(표 2 참조). 일반적으로 우리가 알고 있는 테스트가 실행 기반 테스팅이다. 개발된 기능이 정상적으로 동작하는지 확인한다. 실행 기반 테스팅이 모두 성공했다고 해도 요구된 모든 기능이 구현되었다고 볼 수는 없다. 비실행 기반 테스팅을 통해 요구사항이 모두 반영되었는지 확인한다.
<표 2> 테스팅의 구분
실행 기반 테스팅
실행 기반 테스팅에는 블랙박스 테스팅과 화이트박스 테스팅으로 구분된다(표 3 참조). 실행 기반 테스팅은 대부분 개발자 또는 테스터가 직접 수행할 수 밖에 없었지만 최근에는 테스트 자동화를 통해 쉽고 빠르게 적용하고 있다.
<표 3> 블랙박스 테스팅과 화이트박스 테스팅의 정의
블랙박스 테스트와 화이트박스 테스트는 소프트웨어 내부 로직의 참조 여부로 구분한다. 블랙박스 테스팅은 소프트웨어의 특징이나 요구사항을 기준으로 검토되며, 유닛, 인티그레이션, 기능, 시스템, 적합성 등의 검사가 이루어진다. 화이트박스 테스팅은 소프트웨어가 올바른 로직으로 실행되고 있는지를 검토하는 것으로 블랙박스 테스팅에 비해 번거롭고 시간이 오래 걸리지만 근본적인 테스팅이 이루어진다.
일반적으로, 블랙박스 테스팅만으로 소프트웨어의 정상 여부를 판단하는 경우가 많은데 원하는 결과가 나와도 정확한 로직으로 구동되었는지 화이트박스 테스팅을 통해 확인하는 것이 매우 중요하다.
일반적으로, 블랙박스 테스팅만으로 소프트웨어의 정상 여부를 판단하는 경우가 많은데 원하는 결과가 나와도 정확한 로직으로 구동되었는지 화이트박스 테스팅을 통해 확인하는 것이 매우 중요하다.
비실행 기반 테스팅 비실행 기반 테스팅은 요구사항이 분석, 설계에 명확히 반영되었는지 확인한다. 일반적으로 문서 중심으로 테스트가 진행되며, 워크스루(Workthrough)와 인스펙션(Inspection)을 통해 검토한다(표 4 참조).
<표 4> 워크스루와 인스펙션의 정의
인스펙션은 프로세스 단계가 끝날 때마다 품질관리를 담당하는 전문가와 함께 수행하는 공식적인 활동이다. 인스펙션을 통해 만들어진 산출물의 완성도를 높이게 된다. 워크스루는 인스펙션을 준비하는 비공식적 활동으로 이해하면 된다. 워크스루는 횟수에 제한이 없고 개발팀 내부에서 자체적으로 실시하는 경우가 많다. 워크스루를 통해 예기치 않았던 작은 오류들을 수정하게 된다.
일반적으로, 개발팀에서는 비실행 기반 테스팅을 하지 않거나 작성자가 직접 검토하는 경우가 많다. 소프트웨어는 고객의 요구사항을 기초로 만들어지는데 이를 정리한 산출물들을 검토하지 않으면 프로젝트 후반에 대대적인 수정이 필요할 수도 있다. 표준화된 프로세스가 아니더라도 요구사항이 분석서나 설계서에 반영되었는지 반드시 확인해야 한다.
