[2장] 소프트웨어 개발 수명주기와 테스팅

용어(Keywords)

인수 테스팅(acceptance testing), 알파 테스팅(alpha testing), 베타 테스팅(beta testing), 변경관련 테스팅(change-related testing), 상용 소프트웨어(COTS, Commercial Off-The-Shelf), 컴포넌트 통합 테스팅(component integration testing), 컴포넌트 테스팅(component testing), 확인 테스팅(confirmation testing), 계약 인수 테스팅(contractual acceptance testing), 기능 테스팅(functional testing), 영향도 분석(impact analysis), 통합 테스팅(integration testing), 유지보수 테스팅(maintenance testing), 비기능 테스팅(non-functional testing), 운영 인수 테스팅(operational acceptance testing), 리그레션 테스팅(regression testing), 규정 인수 테스팅(regulatory acceptance testing), 순차적 개발 모델(sequential development model), 시스템 통합 테스팅(system integration testing), 시스템 테스팅(system testing), 테스트 베이시스(test basis), 테스트 케이스(test case), 테스트 환경(test environment), 테스트 레벨(test level), 테스트 대상(test object), 테스트 목적(test objective), 테스트 유형(test type), 사용자 인수 테스팅(user acceptance testing), 화이트박스 테스팅(white-box testing)

2.1 소프트웨어 개발 수명주기 모델

소프트웨어 개발 수명주기 모델은 소프트웨어 개발 프로젝트의 각 단계에서 이루어지는 활동 유형과 이런 활동이 서로 어떻게 논리적 또 순차적으로 연결되는지 보여준다.

여러 가지 소프트웨어 개발 수명주기 모델이 있으며, 각각 다른 테스팅 접근법을 요구한다.

2.1.1 소프트웨어 개발과 소프트웨어 테스팅 (Software Development and Software Testing)

필요한 테스트 활동을 수행할 수 있도록 일반적으로 많이 사용되는 소프트웨어 개발 수명주기 모델을 잘 이해하는 것은 테스터의 중요한 역할 중 하나이다.

모든 소프트웨어 개발 수명주기 모델에 적용하기 좋은 테스팅의 특성을 들면 다음과 같다:

• 모든 개발 활동은 그에 상응하는 테스트 활동이 있다.
• 각 테스트 레벨은 그 레벨에 맞는 구체적인 목적을가진다.
• 주어진 테스트 레벨에 맞는 테스트 분석과 설계는 상응하는 개발 활동이 이루어지고 있는 동안 시작해야 한다.
• 테스터가 요구사항과 설계의 정의와 개선을 위한 대화에 참여하고, 작업 산출물(예: 요구사항, 설계, 사용자 스토리 등)의 초안이 나오는 즉시 리뷰에 참여한다.

이 실러버스에서는 대표적인 소프트웨어 개발 수명주기 모델을 아래와 같이 분류하고 있다:

• 순차적(sequential) 개발 모델
• 반복적 점진적(iterative and incremental) 개발 모델

순차적 개발 모델에서는 소프트웨어 개발 프로세스를 1 차원적 선형(linear)의 순차적 활동으로 설명한다. 즉, 개발 프로세스의 모든 단계는 이전 단계가 완료될 때 시작돼야 한다.

 

폭포수 모델(Waterfall model)에서는 개발 활동(예: 요구사항 분석, 설계, 코딩, 테스팅)이 순차적으로 이루어진다. 이 모델에서의 테스트 활동은 모든 개발 활동을 완료한 후에 이루어진다.

 

V-모델은 테스팅을 초기에 시작하면 좋다는 원리를 토대로 테스트 프로세스를 전반적인 개발 프로세스에 통합한다. 대응하는 각 개발 단계에 테스트 레벨를 부여함으로써 조기 테스팅을 좀 더 적극적으로 구현하고 있다.

 

점진적 개발에서는 요구사항 정의, 시스템의 설계, 구축, 테스팅을 조각으로 나눠서 진행한다. 따라서, 소프트웨어 기능은 점진적으로 늘어나게 된다. 이런 기능 증분(feature increments)의 크기는 다양하게 설정할 수 있다. 기능 증분은 사용자 인터페이스 화면이나 신규 문의 옵션에 생기는 변경 하나만큼 작을 수도 있다.

 

