소프트웨어 개발 수명 주기와 테스팅

(Software Development Lifecycle Models

and Testing)

• 참조 : ISTQB CTFL Syllabus 2018

• 기획 : 와이즈와이어즈㈜
• 담당자 : 이현재 선임 연구원
• Email : hjlee1@wisewires.com
0. 들어가기에 앞서

소프트웨어 개발 수명 주기란 무엇일까요 ?

 목차

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

• 소프트웨어 개발과 소프트웨어 테스팅

• 정황에 따른 소프트웨어 개발 수명주기 모델

2. 테스트 레벨

• 컴포넌트 테스팅

• 통합 테스팅

• 시스템 테스팅

• 인수 테스팅

3. 테스팅 유형

• 기능 테스팅

• 비기능 테스팅

• 화이트박스 테스팅

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

• 테스트 유형과 테스트레벨

4. 유지보수 테스팅

• 유지보수가 필요한 상황

• 유지보수를 위한 영향도 분석
1.소프트웨어 개발 수명주기 모델
• 소프트웨어 개발과 소프트웨어 테스팅

• 정황에 따른 소프트웨어 개발 수명주기 모델

1. 소프트웨어 수명주기 모델
• 소프트웨어 개발과 소프트웨어 테스팅
 폭포수 모델
 순차적 모델 (Linear or Sequential model, 전통적 개발 모델 )
 코드가 완전히 개발된 이후에 단 한번에 테스팅 (testing) 단계 수행

요구사항
Requirements
분석
Analysis
설계
Design
코딩
Coding
테스팅
Testing
배포 Release
1. 소프트웨어 수명주기 모델
• 소프트웨어 개발과 소프트웨어 테스팅
 점진적 모델
 초기 요구사항을 점진적으로 반복되는 개발 주기를 통해 완성도를 높임
 반복 주기 별로 중분 산출물에 대한 테스트를 수행 (V&V)

Build_1
D C T

Requirements
D C T
(1 ~ N) Build_2

Build_N
D C T

* D (Design), C (Coding), T (Test)

1. 소프트웨어 수명주기 모델
• 소프트웨어 개발과 소프트웨어 테스팅
 반복적 모델
 우선 순위에 따라 짧은 주기로 개발을 여러 번 반복하여 결과물 도출
 반복과정에 의해 생성된 시스템은 여러 테스트 레벨에서 개발과정 일부로 테스트
 회귀 테스팅이 모든 반복 과정에서 점차적으로 중요해짐

Req. 1
D C T

Req. 2
D C T

Req. n
D C T
1. 소프트웨어 수명주기 모델
• 소프트웨어 개발과 소프트웨어 테스팅
 V - 모델
 소프트웨어 개발 모델 ( 폭포수 ) 과 대응되는 테스팅 모델 제시
 개발 프로세스 초기에 테스팅 계획과 설계 준비에 도움

Acceptance test Acceptance

Requirements Planning Testing

System test System

Specification Planning Testing
Ve

Integration test
rif

Design Integration
ica

Planning Testing

on
t io

ati
n

lid
Va
Unit test Unit
Coding Testing
Planning

(Actual)Testing
QA
1. 소프트웨어 수명주기 모델
• 소프트웨어 개발과 소프트웨어 테스팅
 Verification & Validation

 Verification( 검증 )
a. 각 개발 활동 단계의 산출물이 주어진 사양에 부합되는지 평가
b. “Are we building the product right?” 에 대한 결과
c. 산출물에 대한 “ review(inspection)” 활동에 해당

 Validation( 확인 )
a. 개발 산출물이 초기 고객 요구사항을 만족하는지 평가
b. “Are we building the right product?” 에 대한 결과
c. 전통적으로 실행 기준의 “ testing” 활동에 해당
1. 소프트웨어 수명주기 모델
• 정황에 따른 소프트웨어 수명 주기 모델
개발 수명 주기 모델에서 성공적인 테스팅 특징

 모든 개발 활동은 테스팅 활동과 대응됨

 각 테스트 레벨은 각각에 맞는 특정한 목적을 가짐
 주어진 테스트 레벨에 대한 테스트 분석과 설계는 대응되는 개발 활동 동안 시작
 테스터는 개발 수명 주기 동안 테스팅 활동에 필요한 초안 준비와 개발문서의 리뷰 활동
2. 테스트 레벨
• 컴포넌트 테스팅

• 통합 테스팅

• 시스템 테스팅

• 인수 테스팅
2. 테스트 레벨
• 테스트 레벨이란 ?
 V - 모델
 소프트웨어 개발 모델 ( 폭포수 ) 과 대응되는 테스팅 모델 제시
 개발 프로세스 초기에 테스팅 계획과 설계 준비에 도움

