'프로젝트/ITAMS'에 해당되는 글 4건

  1. 2013.03.26 프로젝트 개요
  2. 2013.03.26 리스크와 테스팅
  3. 2013.03.26 소프트웨어 수명주기와 테스트 레벨
  4. 2013.03.26 소프트웨어 수명주기와 테스팅
프로젝트/ITAMS2013. 3. 26. 01:46

본 프로젝트는 SW마에스트로 1기 2단계 과정을 통해 진행하였습니다.


--


소프트웨어 테스팅은 소프트웨어 산업뿐만 아니라 전반적인 IT산업나아가 첨단 산업 전반에 걸쳐 영향을 미치고 있다.


<그림 1. 시스템 또는 제품의 결함에 의한 피해>


과거 오라클의 DBMS인 11g가 프로그래밍 실수로 보안취약성을 드러낸 적이 있다. 간단한 프로그래밍 실수로 인해 발생한 보안 취약점이지만, 프로그램을 수정하고 다시 재배포하기까지는 엄청난 비용이 발생하는 것은 당연한 수순. 이런 실수는 비용 발생에 그치는 것이 아니라 오라클이라는 글로벌 소프트웨어 업체의 위상에도 심각한 타격을 주는 것이다.


“오류 없는 소프트웨어 없다”는 개발 내 격언처럼 오류 없는 완벽한 소프트웨어는 한 번도 출시되지 않았으며, 이를 개발할 수 있는 개발자 또한 현재까지 존재하지 않는다. 이 때문에 소프트웨어의 오류를 발견하고 이를 수정하기 위해서는 또 다른 작업이 필요한데, 이것이 바로 소프트웨어 테스팅이며, 이는 소프트웨어 개발 과정 상 필수적인 요소다.


또한 그간 소프트웨어 제품들은 전통적인 소프트웨어 영역에서는 오류가 발생해도 사용자의 이해와 함께 빠른 패치를 통해 커버할 수 있었지만, 최근 첨단 산업 군에서 소프트웨어 비중이 높아짐에 따라 소프트웨어 오류는 커다란 나제로 부각됐다.


미션 크리티컬한 기업용 애플리케이션이나 휴대폰, 자동차, 항공기, 가전제품 내부에서 오류가 발생하면 기업 업무가 마비되거나 대규모 리콜사태, 심지어는 항공기 추락과 같은 엄청난 사건이 발생할 수도 있다. 가전제품이나 휴대폰 자동차의 대규모 리콜 사례의 원인을 분석해보면 내장된 소프트웨어 문제가 대다수였다는 점은 이제 잘 알려진 사실이다.


자동차의 신형 모델에는 80개 이상의 CPU가 탑재되고, 수없이 많은 소프트웨어가 내장돼 자동차를 제어하고 고급 기능을 수행한다. 최근 자동차 리콜의 경우 많은 원인이 소프트웨어 결함으로 판명됨에 따라 소프트웨어의 품질 향상에 심혈을 기울이고 있고 그 핵심에는 소프트웨어 테스팅이 자리하고 있다.


이렇게 판매 이후에 발생하는 문제 외에도 소프트웨어의 오류는 제품 출시 시기까지 영향을 미치고 있다. 그래서 기존에는 제품 양산 직전에 테스트가 이뤄지는 것이 대부분이었는데, 그런 테스트만으로는 소프트웨어가 가질 수 있는 문제점을 커버할 수 없다는 인식이 생기게 됐고, 소프트웨어 개발 프로세스 과정에서부터 개발이 끝난 제품의 소프트웨어까지 오류를 사전에 진단하고 정상 작동 여부를 시험하는 전사적인 테스팅의 중요성이 점점 부각되고 있다.



<그림 2. 오류에 따른 수정 비용>



<그림 3.결함의 이해>


[그림. 2]는 소프트웨어 개발 과정에서 결함을 바로 잡는 데 드는 비용이 단계가 빠를수록 적게 든다는 점을 잘 나타내 주고 있다. 이와 함께 [그림. 3] 은 소프트웨어 주요 결함 중 대다수는 요구사항 정의와 설계 단계에서 발생하지만, 이런 결함을 발견하는 것은 사용자 인수 테스트 단계에서 발견하게 됨으로써 시간과 비용 측면에서 많은 누수현상이 생김을 알 수 있다. 


* 소프트웨어 개발 수명 주기에 따른 테스팅 이론은 다음 링크를 참조한다.




<그림 4. 소프트웨어 테스팅 수명 주기>