반복적 개발은 기능 집합을 종종 고정된 기간의 일련의 주기 안에서 같이 명시, 설계, 구축, 테스트할 때 발생한다.

대표적인 예로는:

• 래셔널 통합 프로세스(Rational Unified Process): 각 반복주기가 상당히 긴 경우가 많으며(예: 2, 3 개월), 따라서 기능 증분도 상당히 큼 (예: 2, 3 개의 연관된 기능 그룹)
• 스크럼(Scrum): 각 반복주기가 짧은 성향을 가지며(예: 몇 시간, 며칠, 또는 몇 주) 따라서 기능 증분도 작음 (예: 몇 가지 개선 사항 혹은 2, 3 개의 신규 기능)
• 칸반(Kanban): 반복주기 기간이 고정된 경우와 고정되지 않은 경우가 있으며, 각 반복주기는 완료 후 하나의 개선 사항이나 기능을 전달하거나 몇 개의 기능을 묶어 한번에 전달할 수도 있음
• 나선형(Spiral): 실험적인 증분을 생성, 일부는 차후 개발 과정에서 상당 부분 수정되거나 심한 경우 폐기되기도 함

순차적 모델과는 다르게 반복적 점진적 모델은 사용 가능한 소프트웨어를 몇 주, 또는 며칠 만에 전달할 수 있다. 다만, 전체 요구사항을 충족하는 제품은 몇 개월 또는 몇 년에 걸쳐 전달하게 된다.

애자일 개발에서의 소프트웨어 테스팅에 대한 추가 정보는 (ISTQB-CTFL-AT, Black 2017, Crispin 2008, Gregory 2015) 참조.

2.1.2 정황에 따른 소프트웨어 개발 수명주기 모델 (Software Development Lifecycle Models in Context)

소프트웨어 개발 수명주기 모델은 프로젝트 정황과 제품 특성에 따라 선택하고 적용해야 한다.

예를 들어, 내부에서만 사용하는 소규모 관리 시스템의 개발과 테스팅은 자동차 브레이크 제어 시스템과 같은 안전 최우선 시스템의 개발, 테스팅과는 달라야한다.

 

또한, 소프트웨어 개발 수명주기 모델 자체도 조합할 수 있다.

예를 들어, 백엔드 시스템과 그것의 통합에 대한 개발과 테스팅에는 V-모델을 사용하고, 프런트엔드 사용자 인터페이스(UI) 기능의 개발과 테스트에는 애자일 개발 모델을 사용할 수 있다. 프로젝트 초반에는 프로토타이핑(prototyping)을 사용하다 실험적인 단계가 끝나면 점진적 개발 모델을 적용하는 경우도 있다.

2.2 테스트 레벨 Test Levels

테스트 레벨이란 함께 분류되고 관리되는 테스트 활동의 집합을 지칭한다.

각 테스트 레벨은 1.4 절에서 설명하고 있는 활동으로 구성되며, 개별 단위(unit)나 컴포넌트에서부터 완성된 시스템이나 경우에 따라서는 시스템의 시스템까지 해당 개발 레벨의 소프트웨어와 관련해 실행되는 전체 테스트 프로세스의 하나의 사례이다. 이 실러버스에서 다루고 있는 테스트 레벨은 다음과 같다:

• 컴포넌트 테스팅
• 통합 테스팅
• 시스템 테스팅
• 인수 테스팅

2.2.1 컴포넌트 테스팅 (Component Testing)

컴포넌트 테스팅의 목적 (Objectives of component testing)

컴포넌트 테스팅(단위 혹은 모듈 테스팅이라고 부르기도 함)은 개별적으로 테스트할 수 있는 컴포넌트에 초점을 맞춘다. 컴포넌트 테스팅의 목적에는 다음과 같은 것들이 있다:

• 리스크 완화
• 컴포넌트의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단
• 컴포넌트 품질 수준에 대한 자신감 획득
• 컴포넌트에 존재하는 결함 발견
• 다음 단계로의 결함 전이 방지

테스트 베이시스 (Test basis)

컴포넌트 테스팅의 테스트 베이시스로 사용할 수 있는 대표적인 작업 산출물은 다음과 같다

