원문 : http://blog.naver.com/josephy74/70018639453
문제가 될 경우 바로 연락주세요. 바로 삭제하겠습니다.
5. Test Management (K3)
5.1 Test organization (K2)
5.1.1 테스팅 조직과 독립성 (K2)
테스팅과 리뷰에 의하여 결함(defect)를 발견하는 효과는 독립적인 테스터를 이용하여 향상시킬 수 있다. 독립의 조건은 다음과 같다.
▪ 개발 팀들 내의 독립적인 테스터들
▪ 프로젝트 관리나 경영진에 보고하는 조직 내의 독립적인 테스트 팀이나 테스트 그룹
▪ 업무 조직, 사용자 커뮤니티, 그리고 IT로 부터 독립적인 테스터들
▪ 사용성 테스터, 보안 테스터, 또는 (표준과 규약에 대하여 소프트웨어 제품을 인증하는) 인증 테스터들과 같이 특정 테스트 목적을 위한 독립적인 테스트 전문가
▪ 조직의 외부 또는 아웃소싱된 독립적인 테스터들
▪ 프로젝트 관리나 경영진에 보고하는 조직 내의 독립적인 테스트 팀이나 테스트 그룹
▪ 업무 조직, 사용자 커뮤니티, 그리고 IT로 부터 독립적인 테스터들
▪ 사용성 테스터, 보안 테스터, 또는 (표준과 규약에 대하여 소프트웨어 제품을 인증하는) 인증 테스터들과 같이 특정 테스트 목적을 위한 독립적인 테스트 전문가
▪ 조직의 외부 또는 아웃소싱된 독립적인 테스터들
일반적으로 규모가 크고, 복잡하거나 안전에 민감한 프로젝트를 위해서는, 독자적인 테스터들에 의한 다양한 테스트 레벨을 갖는 것이 최선이다. 개발 스텝은 특별히 낮은 레벨에서의 테스팅에 참가할 수 있다. 그러나 그들의 객관성의 결여는 때때로 그들의 효과를 제한한다. 독립적인 테스터들은 테스트 프로세스와 규칙을 요구하고 정의할 수 있는 권한을 가질 수 있지만, 이 프로세스 관련 규칙은 단지 관리자 명령이 있을때에만 주어질 수 있다.
독립의 장점은 다음을 포함한다.
▪ 독립적인 테스터들은 다른 여러가지 결함을 찾으며, 편향되지 않는다.
▪ 독립적인 테스터는 명세와 시스템의 구현 동안에 사람들이 만들어 놓은 가정들을 검증할 수 있다.
▪ 독립적인 테스터는 명세와 시스템의 구현 동안에 사람들이 만들어 놓은 가정들을 검증할 수 있다.
약점은 다음을 포함한다.
▪ 개발팀으로부터 고립된다. (완전히 독립적으로 다루어진다면)
▪ 독립적인 테스터들은 최적 체크 포인트로써 병목지점이 될 수 있다.
▪ 개발자들은 품질에 대한 책임감을 잃어 버린다.
▪ 독립적인 테스터들은 최적 체크 포인트로써 병목지점이 될 수 있다.
▪ 개발자들은 품질에 대한 책임감을 잃어 버린다.
테스팅 작업은 특정 테스팅 역할을 담당하는 사람에 의하여 행하여 질 수도 있고, 프로젝트 매니저, 품질 관리자, 개발자, 비지니스와 도메인 전문가, 인프라 스트럭쳐 운영자 또는 IT 운영자와 같은 다른 역할의 누군가에 의하여 행하여 질 수도 있다.
5.1.2 테스트 리더와 테스터의 임무
이 요약서에서는 테스트 리더(test leader)와 테스터의 두 개의 테스트 역할에 대하여 다룬다. 이러한 두 역할을 담당하는 사람들에 의하여 수행되는 액티비티와 작업은 프로젝트와 제품 내용, 역할(roles)내의 사람들과 조직에 따라 다르다.
때때로 테스트 리더는 테스트 매니저(test manager) 또는 테스트 코디네이터(test coordinator)로 불린다. 테스트 리더의 역할은 프로젝트 매니저, 개발 관리자, 품질 보증 관리자 또는 테스트 그룹의 관리자에 의하여 수행될 수 이 있다. 규모가 큰 프로젝트에서는 테스트 리더와 테스트 매니저, 두 가지의 역할이 존재할 수 있다. 일반적으로 테스트 리더는 섹션 1.4에서 정의된 것 같이 테스팅 액티비티와 작업을 계획 및 모니터하고 통제한다.
일반적인 테스터 리더의 임무(tasks)는 다음을 포함한다.
▪ 테스트 전략과 계획을 프로젝트 매니저와 다른 사람들과 함께 기획한다.
▪ 프로젝트에 대한 테스트 전략과 조직에 대한 테스트 정책을 작성하고 리뷰한다.
▪ 통합 계획과 같은, 다른 프로젝트 액티비티에 대하여 테스팅 측면에서 이바지한다.
▪ 테스트의 수행 방법 선택, 테스팅의 시간, 노력 그리고 비용의 평가, 자원의 획득, 테스트 레벨, 주기, 방법 그리고 목표의 정의와 부가 사항 관리 계획을 포함하여 - 테스트 내용과 예상되는 위험을 고려하여 테스트 계획을 세운다.
▪ 테스트의 명세, 준비, 구현과 실행을 초기화하고, 실행을 모니터, 통제한다.
▪ 테스트 결과와 진행에 기반한 계획을 적용하고 (때때로 상태 보고서로 문서화된다.), 문제를 보완하기 위하여 필요한 모든 행동을 취한다.
▪ 추적성을 위하여 테스트웨어(testware)의 적절한 환경 관리사항을 설정한다.
▪ 테스트 프로세스 측정을 위한 적당한 특성(metrics)을 소개하고 제품과 테스팅의 품질을 평가 한다.
▪ 무엇이 어느 정도로 어떻게 자동화 될 것인지를 결정한다.
▪ 테스트 지원 도구를 선택하고 테스터의 도구 사용에 대한 모든 훈련을 구성한다.
▪ 테스트 환경의 구현에 대한 결정을 한다.
▪ 테스트 일정을 잡는다.
▪ 테스팅 동안에 수집된 정보에 기반한 테스트 요약 보고서를 작성한다.
▪ 프로젝트에 대한 테스트 전략과 조직에 대한 테스트 정책을 작성하고 리뷰한다.
▪ 통합 계획과 같은, 다른 프로젝트 액티비티에 대하여 테스팅 측면에서 이바지한다.
▪ 테스트의 수행 방법 선택, 테스팅의 시간, 노력 그리고 비용의 평가, 자원의 획득, 테스트 레벨, 주기, 방법 그리고 목표의 정의와 부가 사항 관리 계획을 포함하여 - 테스트 내용과 예상되는 위험을 고려하여 테스트 계획을 세운다.
▪ 테스트의 명세, 준비, 구현과 실행을 초기화하고, 실행을 모니터, 통제한다.
▪ 테스트 결과와 진행에 기반한 계획을 적용하고 (때때로 상태 보고서로 문서화된다.), 문제를 보완하기 위하여 필요한 모든 행동을 취한다.
▪ 추적성을 위하여 테스트웨어(testware)의 적절한 환경 관리사항을 설정한다.
▪ 테스트 프로세스 측정을 위한 적당한 특성(metrics)을 소개하고 제품과 테스팅의 품질을 평가 한다.
▪ 무엇이 어느 정도로 어떻게 자동화 될 것인지를 결정한다.
▪ 테스트 지원 도구를 선택하고 테스터의 도구 사용에 대한 모든 훈련을 구성한다.
▪ 테스트 환경의 구현에 대한 결정을 한다.
▪ 테스트 일정을 잡는다.
▪ 테스팅 동안에 수집된 정보에 기반한 테스트 요약 보고서를 작성한다.
일반적인 테스터의 작업은 다음을 포함한다.
▪ 테스트 계획을 리뷰하고, 기여한다.
▪ 테스트 가능성(testability)를 위하여 사용자 요구사항과 명세, 그리고 모델을 분석하고, 리뷰하고, 평가한다.
▪ 테스트 명세를 생성한다.
▪ 테스트 환경을 설정한다.(때때로 시스템 관리자와 네트웍 관리자와 함께 협의한다.)
▪ 테스트 데이터를 준비하고 획득한다.
▪ 모든 테스트 레벨의 테스트를 구현하고, 테스트를 실행하고 로깅하여, 결과를 평가하고, 예상되는 결과로 부터의 유도사항을 문서화한다.
▪ 요구되는 테스트 관리자, 또는 관리 도구, 그리고 테스트 모니터링 도구를 이용한다.
▪ 테스트를 자동화시킨다. (개발자나 테스트 자동화 전문가에 지원을 받을 수 있다.)
▪ 컴포넌트와 시스템의 성능을 측정한다.(가능하다면)
▪ 다른 사람들에 의하여 개발된 테스트들을 리뷰한다.
▪ 테스트 가능성(testability)를 위하여 사용자 요구사항과 명세, 그리고 모델을 분석하고, 리뷰하고, 평가한다.
▪ 테스트 명세를 생성한다.
▪ 테스트 환경을 설정한다.(때때로 시스템 관리자와 네트웍 관리자와 함께 협의한다.)
▪ 테스트 데이터를 준비하고 획득한다.
▪ 모든 테스트 레벨의 테스트를 구현하고, 테스트를 실행하고 로깅하여, 결과를 평가하고, 예상되는 결과로 부터의 유도사항을 문서화한다.
▪ 요구되는 테스트 관리자, 또는 관리 도구, 그리고 테스트 모니터링 도구를 이용한다.
▪ 테스트를 자동화시킨다. (개발자나 테스트 자동화 전문가에 지원을 받을 수 있다.)
▪ 컴포넌트와 시스템의 성능을 측정한다.(가능하다면)
▪ 다른 사람들에 의하여 개발된 테스트들을 리뷰한다.
테스트 분석, 테스트 디자인, 특정 테스트 종류나 테스트 자동화를 담당하는 사람들은 자신이 맡은 역할 분야에서 전문가일 수 있다. 테스트 레벨, 제품과 프로세스에 관련된 위험에 따라 다양한 사람들이 어느정도의 독립성을 가지며 테스터의 역할을 맡을 수 있다. 일반적으로 컴포넌트와 통합 레벨에서의 테스터는 개발자가 될 것이며, 승인 테스트 단게의 테스터는 비지니스 전문가나 사용자가 될 것이다. 그리고 운영 승인 테스팅에대한 테스터는 운영자가 될 것이다.
5.2 Test planning and estimation
5.2.1 테스트 계획 (Test planning) (K2)
이 장은 개발, 구현 단계에 있는 과제의 테스트 계획 목적과 유지보수 액티비티들에 대해 설명한다. 계획은 프로젝트 계획이나 마스터 테스트 계획(master test plan), 그리고 시스템 테스팅과 승인 테스팅과 같은 각 테스트 레벨에 대한 분리된 테스트 계획으로 문서화 될 수 있다. "소프트웨어 테스트 문서화를 위한 표준"(IEEE829)에서 테스트 계획의 문서화에 대한 개괄적인 내용을 다루고 있다.
계획은 조직의 테스트 정책, 테스팅의 범위, 목표, 위험, 제약사항, 임계치(criticality), 테스트 가능성, 그리고 자원의 가용성(availability)에 영향을 받는다. 프로젝트와 테스트 계획이 더 많이 진행될수록 계획에 포함시킬수 있는 더 많은 정보가 이용가능해지며, 더욱 구체화 된다.
테스트 계획은 계속진행되는 활동이며, 모든 개발 주기 프로세스와 액티비티에서 수행된다. 테스트 액티비티로부터의 피드백은 변경되는 위험을 인식하는데 사용되며, 계획을 조절할 수 있게 한다.
5.2.2 테스트 계획 액티비티 (Test planning activities) (K2)
테스트 계획 액티비티는 다음을 포함할 수 있다.
• 테스트 레벨과 항목 그리고 종료 특성을 포함한 전체적인 테스팅(테스팅 전략)의 접근 방식을 정의한다.
• 소프트웨어 수명 주기 액티비티(software life cycle activities)에 테스팅 액티비티를 통합하고 구성한다. : 취득(acquisition), 공급(supply), 개발(development), 운영(operation), 그리고 유지보수(maintenance)
• 무엇을 테스트 할 것인지, 어떤 역할이 테스트 액티비티를 수행할 것인지, 언제 그리고 어떻게 테스트 액티비티가 행하여 질 것인지, 어떻게 테스트 결과를 평가할 것인지, 그리고 언제 테스트를 종료할 것인지(종료 특성)을 결정한다.
• 여러가지 정의된 작업에 대한 자원을 할당한다.
• 테스트 문서화를 위한 수량, 세부 레벨, 구조와 템플릿을 정의한다.
• 테스트 준비와 실행, 결함(defect)의 해결과 위허, 이슈사항을 모니터링하고 통제하기 위한 특성들을 선택한다.
• 재현 가능한 테스트 준비와 실행을 지원하기 위한 충분한 정보를 제공하기 위한 테스트 프로시져의 세부 레벨을 설정한다.
• 소프트웨어 수명 주기 액티비티(software life cycle activities)에 테스팅 액티비티를 통합하고 구성한다. : 취득(acquisition), 공급(supply), 개발(development), 운영(operation), 그리고 유지보수(maintenance)
• 무엇을 테스트 할 것인지, 어떤 역할이 테스트 액티비티를 수행할 것인지, 언제 그리고 어떻게 테스트 액티비티가 행하여 질 것인지, 어떻게 테스트 결과를 평가할 것인지, 그리고 언제 테스트를 종료할 것인지(종료 특성)을 결정한다.
• 여러가지 정의된 작업에 대한 자원을 할당한다.
• 테스트 문서화를 위한 수량, 세부 레벨, 구조와 템플릿을 정의한다.
• 테스트 준비와 실행, 결함(defect)의 해결과 위허, 이슈사항을 모니터링하고 통제하기 위한 특성들을 선택한다.
• 재현 가능한 테스트 준비와 실행을 지원하기 위한 충분한 정보를 제공하기 위한 테스트 프로시져의 세부 레벨을 설정한다.
5.2.3 종료 특성 (Exit criteria) (K2)
종료 특성(Exit criteria)의 목적은, 한 테스트 레벨이나 마지막이나 테스트 셋이 특정 목표를 달성 했을 때와 같이, 언제 테스팅을 중단 할 것인가를 정의하는 것이다.
일반적인 종료 특성을 구성하는 것은 다음과 같다.
• 코드, 기능 또는 위험의 커버리지와 같은 측정치의 완벽함
• 결점의 조밀도 또는 신뢰성 측정치의 평가
• 비용
• 고쳐지지 않은 결함이나 특정 영역에 대한 테스트 커버리지의 부족과 같이 잔여하는 위험
• 시장 적기 출시(time to market) 같은 것에 기반한 일정
• 결점의 조밀도 또는 신뢰성 측정치의 평가
• 비용
• 고쳐지지 않은 결함이나 특정 영역에 대한 테스트 커버리지의 부족과 같이 잔여하는 위험
• 시장 적기 출시(time to market) 같은 것에 기반한 일정
5.2.4 테스트 평가 Test estimation (K2)
테스트 효과의 측정을 위한 두가지 방법이 이 요약서에서 커버된다.
• 전형적인 값들(typical values)에 기반하거나 유사한 프로젝트 또는 특성의 구성요소(metrics of former)들에 기반한 테스팅 효과의 평가
• 이러한 작업(tasks)의 소유자나 전문가에 의한 작업의 평가(estimating the tasks) 테스트 효과가 평가되면, 자원이 결정될 수 있으며 일정이 조정될 수 있다.
• 이러한 작업(tasks)의 소유자나 전문가에 의한 작업의 평가(estimating the tasks) 테스트 효과가 평가되면, 자원이 결정될 수 있으며 일정이 조정될 수 있다.
테스팅 효과는 다음에 포함되는 여러가지 요소에 의존할 수 있다.
• 제품의 특성(Characteristics of the product) :
명세와 테스트 모델을 위하여 사용되는 다른 정보의 품질, 제품의 크기, 문제 영역의 복잡성, 신뢰성과 보안에 대한 요구사항, 그리고 문서화에 대한 요구사항
• 개발 프로세스의 특성들(Characteristics of the development process):
조직의 안정성, 사용되는 도구, 테스트 프로세스, 포함된 사람들의 기술, 그리고 시간의 압박
• 테스팅의 결과물 (Outcome of testing):
결함의 갯수와 요구되는 재작업의 분량
명세와 테스트 모델을 위하여 사용되는 다른 정보의 품질, 제품의 크기, 문제 영역의 복잡성, 신뢰성과 보안에 대한 요구사항, 그리고 문서화에 대한 요구사항
• 개발 프로세스의 특성들(Characteristics of the development process):
조직의 안정성, 사용되는 도구, 테스트 프로세스, 포함된 사람들의 기술, 그리고 시간의 압박
• 테스팅의 결과물 (Outcome of testing):
결함의 갯수와 요구되는 재작업의 분량
5.2.5 테스트 방법 (테스트 전략) (Test approaches(test strategies)) (K2)
테스트 방법이나 전략을 구분하는 한가지 방법은 다량의 테스트 디자인 작업이 시작되는 시점에 기초로 하는 것이다.
• 예방적인 방법, 테스트가 가능한 빨리 설계되는 경우
• 반응적인 방법, 테스트 디자인이 소프트웨어나 시스템이 생산된 후에 나오는 경우 일반적인 방법이나 전략은 다음을 포함한다.
• 분석적인 방법, 가장 큰 위험 영역으로 부터 유도된 테스팅과 같은 위험 기반 테스팅처럼
• 모델 기반 방법, 실패 비율(신뢰성 향상 모델과 같은)이나 사용량(운영 프로파일)에 대한 통계적인 정보를 사용하는 확률적인 테스팅
• 계통적인 방법, 실패 기반(추측되는 에러와 결함 공격을 포함하는), 체크 리스트 기반, 그리고 품질 특성 기반의
• 프로세스 또는 표준 준수 방법, 산업에 특화된 표준이나 여러가지 기민한 방법론에 의하여 특화된 것 같은
• 동적이고, 발전적인 방법. 테스팅이 미리 계획한 것보다 이벤트에 더욱 반응적이고, 실행과 평가가 동시 작업일 경우, 예비적인 테스팅과 같은
• 회귀-반대 방법, 기존 테스트 자료, 기능적인 회귀 테스팅의 확장된 자동화, 그리고 표준 테스트 슈트를 재사용하는 것을 포함하는 것과 같은
• 반응적인 방법, 테스트 디자인이 소프트웨어나 시스템이 생산된 후에 나오는 경우 일반적인 방법이나 전략은 다음을 포함한다.
• 분석적인 방법, 가장 큰 위험 영역으로 부터 유도된 테스팅과 같은 위험 기반 테스팅처럼
• 모델 기반 방법, 실패 비율(신뢰성 향상 모델과 같은)이나 사용량(운영 프로파일)에 대한 통계적인 정보를 사용하는 확률적인 테스팅
• 계통적인 방법, 실패 기반(추측되는 에러와 결함 공격을 포함하는), 체크 리스트 기반, 그리고 품질 특성 기반의
• 프로세스 또는 표준 준수 방법, 산업에 특화된 표준이나 여러가지 기민한 방법론에 의하여 특화된 것 같은
• 동적이고, 발전적인 방법. 테스팅이 미리 계획한 것보다 이벤트에 더욱 반응적이고, 실행과 평가가 동시 작업일 경우, 예비적인 테스팅과 같은
• 회귀-반대 방법, 기존 테스트 자료, 기능적인 회귀 테스팅의 확장된 자동화, 그리고 표준 테스트 슈트를 재사용하는 것을 포함하는 것과 같은
예를 들어, 위험 기반의 동적 접근 방법과 같이 여러가지 방법들이 조합될 수 있다.
테스트 방법의 선택은 다음을 포함하는 내용이 고려되어야 한다.
• 프로젝트 실패의 위험, 제품에 대한 위험과 사랑, 환경, 회사에 대한 제품 실패의 위험
• 제안된 기술, 도구와 방법에 대한 사람들의 기술과 경험
• 테스팅 노력의 목적과 테스팅 팀의 임무
• 개발 프로세스에 대한 내부적인 규약과 외부적인 규약과 같은 규약 측면
• 제품이나 비지니스의 본질
• 제안된 기술, 도구와 방법에 대한 사람들의 기술과 경험
• 테스팅 노력의 목적과 테스팅 팀의 임무
• 개발 프로세스에 대한 내부적인 규약과 외부적인 규약과 같은 규약 측면
• 제품이나 비지니스의 본질
============================================================================
◆ Pre-Test
▪ Testability 평가
- 완결성(Completness) - 테스트에 필요한 모든 것이 다 있는가?
- 주요 기능성(Primary functionality) 주요 기능이 잘 동작하는가?
▪ Pre-test 대상
- 테스트 대상 (object) : SW, HW, Prototype, etc
- 테스트 인프라 : 입력값 생성기, 출력값 분석기, 시뮬레이터, 테스트 장비, 등
- 완결성(Completness) - 테스트에 필요한 모든 것이 다 있는가?
- 주요 기능성(Primary functionality) 주요 기능이 잘 동작하는가?
▪ Pre-test 대상
- 테스트 대상 (object) : SW, HW, Prototype, etc
- 테스트 인프라 : 입력값 생성기, 출력값 분석기, 시뮬레이터, 테스트 장비, 등
◆ 테스트 결과 분석(Test Result Analysis)
▪ 실제 테스트 결과와 예상 결과와 비교
▪ 비교 결과의 차이점이 생긴 원인 분석
1. 테스트 (케이스) 결함
- 테스트 실패가 어플리케이션 결함이 아닌 테스트 케이스 자체에 결함이 있는 경우
- 스크립트, 시나리오, 수행상의 오류, 잘못된 테스트 데이터 또는 입력 오류
2. Application 결함
- Documentation (Specification) 결함, SW결함, HW결함, Procedure결함,
▪ 비교 결과의 차이점이 생긴 원인 분석
1. 테스트 (케이스) 결함
- 테스트 실패가 어플리케이션 결함이 아닌 테스트 케이스 자체에 결함이 있는 경우
- 스크립트, 시나리오, 수행상의 오류, 잘못된 테스트 데이터 또는 입력 오류
2. Application 결함
- Documentation (Specification) 결함, SW결함, HW결함, Procedure결함,
Installation 결함
3. Application context error
- User Error
- 테스트 환경과 관련된 SW 에러(OS, DBMS)
3. Application context error
- User Error
- 테스트 환경과 관련된 SW 에러(OS, DBMS)
5.3. Test progress monitoring and control
5.3.1 테스트 진행사항 모니터링 (K1)
테스트 모니터링의 목적은 테스트 액티비티에 대한 피드백과 가시성을 주는 것이다. 모니터되어야하는 정보는 수동이나 자동으로 수집될 수 있으며, 커버리지와 같은 종료 특성을 측정하기 위하여 사용될 수 있다. 또한 특성(metrics)들은 계획된 일정과 예산에 대한 진행상황을 평가하기 위하여 사용된다. 일반적인 테스트 특성(metrics)은 다음을 포함한다.
• 테스트 케이스 준비에서 작업된 퍼센티지(또는 준비된 테스트 케이스의 준비된 퍼센티지)
• 테스트 환경 준비에서 작업된 퍼센티지
• 테스트 케이스 실행(e.g 수행된/수행되지 않은 테스트 케이스의 숫자, 패스된/실패된 테스트 케이스의 숫자)
• 결함 정보(e.g 결함 조밀도, 발견된 결함과 고쳐진 결함, 실패 비율, 재테스트 결과)
• 요구사항, 위험 또는 코드의 테스트 커버리지
• 제품에 대한 테스터의 주된 확신
• 테스트 마일스톤의 일정
• 테스트 비용, 다음 결함을 발견하는 혜택이나 다음 테스트를 실행하는 비용을 포함하는,
• 테스트 환경 준비에서 작업된 퍼센티지
• 테스트 케이스 실행(e.g 수행된/수행되지 않은 테스트 케이스의 숫자, 패스된/실패된 테스트 케이스의 숫자)
• 결함 정보(e.g 결함 조밀도, 발견된 결함과 고쳐진 결함, 실패 비율, 재테스트 결과)
• 요구사항, 위험 또는 코드의 테스트 커버리지
• 제품에 대한 테스터의 주된 확신
• 테스트 마일스톤의 일정
• 테스트 비용, 다음 결함을 발견하는 혜택이나 다음 테스트를 실행하는 비용을 포함하는,
5.3.2 테스트 보고 (K2)
테스트 보고는 다음을 포함하는 테스팅 결과에 대한 정보를 요약하는 것에 관심을 갖는다.
• 언제 종료 특성을 만족했는가와 같은 테스팅 기간 동안에 무슨일이 있어났는가?
• 미래의 액션에 대한 충고와 결정을 지원하기 위한 남겨진 결함의 평가, 연속된 테스팅의
• 미래의 액션에 대한 충고와 결정을 지원하기 위한 남겨진 결함의 평가, 연속된 테스팅의
경제적인 혜택, 눈에 띄는 위험, 그리고 테스트 된 소프트웨어에 대한 확신의 레벨과 같은 분석된 정보와 특성들
특성들은 테스팅 동안에 수집되어야 하고, 테스트 마지막에 평가하기 위하여 수집되어야 한다.
• 테스트 레벨에 대한 테스트 목적의 타당성
• 수행된 테스트 방법의 타당성
• 테스팅 목적 측면에서의 테스팅의 효과
• 수행된 테스트 방법의 타당성
• 테스팅 목적 측면에서의 테스팅의 효과
5.3.3 테스트 통제 (K2)
테스트 통제는 수집되고 보고된 정보와 매트릭의 결과로서 취해진 모든 지침이나 올바른 행동을 묘사한다. 액션들은 모든 테스트 액티비티를 커버할 수 있으며, 다른 소프트웨어 수명주기 액티비티나 작업에 영향을 줄 수 있다.
테스트 통제 액션의 예는 다음과 같다.
• 정의된 위험이 발생할 때 테스트를 다시 우선 순위화 한다. (e.g 늦게 인도된 소프트웨어)
• 테스트 환경의 가용성이 원인이된 테스트 일정의 변경
• 구축시 승인에 앞서 개발자에 의하여 다시 테스트 되어야 하는 수정을 요하는 항목 특성(entry criterion)의 설정
• 테스트 환경의 가용성이 원인이된 테스트 일정의 변경
• 구축시 승인에 앞서 개발자에 의하여 다시 테스트 되어야 하는 수정을 요하는 항목 특성(entry criterion)의 설정
============================================================================
◆ 리포팅 팁[요약]
▪ 단순한 결함 이외의 측정해야 할 다른 것들이 존재
▪ 순간 포착류 측정치 보다는 경향을 리포팅
▪ 리포트의 영향력(impact)을 높이기 위해 리포트 양을 제한
▪ 리포팅의 일관성 유지
▪ "측정"의 의미를 설명 - 당연하다고 가정하지 말것
▪ 쉽게 구분되는 색 이용
▪ 일관성 있는 Look and Feel
▪ 빨간색은 "위험"을 의미함
▪ 누적된 총계는 경향(Trends)을 찝어 나타내줌
▪ 중요한 것은 내용(Content)임
▪ 순간 포착류 측정치 보다는 경향을 리포팅
▪ 리포트의 영향력(impact)을 높이기 위해 리포트 양을 제한
▪ 리포팅의 일관성 유지
▪ "측정"의 의미를 설명 - 당연하다고 가정하지 말것
▪ 쉽게 구분되는 색 이용
▪ 일관성 있는 Look and Feel
▪ 빨간색은 "위험"을 의미함
▪ 누적된 총계는 경향(Trends)을 찝어 나타내줌
▪ 중요한 것은 내용(Content)임
5.4 Configuration management (K2)
구성관리의 목적은 프로젝트와 제품 수명주기(product life cycle)를 통하여 시스템이나 소프트웨어의 산출물(컴포넌트, 데이터 그리고 문서)을 통합하고, 유지하는 것이다.
테스팅에서 구성 관리는 다음을 보장하는 것을 포함할 수 있다.
• 테스트웨어의 모든 항목들은 정의되고, 버전 컨트롤되고, 변경에 대한 추적이 가능하고, 다른 항목들과 연관될 뿐만 아니라, 개발 항목들과도 연관되어 있기에 테스트 프로세스 동안의 추적성은 유지될 수 있다.
• 모든 정의된 문서와 소프트웨어 항목은 테스트 문서에서 명확하게 참조된다.
테스터들은 구성관리를 통해서 테스트된 항목, 테스트 문서들, 테스트들과 테스트 업무를 정확하게 정의햘 수 있다.
테스트 계획 동안에, 구성 관리 절차와 하위구조(도구)가 선택되고, 문서화되며, 구현되어야 한다.
5.5 Risk and testing
위험이란 발생 가능한 이벤트, 장애, 위협을 가리키며, 이것으로 인한 의도되지 않은 결과 즉, 잠재적 문제도 위험 이라고 할 수 있다. 위험의 레벨은 불리한 이벤트의 발생 가능성과 (불리한 이벤트의 결과로 나타나는 손해의)영향에 의하여 결정될 것이다.
5.5.1 프로젝트 위험(Project risk) (K1,K2)
프로젝트 위험이란 프로젝트 목표 달성을 위한 프로젝트의 특성의 주위에 있는 위험들이다.
• 공급자 이슈사항
- 서드 파티 제품의 실패(failure)
- 계약상의 문제
- 서드 파티 제품의 실패(failure)
- 계약상의 문제
• 조직적인 요소(Organizational factors)
- 기술과 직원의 부족
- 개인적인 훈련 문제
- 다음과 같은 정치적인 문제
+ 테스터들의 필요사항과 테스트 결과를 전달하는 것에 의사소통의 문제
+ 테스팅과 리뷰에서 발견된 정보를 처리하는 것에 대한 실패
- 기술과 직원의 부족
- 개인적인 훈련 문제
- 다음과 같은 정치적인 문제
+ 테스터들의 필요사항과 테스트 결과를 전달하는 것에 의사소통의 문제
+ 테스팅과 리뷰에서 발견된 정보를 처리하는 것에 대한 실패
(e.g 테스팅 동안에 발견된 결함 값을 인정하지 않음)
- 테스팅이나 테스팅의 예상치에 대한 부적당한 태도
- 테스팅이나 테스팅의 예상치에 대한 부적당한 태도
• 기술적인 이슈사항
_ 올바른 요구사항을 정의하는 문제
_ 주어진 기존의 제약을 만족할 수 있는 요구사항의 확장
_ 디자인, 코드 기르고 테스트의 품질
_ 올바른 요구사항을 정의하는 문제
_ 주어진 기존의 제약을 만족할 수 있는 요구사항의 확장
_ 디자인, 코드 기르고 테스트의 품질
이러한 위험들을 분석하고 관리하고, 완화시키고자 할 때, 테스트 매니저는 제대로 확립된 프로젝트 관리 원칙을 따라야 한다. "소프트웨어 테스트 문서화를 위한 표준"(IEEE 829)에는 테스트 계획시 위험과 우발상황에 대해서 언급되어야 한다는 것을 약술 하고 있다.
5.5.2 제품 위험 (K2)
소프트웨어나 시스템에서의 잠재적인 실패 영역(불리한 미래 이벤트나 위협)은 제품의 품질에 대한 위험으로 다음과 같은 제품 위험으로 알려져 있다.
• 에러 경향이 있는 소프트웨어의 처리
• 개인이나 회사의 손해의 원인이 될 수 있는 소프트웨어/하드웨어의 잠재성
• 빈약한 소프트웨어 특성들(e.g 기능성, 보안성, 신뢰성, 가용성 그리고 성능)
• 의도한 기능을 수행하지 않는 소프트웨어
• 개인이나 회사의 손해의 원인이 될 수 있는 소프트웨어/하드웨어의 잠재성
• 빈약한 소프트웨어 특성들(e.g 기능성, 보안성, 신뢰성, 가용성 그리고 성능)
• 의도한 기능을 수행하지 않는 소프트웨어
위험은 어디에서 테스팅을 시작하고 어디에 더 테스팅을 해야 하는지를 결정하는데 사용된다. 테스팅은 좋지 않은 효과가 일어나는 위험을 줄이거나, 좋지 않은 효과의 영향을 줄이기 위하여 사용된다.
제품 위험은 프로젝트의 성공에 대한 특별한 종류의 위험이다. 위험을 통제하는 액티비로서 테스팅은 심각한 결함 제거의 효과와 우발적인 계획의 효과를 측정함으로써 남은 위험에 대한 피드백을 제공한다.
위험에 기반한 테스팅 방법은 프로젝트의 초기 단계에서 시작시, 제품 위험의 수준(level)을 줄이는 선행적인(proactive) 기회를 제공한다. 이것은 제품 위험의 정의를 포함하고 테스트 계획, 명세, 준비와 테스트들의 실행을 지도하는데 사용한다. 위험 기반 접근 방법에서, 정의된 위험은 다음을 하는데 사용될 수 있다.
• 사용되어야 하는 테스트 기법을 정의한다.
• 수행되어야 하는 테스팅의 범위를 결정한다.
• 가능한 한 쉽게 심각한 결점을 발견하기 위한 시도시에 테스팅의 우선순위를 정한다.
• 위험을 줄이기 위하여 사용될 수 있는 모든 비 테스팅 액티비티를 결정한다.
• 수행되어야 하는 테스팅의 범위를 결정한다.
• 가능한 한 쉽게 심각한 결점을 발견하기 위한 시도시에 테스팅의 우선순위를 정한다.
• 위험을 줄이기 위하여 사용될 수 있는 모든 비 테스팅 액티비티를 결정한다.
위험 기반 테스팅은 위험과 이러한 위험을 처리하기 위해 요구되는 테스트 레벨을 결정하기 위한 공통의 지식과 프로젝트 이해당사자의 식견을 이끌어낸다.
제품 실패의 변경을 최소화하는 것을 보증하기 위하여, 위험 관리 액티비티는 다음을 위한 정제된 방법을 제공한다.
• 무엇이 잘못될 수 있는지(위험)를 평가한다. (그리고 정식 기반(regular basis)에 대한 재평가를 한다.)
• 어떤 위험을 처리하는 것이 중요한지 결정한다.
• 이러한 위험을 처리하기 위한 액션을 적용한다.
• 어떤 위험을 처리하는 것이 중요한지 결정한다.
• 이러한 위험을 처리하기 위한 액션을 적용한다.
추가적으로, 테스팅은 새로운 위험의 확인을 지원할 수 있으며, 어떤 위험이 줄어야 되는지를 결정하는데 도움이 될 수 있다. 그리고 위험에 대한 불확실성을 줄일 수 있다.
5.6 Incident management (K3)
테스팅의 목적중 하나가 결함을 발견하는 것이기 때문에, 실제 결과와 예상되는 결과 사이의 불일치 사항들(discrepancies)은 부가 사항으로 로그되어야 할 필요가 있다. 부가 사항은 문제의 발견과 분류로 부터 해결방법의 수정과 확인까지 추적 되어야 한다. 모든 부가 사항이 완벽하게 관리되기 위해서, 조직은 분류을 위한 프로세스와 규칙을 만들어야 한다.
부가 사항은 개발, 리뷰, 테스팅 혹은 소프트웨어 제품의 사용중에 발생할 수 있다. 부가 사항은 코드나 동작 시스템내에서, 개발 문서, 테스트 문서 또는 도움말과 같은 사용자 정보나 설치가이드 같은 모든 종류의 문서에서 발생할 수 있다.
부가 사항 보고는 다음의 목적을 가져야 한다.
• 개발자들과 다른 관련자들에게 문제를 정의, 분리, 수정 할 수 있게 하는 피드백을 제공한다.
• 테스트 하는 시스템의 품질과 테스트의 진행사항을 추적하는 수단을 테스트 리더에게 제공한다.
• 테스트 프로세스 향상에 대한 아이디어를 제공한다.
• 테스트 프로세스 향상에 대한 아이디어를 제공한다.
만약 부가사항이 고려된다고 알려졌다면, 테스터나 리뷰어는 일반적으로 다음의 정보를 로그한다.
• 문제 발생 일자, 발생 조직, 승인과 상태
• 범위, 심각도와 부대사건의 우선순위
• 참조, 문제를 나타내는 테스트 케이스 명세의 확인을 포함하는
• 범위, 심각도와 부대사건의 우선순위
• 참조, 문제를 나타내는 테스트 케이스 명세의 확인을 포함하는
부가 사항 보고의 세부 사항은 다음을 포함 할 수 있다.
• 예상되는 결과와 실제 시간
• 부가 사항이 발견된 날짜
• 소프트웨어나 시스템의 확인 또는 구성 항목
• 부가 사항이 관찰된 소프트웨어 또는 시스템 수명주기 프로세스
• 해결이 가능한 예외사항(anomaly)에 대한 설명
• 이해당사자 관심의 영향 정도
• 시스템의 영향에 대한 심각도
• 수정에 대한 긴급도/우선순위
• 부가 사항의 상태(e.g open(개방), deffed(연기), dupplicate(복사), waiting to be fixed(수정 대기), fixed awaiting confirmation test(수정후 확인 테스트 대기중) 또는 close(종료))
• 히스토리 변경, 부가사항을 고립, 수정, 그리고 수정을 확인하기 위한 측면에서 프로젝트 팀의 멤버에 의하여 취해진 액션의 시퀀스와 같은
• 부가 사항이 발견된 날짜
• 소프트웨어나 시스템의 확인 또는 구성 항목
• 부가 사항이 관찰된 소프트웨어 또는 시스템 수명주기 프로세스
• 해결이 가능한 예외사항(anomaly)에 대한 설명
• 이해당사자 관심의 영향 정도
• 시스템의 영향에 대한 심각도
• 수정에 대한 긴급도/우선순위
• 부가 사항의 상태(e.g open(개방), deffed(연기), dupplicate(복사), waiting to be fixed(수정 대기), fixed awaiting confirmation test(수정후 확인 테스트 대기중) 또는 close(종료))
• 히스토리 변경, 부가사항을 고립, 수정, 그리고 수정을 확인하기 위한 측면에서 프로젝트 팀의 멤버에 의하여 취해진 액션의 시퀀스와 같은
부가사항 보고의 구조는 "소프트웨어 테스트 문서화를 위한 표준"(IEEE829)에서 커버하고 예외 보고라 불린다.
============================================================================
◆ 결함 생명 주기 (Defect Lifecycle)
1. 결함 발견 :
- 테스터의 의해 결함 보고
2. 결함 분배 :
- 담당자에게 결함 분배(자동 분배)
3. 결함 수정 :
- 개발자에 의해 결함 수정
4. 결함 확인 :
- 보고자 및 관리자에 의해 결함 수정 확인
5. 결함 종료 :
- 결함이 수정되었을 경우 결함 종료
6. 다시 1번으로..
- 테스터의 의해 결함 보고
2. 결함 분배 :
- 담당자에게 결함 분배(자동 분배)
3. 결함 수정 :
- 개발자에 의해 결함 수정
4. 결함 확인 :
- 보고자 및 관리자에 의해 결함 수정 확인
5. 결함 종료 :
- 결함이 수정되었을 경우 결함 종료
6. 다시 1번으로..
◆ 인시던트(or 결함) 리포트 고려사항
▪ 구조화
▪ 재현
▪ 격리 : 디버그하지는 않음
▪ 일반화 : 가능한 영향(damage)를 예측
▪ 비교 : to 이전 버전 등
▪ 문제점 요약
▪ 압축된 내용
▪ 의미 명확화 : 개발자의 이해를 돕기 위함
▪ 중화 : 개발자를 비난하지 않도록
▪ 검토 : 잘못된 결함 보고 또는 수준 낮은 (bad) 보고 방지
▪ 재현
▪ 격리 : 디버그하지는 않음
▪ 일반화 : 가능한 영향(damage)를 예측
▪ 비교 : to 이전 버전 등
▪ 문제점 요약
▪ 압축된 내용
▪ 의미 명확화 : 개발자의 이해를 돕기 위함
▪ 중화 : 개발자를 비난하지 않도록
▪ 검토 : 잘못된 결함 보고 또는 수준 낮은 (bad) 보고 방지
반응형
'잘난놈되기' 카테고리의 다른 글
| 디그(Digg) + 팟캐스트(Podcast) = 영어 공부 (0) | 2008.01.04 |
|---|---|
| ISTQB Syllabus 2005 통합정리 (6. Tool support for testing) (0) | 2007.11.19 |
| ISTQB Syllabus 2005 통합정리 (4. Test design techniques) (0) | 2007.10.25 |
| ISTQB Syllabus 2005 통합정리 (3. Review) (0) | 2007.10.22 |
| ISTQB Syllabus 2005 통합정리 (2. 소프트웨어 개발주기와 테스팅) (0) | 2007.10.19 |