[그림. 4] 과 같이 기존의 테스트 개념이 테스트 수행이라는 수면 위로 드러난 빙산의 일부분 이였다면, 테스트 계획과 제어, 분석과 설계, 평가와 마감 등과 같은 수행 이전 단계와 이후 단계는 수면 밑에 보이지 않는 거대한 부분이라고 할 수 있다.


즉, 소프트웨어 오류를 찾아내는 것이 테스팅의 목적이라면, 좀 더 적은 비용으로 오류를 찾아내기 위해 테스트 수행 이전 단계에서부터 테스팅의 범주에서 진행해 프로젝트 수행 이후까지 포함 한다는 결론에 이르게 되었고, 이런 개념의 확장은 테스팅 업계가 마케팅 차원에서 확장시킨 것이 아니라 고객들의 필요성과 수요에 따라 확장된 것이라 할 수 있다.


완벽한 제품이나 소프트웨어를 만들기 위해서는 모든 부분을 철저하게 테스트하고 관리하면 되지만, 지금까지 오류 없는 완벽한 소프트웨어는 한 번도 출시되지 않았으며, 이는 현실적으로 유한한 리소스(시간, 비용)를 가지고 제품 또는 소프트웨어의 모든 부분을 테스트하는 것은 불가능하다는 것을 의미한다.


그래서 소프트웨어 테스팅의 주요 방법론으로서 리스크 기반 테스팅(Risk Based Testing) 을 꼽을 수 있다. 리스크는 테스팅을 시작하는 시점을 결정하고, 더 강력하고 깊이 있게 테스트할 부분을 결정하기 위해 사용될 수 있으며, 리스크 제어 활동으로 프로젝트 초기 단계부터 리스크에 미리 대처할 수 있게해 제품의 리스크 수준을 줄여나갈 수 있다.


* 리스크 기반 테스팅 기법은 다음 링크를 참조한다. - http://lyb1495.tistory.com/102


그럼 리스크는 과연 무엇인가? 리스크에 대한 정의는 다음과 같다.


  • P(f) 어떤 기능에서 결함의 발생 가능성을 의미하는 Likelehood로 표현된다.
  • C(f)는 결함이 발생되었을때 비즈니스에 끼치는 영향도를 의마하는 Impact로 표현된다.
  • 그리고 리스크는 이들 두가지 요소의 곱으로 최종 산출된다.

<그림 5. 리스크의 정의>



리스크 기반 테스팅의 전반적은 흐름은 다음과 같다.


<그림 6. 리스크 기반 테스팅 프로세스>


즉, ITAMS(Integrated Testing Asset Management System)
는 리스크 기반 테스팅 기법에 근거해 요구사항, 리스크 데이터, 테스트케이스 등 테스팅 자산을 전사적으로 관리해주며, 프로젝트의 리스크가 무엇이고 그것들의 우선순위를 식별하도록 돕는 솔루션이다.

  • 요구사항, 테스트케이스, 결과 등 테스팅 자산관리 시스템
  • ISO/IEC 29119 및 TMMi 에서 제안하는 프로세스를 구현하기 위해 구체적인 리스크 기반 테스팅을 제공
  • 리스크와 결함 분석을 통한 의사결정 지원 데이터 제공
  • UI와 데이터를 가장 효율적으로 분리할 수 있는 최신의 소프트웨어 아키텍처 적용
  • 요구사항에 대한 Traceability 제공
  • 모바일 디바이스 지원


ITAMS의 주요 구동 화면은 다음과 같다.


<그림 7. 리스크 분석>


[그림. 7]은 정해진 내부 이해 관계자가 개인적으로 리스크를 분석하고 평가하기 위한 화면이다.


모든 이해 관계자가 개인별 리스크 평가를 완료하였다면, 정해진 이해 관계자가 모여 리스크 평가 결과를 공유하고 협의를 이끌어 낸다. 이해관계자는 서로 다른 시각을 지니고 있으므로 동일한 리스크에 대해 리스크 평가 결과가 다른 경우가 훨씬 많다.


<그림 8. 리스크 데이터 시각화>


[그림. 8]은 분석된 리스크들의 커버리지 챠트 및 리스크 매트릭스이다. 


커버리지 챠트에서는 프로젝트의 리스크와 각 리스크에 할당된 리소스를 분석할 수 있다. 리스크가 높은 영역에는 상대적으로 많은 리소스(TC, 고급인력, 시간 등)가 할당 되어야 한다. 이와 같은 차트를 통해 리소스가 많이 투입되어야 하는 영역에 리소스가 올바르게 할당 되었는지, 낭비되고 있는 리소스가 존재하는지 확인할 수 있다.