• 상세 설계
• 코드
• 데이터 모델
• 컴포넌트 명세

테스트 대상 (Test objects)

• 컴포넌트, 단위, 모듈
• 코드 및 데이터 구조
• 클래스
• 데이터베이스 모듈

대표적인 결함과 장애 (Typical defects and failures)

• 잘못된 기능 (예: 설계 명세의 설명과 다름)
• 데이터 흐름 문제
• 잘못된 코드 및 논리

2.2.2 통합 테스팅 (Integration Testing)

통합 테스팅의 목적 (Objectives of integration testing)

통합 테스팅은 컴포넌트나 시스템 간의 상호작용에 초점을 맞춰서 진행한다.
통합 테스팅의 목적에는 다음과 같은 것들이 있다:

• 리스크 완화
• 인터페이스의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단
• 인터페이스 품질 수준에 대한 자신감 획득
• 결함 발견 (결함은 인터페이스 자체 또는 컴포넌트나 시스템에 존재할 수 있다)
• 다음단계로의결함전이방지

이 실러버스에서는 다음과 같은 두 개의 다른 통합 테스팅 레벨을 다루고 있으며, 이런 통합 테스팅은 다양한 크기의 테스트 대상에 수행할 수 있다:

• 컴포넌트 통합 테스팅은 통합된 컴포넌트 간의 상호운용성과 인터페이스에 초점을 맞춘다.
• 시스템 통합 테스팅은 시스템, 패키지, 마이크로 서비스(microservice) 간의 상호운용성과 인터페이스에 초점을 맞춘다.

테스트 베이시스 (Test basis)

통합 테스팅의 테스트 베이시스로 사용할 수 있는 대표적인 작업 산출물은 다음과 같다:

• 소프트웨어 및 시스템 설계
• 시퀀스 다이어그램(sequence diagram)
• 인터페이스 및통신프로토콜명세
• 유스케이스
• 컴포넌트나 시스템 레벨의 아키텍처
• 워크플로우(workflow)
• 외부 인터페이스 정의서

테스트 대상 (Test objects)

• 서브시스템(subsystems)
• 데이터베이스(database)
• 인프라(infrastructure)
• 인터페이스(interfaces)
• APIs
• 마이크로서비스(microservices)

일반적인 결함과 장애 (Typical defects and failures)

컴포넌트 통합 테스팅에서 발견되는 대표적인 결함과 장애는 다음과 같다:

• 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩
• 잘못된 인터페이스 콜 순서나 타이밍
• 인터페이스 불일치
• 컴포넌트간의 통신 장애
• 컴포넌트간의 통신 실패 처리 누락 및 오류
• 컴포넌트간 주고받는 데이터의 의미, 단위, 경계에 대한 잘못된 가정

시스템 통합 테스팅에서 발견되는 대표적인 결함과 장애는 다음과 같다:

• 시스템 간의 일관적이지 않은 메시지 구조
• 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩
• 인터페이스 불일치
• 시스템간의통신장애
• 시스템간의통신실패처리누락및오류
• 시스템간주고받는데이터의의미,단위,경계에대한잘못된가정
• 필수보안규정준수실패

구체적인 접근법과 책임 (Specific approaches and responsibilities)

• 컴포넌트 통합 테스팅은 개발자의 책임인 경우가 많다
• 시스템 통합 테스팅은 일반적으로 테스터의 책임이다.
• 컴포넌트 통합 테스트와 시스템 통합 테스트는 통합 자체에 집중해야 한다.
  예를 들어, 모듈 A 와 모듈 B 를 통합하는 경우, 모듈 간의 커뮤니케이션에 테스트를 집중해야 하며,
  컴포넌트 테스팅에서 커버했어야 할 개별 모듈의 기능에 초점을 맞춰서는 안 된다.

2.2.3 시스템 테스팅 (System Testing)

시스템 테스팅의 목적 (Objectives of system testing)

시스템 테스팅은 전체 시스템 또는 제품의 동작이나 능력에 관심을 가지며, 시스템이 수행할 엔드-투-엔드(end- to-end) 작업과 그런 작업을 수행할 때 나타나는 비기능 동작을 고려하는 경우가 많다.

