일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- QA자격증
- testing
- istqb dump
- 실라버스
- Office test
- 폴라리스오피스
- 테스트 외주
- qa테스트
- 테스트케이스
- 외주 테스트
- 테스트 아웃소싱
- istqb fl
- QA
- 테스팅
- qa 아웃소싱
- 테스트
- 자격증
- Polaris Office
- mobile QA
- 모바일앱 QA
- qa 자격증
- ctfl
- App QA
- 게임 qa
- TestCase
- istqb 기출문제
- 검증
- FL
- Test
- ISTQB
- Today
- Total
QA Outsourcing & Consulting
[CSTS AL] 3. 테스트 방법 - 소프트웨어 개발모델과 테스팅 본문
[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 |