Acceptance test Acceptance

Requirements Planning Testing

System test System

Specification Planning Testing
Ve

Integration test
rif

Design Integration
ica

Planning Testing

on
t io

ati
n

lid
Va
Unit test Unit
Coding Testing
Planning

(Actual)Testing
QA
2. 테스트 레벨

Unit Integration System Acceptance

Testing Testing Testing Testing

 테스트 레벨
a. 단위 테스팅 (Unit testing)
b. 통합 테스팅 (Integration testing)
c. 시스템 테스팅 (System testing)
d. 인수 테스팅 (Acceptance testing)

 각 테스트 레벨을 분류하는 기준

a. 구체적인 목적
b. 테스트 케이스를 도출하기 위해 참고하는 테스트 베이시스
c. 테스트 대상
d. 발견된 전형적인 결함과 장애
e. 구체적인 테스트 접근법과 담당 책임 ( 테스팅 조직 )
2. 테스트 레벨

Unit Integration System Acceptance

Testing Testing Testing Testing

 구체적인 목적
a. 리스크 완화
b. 컴포넌트의 기능과 비기능 동작이 설계 및 명세와 일치하는지 판단
c. 컴포넌트 품질 수준에 대한 자신감 획득
d. 컴포넌트에 존재하는 결함 발견
e. 다음 단계로의 결함 전이 방지

 테스트 케이스를 도출하기 위해 참고하는 테스트 베이시스

a. 상세 설계
b. 코드
c. 데이터 모델
d. 컴포넌트 명세
2. 테스트 레벨

Unit Integration System Acceptance

Testing Testing Testing Testing

 테스트 대상
a. 컴포넌트 , 단위 , 모듈
b. 코드 및 데이터 구조
c. 클래스
d. 데이터베이스 모듈

 대표적인 결함과 장애
a. 잘못된 기능
b. 데이터 흐름 문제
c. 잘못 코드 및 논리
2. 테스트 레벨

Unit Integration System Acceptance

Testing Testing Testing Testing

 구체적인 접근법과 책임
a. 코드를 중심으로 수행하며 단위 테스트 프레임 워크 또는 디버깅 툴 같은 개발 환경을 지원
b. 실무에서는 코드를 작성한 프로그래머가 직접 테스트에 참여
c. 일반적으로 결함이 발견되면 즉시 수정되며 , 정식 결함 관리는 하지 않는 것이 일반적임
d. 코딩 전에 테스트 케이스를 준비하고 , 자동화 하는 것이 좋음
( 테스트 주도 개발 방법론 : test-driven development)
2. 테스트 레벨

Unit Integration System Acceptance

Testing Testing Testing Testing

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

 두 개의 다른 통합 테스팅 레벨
a. 컴포넌트 통합 테스팅
- 통합된 컴포넌트 간의 상호운용성과 인터페이스에 초점
- 컴포넌트 테스팅 후 수행하며 자동화로 진행되는 경향
b. 시스템 통합 테스팅
- 시스템 , 패키지 , 마이크로서비스 (microservice) 간의 상호운용성과 인터페이스에 초점
2. 테스트 레벨

Unit Integration System Acceptance

Testing Testing Testing Testing

 테스트 케이스를 도출하기 위해 참고하는 테스트 베이시스

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

 테스트 대상
a. 서브시스템 (subsystems) d. 인터페이스 (interfaces)
b. 데이터베이스 (database) e. APIs
c. 인프라 (infrastructure) f. 마이크로서비스 (microservices)
2. 테스트 레벨

Unit Integration System Acceptance

Testing Testing Testing Testing

 구체적인 접근법과 책임
a. 컴포넌트 통합 및 시스템 통합 테스팅은 통합 ( 각 모듈간의 커뮤니케이션 ) 자체에 집중
b. 컴포넌트 테스팅에서 커버했어야 할 기능에 초점을 맞추면 안됨
c. 컴포넌트 통합 테스팅은 개발자의 책임 경우가 많음 / 시스템 통합 테스팅은 테스터의 책임
2. 테스트 레벨

Unit Integration System Acceptance

Testing Testing Testing Testing

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

 테스트 베이시스
a. 시스템 및 소프트웨어 요구사항 명세 ( 기능 / 비기능 ) e. 시스템 동작 모델
b. 리스크 분석 보고서 f. 상태 다이어 그램
c. 유즈케이스 g. 시스템 및 사용자 메뉴얼
d. 에픽과 사용자 스토리
2. 테스트 레벨

Unit Integration System Acceptance