• 리스크 완화
• 시스템의 기능/비기능 동작이 설계 및 명시된 대로 이루어지는지 검증
• 완성된 시스템이 기대한 대로 동작하는지 확인
• 전체 시스템 품질에 대한 자신감 획득
• 결함 발견
• 결함이 상위 테스트 레벨이나 생산 단계로의 전이 방지

시스템 테스팅을 통해 법적, 규정 요구사항이나 표준을 만족시킬 수도 있다.

 

테스트 베이시스 (Test basis)

• 시스템 및 소프트웨어 요구사항 명세 (기능/비기능)
• 리스크 분석 보고서
• 유스케이스
• 에픽(epic)과 사용자 스토리
• 시스템 동작 모델
• 상태 다이어그램
• 시스템 및 사용자 매뉴얼

테스트 대상 (Test objects)

• 애플리케이션
• 하드웨어/소프트웨어 시스템
• 운영 시스템
• 테스트 대상 시스템 (SUT, System Under Test)
• 시스템 설정과 설정 데이터

일반적인 결함과 장애 (Typical defects and failures)

• 잘못된 연산
• 시스템의 잘못되거나 예상치 못한 기능/비기능 동작
• 시스템내잘못된제어및데이터흐름
• 엔드-투-엔드 기능 작업 수행 실패
• 시스템 환경에서 시스템의 정상 동작 실패
• 시스템 및 사용자 매뉴얼대로의 시스템 동작 실패

구체적인 접근법과 역할 (Specific approaches and responsibilities)

시스템 테스팅은 기능과 비기능 모두의 측면에서 전반적인 시스템의 엔드-투-엔드 동작에 관심을 가진다.

2.2.4 인수 테스팅 (Acceptance Testing)

인수 테스팅의 목적 (Objectives of acceptance testing)

시스템 테스팅과 마찬가지로 인수 테스팅도 전체 시스템 또는 제품의 동작이나 능력에 초점을 두고 진행하는 경우가 많다.

인수 테스팅으로 법적, 규정 요구사항이나 표준을 만족할 수도 있다.

• 전체 시스템의 품질에 대한 자신감 획득
• 완성된 시스템이 기대한 대로 동작하는지 확인
• 시스템의 기능/비기능 동작이 명세대로 동작하는지 검증

인수 테스팅의 대표적인 형태는 다음과 같다: 

• 사용자 인수 테스팅
• 운영 인수 테스팅
• 계약 및 규제 인수 테스팅
• 알파(alpha) 및 베타(beta) 테스팅

사용자 인수 테스팅 (UAT, User Acceptance Testing)

시스템의 사용자 인수 테스팅은 일반적으로 실제 또는 시뮬레이션된 운영 환경에서 예정된 사용자가 사용하기에 얼마나 적합한지 확인하는 데 관심을 둔다.

 

운영 인수 테스팅 (OAT, Operational Acceptance Testing)

운영자 또는 시스템 관리 직원에 의해 수행되는 시스템 인수 테스팅은(시뮬레이션 된) 생산 환경에서 이루어지는 경우가 많다.

테스트는 운영 측면에 집중돼 있으며, 다음을 포함할 수 있다

• 백업및복원테스팅
• 설치, 삭제, 업그레이드
• 긴급 복구 (disaster recovery)
• 사용자 관리
• 유지보수 작업
• 데이터 로딩 및 이관(migration) 작업
• 보안 취약점 확인
• 성능 테스팅

계약 및 규제 인수 테스팅 (Contractual and regulatory acceptance testing)

계약 인수 테스팅은 주문 개발 소프트웨어의 생산을 위한 계약서에 명시된 인수 조건을 가지고 수행한다. 계약 및 규제 인수 테스팅의 가장 중요한 목적은 계약이나 규제 준수에 대한 자신감의 획득이다.

 

알파 및 베타 테스팅 (Alpha and beta testing)

알파 테스팅은 개발 조직의 현장에서 개발팀이 아닌 신규 혹은 기존 고객이나 운영자, 독립적 테스트 팀이 수행한다.

베타 테스팅은 신규 혹은 기존 고객 이나 운영자가 자신의 환경에서 수행한다.

