서론
테스팅은 소프트웨어 수명주기 전반에 걸쳐 소프트웨어의 리스크를 효과적이고 효율적으로 관리할 수 있는 활동으로서 주목받고 있다. 테스트 프로세스와 소프트웨어 수명주기와의 관계를 살펴보자. 2장의 학습 목표는 "소프트웨어 개발 모델이 무엇이 있으며, 테스트 레벨과 테스트 유형과 더불어 유지보수 테스팅을 이해:하는 것이다. 이를 기억하고 내용을 이해해 보자.
배우기에 앞서 용어 정리
용어를 확실하게 아는 것이 이해에 도움이 된다. ISTQB가 개발자뿐만 아니라 다른 직군도 시험을 충분히 볼 수 있기에 이해하기 쉽게 용어의 정의를 살펴보자.
- V 모델: 요구사항 명세부터 유지보수까지의 소프트웨어 개발 수명주기 활동을 기술한 프레임워크.
- 순차적 개발 모델: 단계적으로 소프트웨어를 개발하는 방법
- 폭포수 개발 모델: 단계별로 진행되는 선형적인 개발 방식
- RUP: 하나로 고정되어 쓰인 프로세스가 아니라, 적응이 가능한 프로세스 프레임워크.
- 컴포넌트 테스팅(단위 테스팅): 개별적인 소프트웨어 컴포넌트에 대한 테스트.
- 통합 테스팅: 통합된 컴포넌트나 시스템 간의 인터페이스와 상호작용에서의 결함을 중점적으로 찾는 테스팅.
- 시스템 테스팅: 명시된 요구사항을 만족하는지 확인하기 위해 통합된 시스템을 테스트하는 절차.
- 인수 테스팅: 시스템이 인수조건을 만족시키는지, 사용자, 고객 또는 다른 인가된 개체가 시스템을 인수할지 결정할 수 있도록 사용자의 필요, 요구, 그리고 비즈니스 프로세스를 고려하여 수행하는 공식적인 테스팅.
- 정적 테스팅: 리뷰 또는 정적 코드 분석과 같이 소프트웨어의 실행 없이 명세 또는 구현, 개발 단계에서 컴포넌트나 시스템을 테스팅하는 것.
- 동적 테스팅: 컴포넌트나 시스템 소프트웨어를 실행하면서 수행하는 테스팅.
- 리그레션 테스팅: 수정으로 인해 변경되지 않은 소프트웨어 영역에 새로운 결함이 유입되지 않았는지, 또는 기존에 숨어있던 결함이 노출되지 않았는지 확인하기 위해 이전에 테스트된 프로그램을 다시 테스팅 하는 것.
- 구조 기반 테스팅: 소프트웨어의 내부 구조를 중점적으로 테스트하는 방법론(화이트 박스의 일종)
- 기능적 특성: 소프트웨어가 사용자에게 제공하는 기능이나 작업
- 비기능적 특성: 소프트웨어의 성능, 보안, 사용자 경험 등과 같은 기능 이외의 측면
- 블랙박스 테스팅(Black box testing): 테스트를 수행할 때 소프트웨어의 내부 구조나 작동 원리에 대해 사전 지식이 없는 상태에서 테스트 케이스를 설계하고 실행하는 방법론
- 화이트박스 테스팅(White box testing): 테스트를 수행할 때 내부 구조와 동작을 이해하여 테스트 케이스를 설계하는 방법론
- 알파 테스팅: 개발조직 외부에 위치한 개발 환경 또는 개발자 사이트에서 잠재적 사용자, 고객 또는 독립된 테스트 팀에 의해 수행되는 가상 혹은 실제 운영상의 테스팅.
- 베타 테스팅: 컴포넌트나 시스템이 사용자/고객의 요구를 충족하는지, 비즈니스 프로세스에 적합한지 등을 결정하기 위해 개발자를 참여시키지 않고, 잠재/기존 고객의 외부 사이트에서 직접 수행하는 운영상의 테스팅.
- 기능 테스팅: 컴포넌트나 시스템의 기능 명세 분석에 정의된 요구 기능이 잘 작동하는 지를 확인하는 테스팅.(블랙박스 테스팅의 일종)
- 구조적 테스팅: 화이트 박스의 일종.
- 비기능 테스팅: 기능성과 연관시키지 않고 신뢰성, 효율성, 유지보수성 그리고 이식성 등과 같은 컴포넌트나 시스템의 품질 특성이나 속성을 테스팅.
소프트웨어 개발 수명주기 모델
소프트웨어 개발 수명주기 모델은 소프트웨어 개발 프로젝트의 각 단계에서 이루어지는 활동 유형과 이런 활동이 서로 어떻게 논리적 또 순차적으로 연결되는지 보여준다. 여러 가지 소프트웨어 개발 수명주기 모델이 있으며, 각각 다른 테스팅 접근법을 요구한다.
소프트웨어 개발과 소프트웨어 테스팅
필요한 테스트 활동을 수행할 수 있도록 일반적으로 많이 사용되는 소프트웨어 개발 수명주기 모델을 잘 이해하는 것은 테스터의 중요한 역할 중 하나이다.
모든 소프트웨어 개발 수명주기 모델에 적용하기 좋은 테스팅의 특성을 들면 다음과 같다.
- 모든 개발 활동은 그에 상응하는 테스트 활동이 있다.
- 각 테스트 레벨은 그 레벨에 맞는 구체적인 목적을 가진다.
- 주어진 테스트 레벨에 맞는 테스트 분석과 설계는 상응하는 개발 활동이 이루어지고 있는 동안 시작해야 한다.
- 테스터가 요구사항과 설계의 정의와 개선을 위한 대화에 참여하고, 작업 산출물의 초안이 나오는 즉시 리뷰에 참여한다.
어떤 소프트웨어 개발 수명주기 모델을 선택하더라도 테스팅을 초기에 시작하면 시간과 비용을 절약할 수 있다는 테스트 원리에 따라, 테스트 활동은 수명주기 초반에 시작해야 한다. 대표적인 소프트웨어 개발 수명주기 모델로 순차적(sequential) 개발 모델와 반복적 점진적(iterative and incremental) 개발 모델이 있다.
V모델(순차적 개발 모델)
순차적 개발 모델에서는 소프트웨어 개발 프로세스를 1차원적 선형(linear)의 순차적 활동으로 설명한다. 즉, 개발 프로세스의 모든 단계는 이전 단계가 완료될 때 시작돼야 한다. 이론적으로는 각 단계가 서로 중첩하지 않지만, 실제로는 다음 단계에서 빨리 피드백을 받는 것이 유익하다.
폭포수 모델(Waterfall model)에서는, 개발 활동이 순차적으로 이루어진다. 이 모델에서의 테스트 활동은 모든 개발 활동을 완료한 후에 이루어진다.
폭포수 모델과는 다르게, V-모델은 테스팅을 초기에 시작하면 좋다는 원리를 토대로 테스트 프로세스를 전반적인 개발 프로세스에 통합한다. 또한, V-모델은 대응하는 각 개발 단계에 테스트 레벨을 부여함으로써 조기 테스팅을 좀 더 적극적으로 구현하고 있다. 이 모델에서는 각 테스트 레벨의 테스트 실행이 순차적으로 이루어지도록 하고 있지만 경우에 따라서는 중첩되기도 한다. 순차적 개발 모델에서는 완성된 기능 세트를 포함한 소프트웨어를 배포할 수 있지만, 일반적으로 이해관계자와 사용자에게 배포하기까지 몇 개월 또는 몇 년이 걸린다.
그럼에도 V 모델을 사용하는 이유는 각각의 개발 단계에서 테스팅을 접근하는 방법을 개략적으로 이해하기 쉽게 모델화하여 보여주기 때문이다.
반복적 점증적 개발 모델
점진적 개발에서는 요구사항 정의, 시스템의 설계, 구축, 테스팅을 조각으로 나눠서 진행한다. 따라서, 소프트웨어 기능은 점진적으로 늘어나게 된다. 이런 기능 증분(feature increments)의 크기는 다양하게 설정할 수 있다. 일부 방법론에서는 증분을 크게 설정하며 다른 방법론에서는 작게 설정하기도 한다. 기능 증분은 사용자 인터페이스 화면이나 신규 문의 옵션에 생기는 변경 하나만큼 작을 수도 있다.
반복적 점증적 모델은 개발주기가 짧고 연속적으로 반복하는 활동으로 이루어진다. 이 개발 방법론은 주로 초기 반복 단계에서 리스크가 높은 모듈이나 주요 아키텍처에 해당하는 시스템 일부를 우선적으로 개발하고 테스팅을 통해 결함이나 장애를 조기에 발견하고 제거할 수 있는 기회를 확보하기 때문에, 개발 리스크를 조기에 감소시킬 수 있는 장점이 있다.
하나의 반복 단계에서 생성한 산출물은 일반적으로 테스트 레벨 전체 또는 일부를 거치면서 검증될 수 있다. 이전 반복 단계에서 개발한 결과물은 현재의 반복에서 추가 개발한 증분에 의해 규모가 점차 커져 부분 시스템을 형성하게 된다. 이때 해당 반복 단계의 증분도 테스팅해야 하지만 부분 시스템 역시 리그레션 여부의 확인 목적으로 테스팅해야 한다. 리그레션 테스팅은 첫 번째 반복 단계에서 테스팅 한 이후로 모든 반복 단계에서 수행되어야 하므로 반복 단계가 거듭될수록 중요해진다. 반복 단계별로 각각의 증분 산출물을 포함한 부분시스템을 대상으로 베리피케이션(검증)과 밸리데이션(확인)을 수행할 수 있다.
반복적 개발 모델에서의 테스팅 관련 추가적인 이슈는 초기 개발 단계에서의 테스팅 및 테스트 환경과 개발이 진행되면서 테스팅 및 테스트 환경이 변경되는 것이다.
- 제한된 세트의 집중된 테스트에서 시작하여 광범위한 세트의 분산된 테스트로 확장
- 테스트 대상 컴포넌트가 점차 증가
- 단순한 테스트 환경에서 복잡한 테스트 환경으로 변화
- 시간이 지남에 따라 개별 유즈케이스 테스팅에서 유즈케이스간의 통합 테스팅으로 변화
이렇게 반복적으로 개발하는 모델의 예는 아래와 같다.
- 에자일 개발 모델
- RUP(Rational Unified Process)
- RAD(Rapid Application Development)
- 이해관계자 중심의 소프트웨어 개발
- 프로토타이핑
반복적 개발은 기능 집합을 종종 고정된 기간의 일련의 주기 안에서 같이 명시, 설계, 구축, 테스트할 때 발생한다. 반복주기에는 전체 프로젝트 범위에 대한 변경이나 기존 반복주기 동안 개발한 기능에 대한 수정이 포함될 수 있다. 각 반복주기에서는 전체 기능 세트 중 일부의 기능을 하는 소프트웨어를 만들어내고 소프트웨어의 기능은 반복주기 횟수가 늘어남에 따라 점차 늘어나게 되고, 완성된 소프트웨어가 배포되거나 개발이 중단될 때까지 진행된다.
점증적 개발의 대표적인 예는 다음과 같다.
- 래셔널 통합 프로세스(Rational Unified Process): 각 반복주기가 상당히 긴 경우가 많으며, 기능 증분도 상당히 큼.
- 스크럼(Scrum): 각 반복주기가 짧은 성향을 가지며 따라서 기능 증분도 작음.
- 칸반(Kanban): 반복주기 기간이 고정된 경우와 고정되지 않은 경우가 있으며, 각 반복주기는 완료 후 하나의 개선 사항이나 기능을 전달하거나 몇 개의 기능을 묶어 한번에 전달할 수도 있음.
- 나선형(Spiral): 실험적인 증분을 생성, 일부는 차후 개발 과정에서 상당 부분 수정되거나 심한 경우 폐기되기도 함.
이런 방법을 사용하면 점진적으로 커지는 시스템을 만들 수 있으며, 해당 시스템은 최종 사용자에게 기능별, 반복주기별, 아니면 좀 더 전통적인 주요 릴리스 단위로 릴리스할 수 있다. 소프트웨어 증분이 최종 사용자를 위한 릴리스인지의 여부와 상관없이 시스템이 커짐에 따라 리그레션 테스팅의 중요성은 증가하게 된다.
순차적 모델과는 다르게 반복적 점진적 모델은 사용 가능한 소프트웨어를 몇 주, 또는 며칠 만에 전달할 수 있다. 다만, 전체 요구사항을 충족하는 제품은 몇 개월 또는 몇 년에 걸쳐 전달하게 된다.
정황에 따른 소프트웨어 개발 수명주기 모델
소프트웨어 개발 수명주기 모델은 프로젝트 정황과 제품 특성에 따라 선택하고 적용해야 한다. 프로젝트의 목표, 개발 대상 제품 유형, 비즈니스 특성, 식별된 제품 및 프로젝트 리스크 등을 기반으로 적합한 소프트웨어 개발 모델을 선택할 필요가 있다. 이뿐만아니라 로젝트의 정황에 따라 테스트 레벨과 테스트 활동을 조합하거나 조정, 소프트웨어 개발 수명주기 모델 자체도 조합, 오브젝트 별로 다른 소프트웨어 개발 수명주기 모델을 적용등이 소프트웨어 개발 수명주기에 영향을 미친다.
소프트웨어 개발 모델이 프로젝트 및 제품 특성의 맥락에 맞게 조정되어야 하는 이유는 다음과 같다.
- 시스템의 제품 리스크의 차이 (복잡하거나 간단한 프로젝트)
- 많은 사업부가 프로젝트나 프로그램의 일부일 수 있다 (순차적 및 애자일 개발의 조합)
- 제품의 짧은 출시 기간 (테스트 레벨에서 테스트 유형의 통합 및 테스트 레벨 병합)
성공적인 테스팅을 위해서는, 그 개발 수명주기 모델에 관계없이 다음과 같은 요건들이 필요하다.
- 모든 개발 활등은 이에 상응하는 테스팅 활동을 동반한다.
- 각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가지고 있다.
- 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되는 개발 활동 동안에 시작되어야 한다.
- 개발 수명주기 동안에 개발 산출물의 초안이 작성되면, 테스터는 이러한 문서를 리뷰하는 활동에 참가해야 한다.
테스트 레벨
테스트 레벨이란 함께 분류되고 관리되는 테스트 활동의 집합을 지칭한다. 각 테스트 레벨은 테스트 프로세스 기초 활동으로 구성되며, 개별 단위(unit)나 컴포넌트에서부터 완성된 시스템이나 경우에 따라서는 시스템의 시스템까지 해당 개발 레벨의 소프트웨어와 관련해 실행되는 전체 테스트 프로세스의 하나의 사례이다. 테스트 레벨은 소프트웨어 개발 수명주기의 기타 활동과도 연관되어 있다.
테스트 레벨은 다음과 같다.
- 컴포넌트 테스팅
- 통합 테스팅
- 시스템 테스팅
- 인수 테스팅
테스트 레벨은 다음과 같은 특성을 기준으로 분류된다.
- 구체적인 목적
- 테스트 케이스를 도출하기 위해 참고하는 테스트 베이시스
- 테스트 대상 (즉, 테스트되고 있는 것)
- 일반적인 결함과 장애
- 구체적인 접근법과 역할
- 테스트 하네스 필요 여부와 툴 지원의 필요성
- 테스트 수행 주체 또는 조직
모든 테스트 레벨에는 적절한 테스트 환경이 필요하다. 예를 들어, 인수 테스팅에는 실제 사용 환경과 유사한 환경이 가장 이상적이지만, 컴포넌트 테스팅에서는 개발자가 자신의 개발 환경을 사용하는 경우가 대부분이다.
컴포넌트 테스팅
컴포너트 테스팅(단위 테스팅)은 테스트가 가능한 (최소) 단위로 나누어진 소프트웨어 내에서 결함을 찾고 그 기능을 검증하는 것이다. 컴포넌트 테스팅은 개발 수명주기의 정황과 시스템에 의존적이면서도 시스템의 다른 부분에서 격리하여 독립적으로 수행해야 한다.
일반적으로 컴포넌트 테스팅은 코드를 중심으로 수행하며, 단위 테스트 프레임웍 또는 디버깅 툴 같은 개발 환경의 지원을 필요로 한다. 이런 프로그램 소스 코드를 활용하여 테스트를 설계하며 주된 테스팅 방법은 구조 기반 테스팅(화이트박스)이라 한다. 또한 코딩 전에 테스트 케이스를 준비하고 자동화하는 방법이 있다. 이를 테스트 중심의 개발 방법론이라 한다. 반복적인 성향이 매우 강한 접근법으로, 테스트 케이스를 개발한 후 작은 규모의 코드를 작성하여 통합하고 테스트가 통과할 때까지 반복 수행한다.
컴포넌트 테스팅의 목적
컴포넌트 테스팅(단위 혹은 모듈 테스팅이라고 부르기도 함)은 개별적으로 테스트할 수 있는 컴포넌트에 초점을 맞춘다.
컴포넌트 테스팅의 목적에는 다음과 같은 것들이 있다.
- 리스크 완화
- 컴포넌트의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단
- 컴포넌트 품질 수준에 대한 자신감 획득
- 컴포넌트에 존재하는 결함 발견
- 다음 단계로의 결함 전이 방지
컴포넌트 테스팅은 소프트웨어 개발 수명주기 모델과 시스템에 따라 개별적으로 이루어지는 경우가 많으며, 그럴 경우 목 오브젝트(mock object), 서비스 가상화(service virtualization), 하네스(harness), 스텁(stub), 드라이버(driver) 등이 필요할 수도 있다. 컴포넌트 테스팅은 기능, 비기능 특성, 구조적 속성 등을 커버할 수 있다.
테스트 베이시스
컴포넌트 테스팅의 테스트 베이시스로 사용할 수 있는 대표적인 작업 산출물은 다음과 같다.
- 상세 설계
- 코드
- 데이터 모델
- 컴포넌트 명세
테스트 대상
컴포넌트 테스팅의 대표적인 테스트 대상은 다음과 같다.
- 컴포넌트, 단위, 모듈
- 코드 및 데이터 구조
- 클래스
- 데이터베이스 모듈
대표적인 결함과 장애
컴포넌트 테스팅의 대표적인 결함과 장애는 다음과 같다.
- 잘못된 기능
- 데이터 흐름 문제
- 잘못된 코드 및 논리
결함은 발견하는 즉시 수정되며, 공식적인 결함 관리 프로세스 없이 이루어지는 경우가 많다. 하지만 개발자가 결함에 대해 보고하는 경우, 근본 원인 분석 및 프로세스 개선에 활용할 수 있는 중요한 정보를 제공하게 된다.
구체적인 접근법과 책임
일반적으로 컴포넌트 테스팅은 코드를 작성한 개발자가 수행하지만, 다른 사람이 수행하더라도 최소한 테스트 대상 코드에 접근할 수 있어야 한다. 개발자는 컴포넌트 개발과 결함 발견 및 수정을 번갈아 가며 진행할 수 있다. 개발자는 컴포넌트 코드를 작성한 후 테스트를 작성하고 실행하는 경우가 많다. 하지만, 특히 애자일 개발에서는, 애플리케이션 코드보다 자동화된 컴포넌트 테스트 케이스를 먼저 작성하는 경우도 있다.
반복적인 프로세스는 전체 컴포넌트가 완성되고 모든 컴포넌트 테스트가 통과할 때까지 계속된다. 테스트 주도 개발은 테스트 우선 접근법의 한 가지 예이다. 테스트 주도 개발은 익스트림 프로그래밍(XP, eXtreme Programming)에서 처음 등장했지만, 현재는 다른 애자일 방법론뿐만 아니라 순차적 수명주기 모델에서도 활용하고 있다.
통합 테스팅
통합 테스팅은 컴포넌트 간의 인터페이스를 테스트하는 것은 물론, OS, 파일 시스템, 하드웨어 또는 시스템 간 인터페이스와 같은 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트 한다. 통합 테스팅은 하나 이상의 테스트 레벨이 있을 수 있으며, 다양한 크기의 테스트 대상에 대해 수행될 수 있다. 예를 들면 아래와 같다.
- 컴포넌트 통합 테스팅은 소프트웨어 컴포넌트 사이의 상호작용을 테스트하며 컴포넌트 테스팅 이후에 수행된다.
- 시스템 통합 테스팅은 시스템 사이의 상호작용을 테스트하며 시스템 테스팅 이후에 수행된다. 이 경우에 개발 조직은 한쪽 시스템에 국한되어 제어 권한을 갖게 되고, 변경 사항이 발생하였을 때 시스템 전체 차원에서의 불안정을 유발할 수 있다. 비즈니스 프로세스가 시스템 간의 업무 흐름을 가지고 있는 경우 시스템 간의 교차점에서 중대한 문제를 야기할 수 있다.
통합하는 범위가 크면 클수록 장애나 결함의 위치를 찾아 격리하기가 쉽지 않다. 이는 개발의 리스크를 증가시키기도 한다. 아래 표를 참고하여 통합 접근법의 특징과 장단점을 비교해 보자.
| 백본(Backbone) | 빅뱅(Big Bang) | 상향식(Bottom Up) | 하향식(Top down) | |
| 수행 방법 |
가장 중요하고 리스크가 높은 모듈로 초기 통합 형성 | 모든 테스트 모듈을 동시에 통합 | 가장 하부의 모듈부터 통합해가면서 | 가장 상부의 모듈부터 통합해가면서 |
| 드라이버 /스텁 |
드라이버/스텁을 필요에 따라 만들어 사용 | 드라이버/스텁 없이 실제 모듈로 테스트 | 테스트 드라이버가 필요하며 점차 개발되고 테스트된 상부 모듈로 대치 | 테스트 스텁이 필요하며 점차 개발되고 테스트된 하부 모듈로 대치 |
| 장점 | 결함 격리 쉬움 리스크가 높은 결함을 초기에 발견 |
단시간 테스트 | 결함 격리 쉬움 하위 모듈을 충분히 테스트 |
결함 격리 쉬움 설계상의 결함을 빨리 발견 |
| 단점 | 테스트 시간이 오래 걸릴 수 있음 | 결함 격리 어려움 | 수정이 어려운 중요한 결함을 상부 구조에서 발견 가능 비즈니스 로직 반영 어려움 |
수정이 어려운 중요한 결함을 하부에서 발견 가능 |
통합 테스팅의 목적
통합 테스팅은 컴포넌트나 시스템 간의 상호작용에 초점을 맞춰서 진행한다.
통합 테스팅의 목적에는 다음과 같은 것들이 있다.
- 리스크 완화
- 인터페이스의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단
- 인터페이스 품질 수준에 대한 자신감 획득
- 결함 발견 (결함은 인터페이스 자체 또는 컴포넌트나 시스템에 존재할 수 있다)
- 다음 단계로의 결함 전이 방지
컴포넌트 테스팅과 마찬가지로, 자동 통합 리그레션 테스트를 수행하여 수정으로 인해 기존 인터페이스, 컴포넌트, 시스템 등이 손상되지 않았다는 확신을 얻는 경우가 있다. 이 대표적으로 다음과 같은 두 개의 다른 통합 테스팅 레벨을 다루고 있으며, 이런 통합 테스팅은 다양한 크기의 테스트 대상에 수행할 수 있다.
- 컴포넌트 통합 테스팅은 통합된 컴포넌트 간의 상호운용성과 인터페이스에 초점을 맞춘다. 컴포넌트 통합 테스팅은 컴포넌트 테스팅 후 수행하며 자동화하는 경우가 많다. 반복적 점진적 개발에서는 컴포넌트 통합 테스트를 지속적 통합 프로세스의 일부로 수행한다.
- 시스템 통합 테스팅은 시스템, 패키지, 마이크로 서비스(microservice) 간의 상호운용성과 인터페이스에 초점을 맞춘다. 시스템 통합 테스팅은 또한 기존 컴포넌트와의 상호운용 혹은 인터페이스를 커버하기도 한다. 이 경우 개발 조직이 외부 인터페이스를 제어하지 않으므로 테스팅에 여러 가지 어려움을 겪게 될 수 있다. 시스템 통합 테스팅은 (순차적 개발과 점진적 반복적 개발 모두에서) 시스템 테스팅 후 또는 진행 중인 시스템 테스팅 활동과 병행해서 수행할 수 있다.
테스트 베이시스
통합 테스팅의 테스트 베이시스로 사용할 수 있는 대표적인 작업 산출물은 다음과 같다.
- 소프트웨어 및 시스템 설계
- 시퀀스 다이어그램(sequence diagram)
- 인터페이스 및 통신 프로토콜 명세
- 유스케이스
- 컴포넌트나 시스템 레벨의 아키텍처
- 워크플로우(workflow)
- 외부 인터페이스 정의서
테스트 대상
통합 테스팅의 대표적인 테스트 대상은 다음과 같다:
- 서브시스템(subsystems)
- 데이터베이스(database)
- 인프라(infrastructure)
- 인터페이스(interfaces)
- APIs
- 마이크로서비스(microservices)
일반적인 결함과 장애
컴포넌트 통합 테스팅에서 발견되는 대표적인 결함과 장애는 다음과 같다.
- 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩
- 잘못된 인터페이스 콜 순서나 타이밍
- 인터페이스 불일치
- 컴포넌트 간의 통신 장애
- 컴포넌트 간의 통신 실패처리 누락 및 오류
- 컴포넌트 간 주고받는 데이터의 의미, 단위, 경계에 대한 잘못된 가정
시스템 통합 테스팅에서 발견되는 대표적인 결함과 장애는 다음과 같다.
- 시스템 간의 일관적이지 않은 메시지 구조
- 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩
- 인터페이스 불일치
- 시스템 간의 통신 장애
- 시스템 간의 통신 실패 처리 누락 및 오류
- 시스템 간 주고 받는 데이터의 의미, 단위, 경계에 대한 잘못된 가정
- 필수 보안 규정 준수 실패
구체적인 접근법과 책임
컴포넌트 통합 테스트와 시스템 통합 테스트는 통합 자체에 집중해야 한다. 컴포넌트 통합 테스팅은 개발자의 책임인 경우가 많다. 시스템 통합 테스팅은 일반적으로 테스터의 책임이다. 이상적인 상황에서는 시스템 통합 테스팅을 수행하는 테스터는 시스템 아키텍처를 이해하고 통합 계획에 참여했어야 한다.
컴포넌트나 시스템을 빌드하기 전에 통합 테스트와 통합 테스트 전략을 세운 경우, 가장 효과적인 테스팅이 가능한 순서대로 컴포넌트나 시스템을 빌드할 수 있다. 시스템 통합 전략은 시스템 아키텍처, 기능 작업, 트랜잭션 처리 순서, 시스템 또는 컴포넌트의 기타 측면 등을 기반으로 수립할 수 있다. 결함 격리를 좀 더 수월하게 하고 결함을 일찍 발견하기 위해 통합은 한 번에 모든 것을 통합하지 않고 가능한 점진적으로 진행해야 한다. 가장 복잡한 인터페이스에 대한 리스크 분석은 통합 테스팅의 노력을 집중시키는 데 도움이 된다.
통합하는 범위가 넓으면 장애를 특정 컴포넌트나 시스템으로 격리하기 어려워지고, 이는 개발의 리스크와 문제 해결(Troubleshooting) 시간을 증가시킬 수 있다. 이것은 지속적인 통합이 관행으로 자리 잡은 배경 중 하나이다. 지속적인 통합에서 소프트웨어는 컴포넌트 단위로 통합(즉, 기능적 통합)된다. 이런 지속적인 통합은 이상적으로 여러 테스트 레벨에 자동 리그레션 테스팅을 적용하는 경우가 많다.
시스템 테스팅
시스템 테스팅은 개발 프로젝트 차원(범위)에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트하는 것이다. 테스팅에서 발견하지 못하여 발생할 수 있는 "환경특성 장애(Environment-specific failure)" 리스크를 최소화하기 위해서 시스템 테스팅은 가능한 범위에서 실제 최종 사용 환경 또는 이와 유사한 환경에서 수행해야 한다.
시스템 테스팅 수행의 근간은 아래와 같은 상위 레벨의 테스트 베이시스이다.
- 리스크 분석서
- 요구사항 명세
- 비즈니스 프로세스
- 유즈 케이스
- 기타 비즈니스 레벨의 시스템 동작 명세
- OS 및 시스템 리소스와의 상호작용 명세
시스템 테스팅은 기능 및 비기능 요구 사항을 모두 검증해야 한다. 기능적 요구 사항의 시스템 테스팅은 테스트 대상의 특성을 가상 상세하게 명세한 문서를 기반으로 테스트를 설계하는 명세기반(블랙박스) 기법을 수행한다. 비기능적 요구 사항의 시스템 테스팅은 소프트웨어의 기능적 품질특성 외의 나머지 부분에 대한 요구사항 검증을 수행한다.
시스템 테스팅의 목적
시스템 테스팅은 전체 시스템 또는 제품의 동작이나 능력에 관심을 가지며, 시스템이 수행할 엔드-투-엔드(endto-end) 작업과 그런 작업을 수행할 때 나타나는 비기능 동작을 고려하는 경우가 많다.
시스템 테스팅의 대표적인 목적은 다음과 같다.
- 리스크 완화
- 시스템의 기능/비기능 동작이 설계 및 명시된 대로 이루어지는지 검증
- 완성된 시스템이 기대한 대로 동작하는지 확인
- 전체 시스템 품질에 대한 자신감 획득
- 결함 발견
- 결함이 상위 테스트 레벨이나 생산 단계로의 전이 방지
시스템에 따라서는 데이터 품질 검증 또한 목적일 수도 있다. 컴포넌트 테스팅이나 통합 테스팅과 마찬가지로, 자동 시스템 리그레션 테스트를 통해 어떤 부분의 수정으로 기존 기능이나 엔드-투-엔드 기능에 문제가 생기지 않았다는 자신감을 얻을 수 있는 경우가 있다. 시스템 테스팅은 이해관계자가 릴리스 결정 시 사용하는 정보를 제공하는 경우가 많다. 시스템 테스팅을 통해 법적, 규정 요구사항이나 표준을 만족시킬 수도 있다. 테스트 환경은 최종 사용, 생산 환경과 부합하는 것이 가장 이상적이다.
테스트 베이시스
시스템 테스팅의 테스트 베이시스로 사용할 수 있는 대표적인 작업 산출물은 다음과 같다.
- 시스템 및 소프트웨어 요구사항 명세 (기능/비기능)
- 리스크 분석 보고서
- 유스케이스
- 에픽(epic)과 사용자 스토리
- 시스템 동작 모델
- 상태 다이어그램
- 시스템 및 사용자 매뉴얼
테스트 대상
시스템 테스팅의 대표적인 테스트 대상은 아래와 같다.
- 애플리케이션
- 하드웨어/소프트웨어 시스템
- 운영 시스템
- 테스트 대상 시스템 (SUT, System Under Test)
- 시스템 설정과 설정 데이터
일반적인 결함과 장애
시스템 테스팅에서 발견되는 결함과 장애는 다음과 같다.
- 잘못된 연산
- 시스템의 잘못되거나 예상치 못한 기능/비기능 동작
- 시스템 내 잘못된 제어 및 데이터 흐름
- 엔드-투-엔드 기능 작업 수행 실패
- 시스템 환경에서 시스템의 정상 동작 실패
- 시스템 및 사용자 매뉴얼대로의 시스템 동작 실패
구체적인 접근법과 책임
시스템 테스팅은 기능과 비기능 모두의 측면에서 전반적인 시스템의 엔드-투-엔드 동작에 관심을 가진다. 시스템 테스팅에서는 테스트 대상 시스템의 특성에 가장 잘 맞는 기법을 사용해야 한다.
시스템 테스팅은 일반적으로 명세에 과도하게 의존하는 독립적인 테스터가 수행한다. 명세 결함은 기대하는 시스템 동작에 대한 이해 부족이나 의견 불일치를 가져올 수 있다. 이런 상황은 시간을 허비하게 만드는 거짓양성이나 결함 발견 효과를 감소시키는 거짓음성(false negatives)의 원인이 될 수 있다. 테스터가 사용자 스토리 개선이나 리뷰와 같은 정적 테스팅 활동에 좀 더 일찍 참여하면 이런 상황을 예방하는 데 도움이 된다.
인수 테스팅
인수 테스팅은 시스템을 사용하는 고객이나 사용자가 전담하여 수행하는 경우가 대부분인데, 다른 이해관계자도 참여할 수 있다.
인수 테스팅의 목적
시스템 테스팅과 마찬가지로 인수 테스팅도 전체 시스템 또는 제품의 동작이나 능력에 초점을 두고 진행하는 경우가 많다. 인수 테스팅의 주된 목적은 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 "확신(Confidence)"을 얻는 것이다. 그 외 인수 테스팅의 목적에는 다음과 같은 것들이 있다.
- 전체 시스템의 품질에 대한 자신감 획득
- 완성된 시스템이 기대한 대로 동작하는지 확인
- 시스템의 기능/비기능 동작이 명세대로 동작하는지 검증
인수 테스팅의 결과로 시스템을 배포하거나 고객(최종 사용자)이 사용할 준비가 어느 정도 됐는지 평가할 수 있는 정보를 만들 수 있다. 인수 테스팅 중 결함을 발견할 수 있지만, 결함 발견이 목적이 아닌 경우가 많으며, 인수 테스팅에서 상당수의 결함이 발견되면 심각한 프로젝트 리스크로 인식하는 경우도 있다. 인수 테스팅으로 법적, 규정 요구사항이나 표준을 만족할 수도 있다.
인수 테스팅은 프로젝트 전 개발 과정에서 수행할 수 있다.
- 상용(COTS) 소프트웨어 제품은 설치되거나 통합되면 인수 테스팅을 수행할 수 있다.
- 컴포넌트의 사용성에 대한 인수 테스팅은 컴포넌트 테스팅 동안에 수행할 수도 있고 요구사항 단계에서 수행 할 수 있다.
- 프로그램의 유지보수성에 대한 인수 테스팅은 컴포넌트 테스트 실행 전에 수행 할 수 있다.
- 새로운 기능상의 개선에 대한 인수 테스팅은 시스템 테스팅 전에 이루어질 수 있다.
인수 테스팅의 대표적인 형태는 다음과 같다.
- 사용자 인수 테스팅(UAT, User Acceptance Testing)
- 운영 인수 테스팅(OAT, Operational Acceptance Testing)
- 계약 및 규제 인수 테스팅
- 알파(alpha) 및 베타(beta) 테스팅
사용자 인수 테스팅
시스템의 사용자 인수 테스팅은 일반적으로 실제 또는 시뮬레이션된 운영 환경에서 예정된 사용자가 사용하기에 얼마나 적합한지 확인하는 데 관심을 둔다. 가장 중요한 목적은 사용자가 그들의 필요에 따라 요구사항을 충족하면서 최소한의 어려움, 비용, 리스크 등으로 비즈니스 프로세스를 수행할 수 있다는 자신감을 획득하는 것이다.
운영 인수 테스팅
운영자 또는 시스템 관리 직원에 의해 수행되는 시스템 인수 테스팅은(시뮬레이션된) 생산 환경에서 이루어지는 경우가 많다. 테스트는 운영 측면에 집중돼 있으며, 다음을 포함할 수 있다.
- 백업 및 복원 테스팅
- 설치, 삭제, 업그레이드
- 긴급 복구 (disaster recovery)
- 사용자 관리
- 유지보수 작업
- 데이터 로딩 및 이관(migration) 작업
- 보안 취약점 확인
- 성능 테스팅
운영 인수 테스팅의 가장 중요한 목적은 운영자 또는 시스템 관리자가 비록 예외적이고 어려운 조건에서라도 운영 환경에서 사용자를 위해 시스템을 정상적으로 유지할 수 있다는 자신감을 얻는 것이다.
계약 및 규제 인수 테스팅
계약 인수 테스팅은 주문 개발 소프트웨어의 생산을 위한 계약서에 명시된 인수 조건을 가지고 수행한다. 인수 조건은 모든 계약 당사자가 계약에 동의할 때 정의해야 한다. 계약 인수 테스팅은 사용자나 독립적인 테스터가 수행하는 경우가 많다.
규제 인수 테스팅은 정부, 법적, 안전 규제 등과 같이 준수해야 하는 모든 규제를 가지고 수행한다. 규제 인수 테스팅은 사용자나 독립적인 테스터가 수행하는 경우가 많으며, 규제 기관이 결과에 대한 실사나 감사를 진행하기도 한다.
계약 및 규제 인수 테스팅의 가장 중요한 목적은 계약이나 규제 준수에 대한 자신감의 획득이다.
알파 및 베타 테스팅
알파 및 베타 테스팅은 소프트웨어 제품을 시장에 출시하기 전에 기존 혹은 신규 사용자, 고객, 운영자 등으로부터 피드백을 받기 원하는 상용 소프트웨어 개발자가 사용하는 경우가 많다. 알파 테스팅은 개발 조직의 현장에서 개발팀이 아닌 신규 혹은 기존 고객이나 운영자, 독립적 테스트팀이 수행한다. 베타 테스팅은 신규 혹은 기존 고객이나 운영자가 자신의 환경에서 수행한다. 베타 테스팅은 알파 테스팅 후에 진행하거나 사전 알파 테스팅 없이 수행할 수도 있다.
알파 및 베타 테스팅의 목적 중 하나는 신규 혹은 기존 고객이나 운영자가 시스템을 일반적인 조건과 운영 환경에서 사용해 자신의 목적을 최소한의 어려움, 비용, 리스크 등으로 완수할 수 있다는 자신감을 획득하는 것이다. 또 다른 목적은 시스템을 사용할 조건 및 환경과 관련된 결함의 발견일 수 있다. 특히, 이런 조건과 환경을 개발팀에서 동일하게 연출하기 어려운 경우 더 그러하다.
고객사의 사이트로 이동하기 전에 개발 완료 후 테스팅하는 소위 '공장 인수 테스팅(Factory acceptance testing)'은 알파 테스트와 같은 의미이고, 고객 사이트로 이동한 후에 테스팅하는 '사이트 인수 테스팅(Site acceptance testing)'은 베타 테스팅과 같은 용어이다.
테스트 베이시스
모든 형태의 인수 테스팅의 테스트 베이시스로 활용할 수 있는 대표적인 작업 산출물은 다음과 같다.
- 비즈니스 프로세스
- 사용자 또는 비즈니스 요구사항
- 규제, 법적 계약, 표준
- 유스케이스 및 사용자 스토리
- 시스템 요구사항
- 시스템 또는 사용자 문서
- 설치 절차
- 리스크 분석 보고서
추가로 운영 인수 테스팅의 테스트 케이스를 도출하기 위한 테스트 베이시스로 다음과 같은 작업 산출물이 사용될 수 있다.
- 백업 및 복원 절차
- 긴급 복구 절차
- 비기능 요구사항
- 운영 문서
- 배포 및 설치 지침
- 성능 목표
- 데이터베이스 패키지
- 보안 표준 또는 규정
테스트 대상
모든 유형의 인수 테스팅의 대표적인 테스트 대상은 다음과 같다.
- 테스트 대상 시스템
- 시스템 설정과 설정 데이터
- 완전히 통합된 시스템의 비즈니스 프로세스
- 복원 시스템이나 비즈니스 연속성 및 긴급 복구 테스팅을 위한 핫 사이트 (hot site)
- 운영 및 유지보수 프로세스
- 양식
- 보고서
- 기존 및 전환된 생산 데이터
일반적인 결함과 장애
모든 유형의 인수 테스팅의 대표적인 결함은 다음과 같다.
- 비즈니스나 사용자 요구사항을 충족하지 못하는 시스템 워크플로우 (workflow)
- 잘못 구현된 비즈니스 규칙
- 계약 혹은 규제 요구사항을 충족하지 못하는 시스템
- 보안 취약성, 많은 부하가 걸렸을 때 성능 효율성 저하, 지원 대상 플랫폼상에서의 잘못된 운영 등과 같은 비기능 장애
구체적인 접근법과 책임
인수 테스팅은 주로 고객, 비즈니스 사용자, 제품 소유자, 혹은 시스템 운영자가 담당하며, 기타 이해관계자가 참여하는 경우도 있다. 인수 테스팅은 순차적 개발 수명주기의 마지막 테스트 레벨로 여겨지는 경우가 많지만, 다음과 같이 다른 시점에서 이루어지는 경우도 있다.
- 상용 소프트웨어 제품에 대한 인수 테스팅은 그것이 설치되거나 통합될 때 이루어진다.
- 신규 기능 개선 사항에 대한 인수 테스팅은 시스템 테스팅 전에 이루어질 수 있다.
반복적 개발에서는 프로젝트팀이 다양한 유형의 인수 테스팅을 각 반복주기 중간 혹은 끝에 편성할 수 있다. 또한, 알파 테스트와 베타 테스트는 각 반복주기 끝에, 혹은 각 반복주기가 완료되고 나서, 또는 몇 개의 반복주기 후에 수행할 수도 있다. 사용자 인수 테스트, 운영 인수 테스트, 규제 인수 테스트, 계약 인수 테스트 등도 각 반복주기 끝에, 혹은 각 반복주기가 완료되고 나서, 또는 몇 개의 반복주기 후에 수행할 수 있다.
테스트 유형
테스트 유형이란 특정 테스트 목적을 위해 소프트웨어 시스템이나 시스템의 일부 특정 속성을 테스트하는 활동의 집합을 얘기한다. 대표적인 목적은 다음과 같다.
- 완전성, 정확성, 적합성 등과 같은 기능 품질 특성 평가
- 신뢰성, 성능 효율성, 보안성, 호환성, 사용성 등과 같은 비기능 품질 특성 평가
- 컴포넌트나 시스템의 아키텍처 및 구조가 정확하고 완전하며 명시된 것과 일치하는지 평가
- 수정의 효과 평가.
기능적 그리고 구조적 테스팅은 소프트웨어의 모델을 이용하거나 필요한 경우 이러한 모델을 생성해 테스팅하는 것이다.
기능 테스팅
기능 테스팅은 시스템이 수행해야 하는 기능을 평가하기 위한 테스트를 포함한다. 일반적으로 기능 요구사항은 비즈니스 요구사항 명세, 에픽(epic), 사용자 스토리, 유스케이스, 기능 명세 등과 같은 작업 산출물에 설명되어 있지만, 문서로 기록되지 않는 경우도 존재한다. 기능이란 시스템이 해야 하는 그 "무엇”을 의미한다.
기능 테스트는 모든 테스트 레벨에서 수행해야 하지만, 각 레벨에서의 관심 사항은 다를 수 있다. 기능 테스팅은 명세 시반 기법을 이용해 소프트웨어나 시스템의 기능에서 테스트 조건과 테스트 케이스를 도출하고, 소프트웨어의 외부적인 행동을 고려한다.(블랙박스 기법)
기능성이라는 품질 특성에 적합성, 정확성, 준수성, 상호운용성, 보안성 등의 부특성을 포함시키고 있다.
기능 테스팅이 얼마나 철저하게 수행됐는지 기능 커버리지를 통해 측정할 수 있다. 기능 커버리지란 어떤 기능이 테스트에 의해 어느 정도 실행됐는지를 말하며, 커버되고 있는 요소 유형에 대한 백분율로 표기된다. 예를 들어, 테스트와 기능 요구사항 간의 추적성을 사용해 이런 요구사항 중 테스팅한 비율을 계산할 수 있고, 결국 커버리지 어디에 빈틈이 있는지 식별할 수 있다.
상호운용성 테스팅(interoperability)은 하나 또는 여러 개의 명시된 컴포넌트나 시스템이 서로 상호 작용하는 소프트웨어 제품의 능력을 평가하는 것이다.
보안성 테스팅은 악의적인 코드와 같은 외부로부터의 위협을 감지해 내는 것과 관련이 있는 기능을 확인한다.
- 보안정책 확인
- 시스템으로 침투하는 보호되지 않는 진입점(트랩도어) 확인
- 가용성(Availability), 무결성(integrity), 기밀성(confidentiality), 부인 방지(non-repudiation) 등의 보안 관련 평가
기능 테스트 설계 및 실행에는 특수한 역량이나 지식이 필요할 수 있다. 소프트웨어가 해결하는 비즈니스 문제에 대한 지식 등이 여기에 포함된다.
비기능 테스팅
시스템의 비기능 테스팅은 사용성, 성능 효율성 또는 보안성과 같은 시스템 특성을 평가한다. 비기능 테스팅이란 시스템이 "어떻게" 동작하는지에 대한 테스팅을 말한다.
일반적인 오해와는 다르게 비기능 테스팅은 모든 테스트 레벨에서 수행할 수 있고, 수행해야 한다. 또한, 가능한 초반에 수행하는 것이 좋다. 비기능 결함을 늦게 발견하게 되면 프로젝트의 성공에 큰 위협이 될 수 있다.
비기능성을 신뢰성, 사용성, 효율성, 유지보수성, 이식성이라는 품질 특성으로 분류하고 각각의 품질 특성을 3가지에서 5가지의 품질 특성으로 세분화한다.
블랙박스 기법은 비기능 테스팅을 위한 테스트 컨디션과 테스트 케이스를 도출하는 데 사용할 수 있다. 예를 들어, 성능 테스트를 위한 스트레스(stress) 조건을 정의하는 데 경곗값 분석을 활용할 수 있다.
비기능 테스팅을 얼마나 철저하게 수행했는지는 비기능 커버리지를 사용해서 측정할 수 있다. 비기능 커버리지란 특정 비기능 요소가 테스트로 어느 정도 실행됐는지를 말해주며 커버하고 있는 요소 유형에 대한 백분율로 표기한다. 예를 들어, 테스트와 지원 기기 간의 추적성을 사용해 이런 기기 중 호환성 테스팅으로 커버된 비율을 계산할 수 있고, 결국 커버리지 어디에 빈틈이 있는지 식별할 수 있다.
비기능 테스트 설계 및 실행에는 특수한 역량이나 지식이 필요할 수 있다. 설계 또는 기술이 내재하고 있는 약점에 대한 지식, 또는 특정한 사용자 기반 등이 여기에 포함된다.
화이트박스 테스팅(구조적 테스팅)
화이트박스 테스팅은 시스템의 내부 구조나 구현을 기반으로 테스트를 도출한다. 내부 구조로는 코드, 아키텍처, 워크플로우(workflow), 시스템 내 데이터 플로우(data flow) 등이 있다.
화이트박스 테스팅이 얼마나 철저하게 이루어졌는지는 구조 커버리지를 통해 측정할 수 있다. 구조 커버리지란 특정 구조 요소가 테스트에 의해 어느 정도 실행됐는지를 말하며, 커버되고 있는 요소 유형에 대한 백분율로 표기한다.
컴포넌트 테스팅 레벨에서 얘기하는 코드 커버리지는 컴포넌트 코드 중 테스트된 비율을 얘기하며, 컴포넌트의 실행 가능한 구문 중 테스트된 비율이나 결정 결과값 중 테스트된 비율 등 코드의 여러 가지 측면(커버리지 항목)으로 측정될 수 있다. 이와 같은 유형의 커버리지를 합쳐서 코드 커버리지라고 한다. 컴포넌트 통합 테스팅 레벨에서는 컴포넌트 간의 인터페이스와 같은 시스템의 아키텍처를 기반으로 화이트박스 테스팅을 수행할 수 있으며, 구조 커버리지를 인터페이스 중 테스트된 비율의 측면에서 측정할 수 있다.
화이트박스 테스트 설계와 구현에는 특수한 역량이나 지식이 필요할 수 있다. 대표적으로 코드가 구축된 방법, 데이터가 저장되는 방법, 코드 커버리지 도구를 사용하는 방법과 해당 결과를 제대로 분석하기 위한 지식 등이 있다.
변경 관련 테스팅(확인(재)/리그레션 테스팅)
결함을 수정하고자 했든 또는 기능을 추가하거나 개선하기 위해서 했든 시스템이 변경되면, 해당 변경이 결함을 제대로 수정했는지, 기능을 올바르게 구현했는지 또 예상하지 못한 부작용이 발생하지 않았는지 확인하기 위한 테스팅을 수행할 필요가 있다. 여기서 결함의 원인을 찾거나 결함을 수정하기 위한 디버깅은 개발 활동이며 테스팅 활동으로 보지 않는다.
- 확인 테스팅(Confirmation testing): 결함이 수정된 후 이 결함으로 인해 불합격했던 모든 테스트 케이스를 새로운 소프트웨어 버전에서 재실행할 수 있다. 결함 수정에 필요한 변경을 커버하기 위해 소프트웨어를 대상으로 새로운 테스트를 수행할 수도 있다. 최소한 결함으로 발생했던 장애의 재현 절차를 새로운 소프트웨어 버전에서 실행해 볼 필요가 있다. 확인 테스팅의 목적은 원래 제대로 결함을 제대로 수정했는지 확인하는 것이다.
- 리그레션 테스팅(Regression testing): 코드의 특정 부분에 대한 변경이 무언가를 수정하기 위해서거나 또는 다른 목적이든 관계없이 이런 변경은 의도치 않게 코드의 다른 부분에 영향을 줄 수 있다. 여기서 다른 부분이란 같은 컴포넌트의 다른 부분, 같은 시스템의 다른 컴포넌트, 경우에 따라서는 다른 시스템일 수도 있다. 변경에는 운영 시스템이나 데이터베이스 관리 시스템의 신규 버전 등과 같은 환경에 대한 변경도 포함된다. 이런 의도하지 않은 부작용을 리그레션이라 부른다. 리그레션 테스팅은 이런 의도하지 않은 부작용을 발견하기 위한 테스트를 수행하는 것이다.
확인 테스팅과 리그레션 테스팅은 모든 테스트 레벨에서 수행 가능하다.
특히 반복적 점진적 개발 수명주기에서는 신규 기능, 기존 기능에 대한 변경, 코드 리팩토링(code re-factoring) 때문에 코드에 잦은 변경이 가해지고 결국 변경 관련 테스팅이 필요하게 된다. 시스템이 진화하는 특성 때문에 확인 및 리그레션 테스팅은 매우 중요하다. 특히 개별 오브젝트가 자주 업데이트되거나 교체되는 사물 인터넷(IoT) 시스템에서는 더욱 중요하다.
리그레션 테스트 스위트는 여러 번 반복 수행되며 대개는 서서히 변화하기 때문에 리그레션 테스팅은 자동화에 적합하다. 이런 테스트의 자동화는 프로젝트 초반에 시작해야 한다.
테스트 유형과 테스트 레벨
위에서 언급한 모든 테스트 유형은 어느 테스트 레벨에서나 수행할 수 있다. 인터넷 뱅킹 애플리케이션의 모든 테스트 레벨에 기능, 비기능, 화이트박스, 변경 관련 테스트가 어떻게 적용되는지 아래에서 예로 설명하고 있다.
아래에서 모든 레벨에 모든 테스트 유형을 적용한 예제를 제공했지만, 모든 소프트웨어가 모든 레벨에 모든 테스트 유형을 적용해야 하는 것은 아니다. 그러나 각 레벨에서 가능한 테스트 유형을 수행하는 것이 중요하며 특히 해당 테스트 유형이 처음으로 발생하는 첫 레벨에서 수행하는 것이 중요하다.
기능 테스트
- 컴포넌트 테스팅에 적용, 컴포넌트가 복잡한 이자 계산을 어떻게 해야 하는지를 기반으로 테스트 설계
- 컴포넌트 통합 테스팅에 적용, 사용자 인터페이스에서 포착하는 계정 정보가 어떻게 비즈니스 로직(logic)으로 전달되는지를 기반으로 테스트 설계
- 시스템 테스팅에 적용, 계좌 소유주가 어떻게 자신의 예금 통장에 신용 한도를 부여할 수 있는지를 기반으로 테스트 설계
- 시스템 통합 테스팅에 적용, 시스템이 외부 마이크로서비스를 사용해서 계좌 소유주의 신용 점수를 확인하는 방법을 기반으로 테스트 설계
- 인수 테스팅에 적용, 은행이 신용 한도를 승인하거나 거절하는 방법을 기반으로 테스트 설계
비기능 테스트
- 컴포넌트 테스팅에 적용, 복잡한 전체 이자 계산을 수행하기 필요한 CPU 사이클(cycle) 횟수를 평가하기 위해 성능 테스트 설계
- 컴포넌트 통합 테스팅에 적용, 사용자 인터페이스에서 비즈니스 로직으로 전달되는 데이터로 인한 버퍼 오버플로우(buffer overflow) 취약성을 위한 보안 테스트 설계
- 시스템 테스팅에 적용, 보이는 화면이 모든 지원 대상 브라우저와 모바일 기기에서 제대로 동작하는지 확인하기 위한 이식성 테스트 설계
- 시스템 통합 테스팅에 적용, 신용 점수 마이크로서비스가 응답하지 않을 때 시스템의 강건성(robustness)을 평가하기 위한 신뢰성 테스트 설계
- 인수 테스팅에 적용, 은행 신용 처리 인터페이스에 장애인의 접근성을 평가하는 사용성 테스트 설계
화이트박스 테스트
- 컴포넌트 테스팅에 적용, 금융 계산을 수행하는 모든 컴포넌트에 대한 완벽한 구문 및 결정 커버리지를 달성하기 위한 테스트 설계
- 컴포넌트 통합 테스팅에 적용, 브라우저 인터페이스의 각 화면이 다음 화면과 비즈니스 로직을 기반으로 데이터를 어떻게 전달하는지 확인하기 위한 테스트 설계
- 시스템 테스팅에 적용, 신용 한도 신청 도중 순차적으로 거치게 되는 웹페이지를 커버하기 위한 테스트 설계
- 시스템 통합 테스팅에 적용, 신용 점수 마이크로서비스로 보내는 모든 조회(inquiry) 유형을 실행하기 위한 테스트 설계
- 인수 테스팅에 적용, 은행 간 이체에서 지원하는 모든 금융 데이터 파일 구조와 값 범위를 커버하기 위한 테스트 설계
변경 관련 테스트
- 컴포넌트 테스팅에 적용, 각 컴포넌트를 위한 자동 리그레션 테스트가 구축되고 지속적인 통합 프레임워크에 포함
- 컴포넌트 통합 테스팅에 적용, 인터페이스 관련 결함 수정이 코드 저장소에 체크인(check-in)됐을 때 해당 수정을 확인하기 위한 테스트 설계
- 시스템 테스팅에 적용, 특정 워크플로우에 속하는 화면 중 하나만 변경되더라도 해당 워크플로우에 대한 모든 테스트 실행
- 시스템 통합 테스팅에 적용, 신용 점수 마이크로서비스에 대한 지속적인 개발의 일환으로 해당 마이크로서비스와 상호작용하는 애플리케이션에 대한 테스트를 매일 재실행
- 인수 테스팅에 적용, 인수 테스팅에서 발견된 결함이 수정되면 기존에 불합격했던 모든 테스트를 재실행
유지보수 테스팅
소프트웨어와 시스템이 생산 환경으로 배포되고 나면 유지보수가 필요하다. 배포된 소프트웨어와 시스템에 대한 다양한 변경은 거의 필연적으로 발생한다. 이런 변경으로는 운영 중 발견한 결함 수정, 신규 기능 추가, 기존 기능의 삭제나 개선 등이 있다. 유지보수는 컴포넌트나 시스템의 수명 동안 그것의 비기능 품질 특성을 보존 혹은 개선하기 위해서도 필요하다. 특히 성능 효율성(performance efficiency), 호환성(compatibility), 신뢰성(reliability), 보안성(security), 이식성(portability)에 대한 보존이나 개선이 필요하다. 이렇듯 유지보수 테스팅은 이미 운영되고 있는 시스템에서 수행되며, 소프트웨어나 시스템이 변경, 단종되었거나 마이그레이션 될 때 발생한다.
유지보수의 일환으로 변경이 이루어지게 되면, 변경의 성공 여부를 평가하고 시스템의 변경되지 않은 부분(많은 경우 시스템의 대부분)에서 부작용의 발생 여부를 확인하기 위한 유지보수 테스팅을 수행해야 한다.
유지보수는 계획된 릴리스나 계획되지 않은 릴리스(핫픽스)와 연관되어 발생할 수 있다.
유지보수 릴리스는 그것의 범위에 따라 다양한 테스트 유형을 활용한 복수의 테스트 레벨에서의 유지보수 테스팅이 필요할 수 있다. 유지보수 테스팅의 범위는 다음과 같은 요소의 영향을 받는다.
- 변경의 리스크 수준
- 기존 시스템의 규모
- 변경의 규모
유지보수가 필요한 상황
계획됐든 계획되지 않았든, 소프트웨어 유지보수, 즉 유지보수 테스팅이 이루어지게 되는 원인은 다양하다. 유지보수의 계기는 다음과 같이 분류할 수 있다.
- 개선을 위한 변경(modification), 계획된 확장(예: 릴리스 기반), 수정 혹은 긴급 변경, 운영 환경 변경, 상용 소프트웨어 업그레이드, 결함 및 취약성을 위한 패치 등
- 이관(migration)을 위한 변경, 하나의 플랫폼에서 다른 플랫폼으로 이관할 때, 변경된 소프트웨어뿐만 아니라 신규 환경에 대한 운영 테스트가 필요할 수 있거나 또는 유지보수하고 있는 시스템에 이관하는 다른 애플리케이션의 데이터를 위한 데이터 전환 테스트 등
- 단종(retirement), 애플리케이션의 수명이 다할 때 등, 애플리케이션이나 시스템이 단종될 때 데이터 이관이나 장시간의 데이터 유지가 필요하면 보관처리에 대한 테스팅이 필요할 수 있다.
- 장시간의 보관이 필요한 경우 차후 복원/회수 절차에 대한 테스팅이 필요할 수 있다.
- 여전히 서비스하고 있는 기능이 있다면, 해당 기능이 정상 동작할 거라는 확신을 얻기 위한 리그레션 테스팅이 필요할 수 있다.
유지보수를 위한 영향도 분석
영향도 분석은 유지보수 릴리스에 포함된 변경을 평가해서, 의도한 결과뿐만 아니라 변경으로 인해 발생할 수 있는 예견된 부작용을 식별하고, 변경의 영향을 받는 시스템 영역을 식별하기 위해 실시한다. 영향도 분석은 변경이 기존 테스트에 미치는 영향을 식별하기 위해 사용할 수 있다. 부작용과 영향받은 시스템 영역에 대해서는, 필요한 경우 변경의 영향을 받는 기존 테스트를 업데이트해서 리그레션 테스트를 수행할 필요가 있다.
시스템의 다른 영역에 발생할 수 있는 영향을 기반으로 변경을 적용하기 전에 영향도 분석을 실시할 수 있으며, 이런 경우 변경을 적용할지 여부를 판단하는 데 도움을 준다.
다음과 같은 상황에서는 영향도 분석이 어려울 수 있다.
- 명세가 너무 오래됐거나 없는 경우
- 테스트 케이스가 문서화되어 있지 않거나 너무 오래된 경우
- 테스트와 테스트 베이시스 간 양방향 추적성이 유지되지 않은 경우
- 도구 활용이 적거나 없는 경우
- 연관된 인원이 도메인이나 시스템 지식을 가지고 있지 않은 경우
- 소프트웨어의 개발 중 유지보수성에 충분히 신경을 쓰지 못한 경우
주섬주섬
공부 정리를 위한 블로그이며, "개발자도 알아야 할 소프트웨어 테스팅 실무 제3판"과 실라버스를 참고하였다.
참고
STEN
www.sten.or.kr
'IT 진로 > 자격증' 카테고리의 다른 글
| STQB_CTFL 6. 테스트 지원 도구 (1) | 2024.05.17 |
|---|---|
| STQB_CTFL 5. 테스트 관리 (0) | 2024.05.16 |
| STQB_CTFL 4. 테스트 설계 기법 (1) | 2024.05.16 |
| STQB_CTFL 3. 정적 테스팅 (0) | 2024.05.12 |
| ISTQB_CTFL 1. 소프트웨어 테스팅의 기초 (0) | 2024.05.10 |
댓글