Testing Testing Testing Testing

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

 일반적인 결함과 장애
a. 잘못된 연산
b. 시스템의 잘못되거나 예상치 못한 기능 / 비기능 동작
c. 엔드 - 투 - 엔드 기능 작업 수행 실패
d. 시스템 환경에서 시스템의 정상 동작 실패
e. 시스템 및 사용자 매뉴얼대로의 시스템 동작 실패
2. 테스트 레벨

Unit Integration System Acceptance

Testing Testing Testing Testing

 구체적인 접근법과 역할
a. 기능 / 비기능 모두의 측면에서 전반적인 시스템의 엔드 - 투 - 엔드 동작에 관심
b. 테스트 대상 시스템의 특성에 가장 잘 맞는 기법을 사용
c. 일반적으로 명세에 과도하게 의존하는 독립적인 테스터가 수행
2. 테스트 레벨

Unit Integration System Acceptance

Testing Testing Testing Testing

 구체적인 목적
a. 전체 시스템의 품질에 대한 자신감 획득
b. 완성된 시스템이 기대한 대로 동작하는지 확인
c. 시스템의 기능 / 비기능 동작이 명세대로 동작하는 검증
d. 결함 발견이 목적이 아닌 경우가 많으며 , 상당수의 결함이 발견되면 심각한 프로젝트
리스크로 인식

 인수 테스팅의 대표적인 형태  소프트웨어 제품을 시장에 출시하기 전 기존 혹은

신규 사용자 , 고객 , 운영자 등으로부터 피드백을
a. 사용자 인수 테스팅
 주문
목적은
원하는
운영자
사용
개발 또는
소프트웨어
소프트웨어의시스템 관리자가
개발자가
생산을 비록
사용
위해 예외적이고
계약서에
b. 운영 인수 테스팅 사용자가
 명시된
어려운 그들의
알파조건에서라도
테스팅 필요에
: 개발운영
조직의따라 요구사항을
환경에서
현장에서 충족하면서
사용자를
개발팀이
위해아닌
인수 조건을 가지고 수행
c. 계약 및 규제 인수 테스팅 최소한의
 신규
사용자를 어려움 , 비용 , 리스크 등으로 비즈니스
인수 혹은
위해기존
조건은 시스템을
모든 고객이나
계약정상적으로
운영 , 독립적
당사자가 유지할테스트팀이
동의 수 있다는
d. 알파 (alpha) 및 베타 (beta) 테스팅 프로세스를
수행획득수행할
 사용자나
자신감 수 있다는 자신감 획득
독립적인 테스터가 수행
 베타 테스팅 : 신규 혹은 기존 고객이나 운영자가
자신의 환경에서 수행
2. 테스트 레벨

Unit Integration System Acceptance

Testing Testing Testing Testing

 테스트 베이시스 ( 공통 )
a. 비즈니스 프로세스
b. 사용자 또는 비즈니스 요구사항
c. 규제 , 법적 계약 , 표준
d. 유즈케이스 및 사용자 스토리
e. 시스템 요구사항
f. 시스템 또는 사용자 문서
g. 설치 절차
h. 리스크 분석 보고서

 추가적인 운영 인수 테스팅에서의 테스트 베이시스

a. 백업 및 복원 절차 c. 비기능 요구사항 e. 배포 및 설치 지침 g. 데이터베이스 패키지
b. 긴급 복구 절차 d. 운영 문서 f. 성능 목표 h. 보안 표준 또는 규정
2. 테스트 레벨

Unit Integration System Acceptance

Testing Testing Testing Testing

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

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

Unit Integration System Acceptance

Testing Testing Testing Testing

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

 구체적인 접근법과 역할
a. 주로 고객 , 비즈니스 사용자 , 제품 소유자 , 혹은 시스템 운영자가 담당
b. 대부분은 순차적 개발 수명주기의 마지막 테스트 레벨이지만 사용 소프트웨어 제품에 대한 인수 테스팅은
그것이 설치되거나 통합될 때 , 신규 기능 개선 사항에 대한 인수 테스팅은 시스템 테스팅 전에 이루어 진다 .
3. 테스트 유형
• 기능 테스팅

• 비기능 테스팅

• 화이트 박스 테스팅

• 변경 관련 테스팅

• 테스트 유형과 테스트 레벨

3. 테스트 유형 (Test type)
• 테스트 유형이란 ?
 특정 테스트 목적을 위해 소프트웨어 시스템이나 시스템의 일부 특정 속성을 테스트하는 활동의 집합

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

 기능 테스팅 (functional testing)

- 소프트웨어가 수행하는 기능에 대한 테스팅

 비 기능 테스팅 (non-functional testing)