알파 및 베타 테스팅은 소프트웨어 제품을 시장에 출시하기 전에 기존 혹은 신규 사용자, 고객, 운영자 등으로부터 피드백을 받기 원하는 상용 소프트웨어 개발자가 사용하는 경우가 많다.

 

테스트 베이시스 (Test basis)

• 비즈니스 프로세스
• 사용자 또는 비즈니스 요구사항
• 규제, 법적 계약, 표준
• 유스케이스 및 사용자 스토리
• 시스템 요구사항
• 시스템 또는 사용자 문서
• 설치 절차
• 리스크 분석 보고서

일반적인 테스트 대상 (Typical test objects)

• 테스트 대상 시스템
• 시스템 설정과 설정 데이터
• 완전히 통합된 시스템의 비즈니스 프로세스
• 복원 시스템이나 비즈니스 연속성 및 긴급 복구 테스팅을 위한 핫 사이트 (hot site)
• 운영 및 유지보수 프로세스
• 양식
• 보고서
• 기존 및 전환된 생산 데이터

일반적인 결함과 장애 (Typical defects and failures)

• 비즈니스나 사용자 요구사항을 충족하지 못하는 시스템 워크플로우 (workflow)
• 잘못 구현된 비즈니스 규칙
• 계약 혹은 규제 요구사항을 충족하지 못하는 시스템
• 보안 취약성, 많은 부하가 걸렸을 때 성능 효율성 저하, 지원 대상 플랫폼상에서의 잘못된 운영 등과 같은 비기능 장애

구체적인 접근법과 역할 (Specific approaches and responsibilities)

사용자 인수 테스트, 운영 인수 테스트, 규제 인수 테스트, 계약 인수 테스트 등도 각 반복주기 끝에, 혹은 각 반복주기가 완료되고 나서, 또는 몇 개의 반복주기 후에 수행할 수 있다.

2.3 테스트 유형 Test Types

테스트 유형이란 특정 테스트 목적을 위해 소프트웨어 시스템이나 시스템의 일부 특정 속성을 테스트하는 활동의 집합을 얘기한다.

대표적인 목적은 다음과 같다:

• 완전성, 정확성, 적합성 등과 같은 기능 품질 특성 평가
• 신뢰성, 성능 효율성, 보안성, 호환성, 사용성 등과 같은 비기능 품질 특성 평가
• 컴포넌트나 시스템의 아키텍처 및 구조가 정확하고 완전하며 명시된 것과 일치하는지 평가
• 수정의 효과 평가. 예를 들어, 결함이 수정됐는지 확인(확인 테스팅)하고 소프트웨어나 환경의 변화로 인해 동작에 의도하지 않은 변화가 없는지(리그레션 테스팅) 평가

2.3.1 기능 테스팅 (Functional Testing)

기능 테스팅은 시스템이 수행해야 하는 기능을 평가하기 위한 테스트를 포함한다.

기능이란 시스템이 해야 하는 그 "무엇”을 얘기한다.

 

기능 테스팅이 얼마나 철저하게 수행됐는지 기능 커버리지를 통해 측정할 수 있다.

기능 커버리지란 어떤 기능이 테스트에 의해 어느 정도 실행됐는 지를 말하며, 커버되고 있는 요소 유형에 대한 백분율로 표기된다.

2.3.2 비기능 테스팅 (Non-functional Testing)

시스템의 비기능 테스팅은 사용성, 성능 효율성 또는 보안성과 같은 시스템 특성을 평가한다.

비기능 테스팅이란 시스템이 "얼마나 잘" 동작하는지에 대한 테스팅을 말한다.

소프트웨어 제품 품질 특성의 분류에 관해서는 ISO 표준(ISO/IEC 25010)을 참조하라.

 

비기능 테스팅을 얼마나 철저하게 수행했는지는 비기능 커버리지를 사용해서 측정할 수 있다.

비기능 커버리지란 특정 비기능 요소가 테스트로 어느 정도 실행됐는 지를 말해주며 커버하고 있는 요소 유형에 대한 백분율로 표기한다.

비기능 품질 특성에 대한 테스팅에 관해서는 ISTQB-CTAL-TA, ISTQB-CTAL-TTA, ISTQB-CTAL-SEC, 기타 ISTQB specialist module 을 참조하라.