일반적으로 테스팅은 제한된 시간과 자원을 가지고 수행되기 때문에 리스크의 우선순위에 따라 테스팅을 진행해야 효과적인 테스팅을 수행할 수 있다. 리스크 매트릭스는 리스크를 4가지 영역으로 구분하고 각 영역에 위치한 리스크가 무엇인지 확인할 수 있는 차트이다.


  • STA(Servere Test Area) : 가장 강도 높게 테스트 해야 하는 영역
  • ITA(Intensive Test Area) : 테스트 가치가 있음
  • STTA(Strong Test Area) : 테스트 가치고 있고, 테스트를 해야함
  • FTA(Fundamental Test Area) : 테스트할 수 있음


<그림 9. 결함 S커브>


[그림. 9]는 결합의 분포비율과 처리상태, 결함 S커브를 확인할 수 있는 화면이다.


결함 S커브는 프로젝트의 개발 기간 동안 발견 된 결함의 개수와 해결된 결함의 관계를 나타내는 그래프이다. 전형적인 결함 추이 그래프는 S곡선을 그리게 되는데 이는 프로젝트가 막바지에 이르게 될수록 발견되는 결함의 개수는 적어지고 해결되는 결함의 개수가 많아져 프로젝트의 종료 시점에는 남은 결함의 개수와 해결된 결함의 개수가 일치하게 되는 것을 의미한다.  


<그림 10. 리스크 매트릭스 구분에 따른 결함 S커브>


[그림. 10]는 결함 S커브를 리스크 매트릭스의 영역별로 확인할 수 있는 화면이다.


의사결정자는 위와 같은 데이터를 통해 제품 출시 일정에 대한 계획을 할 수 있다. 예를 들어 심각한 결함을 의마하는 STA영역에서 결함이 지속적으로 발견되고 있고, 결함 해결 추이가 지연되고 있다면 당연히 제품 출시를 미룰수 밖에 없을 것이다.


<그림 11요구사항에 대한 Traceability>


[그림. 11]은 프로젝트 요구사항에 대한 리스크 아이템, 테스트슈트, 테스트 케이스, 결함 등에 대한 연관 정보를 나타낸다.



<그림 12전체적인 화면 구성>


소프트웨어 테스팅이 소프트웨어 품질관리 있어서 필수 조건이라는 점을 인식하면서도 제대로 테스팅을 하지 않는다는 것은 자사의 제품 품질에 관심은 있지만, 향상시키지는 않겠다는 것과 마찬가지다. 글로벌 경쟁 시대에 접어들면서 품질에 대한 중요성이 나날이 증대되고 있으며, 각 산업에서의 시장 상황 또한 이를 반영해 준다.


소비자들은 이미 품질에 대해 눈을 뜨기 시작했으며, 인터넷을 통해 이런 정보를 실시간으로 공유해가고 있다. 단적인 예로, 온라인 게임의 경우 클로즈베타를 할 경우 예전엔 각종 오류나 미완성 부분에 대해 많이 격려하고 완성도를 높이기 위해 소비자들이 적극적으로 참여했지만, 현재는 유료화 단계의 서비스 품질이 아니면 시장에서 살아남을 수 없다.


 소프트웨어 테스팅 업계 관계자는 “그렇다고 무작정 소프트웨어 품질을 턱없이 고도화하자는 주장이 아니며, 제품 출시 때 자사가 필요한 소프트웨어 품질 수준만큼의 시간과 비용을 투자하라는 것”이라고 설명했다. 소프트웨어 품질은 테스팅에 소요된 시간과 비용만큼 비례하는 경향이 있지만, 어느 수준에 이르게 되면 더 이상 올라가지 않는 한계가 있다.


 STA의 권원일 대표는 “업계에서 테스팅에 관심 있는 개발자와 테스트 엔지니어 등을 대상으로 교육을 진행하다 보면 수강자들이 테스팅에 대해 너무 단편적으로 알고 있다는 것에 놀라곤 한다”고 전했다. “테스팅의 가장 중요한 개념인 테스트 커버리지(Test Coverage)에 대한 개념을 제대로 이래하고 사용하는 이는 거의 없고, 그나마 알고 있는 테스팅 개념과 기법들을 적용하고 있는 경우는 더 찾아보기 힘들다”고 토로했다.