- 신뢰성 , 사용성과 같은 비기능적 품질 특성 테스팅

 화이트박스 테스팅 (white-box testing)

- 소프트웨어나 시스템 구조 또는 아키텍처에 대한 테스팅

 변경 관련 테스팅 (change-relatesd testing)

- 변경 사항에 대한 테스팅
- 확인 테스팅 (confirmation testing) : 결함 수정 후 제거 여부 확인
- 디버깅 (debugging) : 발견된 결함을 수정하는 개발 활동
- 회귀 테스팅 (regression testing) : 의도되지 않은 변경 결과로 다른 결함 발견
3. 테스트 유형 (Test type)
• 기능 테스팅 (Functional Testing)

 시스템이 수행해야 하는 기능을 평가하기 위한 테스트

 모든 테스트 레벨에서 수행해야 하지만 , 각 레벨에서의 주요 사항은 다를 수 있음

 컴포넌트나 시스템의 기능에 대한 테스트 컨디션과 테스트 케이스 도출을 위해 블랙박스 기법을
활용

 기능 커버리지 ( 기능에 대한 테스트 정도 ) 를 통해 수행에 대한 심도 측정

 기능 테스트 설계 및 실행에는 특수한 역량이나 지식이 필요 ( 도메인 지식 )

3. 테스트 유형 (Test type)
• 비기능 테스팅 (Non-functional Testing)

 시스템이 얼마나 잘 동작하는지에 대한 테스트

 모든 테스트 레벨에서 수행해야 하고 , 되도록이면 초반에 수행하는 것이 좋다 .

 컴포넌트나 시스템의 기능에 대한 테스트 컨디션과 테스트 케이스 도출을 위해 블랙박스 기법을
활용

 비기능 커버리지 ( 특정 비기능에 대한 테스트 정도 ) 를 통해 수행에 대한 심도 측정

 기능 테스트 설계 및 실행에는 특수한 역량이나 지식이 필요 ( 도메인 지식 )

 ISO/IEC 25010 의 품질의 주특성 참조

3. 테스트 유형 (Test type)
• 화이트박스 테스팅 (WhiteboxTesting)

 시스템의 내부 구조 ( 코드 , 아키텍쳐 , 워크플로우 (workflow), 시스템 내의 데이터 플로우 ) 나

구현을 기반으로 테스트

 모든 테스트 레벨에서 수행
- 자동화 도구는 선언과 결정과 같은 코드 커버리지 요소 측정 ( 통합 테스트 )
- 호출 체계 ( 구조 : hierarchy) 와 같은 시스템 아키텍처 기반 ( 시스템 테스팅 )
- 비즈니스 모델 또는 메뉴 구조 ( 인수 / 시스템 테스팅 )

 화이트박스 테스트 설계 및 실행에는 특수한 역량이나 지식이 필요 ( 코드 커버리지 측정 도구 )

3. 테스트 유형 (Test type)
• 변경 관련 테스팅 (Change-related Testing)

 확인 테스팅 (confirmation testing)

- 결함이 발견되고 보고되어서 수정된 후에 원래 결함이 성공적으로 제거되었는지 확인하는 테스트

 회귀 테스팅 (regression testing)

• 결함 수정 이후 변경 결과로 도입되었거나 발견되지 않았던 또 다른 결함 발견
- 결함은 테스트 중인 소프트웨어에 존재 , 관련 있는 또는 전혀 관련이 없는 소프트웨어 컴포넌트에 존재
• 소프트웨어 또는 그 환경이 변경되면 수행
• 수행 범위와 정도 : 이전에 정상 동작했던 SW 에서 결함을 발견하지 못해 야기될 수 있는 위험성에 근거
• 모든 레스트 레벨에서 수행
• 기능 , 비기능과 구조적 테스팅에 적용 가능
• 회귀 테스팅은 반복적인 경향이 있으므로 자동화 테스트 대상
3. 테스트 유형 (Test type)
• 테스트 유형과 테스트 레벨 (Test Types and Test Levels) ex. 인터넷 뱅킹 App

 기능 테스팅 (Functional Testing)

테스트 레벨 예시

컴포넌트 테스트 • 컴포넌트가 복잡한 이자 계산을 어떻게 해야 하는지를 기반으로 테스트 설계

• 사용자 인터페이스에서 포착하는 계정 정보가 어떻게 비즈니스 로직 (Logic) 으로

컴포넌트 통합 테스트
전달되는지를 테스트 설계

• 계좌 소유주가 어떻게 자신의 예금 통장에 신용 한도를 부여할 수 있는지를