2.3.3 화이트박스 테스팅 (White-box Testing)

화이트박스 테스팅은 시스템의 내부 구조나 구현을 기반으로 테스트를 도출한다.

내부 구조로는 코드, 아키텍처, 워크플로우(workflow), 시스템 내 데이터 플로우(data flow) 등이 있다

 

화이트박스 테스팅이 얼마나 철저하게 이루어졌는지는 구조 커버리지를 통해 측정할 수 있다.

구조 커버리지란 특정 구조 요소가 테스트에 의해 어느 정도 실행됐는지를 말하며, 커버되고 있는 요소 유형에 대한 백분율로 표기한다.

2.3.4 변경 관련 테스팅 (Change-related Testing)

결함을 수정하고자 했든 또는 기능을 추가하거나 개선하기 위해서 했든 시스템이 변경되면, 해당 변경이 결함을 제대로 수정했는지, 기능을 올바르게 구현했는지 또 예상하지 못한 부작용이 발생하지 않았는지 확인하기 위한 테스팅을 수행할 필요가 있다.

 

확인 테스팅(Confirmation testing)

결함이 수정된 후 이 결함으로 인해 불합격했던 모든 테스트 케이스를 새로운 소프트웨어 버전에서 재실행할 수 있다.

 

리그레션 테스팅(Regression testing)

코드의 특정 부분에 대한 변경이 무언가를 수정하기 위해서거나 또는 다른 목적이든 관계없이 이런 변경은 의도치 않게 코드의 다른 부분에 영향을 줄 수 있다. 리그레션 테스팅은 이런 의도하지 않은 부작용을 발견하기 위한 테스트를 수행하는 것이다. (의도하지 않은 부작용을 리그레션이라 부른다)

특히 반복적 점진적 개발 수명주기(예: 애자일)에서는 신규 기능, 기존 기능에 대한 변경, 코드 리팩토링(code re-factoring) 때문에 코드에 잦은 변경이 가해지고 결국 변경 관련 테스팅이 필요하게 된다. 시스템이 진화하는 특성 때문에 확인 및 리그레션 테스팅은 매우 중요하다

2.3.5 테스트 유형과 테스트 레벨 (Test Types and Test Levels)

위에서 언급한 모든 테스트 유형은 어느 테스트 레벨에서나 수행할 수 있다.

(실러버스 예시 각 참조)

2.4 유지보수 테스팅 Maintenance Testing

소프트웨어와 시스템이 생산 환경으로 배포되고 나면 유지보수가 필요하다.

유지보수의 일환으로 변경이 이루어지게 되면, 변경의 성공 여부를 평가하고 시스템의 변경되지 않은 부분(많은 경우 시스템의 대부분)에서 부작용(예: 리그레션)의 발생 여부를 확인하기 위한 유지보수 테스팅을 수행해야 한다.

유지보수는 계획된 릴리스나 계획되지 않은 릴리스(핫픽스)와 연관되어 발생할 수 있다.

유지보수 릴리스는 그것의 범위에 따라 다양한 테스트 유형을 활용한 복수의 테스트 레벨에서의 유지보수 테스팅이 필요할 수 있다.

2.4.1 유지보수가 필요한 상황 (Triggers for Maintenance)

유지보수의 계기는 다음과 같이 분류할 수 있다:

• 개선을 위한 변경(modification), 계획된 확장(예: 릴리스 기반), 수정 혹은 긴급 변경, 운영 환경 변경(예: 계획된 운영 시스템이나 데이터베이스 업그레이드), 상용 소프트웨어 업그레이드, 결함 및 취약성을 위한 패치 등
• 이관(migration)을 위한 변경

2.4.2 유지보수를 위한 영향도 분석 (Impact Analysis for Maintenance)

영향도 분석은 유지보수 릴리스에 포함된 변경을 평가해서, 의도한 결과뿐만 아니라 변경으로 인해 발생할 수 있는 예견된 부작용을 식별하고, 변경의 영향을 받는 시스템 영역을 식별하기 위해 실시한다.

 

[참고 문헌]

ISTQB_CTFL_파운데이션레벨(FL)_v.2018_실러버스_v3.1.1_한글_v1.0