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

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

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

 (1) 모든 개발 활동은 그에 상응하는 테스트 활동이 있다.

 (2) 각 테스트 레벨은 그 레벨에 맞는 구체적인 목적을 가진다

 (3) 주어진 테스트 레벨에 맞는 테스트 분석과 설계는 상응하는 개발 활동이 이루어지고 있는 동안 시작해야 한다.

 (4) 테스터가 요구사항과 설계의 정의와 개선을 위한 대화에 참여하고, 작업 산출물의 초안이 나오는 즉시 리뷰에 참여한다.

> 테스팅을 초기에 시작하면 시간과 비용을 절약할 수 있다 -> 수명주기 초반에 테스팅 활동을 시작해야 한다.

>> 소프트웨어 개발 생명주기 모델<<

 1. 순차적 개발 모델

 (1) 폭포수 모델

  -개발 활동이 순차적으로 이루어진다 = 테스트활동은 개발 활동이 완료된 뒤에 이루어진다.

  -이해관계자 및 사용자에게 배포하기까지 n개월~n년

 (2) V 모델

  -테스트 프로세스를 전반적인 개발 프로세스에 통합한다. ;;  각 테스트 레벨의 테스트 실행이 경우에 따라서 중첩될 수도 있음

  -각 개발 단계에 테스트 레벨을 부여 -> 조기 테스팅에 더 적극적

 

 2. 점진적 개발, 반복적 개발 : 사용 가능한 소프트웨어 전달에 n주~n일 소요(전체 요구사항은 예외)

  (1) 점진적 개발 : 요구사항 정의, 시스템의 설계, 구축, 테스팅을 조각으로 나눠서 진행 -> 기능 증분

  (2) 반복적 개발 : 기능 집합을 종종 고정된 기간의 일련의 주기 안에서 같이 명시/설계/구축/테스트할 때 발생

     -래셔널 통합 프로세스(Rational Unitied Process) : 긴 반복주기, 큰 기능증분

     -스크럼(Scrum) : 짧은 반복주기, 작은 기능증분

     -칸반(Kanban) : 기간 고정 여부, 반복주기 완료 후 하나/여러 개의 기능을 묶어 전달

     -나선형(Spiral) : 실험적 증분 생성

>전반적인 개발 과정에서 테스트 레벨 중첩/반복적 적용 / 지속적 전달/배포 활용(자기조직적인 팀)

 

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

-시스템의 제품 리스크 차이(복잡/간단한 프로젝트)

-많은 사업부가 프로젝트나 프로그램의 일부일 가능성(순차적/애자일 개발 조합)

-제품의 짧은 출시 기간

 

2.2 테스트 레벨

>함께 분류되고 관리되는 테스트 활동의 집합

(1) 컴포넌트 테스팅

컴포넌트
목적	베이시스	대상	결함과 장애
리스크완화	상세 설계	컴포넌트, 단위, 모듈	잘못된 기능
컴포넌트의 기능/비기능 동작이 설계 및 명세와 일치하는지	코드	코드 및 데이터 구조	데이터 흐름 문제
품질 수준에 대한 자신감	데이터 모델	클래스	잘못된 코드 및 논리
결함 발견	컴포넌트 명세	데이터베이스 모듈
결함 전이 방지

 

(2) 통합 테스팅

통합
목적	베이시스	대상	결함과 장애
			일반	대표
리스크 완화	소프트웨어 및 시스템 설계	서브시스템		시스템 간의 일관적이지 않은 메시지 구조
인터페이스의 기능/비기능 동작이 설계 및 명세와 일치하는지	시퀀스 다이어그램	데이터베이스	잘못된/누락된 데이터, 잘못된 데이터 인코딩
인터페이스 품질 수준에 대한 자신감	인터페이스 및 통신 프로토콜 명세	인프라	잘못된 인터페이스 콜 순서나 타이밍
결함 발견	유스케이스	인터페이스	인터페이스 불일치
결함전이 방지	컴포넌트나 시스템 레벨의 아키텍처	APIs	컴포넌트 간의 통신 장애	시스템 간의 통신 장애
	워크플로우	마이크로서비스	컴포넌트 간의 통신 실패처리 누락 및 오류	시스템 간의 통신 실패 처리 누락 및 오류
	외부 인터페이스 정의서		컴포넌트 간 주고받는 데이터의 의미, 단위, 경계에 대한 잘못된 가정	시스템 간 주고 받는 데이터의 의미, 단위, 경계에 대한 잘못된 가정
				필수 보안 규정 준수 실패

 

(3) 시스템 테스팅

시스템
목적	베이시스	대상	결함과 장애
리스크완화	시스템 및 소프트웨어 요구사항 명세(기능/비기능)	애플리케이션	잘못된 연산
시스템의 기능/비기능 동작이 설계 및 명시된 대로 수행되는지 검증	리스크 분석 보고서	하드웨어/소프트웨어 시스템	시스템의 잘못되거나 예상치 못한 기능/비기능 동작
완성된 시스템 동작 확인	유스케이스	운영 시스템	시스템 내 잘못된 제어 및 데이터 흐름
전체 시스템 품질에 대한 자신감	에픽과 사용자 스토리	테스트 대상 시스템	엔드-투-엔드 기능 작업 수행 실패
결함 발견	시스템 동작 모델	시스템 설정과 설정 데이터	시스템 환경에서 시스템의 정상 동작 실패
결함 전이 방지	상태 다이어그램		시스템 및 사용자 매뉴얼대로의 시스템 동작 실패
	시스템 및 사용자 매뉴얼

 

(4) 인수 테스팅 : 사용자/운영/계약 및 규제/알파 및 베타 테스팅

  -사용자 인수 테스팅

  -운영 인수 테스팅

  -계약 및 규제 인수 테스팅

  -알파 및 베타 테스팅

 

2.3 테스트 유형

2.3.1 기능 테스팅 : 시스템이 수행해야 하는 기능을 평가(기능 : 시스템이 해야 하는 그 '무엇')

-모든 테스트 레벨에서 수행

-블랙박스 기법

-기능 커버리지 : 어떤 기능이 테스트에 의해 어느 정도 실행됐는지.(%)

 

2.3.2 비기능 테스팅 : 시스템 특성 평가(얼마나 잘 동작하는지)

-모든 테스트 레벨에서 수행(가능한 한 초반에)

-블랙박스 기법

-비기능 커버리지

 

2.3.3 화이트박스 테스팅 : 시스템 내부구조/구현을 기반으로 테슽트 도출

-내부 구조: 아키텍처, 워크플로우, 시스템 내 데이터 플로우

-구조 커버리지 : 특정 구조 요소가 테스트에 의해 어느 정도 실행됐는지

>컴포넌트 테스팅 레벨의 코드 커버리지

 

2.3.4 변경 관련 테스팅 

-확인 테스팅

-리그레션 테스팅 : 의도하지 않은 부작용을 발견하기 위한 테스팅

>모든 테스트 레벨에서 수행

>특히 반복적 점진적 개발 수명주기(애자일), 개별 오브젝트가 자주 업데이트되거나 교체되는 IoT 시스템에서 더욱 중요

>리그레션 테스트 스위트 : 여러번 반복 수행, 서서히 변화 -> 자동화에 적합

 

2.4 유지보수 테스팅 : 성능 효율성, 호환성, 신뢰성, 보안성, 이식성 등

2.4.1 유지보수가 필요한 상황

-개선을 위한 변경

-이관을 위한 변경

 

2.4.2 유지보수를 위한 영향도 분석

-목적 : 예견된 부작용 식별, 변경의 영향을 받는 시스템 영역을 식별