시스템 테스트
기반으로 테스트 설계

• 시스템이 외부 마이크로서비스를 사용해서 계좌 소유주의 신용 점수를 확인하는 방법을

시스템 통합 테스트
기반으로 테스트 설계

인수 테스트 • 은행이 신용 한도를 승인하거나 거절하는 방법을 기반으로 테스트 설계

3. 테스트 유형 (Test type)
• 테스트 유형과 테스트 레벨 (Test Types and Test Levels) ex. 인터넷 뱅킹 App

 비기능 테스팅 (Non-Functional Testing)

테스트 레벨 예시

• 복잡한 전체 이자 계산을 수행하기 필요한 CPU 사이클 (cycle) 횟수를 평가하기 위해

컴포넌트 테스트
성능 테스트 설계

• 사용자 인터페이스에서 비즈니스 로직 (Logic) 으로 전달되는 데이터로 인한

컴포넌트 통합 테스트
버퍼 오버플로우 취약성을 위한 보안 테스트 설계

• 보이는 화면이 모든 지원 대상 브라우저와 모바일 기기에서 제대로 동작하는지 확인하기 위한

시스템 테스트
이식성 테스트 설계

• 신용 점수 마이크로서비스가 응답하지 않을 때 시스템의 강건성 (robustness) 을 평가하기 위한

시스템 통합 테스트
신뢰성 테스트 설계

인수 테스트 • 은행 신용 처리 인터페이스에 장애인의 접근성을 평가하는 사용성 테스트 설계

3. 테스트 유형 (Test type)
• 테스트 유형과 테스트 레벨 (Test Types and Test Levels) ex. 인터넷 뱅킹 App

 화이트박스 테스팅 (Whitebox Testing)

테스트 레벨 예시

• 금융 계산을 수행하는 모든 컴포넌트에 대한 완벽한 구문 및 결정 커버리지를 달성하기 위안

컴포넌트 테스트
테스트 설계

• 브라우저 인터페이스의 각 화면이 다음 화면과 비즈니스 로직을 기반으로 데이터를 어떻게

컴포넌트 통합 테스트
전달되는지 확인하기 위한 테스트 설계

시스템 테스트 • 신용 한도 신청 도중 순차적으로 거치게 되는 웹페이지를 커버하기 위한 테스트 설계

시스템 통합 테스트 • 신용 점수 마이크로서비스로 보내는 모든 조회 (inquiry) 유형을 실행하기 위한 테스트 설계

• 은행 간 이체에서 지원하는 모든 금융 데이터 파일 구조와 값 범위를 커버하기 위한

인수 테스트
테스트 설계
3. 테스트 유형 (Test type)
• 테스트 유형과 테스트 레벨 (Test Types and Test Levels) ex. 인터넷 뱅킹 App

 변경 관련 테스팅 (change-related Testing)

테스트 레벨 예시

컴포넌트 테스트 • 각 컴포넌트를 위한 자동 리그레션 테스트가 구축되고 지속적인 통합 프레임워크에 포함

• 인터페이스 관련 결함 수정이 코드 저장소에 체크인 (check-in) 됐을 때 해당 수정을 확인하기

컴포넌트 통합 테스트
위한 테스트 설계

• 특정 워크플로우에 속하는 화면 중
시스템 테스트
하나만 변경되더라도 해당 워크플로우에 대한 모든 테스트 실행

• 신용 점수 마이크로서비스에 대한 지속적인 개발의 일환으로 해당 마이크로서비스와

시스템 통합 테스트
상호작용하는 애플리케이션에 대한 테스트를 매일 재실행

인수 테스트 • 인수 테스팅에서 발견된 결함이 수정되면 기존에 불합격했던 모든 테스트를 재실행

4. 유지보수 테스팅
• 유지보수가 필요한 상황

• 유지보수를 위한 영향도 분석
4. 유지보수 테스팅

 소프트웨어 또는 시스템이 변경 , 단종 , 전이 (migration) 되는 경우에 발생

 변경을 위한 유지보수 테스팅

- 릴리즈 기반의 계획된 개선을 위한 변경
- 수정에 의한 변경과 긴급 변경 , 환경상의 변경
- 계획된 OS / DB 업그레이드 , OS 의 새로 드러난 취약점 패치

 전이를 위한 유지보수 테스팅

- 변경된 소프트웨어에 대한 운영 테스트
- 새로운 환경에서 운영 테스트

 단종을 위한 유지보수 테스팅

- 데이터를 전이 (migration) 하는 테스팅
- 데이터 보유 기간이 필요하다면 데이터 저장하는 것을 테스팅
감사합니다
Thank you