QA Outsourcing & Consulting

[CSTS AL] 3. 테스트 방법 - 소프트웨어 개발모델과 테스팅 본문

IT Trend/CSTS AL & ISO 29119

[CSTS AL] 3. 테스트 방법 - 소프트웨어 개발모델과 테스팅

인프라웨어테크놀러지(IT) 2019. 4. 11. 11:30

소프트웨어 개발모델과 테스팅에 대해 정리합니다.


※ 소프트웨어 개발모델

* 일반적으로 많이 사용되는 소프트웨어 개발 수명주기 모델을 잘 이해하는 것은 테스터의 중요한 역할

* 테스트 활동은 수명주기 초반에 시작해야함

> 어떤 개발 수명주기 모델을 선택하더라도 테스팅을 초기에 시작하면 시간과 비용을 절약할 수 있음

> 개발 초기에 발견한 결함은 수정하는 비용도 비교적 저렴


- 순차적(sequential) 개발 모델과 테스팅

*  V-모델 > 폭포수 모델에 근간을 두고 있음

: 테스팅을 초기에 시작하면 좋다는 원리를 토대로 테스트 프로세스를 전반적인 개발 프로세스에 통합한 모델

: 조기 테스팅을 적극적으로 구현한 모델

: 각 테스트 레벨의 테스트 실행이 순차적으로 이루어지도록 되어있으나, 경우에 따라 중첩됨

: 각각의 개발 단계에서 테스팅을 접근하는 방법을 개략적으로 이해하기 쉽게 모델화하여 보여주는 것

각 단계가 1:1 대응되지는 않음

[기본적인 V-모델]


* Verification - 개발 단계의 산출물이 그 단계의 초기에 설정된 조건을 만족하는지 여부를 검증하는 것

* Validation - 각 개발 단계 말에서 사용자의 관점으로 요구사항이 만족되는지 확인하는 것


* V-모델에서 제시하는 테스트 레벨

- 단위 테스팅(컴포넌트 테스팅)

- 통합 테스팅

- 시스템 테스팅

- 인수 테스팅

: 테스팅으로 표현되도 기능성테스팅/비기능성테스팅과 같은 맥락이 아님

프로젝트나 소프트웨어의 제품 특성에 따라 개발단계 및 테스팅 레벨 구성이 달라짐

: 각 레벨은 서로 종속성을 지니기 때문에 하나의 테스트 레벨에서 다른 테스트 레벨로 옮겨가기 위한 종료 및 시작 조건(Exit And entry criteria)을 갖추는 것이 바람직함


- Iterative-incremental 모델 : 반복적-점진적 개발 모델과 테스팅

* 반복적 개발 모델

: 고정된 기간의 일련주기 안에서 명시, 설계, 구축, 테스트할 때 발생

: 반복주기에는 전체 프로젝트 범위의 변경, 개발한 기능에 대한 수정이 포함될 수 있음

: 각 반복주기에는 전체 기능 중 일부 기능에 대한 개발이 진행됨 > 반복주기 횟수가 늘어남 → 소프트웨어의 기능이 늘어남

: 완성된 소프트웨어가 배포되거나 개발이 중단될 때까지 진행됨


* 점진적 개발 모델

: 요구사항 정의, 시스템의 설계, 구축, 테스팅을 조각으로 나눠서 진행 → 소프트웨어의 기능이 점진적으로 늘어남(기능 증분)

: 기능 증분(Feature increments)의 크기는 다양하게 설정 가능


* ex

- RUP(Rational Unified Process) : 각 반복주기가 상당히 긴 경우가 많음 > 기능 증분도 상당히 큼

- 애자일(Agile) 개발모델 (아래에서 더 자세히 확인한다.)

- 스크럼(Scrum) : 각 반복주기가 짧은 성향을 가짐 > 기능 증분도 작음

- 칸반(Kanban)

- 나선형(Spiral), 프로토타이핑(Prototyping)


: 전반적인 개발 과정에서 테스트 레벨을 중첩, 반복적으로 적용하는 경우가 많아짐