ITAMS와 같은 솔루션을 통해 ISO/IEC 29119와 같은 테스팅 국제 표준을 국내에 소개하고, 나아가 SO/IEC 29119에 기반하고 Risk Based Testing 기법을 지원하는 통합 테스팅 솔루션으로 자리 잡아 소프트웨어는 물론 자동차, 항공기, 의료 등과 같은 첨단 산업분야에서도 고객과 성공하는 프로젝트를 만들어가는 것을 기대한다.



* 프로젝트에 도움을 주신분들









'프로젝트 > ITAMS' 카테고리의 다른 글

프로젝트 개요  (0) 2013.03.26
리스크와 테스팅  (0) 2013.03.26
소프트웨어 수명주기와 테스트 레벨  (0) 2013.03.26
소프트웨어 수명주기와 테스팅  (0) 2013.03.26
Posted by devop

댓글을 달아 주세요

프로젝트/ITAMS2013. 3. 26. 01:43

1. 테스팅에서의 리스크


제한된 시간과 자원의 한계를 극복하기 위해서는 리스크를 고려해야 한다.


리스크(Risk) = 장애(Failure) 가능성 * 손실(Damage)

장애 가능성 = 사용빈도 * 결함 가능성 


1.1. 리스크 분류


1.1.1. 프로젝트 리스크 - 프로젝트 목적을 달성하기 위한 프로젝트의 역량 전반과 관계하는 리스크

  • 조직적인 요소기술적 이슈

  • 공급자 이슈

  • 프로덕트 리스크


1.1.2. 프로덕트 리스크

  • SW나 시스템에 의도치 않은 향후 이벤트나 위험 요소가 존재하는 잠재적인 장야 영역을 말함

  • 제품의 품질에 대한 리스크



 


2. 리스크 기반 테스팅


2.1. 절차


리스크 식별 -> 리스크 분석 -> 리스크 계획 -> 리스크 추적

 

2.2. 리스크 식별


무엇이 리스크이고 어디에 리스크가 있는지 확인


  • 기능적/기술적 아이템으로 분리

  • 요구사항에 따른 상위레벨 테스트 관련 항목

  • 아키텍처에 따른 하위레벨 테스트 관련 항목

  • 브레인스토밍 세션 이용 가능

  • 35개 이하의 리스크 아이템 식별 권장


2.3. 리스크 분석


중요하고, 복잡하고 잠재적으로 결함이 많은 부분을 분석(리스크 우선순위 결정)


2.3.1. 장애발성 가능성(Likelihood)

  • 복잡성

  • 새로운 개발의 정도

  • 상호관계

  • 크기

  • 사용된 기술의 난이도/최신성

  • 개발팀의 경험 미흡


2.3.2. 장애로 인한 영향(Impact)

  • 사용자에 의한 취급 중요도(잘 팔리는 아이템)

  • 경제적, 사회적, 회사 이미지적 피해

  • 사용강도

  • 외부적 가시성

 

제품의 리스크 요소에 해당하는 리스크 아이템 각각에 대해 리스크 수준을 표현한다.

<리스크 테이블 예시>


2.3.3. 리스크 매트릭스

  • STA(Servere Test Area) : 가장 강도 높게 테스트 해야 하는 영역

  • ITA(Intensive Test Area) : 테스트 가치가 있음

  • STTA(Strong Test Area) : 테스트 가치고 있고, 테스트를 해야함

  • FTA(Fundamental Test Area) : 테스트할 수 있음


<리스크 매트릭스 예시>


2.4. 리스크 계획

리스크 정보를 근거로 대처 방안 수립(리스크 줄이는 테스트 생성)

리스크의 강도에 따라 인력배치, 테스트 설계 기법, 리포팅, 리뷰, 테스팅에 필요한 요소들을 차별화 시켜 테스트를 수행한다.


2.4.1. 하위 레벨 테스팅

  • 기술적 리스크에 집중

  • 우선순위 : STA -> ITA -> STTA -> FTA


2.4.2. 상위 레벨 테스팅

  • 사업적 리스크에 집중

  • 우선순위 : STA -> STTA -> ITA -> FTA


2.5. 리스크 추적

리스크 및 리스크에 대한 대응을 모니터링.

  • 리스크가 높은 곳 -> 테스트케이스 수가 많음

  • 리스크가 낮은 곳 -> 테스트케이스 수가 적음


<리스크 커버리지 예시. 리스크 기반 테스팅 전략이 최적으로 구현되지 않음.>


'프로젝트 > ITAMS' 카테고리의 다른 글

프로젝트 개요  (0) 2013.03.26
리스크와 테스팅  (0) 2013.03.26
소프트웨어 수명주기와 테스트 레벨  (0) 2013.03.26
소프트웨어 수명주기와 테스팅  (0) 2013.03.26
Posted by devop

댓글을 달아 주세요

프로젝트/ITAMS2013. 3. 26. 01:26

1. 테스트 레벨


한 번에 총체적으로 조직화 하고 관리하는 테스트 활동의 묶음(단위 테스트, 시스템 테스트, 통합 테스트, 인수 테스틍 등.)


1.1. 특징

  • 독립적 계획 활동

  • 독립적인 테스트 설계, 실행, 완료 및 리포팅 마감 활동

  • 독립적 테스트 팀, 독립적 환경


각 테스트 레벨의 일반적인 목표(목적) 존재

테스트 케이스를 도출해 내는데 참조되는 개발 입력산출물(테스트베이시스)

테스트 대상

발견된 전형적인 결함과 장애

테스트 하네스(드라이버) 필요 여부와 툴 지원의 필요성

특정한 테스트 접근법과 담당 책임 

<각 테스트 레벨에서 독립적으로 식별 가능한 내용>






2. 단위 or 컴포넌트 테스팅


소프트웨어의 각각의 단위를 다른 부분과 연계되는 부분은 고려하지 않고 단위 자체에만 집중하여 테스트

개발자가 원시코드를 가지고 테스트 함.


2.1. 단위(컴포넌트) 테스팅의 목적

  • 기본적인 패스를 확인

  • 모든 에러 핸들링 패스를 확인

  • 모듈 인터페이스 확인

  • 로컬 데이터 확인, 경계값 확인



2.2. 단위 테스트 기법과 완료 조건


기법

  • Control flow 테스트

  • Condition decision 커버리지 테스트

  • 등가분할 & 경계값 입력 테스트


완료 조건 - 통합테스트 책임자가 테스트로의 시작 조건을 만족시켰다고 판단하는 경우






3. 통합 테스트


시스템이나 시스템 구성요소 또는 소프트웨어 프로그램의 데이터 및 기능의 인터페이스(흐름)가 정상적으로 작동하는지에 중점을 두고 수행하는 테스트.

단위 테스트를 통과한 개발 소프트웨어/하드웨어 컴포넌트간 인터페이스 및 연동 기능 등을 구조적으로 접근하여 테스트 한다.

 

3.1. 통합 테스팅 접근법


결합을 격리 시키기 위해 다양한 통합 테스팅 접근법이 존재


  • 빅뱅 통합 - 모든 모듈을 한번에 통합결합 격리 어려움
  • 상향식 통합 - DBMSOS등과 직접적으로 인터랙션하는 하위 모델을 먼저 개발 통합
  • 하향식 통합 - 비즈니스에 가까운 모듈부터 하위 모델로 통합
  • 백본 통합 - 소프트웨어 리스크가 높은 것을 우선적으로 통합 접근







4. 시스템 테스트


  • 실제환경과 가능한 유사한 환경에서 진행.

  • 개발 조직과는 독립된 테스트 조직에서 수행함.

  • 단위/통합 테스트가 가능한 완벽히 완료되어 기능상에 문제가 없는 상태여야 함.

  • 시스템 성능과 관련된 요구사항이 완벽하게 수행되는지를 테스트하기 때문에 사전 요구사항이 명확해야 함.

 

4.1. 시스템 테스팅의 테스트 베이시스


  • 요구사항 명세서

  • 리스크 분석 결과

  • 비즈니스 절차

  • 유즈케이스

  • 상위레벨의 시스템 동작 기록 문서

  • OS, 시스템 리소스와의 상호작용

 

4.2. 기능적 요구사항과 비기능적 요구사항 테스트


  • 기능적 요구사항 테스트 - 명세기반 기반

  • 비기능적 요구사항 테스트 - 구조기반 기법. 성능사용성신뢰성이식성 테스트 등





5. 인수 테스트


테스팅 환경 자체가 사용자 환경으로 바뀌고 수행하는 주체가 사용자이다.

인수 테스팅은 일반적인 테스트 레벨의 가장 마지막 상위 레벨로, SW 제품에 대한 요구사항이 제대로 이행되었는지 확인.

 

5.1. 인수 테스팅의 목적


  • 제품에 대한 확신
  • 배포 또는 실제 사용할 준비가 되었는지 평가
  • 최종 단계의 테스팅이 아닐 수 있음(인수 테스트 후 대규모 시스템 통합 테스트 실행 가능)

 