: 하나의 반복 단계에서 생성한 산출물 > 일반적으로 테스트 레벨 전체 혹은 일부를 거치면서 검증될 수 있음

: 반복단계의 증분은 추가 개발하는 증분에 의해 규모가 점차 커짐 > 부분 시스템을 형성

: 반복 단계의 증분 테스팅 필요

>> 부분 시스템도 리그레이션 테스팅이 필요

>>> 첫번째 반복 단계에서 테스팅한 이후 모든 반복단계에서 리스레이션 테스팅이 중요해짐


* 주요이슈

: 초기 개발 단계에서의 테스팅 및 테스트 환경과 개발이 진행되면서 테스팅 및 테스트 환경이 변경됨

- 제한된 세트의 집중된 테스트에서 시작 > 광범위한 세트의 분산된 테스트로 확장

- 테스트 대상 컴포넌트 증가

- 단순한 테스트 환경 > 복잡한 테스트 환경으로 변화

- 개별 유즈케이스 테스팅 > 유즈케이스간의 통합 테스팅으로 변화


- 애자일 모델과 테스팅

* 애자일 방법론

: 아무 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법 사이의 타협점을 찾고자 하는 개발 방법론

: 데드라인을 정해놓지 않은 방법론

: 애자일속도(각 스프린트(개발사이클) 별 프로젝트 진행 속도)를 보고 데드라인 예측 > 애자일 속도가 중요함

- 스크럼

: 각 개발자가 자신에게 할당된 태스크를 혼자서 진행, 진행이 더딘 경우 도움 요청

: '이미 익숙한 일들을 해내는 전문가들'이 모여 고객에게 의미 있는 분량의 제품 업데이트를 제공하기에 적합

- 칸반

동시에 진행할 수 있는 일의 수를 제한해버리면 전체 효율이 올라간다는 것이 핵심

: '군더더기를 뺀다'는 의미로 린Lean 방법이라고도 부름

: 각 개발자가 자신에게 할당된 태스크를 혼자서 진행, 완료되면 다른 태스크를 시작

잠재 고객은 있지만, 상당한 리서치를 요하는 제품을 개발할 때 적합.


* 애자일 개발 모델에 따른 테스트

: 일반적으로 TDD를 이야기함 > 개발과 동시에 지속적인 회귀테스트를 진행

: 팀이 각 스크럼팀으로 나뉘고 스크럼팀에 개발자와 QA가 같이 조직

: QA는 독립적이기도 하고 독립적이지 않기도 해야함 > 회사의 상황에 따라 적절한 조정필요

 - 애자일 프로세스에서의 테스터 역할

: 테스터는 애자일 팀의 일원

: 릴리즈/이터레이션(Iteration) 계획에 참여

: 개발시작부터 테스팅 활동 시작

: 인수 테스트의 테스트 기준을 정의하기 위해 고객과 협업하고 시스템이 예상한 대로 정확하게 동작하는지 검증

: 스토리가 완료되면 그것을 테스팅

: 탐색적 테스팅에 더 집중

: 동료 테스팅을 수행, 개발팀과 협업, 팀에 지속적인 피드백 제공


- 개발 수명주기 모델에서의 테스팅

* 개발 수명주기 모델은 프로젝트의 정황과 제품 특정에 따라 선택하고 적용해야 

* 성공적인 테스팅

- 모든 개발 활동은 그에 상응하는 테스팅 활동을 동반해야함

- 각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가지고 있어야 함

- 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되는 개발 활동 동안 시작되어야 함

- 개발 산출물 초안이 작성되면, 테스터는 그러한 문서를 리뷰하는 활동에 참가해야함


'IT Trend > CSTS AL & ISO 29119' 카테고리의 다른 글

[ISO 29119] 2. 표준소개  (0) 2019.04.04
[CSTS AL] 2. 테스트 개념  (0) 2019.03.21
[ISO 29119] 1. 시험준비  (0) 2019.02.22
[CSTS AL] 1. 시험준비  (0) 2019.02.15
Comments