5.2. 인수 테스팅의 형태


  • 사용자 인수 테스팅
  • 운영상의 인수 테스팅
  • 계약 인수 테스팅과 규정 인수 테스팅
  • 알바 테스팅 & 베타(필드) 테스팅



'프로젝트 > ITAMS' 카테고리의 다른 글

프로젝트 개요  (0) 2013.03.26
리스크와 테스팅  (0) 2013.03.26
소프트웨어 수명주기와 테스트 레벨  (0) 2013.03.26
소프트웨어 수명주기와 테스팅  (0) 2013.03.26
Posted by devop

댓글을 달아 주세요

프로젝트/ITAMS2013. 3. 26. 01:05

1. V모델(순차적 개발 모델)


waterfall 개발 프로세스 모델(요구사항 분석 -> 설계 -> 코딩 -> 테스팅이 순차적으로 독립적으로 수행)을 기반으로 만들어졌으며 여러 테스팅 관련 컨셉을 함께 보여주는 모델로 폭포수 모델과 마찬가지로 요구사항 분석 -> 설계 -> 코딩 -> 테스팅이라는 일련의 단계를 통해 소프트웨어를 개발하는 모델.


또한 개발 각 단계에 대응하는 테스트 레벨이 존재하여 개발활동과 테스트 활동이 밀접하게 연계되있음을 보여준다.



1.1. 조기 테스팅(Early Testing)


* 개발 시작과 동시에 테스트를 수행하는 것 -> 결함을 예방할 수 있다.

* 명세서만 있어도 테스트를 설계하고 테스트 케이스를 도출할 수 있다.


한계점 : 조기 테스트 설계 적용 시에 요구사항이 자주 변경되면 V모델을 적용하는데 큰 한계가 있음.

(변경된 요구사항은 다른 단계 활동들에 큰 영향을 미치기 때문이다.)


대처법 : 리스크가 자장 높은 부분을 중점적으로 테스트 케이스로 변환한다.

(향후에 테스트 케이스 재작업을 줄일 수 있고, 요구사항이 변경되더라도 리스크가 높은 부분을 테스트 케이스로 만들면서 검증하는 과정을 거치는 것은 의미가 크다.


1.2. V모델의 장점


* 각각의 요구사항 분석서를 보고 테스트 케이스를 만들어 요구사항의 결함을 미리 발견하여 예방할 수 있다.

* 개발 초기에 있을 수 있는 결함을 줄여 개발기간도 줄이고 제품의 완성도를 높임






2. 반복적 - 점진적 개발 모델


점진적으로 효과적인 결과물을 산출하기 위해 일련의 활동을 반복적으로 적용하려는 개발 스타일. 최근에는 XP, Scrum 등 애자일 개발 방법론이 상당히 회자되고 있으며 적용 사례를 급속히 늘려가고 있다.


2.1. waterfall 개발 VS Iterative 개발 프로세스


waterfall 개발 프로세스 장단점


  • 단순한 형태의 개발 수명 주기
  • 결과물로 수행 전까지 문서만 존재
  • 리스크를 프로젝트 중간 이후의 코딩 단계까지 가지고 감
  • 개발 프로젝트 예측이 어려움




Iterative 개발 프로세스 장단점


  • 각 Iteration별 실제 개발 결과물 존재
  • 리스크를 개발 앞 단에서 처리
  • 개발 프로젝트 예측이 용이
  • 개발 과정이 폭포수 개발에 비해 복잡함



2.2. Iterative 개발 프로세스에 대한 테스팅 이슈


  • 반복 과정에 의해 생성된 결과 시스템은 여러 테스트 레벨에서 개발과정의 일부로 테스트
  • 증분 산출물 테스트 & 부분 시스템 테스트
  • 리그레이션 테스팅이 점차적으로 중요해짐 -> TDD테스트
  • 테스트 대상은 다수개로 증가하고, 테스트 환경의 변화로 유즈케이스 간의 활동 테스팅이 요구됨
  • 반복주기에 작은 V모델이 존재

'프로젝트 > ITAMS' 카테고리의 다른 글

프로젝트 개요  (0) 2013.03.26
리스크와 테스팅  (0) 2013.03.26
소프트웨어 수명주기와 테스트 레벨  (0) 2013.03.26
소프트웨어 수명주기와 테스팅  (0) 2013.03.26
Posted by devop

댓글을 달아 주세요