ISTQB_CTAL_TM_Syllabus_v2012_Kor(고급레벨 실러버스)

ISQTB Certified Tester Advanced Level(TA, TM, TTA 모듈)

- 시험레벨: Certified Tester Advanced Level(TA, TM, TTA 모듈)
- 시험시간: 10:00 ~ 14:00(설명 시간 포함)
- 비용: 242,000원(VAT 포함) (자격심사 비용 55,000원 별도)
- 시험 신청 인원에 따라 시험장이 변경될 수 있습니다.
- 기존에 Advanced Level 자격심사를 완료하여 합격하신 분은 자격증빙 및 심사료가 면제됩니다.

*현재 CTAL 자격심사는 재인증을 필요로 하지 않습니다. 
*만약 CTAL 자격요건이 강화될 경우에는 경력에 대한 추가의 인증이 요구될 수 있습니다.
* 과거에 자격심사를 통과했으나 시스템에 등록되지 않아 면제대상으로 확인되지 않는 경우, 시험 신청 후 1:1 문의
혹은 메일을 통해 문의주시기 바랍니다.
* 시험과 연계된 자격심사는 시험 접수 마감일까지 접수 및 심사비용이 납부되어야 합니다.

시험 범위: Advanced Level Syllabus V.2012

시험 언어: 한글/영어 객관식
합격 기준: 백분율 65% 이상의 점수 취득 시 합격
결과 발표:시험 약 15일 후 (오후 9시 시스템을 통해 발표. 발표일은 신청페이지 참조)
※ 시험 규정은 국제 ISTQB^®의 결정에 따라 변경될 수 있습니다

모듈 별 시험 시간
- 한글 시험 시간 안내
* Test Manager(한글) 65문항 3시간 (180분)
* Test Analyst(한글) 60문항 3시간 (180분)
* Technical Test Analyst(한글) 45문항 2시간 (120분)
· 한글시험의 경우 추가시간이 주어지지 않고 사전 이용이 불가합니다.
- 영문 시험 시간 안내
* Test Manager(영어) 65문항 3시간 45분(225분)
* Test Analyst(영어) 60문항 3시간 45분(225분)
* Technical Test Analyst(영어) 45문항 2시간 30분(150분)
· 비영어권 응시자가 영어시험을 치를 경우 주어지는 추가시간이 적용되었습니다.
· 영어시험의 경우 종이 사전 이용이 가능합니다.

01. 이 교과목 소개

이 강의 계획은 시험 관리자를 위한 고급 레벨의 국제 소프트웨어 시험 자격을 위한 토대를 형성합니다. ISTQB®는 다음과 같이 이 강의 계획서를 제공합니다 :

1. National Boards, 현지 언어로 번역하고 훈련 제공자를 승인하십시오. 내셔널 보드는 강의 계획서를 자신의 특정 언어 요구에 맞게 조정하고 해당 지역 출판물에 적용 할 참조를 수정할 수 있습니다.

2. 시험 준비위원회 (Board to Exam Board) : 각 강의 계획의 학습 목표에 맞게 현지 언어로 시험 문제를 추출합니다.

3. 훈련 제공자에게 코스웨어를 만들고 적절한 교수 방법을 결정합니다. 4. 인증 후보자에게, 시험을 준비하십시오 (훈련 과정의 일부로서 또는 독립적으로).

5. 국제 소프트웨어 및 시스템 엔지니어링 커뮤니티, 소프트웨어 및 시스템 테스트의 직업을 사전에, 도서 및 기사의 기초로. ISTQB®는 다른 기관이 사전에 서면 허가를 받고 구한 경우에 이 강의 계획서를 다른 목적으로 사용할 수 있도록 허용 할 수 있습니다.

02 개요

고급 레벨은 세 가지 별도의 강의 계획서로 구성됩니다:

l  시험 관리자

l  테스트 분석가

l  기술 테스트 분석가

고급 수준 개요 문서 [ISTQB_AL_OVIEW]에는 다음 정보가 포함됩니다.

l  각 강의 계획서의 비즈니스 성과

l  각 강의 요약

l  강의 계획표 사이의 관계

l  인지 수준 (K 수준)에 대한 설명

* 부록

03 시험 학습 목표

학습 목표는 비즈니스 성과를 지원하며 Advanced Test Manager 인증을 취득하기 위한 시험을 만드는 데 사용됩니다. 일반적으로 이 교과의 모든 부분은 K1 레벨에서 시험을 치 룰 수 있습니다. 즉, 응시자는 용어나 개념을 인식하고 기억하고 기억할 것입니다. K2, K3 및 K4 레벨의 학습 목표는 해당 장의 시작 부분에 나와 있습니다.

1. 테스팅 프로세스 - 420 분.

키워드

종료 기준, 테스트 케이스, 테스트 종료, 테스트 조건, 테스트 컨트롤, 테스트 디자인, 테스트 실행, 테스트 구현, 테스트 로그, 테스트 계획, 테스트 절차, 테스트 스크립트, 테스트 요약 보고서

테스트 프로세스 학습 목표

1.2 시험 계획, 모니터링 및 제어

TM-1.2.1 (K4) 테스트 활동을 계획하고 테스트 목표를 달성 할 제품을 작동시키기 위해 시스템에 대한 테스트 요구 사항을 분석합니다.

1.3 시험 분석

TM-1.3.1 (K3) 추적 성을 사용하여 테스트 목표, 테스트 전략 및 테스트 계획과 관련하여 정의 된 테스트 조건의 완전성과 일관성을 검사합니다.

TM-1.3.2 (K2) 테스트 조건을 지정할 수 있는 세부 수준에 영향을 줄 수 있는 요인과 세부 조건에서 테스트 조건을 지정하기 위한 장단점을 설명하십시오.

1.4 시험 설계

TM-1.4.1 (K3) 추적 가능성을 사용하여 정의 된 테스트 조건과 관련하여 설계된 테스트 케이스의 완결성과 일관성을 검사합니다.

1.5 시험 구현

TM-1.5.1 (K3) 위험, 우선 순위, 테스트 환경 및 데이터 종속성 및 제약 조건을 사용하여 테스트 목표, 테스트 전략 및 테스트 계획과 관련하여 완전하고 일관된 테스트 실행 일정을 개발하십시오.

1.6 테스트 실행

TM-1.6.1 (K3) 추적 성을 사용하여 테스트 진행 상황을 모니터링 하여 테스트 목표, 테스트 전략 및 테스트 계획의 일관성 및 일관성을 확인하십시오.

1.7 종료 기준 평가 및 보고

TM-1.7.1 (K2) 종료 기준에 대한 정확한 보고 및 평가를 지원하기 위해 테스트 프로세스 중 정확하고 시기 적절한 정보 수집의 중요성을 설명하십시오.

1.8 시험 종료 활동

TM-1.8.1 (K2) 테스트 클로저 활동의 네 가지 그룹을 요약합니다.

TM-1.8.2 (K3) 프로세스를 평가하고 개선 할 영역을 발견하는 프로젝트 회고를 구현하십시오.

1.1 서론

ISTQB® 기초 수준 시험 계획서는 다음과 같은 활동을 포함하는 기본적인 시험 과정을 설명합니다:

l  계획 및 제어

l  분석 및 설계

l  구현 및 실행

l  종료 기준 평가 및 보보

l  테스트 종료 활동

Foundation Level 요강은 논리적으로 순차적이지만 프로세스의 활동이 중복되거나 동시에 일어날 수 있다고 말합니다. 시스템 및 프로젝트의 맥락에서 이러한 주요 활동을 조정하는 것이 일반적으로 필요합니다.

 

고급 레벨 강의에서는 프로세스의 추가 개선 및 최적화를 제공하고 소프트웨어 개발 라이프 사이클에보다 잘 부합하며 효과적인 테스트 모니터링 및 제어를 용이하게 하기 위해 이러한 활동 중 일부를 개별적으로 고려합니다. 활동은 이제 다음과 같이 간주됩니다:

l  계획, 모니터링 및 제어

l  분석

l  설계

l  구현

l  실행

l  중료 기준 평가 및 보고

l  테스트 종료 활동들

1.2 시험 계획, 모니터링 및 제어

이 절에서는 테스트 계획, 모니터링 및 제어 프로세스에 중점을 둡니다. Foundation Level에서 설명한 것처럼 이러한 활동은 테스트 관리 역할입니다.

1.2.1 테스트 계획

각 테스트 레벨에 대해 테스트 계획은 해당 레벨의 테스트 프로세스가 시작될 때 시작되어 해당 레벨의 종결 작업이 완료 될 때까지 프로젝트 전체에서 계속됩니다. 여기에는 시험 전략에서 확인 된 사명과 목표를 달성하는 데 필요한 활동과 자원을 식별하는 작업이 포함됩니다. 테스트 계획에는 프로젝트를 인도하기 위해 사용될 메트릭스를 수집하고 추적하는 방법을 식별하고, 목표 달성을 계획하고 평가하기 위해 준수를 결정하는 것도 포함됩니다. 계획 단계에서 유용한 측정 항목을 결정하면 도구를 선택하고, 교육을 예약하고, 문서화 지침을 설정할 수 있습니다.

테스트 프로젝트를 위해 선택된 전략 (또는 전략)은 계획 단계에서 발생해야 하는 작업을 결정하는 데 도움이 됩니다. 예를 들어, 위험 기반 테스트 전략 (2 장 참조)을 사용할 때 위험 분석은 식별 된 제품 위험을 줄이고 비상 계획 수립에 필요한 완화 활동과 관련하여 테스트 계획 프로세스를 안내하는 데 사용됩니다. 보안과 관련된 가능성이 높고 심각한 잠재적 인 결함이 여러 개 발견되면 보안 테스트를 개발하고 실행하는 데 많은 노력을 기울여야 합니다. 마찬가지로, 심각한 결함이 일반적으로 설계 사양에서 발견되는 경우, 테스트 계획 프로세스는 설계 스펙에 대한 추가 정적 테스트 (검토)를 초래할 수 있습니다.

또한 위험 정보는 다양한 테스트 활동의 우선 순위를 결정하는 데 사용될 수 있습니다. 

예를 들어, 시스템 성능이 높은 위험이 있는 경우 통합 코드가 제공되는 즉시 성능 테스트를 수행 할 수 있습니다.

마찬가지로, 대응 전략을 사용하는 경우, 예비 테스트와 같은 동적 테스트 기술을 위한 테스트 헌장 및 도구를 만들기 위한 계획이 필요합니다.

또한 테스트 계획 단계는 테스트 관리자가 각 테스트 수준을 적용 할 것인지, 각 수준의 목표와 목표를 결정할 것인지, 각 테스트 단계에서 어떤 테스트 기술을 사용할 것인지 등 테스트 관리자가 명확하게 정의한 방식입니다. 예를 들어 특정 항공 전자 시스템의 위험 기반 테스트에서 위험 평가는 필요한 코드 도달 범위와 그에 따라 사용되는 테스트 기술을 규정합니다.

테스트 기반 (예: 특정 요구 사항 또는 위험), 테스트 조건 및 이를 포괄하는 테스트 간에는 복잡한 관계가 존재할 수 있습니다. 다 대 다 관계는 종종 이러한 작업 제품간에 존재합니다. 테스트 계획, 모니터링 및 제어를 효과적으로 구현할 수 있도록 이해해야 합니다. 도구 결정은 작업 결과 간의 관계에 대한 이해에 달려있다.

또한 개발 팀에서 생산 한 작업 제품과 테스트 팀간에 관계가 있을 수 있습니다. 예를 들어, 추적 가능성 매트릭스는 시스템 설계자의 세부 설계 사양 요소, 비즈니스 분석가의 비즈니스 요구 사항 및 테스트 팀이 정의한 테스트 작업 제품 간의 관계를 추적해야 할 수 있습니다. 하위 수준의 테스트 사례를 설계하고 사용하려는 경우 계획 단계에서 정의 된 요구 사항에 따라 개발 팀의 세부 디자인 문서가 승인되어 테스트 사례를 만들 수 있습니다. 민첩한 라이프 사이클을 따르는 경우 비공식적 인 정보 전달 세션을 사용하여 테스트를 시작하기 전에 팀간에 정보를 전달할 수 있습니다.

또한 테스트 계획에는 해당 범위에 속하지 않는 기능을 명시 적으로 식별 할뿐만 아니라 해당 범위 내에 있는 소프트웨어의 특정 기능 (해당되는 경우 위험 분석을 기반으로 함)이 나열 될 수도 있습니다. 프로젝트에 적합한 형식 및 문서 수준에 따라 범위 내에 있는 각 기능은 해당하는 테스트 디자인 사양과 연관 될 수 있습니다.

이 단계에서는 테스트 관리자가 프로젝트 설계자와 협력하여 초기 테스트 환경 사양을 정의하고, 필요한 리소스의 가용성을 확인하고, 환경을 구성 할 사람들이 그렇게 하도록 하기 위해 노력할 것을 요구할 수 있습니다. 테스트 환경을 완료하고 제공하는 데 필요한 비용 / 배달 시간 및 작업을 이해해야 합니다.

마지막으로 모든 외부 종속성 및 관련 서비스 수준 계약 (SLA(Service Level Agreement;서비스수준협약서)

서비스를 제공함에 있어서 공급자와 사용자간에 서비스에 대하여 측정지표와 목표 등에 대한 협약서)을 식별하고 필요한 경우 초기 연락을 취해야 합니다. 종속성의 예로는 외부 그룹에 대한 리소스 요청, 다른 프로젝트 (프로그램 내에서 작업하는 경우), 외부 공급 업체 또는 개발 파트너, 배포 팀 및 데이터베이스 관리자와의 종속 관계가 있습니다.

1.2.2 테스트 모니터링 및 제어

테스트 관리자가 효율적인 테스트 제어를 제공하려면 계획에 따라 테스트 작업 제품 및 리소스를 추적 할 수 있도록 테스트 일정 및 모니터링 프레임 워크를 구축해야 합니다. 이 프레임 워크에는 시험 작업 제품 및 활동의 상태를 계획 및 전략적 목표와 관련시키는 데 필요한 세부 조치 및 목표가 포함 되어야 합니다.

작고 덜 복잡한 프로젝트의 경우, 테스트 작업 제품 및 활동을 계획 및 전략 목표와 관련시키는 것은 상대적으로 쉽지만 일반적으로 이를 달성하기 위해보다 세부적인 목표를 정의해야 합니다. 여기에는 테스트 목표를 충족시키는 측정 및 목표 및 테스트 기준의 범위가 포함될 수 있습니다.

특히 중요한 것은 테스트 작업 제품 및 활동의 상태를 프로젝트 및 비즈니스 이해 관계자가 이해하고 관련성이 있는 방식으로 테스트 기반에 연관시켜야 한다는 것입니다.

테스트 조건 및 테스트 조건 그룹을 기반으로 목표를 정의하고 진행 상황을 측정하는 것은 다른 테스트 작업 제품을 테스트 조건을 통해 테스트 기준과 관련시킴으로써 이를 달성하기 위한 수단으로 사용할 수 있습니다. 추적 가능성 상태에 대한보고 기능을 포함하여 적절하게 구성된 추적 기능은 개발 작업 제품, 테스트 기초 및 테스트 작업 제품간에 존재하는 복잡한 관계를 보다 투명하고 이해하기 쉽게 만듭니다.

간혹 이해 관계자가 모니터 해야 하는 세부적인 측정 및 목표는 시스템 기능 또는 사양과 직접 관련이 없으며, 특히 정식 문서가 거의 또는 전혀 없는 경우 특히 그렇습니다. 예를 들어 비즈니스 이해 관계자는 사양이 시스템 기능면에서 정의 되더라도 운영 비즈니스주기에 대해 적용 범위를 설정하는 데 더 많은 관심을 가질 수 있습니다. 프로젝트의 초기 단계에서 비즈니스 이해 관계자의 참여는 프로젝트 기간 동안 더 나은 제어를 제공하는 데 사용될 수 있을 뿐만 아니라 프로젝트 전체에서 테스트 활동을 추진하고 영향을 줄 수 있는 이러한 조치 및 목표를 정의하는 데 도움이 될 수 있습니다. 예를 들어, 이해 관계자 측정 및 목표는 테스트 설계 및 테스트 구현 작업 제품 및 / 또는 테스트 실행 일정을 구성하여 이러한 조치에 대한 테스트 진행 상황을 정확하게 모니터링 할 수 있게 합니다. 이러한 목표는 또한 특정 테스트 레벨에 대한 추적 성을 제공하고 다양한 테스트 레벨에서 정보 추적 성을 제공 할 수 있는 잠재력을 제공합니다.

테스트 컨트롤은 지속적인 활동입니다. 실제 진행 상황을 계획과 비교하고 필요할 때 시정 조치를 취하는 과정이 포함됩니다. 테스트 컨트롤은 필요에 따라 테스트 계획 활동을 다시 방문하는 것을 포함하여 임무, 전략 및 목표를 수행하도록 테스트를 안내합니다. 제어 데이터에 대한 적절한 반응은 상세한 계획 정보에 달려 있습니다.

테스트 계획 문서 및 테스트 제어 활동의 내용은 2 장에서 다룹니다.

 

1.3 시험 분석

재단 수준 강의에 설명 된 대로 테스트 분석 및 설계를 함께 고려하는 대신 고급 설계 요강은 테스트 설계 작업 제품의 생산을 용이하게 하기 위해 병렬, 통합 또는 반복 활동으로 구현할 수 있음을 인식하면서도 이를 별도의 활동으로 간주합니다.

테스트 분석은 테스트 조건의 형태로 "무엇을 테스트 할 것인가"를 정의하는 활동입니다. 테스트 조건은 테스트 기준, 테스트 목표 및 제품 위험 분석을 통해 확인할 수 있습니다. 그것들은 성공을 위한 상세한 측정 및 목표로 간주 될 수 있으며 (예 : 종료 기준의 일부로) 테스트 목표 및 성공을 위한 기타 프로젝트 또는 이해 관계자 기준을 포함하여 전략적 목표를 테스트 기준으로 추적 할 수 있어야 합니다. 테스트 조건은 또한 테스트 디자인과 다른 테스트 작업 제품에 생성물이 생성 될 때 추적 가능해야 한다.

주어진 수준의 테스트에 대한 테스트 분석은 해당 수준에 대한 테스트 기준이 수립되는 즉시 수행 될 수 있습니다. 공식 테스트 기술 및 기타 일반적인 분석 기술 (예: 분석 위험 기반 전략 및 분석 요구 사항 기반 전략)을 사용하여 테스트 조건을 식별 할 수 있습니다. 테스트 조건은 테스트 레벨, 분석 수행 시에 이용 가능한 정보 및 선택된 상세 수준 (즉, 문서의 세분 성 정도)에 따라 값 또는 변수를 지정할 수도 지정하지 않을 수도 있습니다.

테스트 조건을 지정하는 세부 수준을 결정할 때 고려해야 할 요소는 다음과 같습니다.

l  테스트 수준

l  테스트 수준의 세부 수준 및 품질

l  시스템 / 소프트웨어 복잡성

l  프로젝트 및 제품 위험 테스트 기준, 테스트 대상 및 테스트 방법

소프트웨어 개발 수명주기

l  활용되는 테스트 관리 툴

l  시험 설계 및 기타 시험 작업 제품을 명시하고 문서화하는 수준

l  테스트 분석가의 기술 및 지식

l  테스트 프로세스의 성숙도와 조직 자체 (성숙도가 높을수록 세부 수준이 더 높아지거나 세부 수준이 낮아질 수 있음)

l  협의를 위한 다른 프로젝트 이해 관계자의 가용성

세부적인 방식으로 테스트 조건을 지정하면 더 많은 수의 테스트 조건이 생성되는 경향이 있습니다. 예를 들어, 전자 상거래 응용 프로그램의 경우 "Test checkout"이라는 하나의 일반 테스트 조건을 가질 수 있습니다. 그러나 세부 테스트 조건 문서에서는 지원되는 각 지불 방법에 대해 하나의 조건, 가능한 각 대상 국가에 대해 하나의 조건 등 여러 테스트 조건으로 나눌 수 있습니다.

세부적인 수준에서 테스트 조건을 지정하는 몇 가지 이점은 다음과 같습니다:

l  다른 테스트 작업 제품 (예 : 테스트 케이스)과 테스트 기반 및 테스트 목표를 더 유연하게 연관시켜 테스트 관리자를 보다 정확하고 효과적으로 모니터링하고 제어 할 수 있습니다

l  테스트 수준이 설정되고 시스템 아키텍처 및 세부 설계가 가능 해지면 잠재적으로 프로젝트의 초기 단계에서 발생하는 결함 레벨 예방에 기여합니다.

l  작업 제품을 이해할 수 있는 측면에서 테스트 제품과 관련시킵니다 (종종 테스트 케이스 및 기타 테스트 작업 제품은 비즈니스 이해 관계자에게 아무런 의미가 없으며 실행되는 테스트 케이스 수와 같은 간단한 메트릭은 이해 관계자의 요구 사항 범위를 의미하지 않습니다).

l  다른 테스트 활동뿐만 아니라 다른 개발 활동에도 영향을 미치고 지시 할 수 있습니다.

l  세부적인 측정 및 목표를 보다 효율적으로 적용하여 테스트 설계, 구현 및 실행을 최적화하고 결과 작업 제품을 최적화 할 수 있습니다.

l  테스트 레벨 내에서 더 명확한 수평 추적 성을 위한 기초를 제공합니다.

상세 수준에서 테스트 조건을 지정하는 데는 몇 가지 단점이 있습니다.

l  잠재적으로 시간이 많이 소요됩니다.

l  변화하는 환경에서 유지 보수가 어려울 수 있습니다.

l  형식의 수준은 팀 전체에 걸쳐 정의되고 구현되어야 합니다.

상세한 테스트 조건의 지정은 다음 상황에서 특히 효과적 일 수 있습니다.

l  개발 라이프 사이클, 비용 및 / 또는 시간 제약 또는 기타 요소를 수용하기 때문에 체크리스트와 같은 경량 테스트 설계 문서화 방법이 사용되고 있습니다.

l  테스트 기준으로 공식 요구 사항 또는 기타 개발 작업 제품이 거의 없거나 전혀 없습니다.

l  이 프로젝트는 대규모, 복잡하거나 위험성이 높으며 테스트 케이스를 개발 작업 제품과 관련시킴으로써 제공 할 수 없는 수준의 모니터링 및 제어가 필요합니다.

테스트 기준은 설계 작업 제품을 테스트하기 위해 쉽고 직접적으로 관련 될 수 있는 경우보다 세분화하여 지정할 수 있습니다. 이것은 다음과 같은 경우에 해당합니다.

l  구성 요소 레벨 테스트

l  테스트 대상과 테스트 방법간에 단순한 계층 적 관계가 있는 덜 복잡한 프로젝트입니다.

l  유스 케이스가 테스트를 정의하는 데 활용 될 수 있는 인수 테스트.

1.4 테스트 설계

테스트 설계는 무언가가 테스트되는 방법을 정의하는 활동입니다. 테스트 전략 및 / 또는 테스트 계획에서 확인 된 테스트 기술을 사용하여 식별 된 테스트 조건 또는 테스트 기반을 단계적으로 상세하게 작성하여 테스트 케이스를 식별하는 작업입니다. 테스트 모니터링, 테스트 제어 및 추적 가능성에 사용되는 접근 방식에 따라 테스트 사례는 테스트 기반 및 정의 된 목표와 직접 관련 될 수 있습니다 (또는 테스트 조건을 통해 간접적으로 관련 될 수 있음). 이러한 목표에는 전략 목표, 테스트 목표 및 성공을 위한 기타 프로젝트 또는 이해 관계자 기준이 포함됩니다.

일단 시험 조건이 확인되고 시험 설계에 대한 채택 된 접근법에 따라 저 수준 또는 고 수준 시험 경우의 생산을 가능하게 하는 충분한 정보가 이용 가능하면 주어진 시험 레벨에 대한 시험 설계가 수행 될 수 있다. 높은 수준의 테스트를 위해서는 테스트 설계가 초기 테스트 분석에 이어 별도의 활동 일 가능성이 높습니다. 낮은 수준의 테스트의 경우 테스트 분석 및 설계가 통합 된 활동으로 수행 될 가능성이 큽니다.

또한 테스트 구현 중에 일반적으로 발생하는 일부 태스크는 반복적 인 접근 방법을 사용하여 실행에 필요한 테스트를 작성하는 경우 테스트 설계 프로세스에 통합 될 가능성이 있습니다; 예를 들어, 테스트 데이터의 생성. 사실, 이 접근법은 테스트 조건의 적용 범위를 최적화하여 프로세스에서 저 수준 또는 고급 테스트 케이스를 생성 할 수 있습니다.

1.5 시험 구현

테스트 구현은 테스트 분석가가 테스트를 구성하고 우선 순위를 정하는 활동입니다. 형식적으로 문서화 된 상황에서 테스트 구현은 테스트 설계가 구체적인 테스트 케이스, 테스트 절차 및 테스트 데이터로 구현되는 활동입니다. IEEE 829 [IEEE829] 표준을 따르는 일부 조직에서는 테스트 케이스 사양 및 테스트 절차 사양의 테스트 단계에서 입력 및 관련 예상 결과를 정의합니다. 보다 일반적으로 각 테스트의 입력, 예상 결과 및 테스트 단계가 함께 문서화됩니다. 테스트 구현은 또한 저장된 테스트 데이터 (예: 플랫 파일 또는 데이터베이스 테이블)의 생성을 포함합니다.

테스트 구현에는 테스트 팀이 테스트 실행 준비가 되었는지를 확인하기 위한 최종 검사도 포함됩니다. 검사에는 필수 테스트 환경의 전달, 데이터 및 코드 테스트 (일부 테스트 환경 및 / 또는 코드 수락 테스트 실행 가능성) 확인 및 모든 테스트 사례 작성, 검토 및 실행 준비가 포함될 수 있습니다. 또한 문제의 시험 레벨에 대한 명시 적 및 암묵적 진입 기준에 대한 점검을 포함 할 수 있다 (1.7 절 참조). 테스트 구현에는 테스트 환경 및 테스트 데이터에 대한 자세한 설명을 개발하는 작업도 포함될 수 있습니다.

테스트 구현 중에 수행 된 세부 수준 및 관련 복잡성은 테스트 작업 제품 (예: 테스트 케이스 및 테스트 조건)의 세부 사항에 의해 영향을 받을 수 있습니다. 일부 경우, 특히 회귀 테스트에서 장기간 재사용을 위해 테스트를 보관 해야 하는 경우 테스트를 실행하는 테스터에 관계없이 안정적이고 일관된 실행을 보장하기 위해 테스트 실행에 필요한 단계에 대한 자세한 설명을 제공 할 수 있습니다. 규제 규칙이 적용되는 경우, 테스트는 적용 가능한 표준에 대한 준수의 증거를 제공 해야 합니다 (2.9 절 참조).

테스트 구현 중에 수동 및 자동 테스트를 실행하는 순서는 테스트 실행 일정에 포함 되어야 합니다. 테스트 관리자는 테스트가 특정 주문이나 특정 장비에서 실행 되어야 하는 위험 및 우선 순위를 비롯한 제약 조건을 신중하게 확인 해야 합니다. 테스트 환경 또는 테스트 데이터에 대한 종속성을 알고 확인 해야 합니다.

초기 테스트 구현에는 몇 가지 단점이 있을 수 있습니다. 예를 들어 애자일 라이프 사이클에서는 코드가 반복에서 반복 될 때마다 코드가 크게 변경되어 많은 구현 작업이 쓸모 없게 됩니다. 수명주기가 Agile처럼 변경되기 쉽지 않아도 반복 또는 점진적 수명주기가 반복 될 때마다 스크립트 테스트를 신뢰할 수 없게 만들거나 높은 유지 관리 요구가 발생할 수 있습니다.

수명주기가 Agile처럼 변경되기 쉽지 않아도 반복 또는 점진적 수명주기가 반복 될 때마다 스크립트 테스트를 신뢰할 수 없게 만들거나 높은 유지 관리 요구가 발생할 수 있습니다. 프로젝트의 후반부에 요구 사항이 빈번하게 변경되는 관리가 불량한 순차적 라이프 사이클에서도 마찬가지입니다. 광범위한 테스트 구현 노력을 시작하기 전에 소프트웨어 개발 수명주기 및 테스트에 사용할 수 있는 소프트웨어 기능의 예측 가능성을 이해하는 것이 좋습니다.

초기 테스트 구현에는 몇 가지 이점이 있을 수 있습니다. 예를 들어, 구체적인 테스트는 테스트 기반에 따라 작성된 경우 소프트웨어가 어떻게 동작해야 하는지에 대한 작업 예제를 제공합니다. 비즈니스 도메인 전문가는 추상 비즈니스 규칙을 검증하는 것보다 구체적인 테스트를 쉽게 검증 할 수 있으므로 소프트웨어 사양의 약점을 식별 할 수 있습니다. 이러한 검증 된 테스트는 소프트웨어 설계자와 개발자에게 필요한 동작을 명쾌하게 보여줄 수 있습니다.

1.6 테스트 실행

테스트 객체가 전달되고 실행 테스트를 위한 입력 조건이 충족되면 테스트 실행이 시작됩니다. 테스트는 테스트 실행 전에 설계되거나 최소한 정의되어야 합니다. 특히 테스트 관리, 결함 추적 및 (해당되는 경우) 테스트 실행 자동화를 위한 도구가 제자리에 있어야 합니다. 메트릭 추적을 포함한 테스트 결과 추적이 작동해야 하며 추적 된 데이터는 모든 팀원이 이해해야 합니다. 테스트 로깅 및 결함보고 표준을 사용할 수 있고 게시해야 합니다. 테스트 실행 전에 이러한 항목이 제자리에 있음을 보장함으로써 실행을 효율적으로 진행할 수 있습니다.

테스트 관리자는 테스터가 테스트 중에 관찰되는 추가 흥미로운 테스트 시나리오 및 동작을 포함 할 수 있도록 약간의 자유 허용을 고려해야 만하지만 테스트 사례에 따라 실행해야 합니다. 최소한 부분적으로 반응하는 테스트 전략을 따르면 경험 기반 및 결함 기반 기술을 사용하여 테스트 세션을 예약해야 합니다. 물론 이러한 비 스크립트 테스트 중에 발견 된 모든 실패는 실패를 재현하는 데 필요한 서면 테스트 케이스의 변형을 설명해야 합니다. 자동화 된 테스트는 편차 없이 정의 된 지침을 따릅니다.

테스트 실행 중 테스트 관리자의 주된 역할은 테스트 계획에 따라 진행 상황을 모니터링하고, 필요한 경우 임무, 목표 및 전략 측면에서 테스트를 성공적인 결론으로 ​​이끌기 위한 제어 조치를 시작하고 수행하는 것입니다. 그렇게 하기 위해, 테스트 관리자는 테스트 결과에서 테스트 조건, 테스트 기준, 그리고 궁극적으로 테스트 목표, 그리고 테스트 목표까지 테스트 결과까지 추적 할 수 있습니다. 이 프로세스는 2.6 절에 자세히 설명되어 있습니다.

1.7 종료 기준 평가 및 보고

테스트 진행 모니터링 및 제어에 대한 문서 및 보고는 2.6 절에서 자세히 설명합니다.

 

테스트 프로세스의 관점에서 종료 기준 및 보고를 평가하는 데 필요한 소스 정보를 제공하기 위한 효과적인 프로세스가 마련되어 있는지 확인하는 것이 중요합니다.

정보 요구 사항의 정의 및 수집 방법은 테스트 계획, 모니터링 및 제어의 일부입니다. 테스트 분석, 테스트 설계, 테스트 구현 및 테스트 실행 중에 테스트 관리자는 해당 활동을 담당하는 테스트 팀의 구성원이 효과적인 평가 및 보고를 용이하게 할 수 있도록 정확하고 시기 적절한 방식으로 필요한 정보를 제공하는지 확인해야 합니다.

보고에 필요한 세부 빈도와 세부 수준은 프로젝트와 조직에 따라 다릅니다. 이것은 테스트 계획 단계에서 협상되어야 하며 관련 프로젝트 이해 관계자와의 협의를 포함해야 합니다.

1.8 시험 종료 활동

테스트 실행이 완료되면 키 출력을 캡처하여 관련 사용자에게 전달하거나 보관해야 합니다. 집합 적으로 이들은 테스트 클로저 활동입니다. 테스트 클로저 활동은 네 가지 주요 그룹으로 분류됩니다.

1. 테스트 완료 확인 - 모든 테스트 작업이 실제로 완료되었는지 확인합니다. 예를 들어 모든 계획 테스트는 실행되거나 고의적으로 스킵 되어야 하며 알려진 모든 결함은 고정되어 있어야 하며 향후 테스트를 위해 테스트를 거쳤거나 영구적 인 제한 사항으로 받아 들여야 합니다.

2. 테스트 산출물 핸드 오버 - 필요한 작업 산출물을   사람들에게 전달합니다. 예를 들어, 지연되거나 수락 된 알려진 결함은 시스템 사용을 사용하고 지원하는 사람들에게 전달되어야 합니다. 테스트 및 테스트 환경은 유지 보수 테스트 담당자에게 제공되어야 합니다. 회귀 테스트 세트 (자동 또는 수동)를 문서화하여 유지 보수 팀에 전달해야 합니다.

3. 배운 교훈 - 테스트 프로젝트 내에서 그리고 전체 소프트웨어 개발 수명주기에 걸친 중요한 교훈이 문서화 될 수 있는 회고 회의를 수행하거나 참여할 수 있습니다. 이러한 회의에서는 좋은 사례가 반복 될 수 있고 빈약 한 사례가 반복되지 않거나 문제를 해결할 수 없는 경우 프로젝트 계획에 수용되도록 계획이 수립됩니다. 고려해야 할 영역은 다음과 같습니다:

a. 품질 위험 분석 세션의 사용자 표현이 폭 넓은 단면 이었습니까? 예를 들어 예상치 못한 결함 클러스터가 늦게 발견 되었기 때문에 팀은 미래의 프로젝트에 대한 품질 위험 분석 세션에 사용자 영역의 광범위한 섹션을 참여시켜야 한다는 사실을 발견했을 수 있습니다.

b. 견적이 정확 했습니까? 예를 들어 예상치가 크게 잘못 판단되었을 수 있으며, 따라서 미래의 추정 활동은 비효율적 인 테스트 또는 예상보다 실제적으로 낮은 예상과 같은 근본적인 원인과 함께 이를  설명 해야 합니다.

c. 결함의 원인과 영향 분석의 경향과 결과는 무엇입니까? 예를 들어, 늦은 변경 요청이 분석 및 개발의 품질에 영향을 미쳤는지 평가하고, 불량 사례(예를 들어, 결함을 이전보다 비용 효율적으로 발견 할 수 있는 테스트 레벨을 건너 뜀)를 나타내는 추세를 찾습니다. 결함 추세가 신기술, 직원 배치 변경 또는 기술 부족과 같은 영역과 관련 될 수 있는지 확인하십시오.

d. 잠재적 인 프로세스 개선 기회가 있습니까?

e. 향후 계획에 수용되어야 할 계획에서 예기치 않은 차이가 있었습니까?

4. 구성 관리 시스템에서 결과, 로그, 보고서 및 기타 문서 및 작업 제품을 보관합니다. 예를 들어, 테스트 계획과 프로젝트 계획은 계획 보관소에 저장되어야 하며 시스템과 버전에 명확하게 연결되어 있어야 합니다.

이러한 작업은 중요하며 종종 누락되어 테스트 계획의 일부로 명시 적으로 포함되어야 합니다.

일반적으로 프로젝트 팀 구성원의 조기 재 할당 또는 해고, 후속 프로젝트의 자원 또는 일정 압력 또는 팀 번아웃 으로 인해 이러한 작업 중 하나 이상을 생략 할 수 있습니다. 사용자 지정 개발과 같이 계약에 따라 수행되는 프로젝트의 경우 계약에서 필요한 작업을 지정 해야 합니다.

2. 테스트 관리 - 750 분.

키워드

레벨 테스트 계획, 마스터 테스트 계획, 제품 위험, 프로젝트 위험, 품질 위험, 위험, 위험 분석, 위험 평가, 위험 식별, 위험 수준, 위험 관리, 위험 완화, 위험 기반 테스트, 테스트 접근 방식, 테스트 조건, 테스트 제어, 테스트 디렉터, 테스트 추정, 테스트 리더, 테스트 레벨, 테스트 관리, 테스트 모니터링, 테스트 계획, 테스트 정책, 테스트 전략, Wide Band Delphi(노력을 추정하는 합의 기반 기술)

테스트 관리를 위한 학습 목표

2.2 상황에 따른 테스트 관리

TM-2.2.1 (K4) 소프트웨어 개발 라이프 사이클 모델을 비롯하여 소프트웨어 프로젝트 또는 프로그램의 이해 관계자, 상황 및 요구 사항을 분석하고 최적의 테스트 활동을 식별합니다.

TM-2.2.2 (K2) 소프트웨어 개발 라이프 사이클 활동 및 작업 제품이 테스트에 미치는 영향, 테스트가 소프트웨어 개발 수명주기 활동 및 제품 작동에 미치는 영향을 이해합니다.

TM-2.2.3 (K2) 경험 기반 테스트 및 비 기능 테스트와 관련된 테스트 관리 문제를 관리하는 방법을 설명하십시오. 

2.3 테스트 우선 순위 지정 및 노력 할당을 위한 위험 우선 테스트 와 기타 접근.

TM-2.3.1 (K2) 위험 기반 테스트가 위험에 대응하는 다양한 방법을 설명하십시오

TM-2.3.2 (K2) 제품 위험 분석을 위한 다양한 기술을 설명하고 예제를 제공합니다.

TM-2.3.3 (K4) 주요 프로젝트 이해 관계자 관점을 기반으로 위험 및 평가 된 위험 수준을 요약하여 제품 품질 위험을 분석, 식별 및 평가합니다.

TM-2.3.4 (K2) 수명주기 및 테스트 프로세스 전반에 걸쳐 평가 된 위험 수준에 따라 식별 된 제품 품질 위험을 완화하고 관리 할 수 있는 방법을 설명하십시오.

TM-2.3.5 (K2) 테스트 선택, 테스트 우선 순위 및 노력 할당에 대한 다양한 옵션의 예를 제시하십시오. 

2.4 시험 문서 및 기타 작업 산출물

TM-2.4.1 (K4) 주어진 테스트 정책 샘플 및 테스트 전략을 분석하고 마스터 테스트 계획, 레벨 테스트 계획 및 이 문서와 완벽하고 일관성 있는 기타 테스트 작업 산출물을 작성하십시오.

TM-2.4.2 (K4) 주어진 프로젝트의 경우 프로젝트 위험을 분석하고 적절한 위험 관리 옵션 (즉, 완화, 만일의 사태, 전이 및 / 또는 인수)을 선택하십시오.

TM-2.4.3 (K2) 시험 전략이 시험 활동에 어떻게 영향을 미치는 지 설명하고 예를 든다.

TM-2.4.4 (K3) 적용 가능한 경우 표준 기관에서 사용 가능한 템플릿을 적용하여 조직, 라이프 사이클 및 프로젝트 요구에 맞는 테스트 작업 제품을 위한 문서 규범 및 템플릿을 정의하십시오.

2.4 시험 문서 및 기타 작업 산출물

TM-2.4.1 (K4) 주어진 테스트 정책 샘플 및 테스트 전략을 분석하고 마스터 테스트 계획, 레벨 테스트 계획 및 이 문서와 완벽하고 일관성 있는 기타 테스트 작업 산출물을 작성하십시오.

TM-2.4.2 (K4) 주어진 프로젝트의 경우 프로젝트 위험을 분석하고 적절한 위험 관리 옵션 (즉, 완화, 만일의 사태, 전이 및 / 또는 인수)을 선택하십시오.

TM-2.4.3 (K2) 시험 전략이 시험 활동에 어떻게 영향을 미치는 지 설명하고 예를 든다.

TM-2.4.4 (K3) 적용 가능한 경우 표준 기관에서 사용 가능한 템플릿을 적용하여 조직, 라이프 사이클 및 프로젝트 요구에 맞는 테스트 작업 제품을 위한 문서 규범 및 템플릿을 정의하십시오.

2.5 테스트 평가

TM-2.5.1 (K3) 주어진 프로젝트의 경우 모든 적용 가능한 평가 기법을 사용하여 모든 테스트 프로세스 활동에 대한 예상치를 작성하십시오. TM-2.5.2 (K2) 시험 견적에 영향을 줄 수 있는 요소의 예를 이해하고 제시하십시오

2.6 테스트 메트릭스의 정의와 사용

TM-2.6.1 (K2) 일반적인 테스트 관련 메트릭을 기술하고 비교합니다.

TM-2.6.2 (K2) 테스트 진행 모니터링의 다양한 차원 비교

TM-2.6.3 (K4) 잔여 위험, 결함 상태, 테스트 실행 상태, 테스트 커버리지 상태 및 확신을 제공하여 프로젝트 이해 관계자가 릴리스 결정을 내릴 수 있도록 테스트 결과를 분석하고 보고합니다.

 2.7 테스트의 비즈니스 가치

TM-2.7.1 (K2) 품질 비용을 결정하는 네 가지 범주 각각에 대한 예제를 제공하십시오

TM-2.7.2 (K3) 기타 정량적 및 질적 고려 사항과 함께 품질 비용을 기준으로 테스트 가치를 추정하고 예상 가치를 테스트 관계자에게 알립니다.

 2.8 분산, 아웃소싱 및 인소싱 테스트

TM-2.8.1 (K2) 분산, 아웃소싱 및 인소싱 된 테스트 팀 인력 배치 전략의 성공적인 사용에 필요한 요소를 이해합니다.

 2.9 산업 표준의 응용 관리

TM-2.9.1 (K2) 소프트웨어 테스트를 위한 소스 및 표준 사용 요약

2.1 소개

고급 레벨에서는 시험 전문가를 위해 직업 전문화가 시작되었습니다. 이 장에서는 테스트 리더가 테스트 리더, 테스트 관리자 및 테스트 디렉터로 이동할 때 필요한 지식 영역에 중점을 둡니다. 이 강의 계획서에서 우리는 다른 조직이 그러한 직위에 있는 사람들의 직책과 책임 수준에 대해 서로 다른 정의를 갖게 된다는 것을 이해하고 시험 관리자로서 이 전문가들에게 집합 적으로 언급합니다.

 

2.2 상황에 따른 테스트 관리

관리자의 핵심 책임은 부가 가치 프로세스를 수행하기 위해 자원 (인력, 소프트웨어, 하드웨어, 인프라 등)을 보호하고 활용하는 것입니다. 소프트웨어 및 IT 관리자의 경우 프로세스는 종종 소프트웨어 또는 내부 또는 외부 사용을 위한 시스템을 제공하기 위한 프로젝트 또는 프로그램의 일부입니다. 시험 관리자의 경우, 시험은 시험과 관련된 사람들, 특히 기초 수준 시험 계획서와 이 강의 계획서 1 장에 설명 된 기본적인 시험 과정 활동입니다. 테스트 프로세스는 프로젝트 또는 프로그램의 전반적인 성공에 기여함으로써 (또는 더 심각한 유형의 실패를 방지함으로써) 가치를 추가하기 때문에 테스트 관리자는 그에 따라 테스트 프로세스를 계획하고 제어해야 합니다. 즉, 테스트 관리자는 다른 이해 관계자의 필요와 상황, 테스트 (테스트가 진행되는 소프트웨어 개발 수명주기) 및 해당 활동에 따라 관련 활동과 작업 결과를 포함한 테스트 프로세스를 적절히 조정해야 합니다. 작업 제품 (예 : 요구 사항 사양).

2.2.1 이해 관계자 테스트 이해

테스트의 이해 관계자들은 테스트 활동, 테스트 작업 제품 또는 최종 시스템 또는 산출물의 품질에 관심이 있는 사람들입니다. 이해 관계자의 관심은 테스트 활동에 직접 또는 간접적으로 관여하거나, 테스트 작업 제품을 직접 또는 간접적으로 수령하거나, 프로젝트 또는 프로그램에서 산출 한 산출물의 품질에 의해 직접 또는 간접적으로 영향을 미칠 수 있습니다.

테스트 이해 관계자는 프로젝트, 제품, 조직 및 기타 요소에 따라 다르지만 다음과 같은 역할을 포함 할 수 있습니다.

 

l  개발자, 개발 리드 및 개발 관리자 이러한 이해 관계자는 테스트중인 소프트웨어를 구현하고 테스트 결과를 수신하며 종종 이러한 결과에 따라 조치를 취해야 합니다 (예 :보고 된 결함 수정).

l  데이터베이스 설계자, 시스템 설계자 및 설계자 이러한 이해 관계자는 소프트웨어를 설계하고 테스트 결과를 수신하며 종종 이러한 결과에 대해 조치를 취해야 합니다.

l  마케팅 및 비즈니스 분석가. 이러한 이해 관계자는 소프트웨어에 존재해야 하는 기능 및 해당 기능에 내재 된 품질 수준을 결정합니다. 또한 이들은 종종 필요한 테스트 커버리지를 정의하고 테스트 결과를 검토하며 테스트 결과를 기반으로 의사 결정을 내리는 데 관여합니다.

l  고위 경영진, 제품 관리자 및 프로젝트 후원자. 이러한 이해 관계자는 필요한 테스트 커버리지를 정의하고 테스트 결과를 검토하며 테스트 결과를 기반으로 의사 결정을 내리는 데 종종 관여합니다. 프로젝트 관리자. 이러한 이해 관계자는 품질, 일정, 기능 및 예산 우선 순위의 균형을 유지해야 하는 성공 프로젝트를 관리 해야 합니다. 이들은 종종 테스트 활동에 필요한 리소스를 조달하고 테스트 계획 및 제어에서 테스트 관리자와 협력합니다.

l  기술 지원, 고객 지원 및 헬프 데스크 직원. 이러한 이해 관계자는 제공되는 소프트웨어의 기능 및 품질의 이점을 누리는 사용자 및 고객을 지원합니다. 직접 및 간접 사용자. 이러한 이해 관계자는 소프트웨어를 직접 사용 (즉, 최종 사용자)하거나 소프트웨어에 의해 생성되거나 지원되는 출력 또는 서비스를 수신합니다.

 

이해 관계자 테스트에 대한 자세한 내용은 [Goucher09]의 2 장을 참조하십시오.

이 이해 관계자 목록은 포괄적이지 않습니다. 테스트 매니저는 프로젝트 또는 프로그램에 대한 특정 테스트 관계자를 확인해야 합니다. 또한 테스트 관리자는 테스트를 통해 이해 관계자 관계의 정확한 특성과 테스트 팀이 이해 관계자의 요구를 충족시키는 방법을 이해해야 합니다. 위에 설명 된 테스트 담당자를 식별하는 것 외에도 테스트 관리자는 테스트에 영향을 미치거나 테스트의 영향을 받는 다른 소프트웨어 개발주기 활동을 식별하고 제품을 작동해야 합니다. 이 과정이 없으면 테스트 프로세스가 최적의 효율성과 효율성을 달성하지 못할 수도 있습니다 (2.2.3 절 참조).

2.2.2 추가 소프트웨어 개발주기 활동 및 작업 제품

소프트웨어 테스팅은 테스팅 활동 이외의 환경에서 생성 된 하나 이상의 작업 결과물의 품질을 평가하기 위한 것이므로, 대개의 소프트웨어 개발 라이프 사이클 활동의 맥락에서 존재합니다. 테스트 관리자는 Foundation Level 강의에서 논의 된 것처럼 다른 활동 및 작업 결과물이 테스트에 미치는 영향과 테스트가 이러한 다른 활동 및 작업 결과에 미치는 영향을 이해하면서 테스트 활동을 계획하고 안내해야 합니다.

예를 들어 민첩한 개발 방식을 사용하는 조직에서 개발자는 종종 테스트 중심 개발을 수행하고 자동화 된 단위 테스트를 작성하며 구성 관리 시스템에 코드 (코드에 대한 테스트와 함께)를 지속적으로 통합합니다. 테스트 관리자는 테스터가 이러한 활동에 통합되고 정렬되도록 개발 관리자와 협력해야 합니다. 테스터는 단위 테스트를 검토하여 이러한 테스트의 적용 범위와 효과성에 대한 제안을 제출하고 소프트웨어 및 구현에 대한 더 깊은 이해를 얻을 수 있습니다. 테스터는 자신의 자동화 된 테스트, 특히 기능 회귀 테스트를 구성 관리 시스템에 통합하는 방법을 평가할 수 있습니다. [Crispin09]

테스트 활동, 다른 테스트 이해 관계자, 소프트웨어 개발 수명주기 작업 활동 및 작업 제품 간의 특정 관계가 프로젝트, 선택한 소프트웨어 개발 수명주기 및 기타 다양한 요인에 따라 다르지만 테스트는 밀접하게 상호 연결되며 다음과 관련됩니다.

l  요구 사항 엔지니어링 및 관리. 테스트 관리자는 테스트 노력의 범위 지정 및 평가 과정에서 요구 사항을 고려해야 하며 요구 사항의 변경 사항을 숙지하고 이러한 변경 사항에 맞게 테스트 제어 작업을 수행해야 합니다. 기술 테스트 분석가와 테스트 분석가는 요구 사항 검토에 참여해야 합니다.

l  프로젝트 관리. 테스트 관리자는 테스트 분석가 및 기술 테스트 분석가와 함께 프로젝트 관리자에게 일정 및 리소스 요구 사항을 제공해야 합니다. 테스트 관리자는 프로젝트 관리자와 협력하여 프로젝트 계획의 변경 사항을 이해하고 변경 사항에 따라 테스트 제어 작업을 수행해야 합니다.

l  구성 관리, 릴리스 관리 및 변경 관리 테스트 관리자와 테스트 팀은 테스트 개체 전달 프로세스 및 메커니즘을 설정하고 테스트 계획의 메커니즘을 캡처해야 합니다. 테스트 관리자는 테스트 분석가 및 기술 테스트 분석가에게 빌드 확인 테스트를 만들고 테스트 실행 중 버전 제어를 보장하도록 요청할 수 있습니다.

l  소프트웨어 개발 및 유지 보수. 테스트 관리자는 개발 관리자와 협력하여 결함 관리에 참여 할 뿐만 아니라 각 테스트 릴리스의 내용과 날짜를 포함하여 테스트 객체의 전달을 조정해야 합니다 (4 장 참조).

l  기술적 지원. 테스트 관리자는 기술 지원 관리자와 협력하여 테스트 종료 중에 테스트 결과가 올바르게 전달되도록 하여 릴리스 이후 제품 지원과 관련된 사람들이 알려진 실패 및 해결 방법을 인식하도록 해야 합니다. 또한 테스트 관리자는 기술 지원 관리자와 협력하여 테스트 프로세스 개선을 구현하기 위해 생산 실패를 분석해야 합니다.

l  기술 문서 제작. 테스트 관리자는 Technical Documentation Manager (기술 문서 관리자)와 협력하여 적시에 테스트 용 문서를 제공하고 해당 문서의 결함 관리를 보장해야 합니다.

 위에서 설명한 테스트 이해 관계자를 확인하는 것 외에도 테스트 관리자는 테스트에 영향을 미치거나 테스트의 영향을 받는 다른 소프트웨어 개발주기 활동을 식별하고 제품을 작동시켜야 합니다. 그렇지 않은 경우 테스트 프로세스가 최적의 효율성과 효율성을 달성하지 못합니다.

2.2.3 시험 활동 및 기타 수명주기 활동의 정렬

테스트는 사용 된 소프트웨어 개발 모델에 관계없이 프로젝트의 필수적인 부분이어야 합니다. 여기에는 다음이 포함됩니다:

l  폭포수 모델, V- 모델 및 W- 모델과 같은 순차적 모델. 순차적 모델에서는 주어진 단계 (예: 요구 사항, 설계, 구현, 단위 테스트, 통합 테스트, 시스템 테스트 및 인수 테스트)의 모든 작업 결과와 활동이 다음 단계가 시작되기 전에 완료됩니다. 테스트 계획, 테스트 분석, 테스트 디자인 및 테스트 구현은 문제의 테스트 수준에 따라 오버랩의 정확한 특성과 함께 프로젝트 계획, 비즈니스 / 요구 사항 분석, 소프트웨어 및 데이터베이스 디자인 및 프로그래밍과 겹치는 방식으로 진행됩니다. 테스트 실습은 기초 수준 강의와 이 강의 계획서에서 논의 된 테스트 수준에 따라 순차적으로 진행됩니다.

l  RAD (Rapid Application Development; 급속도 어플리케이션 개발) 및 RUP (Rational Unified Process; 래셔널 통합 프로세스)와 같은 반복 또는 증분 모델. 반복 또는 증분 모델에서, 구현 될 피쳐들은 (예를 들어, 비즈니스 우선 순위 또는 리스크에 따라) 그룹화되고, 작업 제품 및 활동을 비롯한 다양한 프로젝트 단계가 각각의 피쳐 그룹에 대해 발생한다. 단계는 순차적으로 또는 중첩 된 방식으로 수행 될 수 있으며, 반복 자체는 순차적이거나 중첩 될 수 있다. 프로젝트를 시작하는 동안 프로젝트 계획 및 비즈니스 / 요구 사항 분석과 병행하여 고급 테스트 계획 및 테스트 분석이 진행됩니다. 겹쳐진 방식으로 각 반복의 시작 부분에 상세한 테스트 계획, 테스트 분석, 테스트 디자인 및 테스트 구현이 발생합니다. 테스트 실행에는 종종 테스트 레벨이 중첩됩니다. 각 테스트 레벨은 가능한 한 일찍 시작되며 이후의 높은 테스트 레벨이 시작된 후에 계속 될 수 있습니다.

l  SCRUM 및 익스트림 프로그래밍 (XP)과 같은 애자일. 이것은 반복이 매우 짧은 (종종 2 ~ 4 주) 반복적 인 주기입니다. 각 반복에 대한 작업 산출물 및 활동은 다음 반복이 시작되기 전에 완료됩니다 (즉, 반복은 순차적입니다). 테스트는 반복 모델과 유사하지만 테스트 활동 (다양한 수준에서)과 개발 활동이 상당히 중복되는 것을 포함하여 개발 활동과 다양한 테스트 활동의 중복 정도가 높습니다. 테스트 활동을 포함하여 반복되는 모든 활동은 다음 반복이 시작되기 전에 완료되어야 합니다. Agile 프로젝트에서 Test Manager의 역할은 대개 직속 관리 역할에서 기술 권한 / 권고 역할로 변경됩니다.

l  나선. 나선형 모델에서는 프로젝트 초기에 프로토 타입을 사용하여 실현 가능성을 확인하고 프로토 타이핑 실험이 수행되는 순서를 선택하는 비즈니스 우선 순위 및 기술적 위험 수준을 사용하여 설계 및 구현 결정을 실험합니다. 이 프로토 타입은 기술적 인 문제의 어떤 부분이 미해결인지를 결정하기 위해 테스트됩니다. 주요 기술적 문제가 해결되면 순차적 또는 반복적 모델에 따라 프로젝트가 진행됩니다.

라이프 사이클 내에서 테스트 활동을 적절히 조정하려면 테스트 관리자가 조직에서 사용되는 라이프 사이클 모델을 자세하게 이해해야 합니다. 예를 들어 V- 모델에서 시스템 테스트 레벨에 적용된 ISTQB 기본 테스트 프로세스는 다음과 같이 정렬 될 수 있습니다.

l  시스템 테스트 계획 작업은 프로젝트 계획과 동시에 이루어지며 시스템 테스트 실행 및 종료가 완료 될 때까지 테스트 제어가 계속됩니다.

l  시스템 테스트 분석 및 설계 활동은 요구 사항 명세, 시스템 및 아키텍처 (고수준) 설계 명세 및 구성 요소 (저수준) 설계 명세와 동시에 발생합니다.

l  이러한 활동의 ​​대부분은 일반적으로 코딩 및 구성 요소 테스트와 동시에 이루어 지지만 시스템 테스트 구현 활동은 시스템 테스트 실행을 시작하기 며칠 전부터 자주 확장되는 시스템 테스트 구현 활동에 대한 작업으로 시작될 수 있습니다.

l  시스템 테스트 실행 작업은 시스템 테스트 항목 기준이 모두 충족 (또는 철회) 될 때 시작됩니다. 이는 일반적으로 최소한 구성 요소 테스트와 종종 구성 요소 통합 테스트가 완료되었음을 의미합니다. 시스템 테스트 종료는 시스템 테스트 종료 기준이 충족 될 때까지 계속됩니다.

l  시스템 테스트 종료 평가 및 시스템 테스트 결과보고는 시스템 테스트 실행 전반에 걸쳐 발생하며 일반적으로 프로젝트 마감일이 가까워지면 빈도와 긴급도가 높아집니다.

l  시스템 테스트 종료 조건은 시스템 테스트 종료 기준이 충족되고 시스템 테스트 실행이 완료되었다고 선언 된 후에 발생하지만 인수 테스트가 끝나고 모든 프로젝트 활동이 끝날 때까지 지연 될 수 있습니다.

반복 또는 점진적 라이프 사이클에서 동일한 작업을 수행해야 하지만 타이밍과 범위는 다를 수 있습니다. 예를 들어, 프로젝트 초기에 전체 테스트 환경을 구현하는 것이 아니라 현재 반복에 필요한 부분 만 구현하는 것이 더 효율적일 수 있습니다. 반복 또는 점진적 라이프 사이클 모델 중 하나를 사용하면 계획이 훨씬 앞당겨 질수록 기본 테스트 프로세스의 범위가 확장 될 수 있습니다.

각 프로젝트에서 발생하는 계획 단계뿐 아니라 테스트 실행 및 보고는 팀에서 사용하는 수명주기의 영향을 받을 수도 있습니다. 예를 들어, 반복적 인 라이프 사이클에서 다음 반복의 시작 전에 완전한 보고서를 작성하고 사후 검토 세션을 수행하는 것이 효과적 일 수 있습니다. 각 반복을 미니 프로젝트로 처리함으로써 팀은 이전 반복 과정에서 발생한 문제를 기반으로 수정하고 조정할 수 있는 기회를 얻습니다. 반복 작업은 짧고 시간이 제한 될 수 있으므로 이 보고 및 평가에 소요되는 시간과 노력을 줄이는 것이 바람 직 할 수 있지만 작업은 전반적인 테스트 진행 상황을 추적하고 문제 영역을 신속하게 식별 할 수 있는 방법으로 수행되어야 합니다. 반복은 짧고 시간이 제한 될 수 있기 때문에 이 보고 및 평가에 소요되는 시간과 노력을 줄이는 것이 바람 직 할 수 있지만 작업은 전반적인 테스트 진행 상황을 추적하고 가능한 빨리 문제 영역을 식별하는 방법으로 수행되어야 합니다. 한 번의 반복에서 경험 한 프로세스 문제는 수정 조치가 취해지지 않으면 다음 반복에서 쉽게 영향을 받거나 반복됩니다.

테스트를 다른 라이프 사이클 활동과 정렬하는 방법에 대한 일반 정보는 테스트 전략에서 캡처 될 수 있습니다 (2.4.2 절 참조). 테스트 관리자는 테스트 계획 및 / 또는 프로젝트 계획 중 각 테스트 수준 및 선택한 소프트웨어 개발 라이프 사이클 및 테스트 프로세스 조합에 대해 프로젝트 별 맞춤을 수행해야 합니다.

조직, 프로젝트 및 제품의 필요에 따라 Foundation Level 강의에 정의 된 것 이외의 추가 테스트 레벨이 필요할 수 있습니다. 예를 들면 다음과 같습니다.

l  하드웨어 - 소프트웨어 통합 테스트

l  시스템 통합 테스트

l  기능 상호 작용 테스트

l  고객 제품 통합 테스트

각 테스트 레벨에는 다음 요소가 명확하게 정의되어 있어야 합니다.

l  달성 가능한 목표를 가진 테스트 목표

l  테스트 범위 및 테스트 항목

l  테스트 기준과 해당 기준의 범위를 측정하는 수단 (예 : 추적 성)

l  종료 기준

l  결과보고를 포함한 테스트 산출물

l  해당 테스트 기술 및 해당 기술을 사용하여 적절한 적용 범위

l  테스트 목표, 진입 및 퇴출 기준 및 결과보고 (적용 범위 측정 포함)와 관련된 측정 및 메트릭

l  특정 테스트 작업에 적용 할 테스트 도구 (해당되는 경우)

l  리소스 (예 : 테스트 환경)

l  테스트 팀 내부 및 외부의 책임 있는 개인 및 그룹 조직

l  규정 또는 기타 표준 준수 (적용 가능한 경우)

이 장의 뒷부분에서 설명하는 것처럼 모범 사례는 유사한 테스트의 여러 수준에서 낭비되고 위험한 간격을 피하기 위해 모든 테스트 수준에서 일관되게 이러한 요소를 정의하는 것입니다.

2.2.4 비 기능 테스트 관리

기능 외 테스트를 계획하지 않으면 출시 후 시스템에 심각한, 때로는 비참한 품질 문제가 발견 될 수 있습니다. 그러나 많은 유형의 비 기능 테스트는 비용이 많이 들기 때문에 테스트 관리자는 위험 및 제약 조건에 따라 수행 할 비 기능 테스트를 선택해야 합니다. 또한 여러 가지 유형의 비 기능 테스트가 있으며 그 중 일부는 해당 애플리케이션에 적합하지 않을 수 있습니다.

테스트 관리자는 모든 계획 고려 사항을 처리 할 수 있는 전문 지식이 충분하지 않기 때문에 테스트 관리자는 비 기능 테스트 활동에 할당 된 기술 테스트 분석가 (경우에 따라 테스트 분석가)에게 일부 테스트 계획 책임을 위임해야 합니다. 테스트 관리자는 분석가에게 다음과 같은 일반적인 요소를 고려해야 합니다.

l  이해 관계자 요구 사항

l  필요한 툴링

l  테스트 환경

l  조직적 요인

l  보안

자세한 내용은 고급 기술 테스트 분석가 요강 [ISTQB ATTA SYL]의 4 장을 참조하십시오.

테스트 관리자를 위한 또 다른 중요한 고려 사항은 비 기능 테스트를 소프트웨어 개발 라이프 사이클에 통합하는 방법입니다. 일반적인 실수는 비 기능 테스트를 시작하기 전에 모든 기능 테스트가 완료 될 때까지 기다리는 것이고, 이로 인해 중요한 기능 외 결함이 늦게 발견 될 수 있습니다. 대신, 비 기능적 테스트는 위험에 따라 우선 순위를 매기고 시퀀싱 해야 합니다. 초기 테스트 단계 또는 개발 중에도 기능 외 위험을 완화 할 수 있는 방법이 있습니다. 예를 들어, 시스템 설계 중에 사용자 인터페이스 프로토 타입의 유용성 검토는 시스템 테스트가 끝날 때 발견되는 중요한 일정 문제를 일으키는 사용 가능성 결함을 식별하는 데 매우 효과적 일 수 있습니다.

반복되는 라이프 사이클에서 변화와 반복의 속도는 정교한 테스트 프레임 워크의 구축을 요구하는 특정 비 기능 테스트에 초점을 맞추기 어려울 수 있습니다. 단일 반복의 시간 계보다 더 오래 걸리는 테스트 설계 및 구현 활동은 반복 외부의 별도 작업 활동으로 구성되어야 합니다.

2.2.5 경험 기반 테스트 관리

경험 기반 테스팅은 다른 테스팅 기법이 누락 될 수 있는 결함을 효율적으로 찾아내어 그 기술의 완전성을 검사하는 이점을 제공하지만 테스트 관리에 몇 가지 문제점을 제공합니다. 테스트 관리자는 경험 기반 기술, 특히 탐색 테스트의 이점뿐만 아니라 문제점을 인식하고 있어야 합니다. 전형적인 경량 로깅과 최소한의 고급 테스트 준비를 감안할 때 그러한 테스트 중 달성 한 적용 범위를 결정하는 것은 어렵습니다. 테스트 결과의 재연성은 특히 여러 명의 테스터가 관련되어있을 때 특별한 관리주의가 필요합니다.

경험 기반 테스트, 특히 탐색 적 테스트를 관리하는 한 가지 방법은 테스트 작업을 테스트 세션이라고도 하는 30 ~ 120 분의 작은 기간으로 나누는 것입니다.

이번에는 타임박스가 제한되고 세션에서 수행 할 작업에 중점을 두고 일정 수준의 모니터링 및 일정을 제공합니다. 각 세션에서는 시험 관리자가 서면 또는 구두로 테스터에게 전달하는 테스트 차터를 다룹니다. 테스트 차터는 테스트 세션에서 다루게 될 테스트 조건을 제공하여 여러 사람들이 동시에 탐색 테스트를 수행하는 경우 중점을 유지하고 중복을 방지하는 데 도움이 됩니다.

경험 기반 테스팅을 관리하는 또 다른 기법은 이러한 직접적이고 자발적인 테스팅을 보다 전통적인 사전 설계 테스팅 세션으로 통합하는 것입니다. 예를 들어, 테스터는 사전 정의 된 테스트에서 명시적인 단계, 입력 및 예상 결과를 넘어 탐험 할 수 있는 권한 (및 할당 된 시간)을 부여 받을 수 있습니다. 테스터는 사전 정의 된 테스트를 실행하기 전, 도중 또는 후에 일일 테스트의 일부로 그러한 자체 테스트 세션을 할당 받을 수 있습니다. 그러한 테스트 세션에서 향후 테스트를 위해 결함 또는 흥미 있는 영역을 식별하면 미리 정의 된 테스트가 업데이트 될 수 있습니다.

탐색 세션이 시작될 때 테스터는 테스트를 확인하고 필요한 설정 작업을 수행합니다. 세션 동안 테스터는 테스트중인 애플리케이션에 대해 학습하고, 적용되는 기술 및 애플리케이션에 대해 학습 된 내용에 따라 테스트를 설계 및 실행하고, 결함을 조사하고, 테스트 결과를 로그에 캡처합니다. (테스트의 반복성이 필요한 경우 테스터는 테스트 입력, 동작 및 이벤트도 기록해야 합니다.) 세션이 끝나면 후속 세션의 방향을 설정하는 디브리핑(보고하기)이 발생할 수 있습니다.

 

2.3 리스크-기반 테스트 및 우선 순위 지정 및 노력 할당을 위한 기타 테스트

 

범용 테스트 관리 과제는 테스트의 적절한 선택, 할당 및 우선 순위 지정입니다. 즉, 실질적으로 무한한 수의 테스트 조건 및 조건 조합이 적용될 수 있고, 테스트 팀은 유한 조건 집합을 선택하고 테스트 사례로 각 조건을 충당하기 위해 할당 할 적절한 노력을 결정해야하고, 테스트 케이스로 각 조건을 충당하기 위해 할당하려는 노력의 적절한 양을 결정하고, 그리고 테스트 케이스를 우선 순위에 따라 순서대로 배열하여 효율성을 최적화하고 테스트 작업의 효율을 높일 수 있습니다. 상호 작용하는 많은 제약 조건과 변수가 타협된 솔루션을 필요로 할지도 모르지만 다른 요인과 함께 위험 식별 및 분석을 이 문제를 해결하는 데 도움을 주기 위해 Test Manager가 사용할 수 있습니다.

 

2.3.1 위험 기반 테스트

위험은 부정적이거나 바람직하지 않은 결과 또는 사건의 가능성입니다. 고객, 사용자, 참가자 또는 제품 품질 또는 프로젝트 성공에 대한 이해 관계자의 인식을 감소시키는 문제가 발생할 때마다 위험이 존재합니다. 잠재적 인 문제의 주요 효과가 제품 품질에 있는 경우 잠재적 인 문제를 품질 위험, 제품 위험 또는 제품 품질 위험이라고 합니다. 잠재적 인 문제의 주요 효과가 프로젝트 성공에 있는 경우, 잠재적 인 문제를 프로젝트 위험 또는 계획 위험이라고 합니다.

위험 기반 테스팅에서는 이해 관계자와의 제품 품질 위험 분석 과정에서 품질 위험을 확인하고 평가합니다. 그런 다음 테스트 팀은 품질 위험을 줄이기 위해 테스트를 설계, 구현 및 실행합니다. 품질에는 고객, 사용자 및 이해 관계자 만족도에 영향을 주는 기능, 동작, 특성 및 속성의 전체가 포함됩니다. 따라서 품질 위험은 제품에 품질 문제가 존재할 수 있는 잠재적 인 상황입니다. 시스템에 대한 품질 위험의 예로는 보고서의 잘못된 계산 (정확도와 관련된 기능상의 위험), 사용자 입력 (응답 및 응답 시간과 관련된 기능 외 위험) 및 화면 및 필드 이해 어려움 유용성 및 이해 가능성과 관련된 기능적 위험). 테스트 결과 결함이 발견되면 테스트를 통해 결함에 대한 인식을 제공하고 릴리즈 전에 품질 위험을 사전에 처리 할 수 ​​있습니다. 테스트에서 결함이 발견되지 않으면 테스트를 통해 테스트 된 조건에서 시스템이 올바르게 작동하는지 확인함으로써 품질 위험을 완화했습니다.

 

위험 기반 테스트는 제품 품질 위험을 사용하여 테스트 조건을 선택하고 해당 조건에 테스트 노력을 할당하며 결과 테스트 사례의 우선 순위를 정합니다. 수집 된 문서의 유형과 수준 및 적용되는 형식 수준 모두에서 상당한 차이가 있는 위험 기반 테스트를 위한 다양한 기술이 있습니다. 명시 적이든 묵시적이든 상관없이 위험 기반 테스트는 전반적인 품질 위험 수준을 줄이기 위해 테스트를 사용하고 특히 위험 수준을 허용 가능한 수준으로 낮추는 것을 목표로 합니다.

위험 기반 테스트는 네 가지 주요 활동으로 구성됩니다.

l  리스크 식별

l  리스크 평가

l  리스크 완화

l  리스크 관리

이러한 활동은 중복됩니다. 다음 하위 섹션에서는 이러한 각 활동에 대해 설명합니다.

가장 효과적이기 위해서는 프로젝트의 현실성으로 인해 일부 이해 관계자가 다른 이해 관계자의 대리 역할을 하게 될 수도 있지만 위험 식별 및 평가에는 모든 프로젝트 및 제품 이해 관계자 그룹의 대표자가 포함되어야 합니다. 예를 들어, 대중 시장 소프트웨어 개발에서는 잠재적 인 고객의 작은 샘플이 소프트웨어 사용에 가장 큰 영향을 줄 수 있는 잠재적 인 결함을 식별하는 데 도움을 요청 받을 수 있습니다. 이 경우 잠재 고객의 샘플은 전체 최종 고객 기반의 대리 역할을 합니다. 테스터는 제품 품질 위험 및 실패에 대한 전문 지식으로 인해 위험 식별 및 평가 프로세스에 적극적으로 참여해야 합니다.

 

2.3.1.1 리스크 식별

이해 관계자는 다음 기술 중 하나 이상을 통해 위험을 식별 할 수 있습니다.

l  전문가 인터뷰

l  독립적 인 평가

l  위험 요소 템플릿 사용

l  프로젝트 회고

l  위험 워크샵

l  브레인 스토밍

l  점검표

l  과거 경험에 대한 호출

가능한 가장 광범위한 이해 관계자 샘플을 포함시킴으로써 위험 식별 프로세스는 제품 품질 위험의 대부분을 식별 할 가능성이 높습니다.

위험 식별은 종종 부산물, 즉 제품 품질 위험이 아닌 문제의 식별을 생성합니다. 예제에는 제품 또는 프로젝트에 대한 일반적인 질문 또는 문제 또는 요구 사항 및 디자인 사양과 같은 참조 된 문서의 문제가 포함됩니다. 프로젝트 위험도는 종종 품질 위험 식별의 부산물로 식별되지만 위험 기반 테스트의 주요 초점은 아닙니다. 그러나 프로젝트 리스크 관리는 리스크 기반 테스트뿐만 아니라 모든 테스트에서 중요하며 2.4 절에서 더 자세히 논의됩니다.

2.3.1.2 리스크 평가

일단 위험 식별이 이루어지면 위험 평가를 시작할 수 있으며 이러한 위험을 연구 할 수 있습니다. 특히 위험 평가에는 각 위험을 범주화하고 각 위험과 관련된 가능성 및 영향을 결정해야 합니다. 위험 평가는 또한 위험 소유자와 같은 각 위험의 다른 속성을 평가하거나 할당하는 것을 포함 할 수 있습니다.

위험 범주화는 각 위험 요소를 성능, 안정성, 기능 등과 같은 적절한 유형으로 배치하는 것을 의미합니다. 일부 조직에서는 분류를 위해 ISO 9126 표준 [ISO9126] (ISO 25000 표준 [ISO25000]으로 대체 됨) 품질 특성을 사용하지만 많은 조직에서는 다른 분류 체계를 사용합니다.

위험 식별을 위해 사용되는 동일한 체크리스트는 종종 위험을 분류하는 데 사용됩니다. 일반적인 품질 위험 체크리스트가 존재하며 많은 조직에서 이러한 체크리스트를 사용자 정의합니다. 위험 식별의 기초로 체크리스트를 사용할 때, 식별 과정에서 위험의 범주화가 종종 발생합니다.

위험 수준 결정에는 일반적으로 각 위험 항목에 대해 발생할 가능성과 발생시 영향을 평가해야 합니다. 발생 확률은 잠재적 인 문제가 테스트중인 시스템에 존재할 확률입니다. 즉, 가능성은 기술 위험 수준의 평가입니다. 제품 및 프로젝트 위험 가능성에 영향을 미치는 요소에는 다음이 포함됩니다:

l  기술과 팀의 복잡성

l  비즈니스 분석가, 디자이너 및 프로그래머 간의 인사 및 교육 문제

l  팀 내 분쟁

l  공급자와의 계약 문제

l  지리적으로 분산 된 팀

l  레거시 대 새로운 접근법

l  도구 및 기술

l  약한 관리 또는 기술적 리더십

l  시간, 자원, 예산 및 관리 압력

l  초기 품질 보증 활동의 부재

l  높은 변화율

l  높은 초기 불량률

l  인터페이스 및 통합 문제

발생시의 영향은 사용자, 고객 또는 기타 이해 관계자에게 미치는 영향의 심각도입니다. 프로젝트 및 제품 위험에 영향을 미치는 요소에는 다음이 포함됩니다:

l  영향을 받은 기능의 사용 빈도

l  비즈니스 목표 달성을 위한 기능의 중요성

l  평판에 대한 피해

l  사업 상 손실

l  잠재적 인 경제적, 생태적 또는 사회적 손실 또는 책임

l  민사 또는 형사상의 법적 제재

l  면허 소실

l  합리적인 해결 방법 부족

l  부정적인 홍보로 이어지는 실패의 가시성

l  안전

위험 수준은 정량적으로나 질적으로 평가 될 수 있습니다. (어떤 일이 있을) 공산[가능성]과 영향을 정량적으로 확인할 수 있다면 두 값을 곱하여 양적 위험 우선 순위 수를 계산할 수 있습니다. 그러나 일반적으로 위험 수준은 질적으로 만 확인할 수 있습니다. 즉, 가능성이 매우 높음, 높음, 보통, 낮음 또는 매우 낮음을 말할 수 있지만 실제 정확도가 있는 비율로 확률을 표현할 수는 없습니다. 이와 유사하게 영향이 매우 높거나, 높음, 보통, 낮음 또는 매우 낮다고 말할 수는 있지만 재무 적 측면에서 완전하고 정확한 방식으로 영향을 표현할 수는 없습니다. 이러한 위험 수준의 정성적 평가는 정량적 접근법보다 열등하지 않아야 한다. 실제로 위험 수준의 정량적 평가가 부적절하게 사용될 때, 결과는 실제로 위험을 이해하고 관리 할 수 있는 범위에 대해 이해 관계자를 오도합니다. 위험 수준의 정성적 평가는 종종 곱셈 또는 추가를 통해 합산 된 위험 점수를 생성합니다. 이 총 위험 점수는 위험 우선 순위 번호로 표현 될 수 있지만 서수 비율에 대한 질적 인 상대적 등급으로 해석되어야 합니다.

또한 위험 분석이 광범위하고 통계적으로 유효한 위험 데이터를 기반으로 하지 않는 한 위험 분석은 주주의 주관적 가능성 및 영향에 대한 인식을 기반으로 합니다. 프로젝트 관리자, 프로그래머, 사용자, 비즈니스 분석가, 설계자 및 테스터는 일반적으로 각기 다른 지각을 가지므로 각 위험 항목의 위험 수준에 대한 의견이 다를 수 있습니다.

 위험 분석 프로세스에는 합의에 도달하거나 최악의 경우 동의 수준을 설정하는 방법이 포함되어야 합니다 (예 : 경영진의 지시 또는 위험 항목의 평균, 중앙값 또는 모드 수준 취하기). 또한, 위험 수준은 시험 순서, 우선 순위 및 노력 배분 측면에서 의미 있는 지침을 제공 할 수 있도록 범위를 통해 양호한 분배가 이루어 지도록 점검되어야 합니다. 그렇지 않으면 위험 수준을 위험 완화 활동의 가이드로 사용할 수 없습니다.

2.3.1.3 위험 완화

위험 기반 테스트는 품질 위험 분석 (제품 품질 위험 파악 및 평가)으로 시작됩니다. 이 분석은 마스터 테스트 계획 및 기타 테스트 계획의 기초입니다. 계획에 명시된 대로 위험을 감당하기 위해 테스트가 설계, 구현 및 실행됩니다. 테스트 개발 및 실행과 관련된 노력은 위험 수준에 비례합니다. 테스트 개발 및 실행과 관련된 노력은 위험 수준에 비례하는데 이는 더 높은 위험에 대해 보다 세심한 테스트 기술 (쌍 테스트)을 사용한다는 것을 의미하고,적은 위험에 대해서는 세심한 테스트 기술 (예 : 동등한 파티셔닝 또는 타임 박스 탐색 테스트)을 사용합니다. 또한 테스트의 개발 및 실행의 우선 순위는 위험 수준에 따라 결정됩니다. 일부 안전 관련 표준 (예 : FAA DO-178B / ED 12B, IEC 61508)은 위험 수준에 따라 테스트 기법 및 적용 범위를 규정합니다. 또한 위험 수준은 프로젝트 작업 제품 검토 (테스트 포함), 독립 수준, 테스터 경험 수준 및 확인 테스트 (재 테스팅) 정도와 같은 결정에 영향을 주어야 합니다. 회귀 테스트가 수행되었습니다. 프로젝트 동안 테스트 팀은 알려진 품질 위험과 관련된 품질 위험 집합 및 / 또는 위험 수준을 변경하는 추가 정보를 알고 있어야 합니다. 테스트에 대한 조정을 초래하는 품질 위험 분석의 주기적 조정이 이루어져야 합니다. 이러한 조정은 적어도 주요 프로젝트 일정에서 이루어져야 합니다. 조정에는 새로운 위험 파악, 기존 위험 수준 재평가, 위험 완화 활동의 효과 평가 등이 포함됩니다. 예를 들어, 요구 사항 단계에서 요구 사항 사양을 기반으로 위험 식별 및 평가 세션이 발생하면 일단 설계 사양이 완성되면 위험을 다시 평가해야 합니다. 다른 예를 들자면, 테스트하는 동안 구성 요소에 예상되는 결함 수보다 많은 수의 결함이 포함되어있는 것으로 밝혀지면 이 영역의 결함 확률이 예상보다 높다는 결론을 내릴 수 있으며 따라서 위험의 가능성과 전반적인 수준을 상향 조정할 수 있습니다. 이로 인해 이 구성 요소에 대해 수행 할 테스트의 양이 증가 할 수 있습니다.

테스트 실행이 시작되기 전에 제품 품질 위험도 완화 될 수 있습니다. 예를 들어 위험 식별 중에 요구 사항 문제가 있는 경우 프로젝트 팀은 철저한 요구 사항 검토를 완화 조치로 구현할 수 있습니다. 이렇게 하면 위험 수준이 낮아질 수 있으므로 나머지 품질 위험을 완화하기 위해 필요한 테스트가 줄어 듭니다.

2.3.1.4 생명주기에 있는 리스크 관리

이상적으로는 전체 라이프 사이클에서 리스크 관리가 발생합니다. 조직에 테스트 정책 문서 및 / 또는 테스트 전략 문서가 있는 경우 테스트에서 제품 및 프로젝트 위험을 관리하는 일반적인 프로세스를 설명하고 위험 관리가 테스트의 모든 단계에 어떻게 통합되고 영향을 미치는지 보여 주어야 합니다.

위험 의식이 프로젝트 팀에 퍼져있는 성숙한 조직에서 위험 관리는 테스트뿐만 아니라 여러 단계에서 발생합니다. 중요한 위험 요소는 특정 테스트 레벨 이전에 다루어 질뿐만 아니라 초기 테스트 레벨에서도 다루어집니다. (예를 들어, 성능이 핵심 품질 위험 영역으로 확인되면 시스템 테스트 초기에 성능 테스트가 시작될 뿐만 아니라 유닛 및 통합 테스트 중에 성능 테스트가 실행됩니다.) 성숙한 조직은 위험을 식별 할뿐만 아니라 소스를 식별합니다 위험의 결과와 그러한 위험의 결과는 결과가 되어야 합니다. 이러한 결함이 발생하는 경우 근본 원인 분석을 통해 위험 원천을 보다 깊이 이해하고 처음부터 결함을 예방하는 프로세스 개선을 구현합니다. 소프트웨어 개발 수명주기 전반에 걸쳐 완화 요소가 존재합니다.

 관련 작업 활동, 시스템 동작 분석, 비용 기반 위험 평가, 제품 위험 분석, 최종 사용자 위험 분석 및 책임 위험 분석을 고려하여 위험 분석에 대한 충분한 정보가 제공됩니다. 위험 분석은 테스트를 초월하여 테스트 팀이 프로그램 차원의 위험 분석에 참여하고 영향을 미칩니다.

대부분의 위험 기반 테스트 방법에는 위험 수준을 사용하여 테스트 순서를 지정하고 우선 순위를 지정하는 기술이 포함되어 있으므로 테스트 실행 중 가장 중요한 영역을 조기에 파악하고 가장 중요한 결함을 발견 할 수 있습니다. 경우에 따라 위험도가 가장 높은 테스트는 위험도가 낮은 테스트보다 먼저 실행되며 테스트는 엄격한 위험 순서 (종종 "깊이 우선"이라고도 함)로 실행됩니다. 다른 경우, 표본 추출 접근법은 모든 위험 항목을 적어도 한 번 ("너비 우선"이라고도 함) 적용 범위를 보장하면서 선택 항목에 가중치를 주는 위험을 사용하여 식별 된 모든 위험 항목에 대한 테스트 샘플을 선택하는 데 사용됩니다 .

위험 기반 테스팅이 깊이 우선인지 너비 우선인지에 관계없이 모든 테스트를 실행하지 않고 테스트에 할당 된 시간이 소비 될 수 있습니다. 리스크 기반 테스팅을 통해 테스터는 현 시점에서 리스크의 잔존 정도를 관리 부서에 보고 할 수 있으며, 테스트를 연장할지 또는 사용자, 고객, 헬프 데스크 / 기술 지원부 / 또는 운영 직원에 나머지 위험을 이전할지 결정할 수 있습니다.

테스트를 실행하는 동안 가장 정교하거나 위험한 테스트 기법을 사용하여 프로젝트 참가자, 프로젝트 및 제품 관리자, 임원, 고위 관리자 및 프로젝트 이해 관계자가 소프트웨어 개발을 모니터링하고 제어 할 수 있습니다 잔류 위험 수준을 기준으로 출시 결정을 하는 등의 이를 위해서는 각 테스트 관계자가 이해할 수 있는 방식으로 테스트 매니저가 위험 측면에서 테스트 결과를 보고해야 합니다.

2.3.2 위험 기반 테스트 기법

위험 기반 테스트에는 여러 가지 기법이 있습니다. 이 기술 중 일부는 고도의 비공식적 인 기술입니다. 예를 들면 시험 검사자가 시험 적 검사 중에 품질 위험을 분석하는 접근법을 포함한다 [Whittaker09]. 이는 테스트를 안내하는 데 도움이 될 수 있지만 결함이 아닌 영향 가능성에 과도하게 중점을 둘 수 있으며 여러 기능을 수행하는 이해 관계자의 의견을 포함하지 않습니다. 또한 이러한 접근법은 주관적이며 개별 테스터의 기술, 경험 및 선호도에 따라 달라집니다. 따라서 이러한 접근법은 거의 위험 기반 테스트의 모든 이점을 얻지 못합니다.

비용을 최소화하면서 위험 기반 테스팅의 이점을 포착하기 위해 많은 실무자가 가벼운 리스크 기반 접근법을 사용합니다. 이들은 비공식적 인 접근법의 반응과 유연성을 보다 공식적인 접근 방식의 힘과 일치 된 의견으로 조화시킨다. 경량 접근법의 예로는 PRAM (Pragmatic Risk Analysis and Management) [Black09], SST (Systematic Software Testing) [Craig02] 및 PRM (Product Risk Management) [vanVeenendaal12] 등이 있습니다. 이러한 기술은 일반적으로 위험 기반 테스트의 일반적인 특성 외에도 다음과 같은 특성을 가지고 있습니다:

l  특히 위험 기반 테스트를 통해 업계 경험을 토대로 시간이 지남에 따라 발전했습니다.

l  초기 위험 식별 및 평가 중에 비즈니스 및 기술적 관점 모두를 대표하는 다양한 이해 관계자 팀의 광범위한 참여를 기반으로 합니다.

l  프로젝트 초기 단계, 품질 위험을 완화하는 옵션이 최대화 될 때 및 위험 분석의 주 작업 제품 및 제품이 위험을 최소화하는 방식으로 제품의 사양 및 구현에 영향을 줄 수 있을 때 도입 될 때 최적화됩니다.

l  생성 된 결과 (위험 매트릭스 또는 위험 분석 테이블)를 테스트 계획 및 테스트 조건의 기초로 사용하고 따라서 모든 후속 테스트 관리 및 분석 활동을 사용합니다.

l  테스트 참여자의 모든 레벨에 대한 잔여 위험 측면에서 테스트 결과의 보고를 지원합니다.

이러한 기술 중 일부 (예 : SST)는 위험 분석에 대한 입력 사항으로 요구 사항 사양을 요구하며 요구 사항 사양이 제공되는 경우를 제외하고는 사용할 수 없습니다.

 다른 기술 (예 : PRisMa 및 PRAM)은 위험 분석에 대한 입력으로 요구 사항 및 / 또는 기타 사양을 사용하여 혼합 된 위험 및 요구 사항 기반 전략의 사용을 권장하지만 이해 관계자의 입력을 기반으로 전적으로 기능 할 수 있습니다. 요구 사항을 입력으로 사용하면 요구 사항을 잘 파악하는 데 도움이 되지만 테스트 관리자는 요구 사항에서 제안하지 않은 중요한 위험 (특히 기능 외 영역)을 놓치지 않도록 해야 합니다. 우선 순위가 높은 요구 사항이 입력으로 제공되면 일반적으로 위험 수준과 요구 사항 우선 순위간에 강력한 상관 관계가 있습니다.

이러한 기술 중 많은 부분은 위험 접근 및 평가 프로세스의 사용을 테스트 접근법에 대한 이해 관계자 간의 합의를 도출하는 방법으로 장려합니다. 이것은 강력한 이점이지만 이해 관계자가 그룹 브레인 스토밍 세션 또는 일대일 인터뷰에 참여할 시간을 할애해야 합니다. 부족한 이해 관계자 참여로 인해 위험 분석에 틈이 생깁니다. 물론 이해 관계자가 위험 수준에 동의하는 것은 아니므로 품질 위험 분석 노력을 이끌어가는 사람은 최선의 합의 정도를 달성하기 위해 이해 관계자와 창의적이고 적극적으로 노력해야 합니다. 숙련 된 중재자 평가 회의에 대한 모든 기술은 품질 위험 분석을 이끌어내는 사람에게 적용 할 수 있습니다.

좀 더 공식적인 기술처럼 가벼운 기술을 사용하면 비즈니스 또는 기술 위험을 강조하는 우도 및 영향 요인의 가중치를 사용할 수 있습니다 (예: 테스트 수준에 따라 다름). 하지만 좀 더 공식적인 기술과 달리 가벼운 기술입니다.

l  가능성과 영향의 두 가지 요인 만 사용하십시오;그리고,

l  간단하고 질적 인 판단과 척도를 사용하십시오.

이러한 접근 방식의 경량 성은 융통성, 다양한 도메인에서의 적용 가능성, 모든 경험 및 기술 수준 (비 기술적 인 사람 및 중학생이더라도) 간의 팀 전반에 대한 접근성을 제공합니다.

공식적이고 보통보다 큰 규모의 끝에 Test Manager는 다양한 옵션을 사용할 수 있습니다:

l  위험 분석: 업스트림에서 분석 프로세스를 확장하여 각 위험의 기초가 되는 위험을 식별합니다.

l  위험 평가 프로세스에서 각 품질 위험 항목에 대해 다음 세 가지 요인을 결정하는 작업과 관련된 노출 비용. 1) 위험 항목과 관련된 실패의 가능성 (백분율로 표시). 2) 위험 항목과 관련된 전형적인 실패와 관련된 손실 비용 (재정적 인 양으로 표현됨). 3) 그러한 실패에 대한 테스트 비용.

l  품질 위험, 그 잠재적 인 원인 및 그 가능한 영향을 확인한 후 심각도, 우선 순위 및 탐지 등급이 지정된 고장 모드 및 영향 분석 (FMEA) 및 그 변종 [Stamatis03].

l  QFD (Quality Function Deployment)는 테스트의 함의, 특히 고객 또는 사용자 요구 사항에 대한 부정확하거나 불충분 한 이해로 인해 발생하는 품질 위험과 관련한 품질 위험 관리 기술입니다.

l  Fault Tree Analysis (FTA)는 고장을 일으킬 수 있는 결함부터 시작하여 오류 또는 결함이 있는 근본 원인 분석의 대상이 되는 다양한 실제 관찰 된 고장 (시험 또는 생산) 또는 잠재적 고장 (품질 위험) 여러 가지 근본 원인이 확인 될 때까지 계속해서 결함을 일으킬 수 있습니다.

위험 기반 테스트에 사용되어야 하는 특정 기술과 각 기법의 형식은 프로젝트, 프로세스 및 제품 고려 사항에 따라 다릅니다. 예를 들어 Whittaker의 탐색 기술과 같은 비공식적 인 접근법은 패치 또는 빠른 수정에 적용될 수 있습니다. 민첩한 프로젝트에서는 품질 위험 분석을 각 스프린트의 초기 단계에 완전히 통합하고 위험에 대한 문서화를 사용자 스토리 추적에 혼합합니다. 시스템 시스템은 각 시스템과 전체 시스템의 위험 분석이 필요합니다. 안전과 업무에 필수적인 프로젝트는 높은 수준의 형식과 문서화가 필요합니다.

리스크 기반 테스트를 위한 투입물, 프로세스 및 산출물은 선택된 기술에 의해 결정되는 경향이 있다. 공통 입력에는 이해 관계자 통찰력, 사양 및 기록 데이터가 포함됩니다. 일반적인 프로세스에는 위험 식별, 위험 평가 및 위험 제어가 포함됩니다. 전체적으로 일반적인 결과물에는 품질 위험 목록 (관련 위험 수준 및 테스트 노력 권장), 사양과 같은 입력 문서에서 발견 된 결함, 위험 항목과 관련된 질문 또는 문제점, 테스트 또는 프로젝트에 영향을 주는 프로젝트 위험 목록이 포함됩니다.

 

일반적으로 위험 기반 테스트의 가장 중요한 성공 요인은 위험 파악 및 평가에 올바른 이해 관계자 팀의 참여입니다. 모든 이해 관계자는 제품의 품질 구성 요소와 품질에 대한 우선 순위 및 우려 사항에 대해 자체적으로 이해합니다. 그러나 이해 관계자는 비즈니스 이해 관계자와 기술적 이해 관계자라는 두 가지 범주로 구분됩니다.

 

비즈니스 이해 관계자에는 고객, 사용자, 운영 직원, 헬프 데스크 및 기술 지원 직원 등이 포함됩니다. 이러한 이해 관계자는 고객 및 사용자를 이해하므로 위험을 식별하고 비즈니스 관점에서 영향을 평가할 수 있습니다.

 

기술적 이해 관계자에는 개발자, 설계자, 데이터베이스 관리자 및 네트워크 관리자 등이 포함됩니다. 이해 관계자는 소프트웨어가 실패 할 수 있는 방식으로 위험을 식별하고 기술적 인 관점에서 가능성을 평가할 수 있습니다.

 

일부 이해 관계자는 비즈니스와 기술적 관점을 모두 가지고 있습니다. 예를 들어, 테스트 또는 비즈니스 분석 역할을 담당하는 분야별 전문가는 기술 및 비즈니스 전문 지식으로 인해 위험에 대해보다 폭 넓은 시각을 가지고 있습니다.

 

위험 항목을 식별하는 프로세스는 상당한 위험 목록을 생성하는 프로세스입니다. 이해 관계자가 위험 항목에 대해 논할 필요는 없습니다. 한 이해 관계자가 시스템의 품질에 대한 위험으로 인식하는 한 위험 요소입니다. 그러나 이해 관계자가 위험 수준에 대한 등급에 대한 합의를 이끌어내는 것이 중요합니다. 예를 들어, 공산 및 영향을 평가 요인으로 사용하는 경량 접근법에서 프로세스의 일부는 우연과 영향에 대한 공통 순위 체계를 찾는 것을 포함해야 합니다. 테스트 그룹을 포함한 모든 이해 관계자는 동일한 규모를 사용해야 하며 각 품질 위험 항목에 대한 단일 가능성 및 영향 등급에 수렴 할 수 있어야 합니다.

위험 기반 테스트를 장기간 사용하려면 테스트 관리자가 이해 관계자와의 위험 기반 테스트를 성공적으로 옹호하고 시작해야 합니다. 교차 기능 그룹은 기술의 지속적인 사용을 보장하기 위해 위험 분석의 가치를 알아야 합니다. 이를 위해서는 테스트 관리자가 이해 관계자의 필요, 기대 및 프로세스 가용성에 대한 시간을 이해해야 합니다.

품질 위험 분석 프로세스에 대한 이해 관계자의 적극적인 참여는 Test Manager에게 중요한 이점을 제공합니다. 이러한 이점은 요구 사항이 약하거나 부족한 특정 요건을 충족하지 못하는 프로젝트에서 적절한 체크리스트를 사용하여 이해 관계자가 위험을 식별 할 수 있다는 것입니다. 이 이점은 위험 기반 테스트의 구현 후 테스트 팀의 결함 탐지 효율성이 향상 될 때 나타납니다. 이것은 보다 완벽한 테스트 기준 (이 경우 품질 위험 항목 목록)이 사용되기 때문에 발생합니다.

위험 기반 테스트를 위한 테스트 클로저 동안 테스트 팀은 이점을 실현 한 정도를 측정해야 합니다. 많은 경우, 이는 팀과의 통계 및 협의를 통해 다음 네 가지 질문 중 일부 또는 전부에 대답하는 것입니다.

l  테스트 팀이 덜 중요한 결함보다 중요한 결함의 더 많은 부분을 감지 했습니까?

l  테스트 팀은 테스트 실행 초기에 중요한 결함 대부분을 발견 했습니까?

l  테스트 팀은 테스트 결과를 위험 측면에서 이해 관계자에게 설명 할 수 있었습니까?

l  테스트 팀이 건너 뛴 테스트 (있는 경우)가 실행 된 것보다 연관된 위험 수준이 낮습니까?

대부분의 경우 위험 기반 테스트를 성공적으로 수행하면 네 가지 질문에 모두 긍정적 인 답변이 됩니다. 장기적으로 테스트 관리자는 품질 위험 분석 프로세스의 효율성을 높이기 위해 이러한 측정 기준에 대한 프로세스 개선 목표를 설정해야 합니다. 물론 다른 메트릭스와 성공 기준을 리스크 기반 테스트에도 적용 할 수 있으며, 테스트 관리자는 이러한 메트릭 간의 관계, 그리고 테스트 팀이 제공하는 전략적 목표, 특정 측정 항목 및 성공 기준 세트를 기반으로 하는 관리로 인해 발생할 행동을 신중하게 고려해야 합니다.

 

2.3.3 시험 선택을 위한 다른 기술

많은 테스트 매니저가 리스크 기반 테스트를 테스트 전략의 한 요소로 채택하고 있지만, 대부분의 테스트 매니저는 다른 기술도 포함하고 있습니다.

테스트 조건을 개발하고 우선 순위를 정하는 데 가장 눈에 띄는 대체 기술 중 하나는 요구 사항 기반 테스팅입니다. 요구 사항 기반 테스트는 모호성 검토, 테스트 조건 분석 및 원인 효과 그래프 작성과 같은 여러 기술을 활용할 수 있습니다. 모호성 검토는 공통 요구 사항 결함 목록 ([Wiegers03] 참조)을 사용하여 요구 사항의 모호성을 확인하고 테스트 기준으로 사용되는 모호성을 제거합니다.

[Craig02]에 설명 된 대로 테스트 조건 분석에는 테스트 조건을 파악하기 위해 요구 사항 사양을 자세히 읽는 것이 포함됩니다. 이러한 요구 사항에 우선 순위가 할당 된 경우 이를 사용하여 노력을 할당하고 테스트 사례의 우선 순위를 지정할 수 있습니다. 할당 된 우선 순위가 없는 경우 위험 기반 테스트와 요구 사항 기반 테스팅을 혼합하지 않고 적절한 노력 및 테스트 순서를 결정하기가 어렵습니다.

원인 분석 그래프는 고급 분석 분석 모듈에서 테스트 분석의 일부로 테스트 조건의 조합을 다루는 맥락에서 논의됩니다. 그러나 관리 가능한 수의 테스트 케이스에 대해 매우 큰 테스트 문제를 줄이고 테스트 기준의 100 % 기능적 범위를 제공 할 수 있다는 점에서 더 광범위한 사용법을 가지고 있습니다. 원인 - 원인 그래프는 또한 테스트 케이스 설계 동안 테스트 기반에서 결함을 식별합니다. 테스트 설계가 초안 요구 사항에 대해 시작될 때 소프트웨어 개발 라이프 사이클 초기에 결함을 식별 할 수 있습니다. 인과 적 효과 그래프의 채택에 대한 한 가지 주요 장애는 이러한 그래프를 작성하는 복잡성입니다. 이 방법을 지원하는 도구가 있어서 수동으로 하기가 복잡 할 수 있습니다. 요구 사항 기반 테스트의 일반적인 장애물은 요구 사항 사양이 모호하고, 테스트 할 수 없거나, 불완전하거나, 존재하지 않는 경우가 종종 있습니다. 모든 조직이 이러한 문제를 해결하기 위해 동기 부여를 받는 것은 아니므로 그러한 상황에 직면 한 테스터는 다른 테스트 전략을 선택해야 합니다.

기존 요구 사항의 사용을 늘리기 위해 때때로 사용되는 또 다른 방법은 사용 사례 또는 사용자 프로필, 사용자 (개인 설정이라고도 함), 입력 및 출력의 혼합을 사용하는 모델 기반 접근 방식입니다. 시스템의 실제 사용을 정확하게 묘사합니다. 이를 통해 기능뿐 아니라 유용성, 상호 운용성, 안정성, 보안 및 성능을 테스트 할 수 있습니다.

테스트 분석 및 계획을 수행하는 동안 테스트 팀은 사용 프로필을 확인하고 테스트 사례를 사용하려고 시도합니다. 사용 프로필은 사용 가능한 정보를 기반으로 소프트웨어를 실제로 사용하는 예상치 입니다. 이는 위험 기반 테스트와 마찬가지로 사용 프로필이 최종 현실을 완벽하게 모델링하지 못할 수도 있음을 의미합니다. 그러나 충분한 정보와 이해 관계자의 의견을 사용할 수 있다면 모델이 적절할 것입니다 ([Musa04] 참조).

일부 검사 관리자는 검사 목록과 같은 체계적인 접근법을 적용하여 검사 대상, 양, 정도 및 순서를 결정합니다. 매우 안정적인 제품의 경우 주요 기능 및 비 기능 영역에 대한 점검 목록을 기존 테스트 사례의 저장소와 결합하여 충분할 수 있습니다.

체크리스트는 일반적으로 발생한 변경 유형 및 양을 기준으로 노력 할당 및 테스트 시퀀싱을 위한 경험적 방법을 제공합니다.

이러한 접근법은 경미한 변화 이상을 테스트하는 데 사용될 때 유효성이 떨어지는 경향이 있습니다. 마지막으로, 또 다른 일반적인 방법은 반응 방식을 사용하는 것입니다. 사후 대응 방식에서는 테스트 실행 전에 테스트 분석, 설계 또는 구현 작업이 거의 발생하지 않습니다. 테스트 팀은 실제로 전달 된 제품에 반응하는 데 중점을 둡니다. 발견 된 버그 클러스터는 향후 테스트의 초점이 됩니다. 우선 순위 및 할당은 완전히 동적입니다. 리 액티브 접근법은 다른 접근법을 보완하는 역할을 할 수 있지만, 독점적으로 사용되는 경우 반응적인 접근 방식은 중요하지만 많은 수의 버그를 겪지 않는 응용 프로그램의 주요 영역을 놓치는 경향이 있습니다.

 

2.3.4 테스트 프로세스의 테스트 우선 순위 지정 및 노력 할당

Test Manager가 사용하는 기술이나 기술의 혼합이 무엇이든, Test Manager는 해당 기술을 프로젝트 및 테스트 프로세스에 통합해야 합니다. 예를 들어, 순차 라이프 사이클 (예: V-model)에서 테스트 팀은 테스트를 선택하고, 테스트 노력을 할당하며, 요구 사항 단계에서 테스트에 우선 순위를 매기고 주기적으로 조정합니다. 반복적 또는 민첩한 라이프 사이클에는 반복 방식을 반복해야 합니다. 테스트 계획 및 통제는 위험, 요구 사항 및 / 또는 사용 프로필이 진화 할 정도를 고려하고 적절하게 대응해야 합니다. 테스트 분석, 설계 및 구현 중에 테스트 계획 중에 결정된 할당 및 우선 순위를 적용해야 합니다. 신중한 분석 및 / 또는 모델링이 발생하는 테스트 프로세스의 공통적 인 붕괴이며, 앞으로 진행될 테스트 프로세스를 안내하는 데 사용되지 않는 정보에 대해서만 해당됩니다. 이 고장은 일반적으로 설계 및 구현 중에 발생합니다.

테스트 실행 시 테스트 계획 중에 결정된 우선 순위 결정을 수행해야 하지만 계획을 처음 작성한 후에 얻은 정보를 기반으로 주기적으로 우선 순위를 업데이트하는 것이 중요합니다. 테스트 결과를 평가하고 보고 할 때 테스트 관리자는 위험, 요구 사항, 사용 프로필, 검사 목록 및 테스트를 선택하고 우선 순위를 지정하는 데 사용되는 기타 가이드의 측면에서 평가하고 보고해야 합니다. 필요한 경우 테스트 우선 순위 설정이 테스트 우선 순위 구성표에 따라 수행되어야 합니다.

결과보고 및 종료 기준 평가의 일부로 테스트 관리자는 테스트가 완료된 정도를 측정 할 수 있습니다. 여기에는 테스트 사례를 추적하고 발견 된 결함을 관련 테스트 기준으로 되돌려 보내야 합니다. 예를 들어 위험 기반 테스팅에서 테스트가 실행되고 결함이 발견되면 테스터는 남아있는 위험 수준을 검사 할 수 있습니다. 이는 출시시기를 결정할 때 위험 기반 테스트의 사용을 지원합니다. 테스트보고는 적용되고 아직 달성되지 않은 이익뿐만 아니라, 커버되고 여전히 열려있는 리스크를 다루어야 합니다. 위험 범위에 따라 테스트 결과를 보고하는 예는 [Black03]을 참조하십시오.

마지막으로 테스트 종료 시 테스트 관리자는 품질 측면에서 고객 및 사용자의 요구 사항과 기대치를 포함하여 테스트 이해 관계자의 요구와 기대와 관련된 메트릭 및 성공 기준을 평가해야 합니다. 테스트가 이러한 요구와 기대를 충족시킬 때만 테스트 팀이 진정으로 효과적이라고 주장 할 수 있습니다.

2.4 시험 문서 및 기타 작업 산출물

문서는 종종 테스트 관리 활동의 일부로 생성됩니다. 테스트 관리 문서의 구체적인 이름과 각 문서의 범위는 다양하지만 다음은 조직 및 프로젝트에서 발견되는 일반적인 테스트 관리 문서 유형입니다:

l  테스트 정책 – 테스트를 위한 조직의 목적 및 목표를 설명합니다.

l  테스트 전략 – 테스트를 위한 조직의 일반적인 프로젝트 독립적 방법을 설명합니다.

l  마스터 테스트 계획 (또는 프로젝트 테스트 계획) - 테스트 계획의 구현을 설명합니다.

l  레벨 테스트 계획 (또는 단계 테스트 계획) - 수행 할 특정 활동을 설명합니다.

이러한 유형의 문서의 물리적 배열은 상황에 따라 다를 수 있습니다. 일부 조직과 일부 프로젝트에서는 단일 문서로 결합 될 수 있습니다. 다른 것들은 별도의 문서에서 찾을 수 있습니다; 일부에서는 그 내용이 테스트를 위해 직관적이고, 비판적이거나, 전통적인 방법론으로 표현 될 수 있습니다. 규모가 크고 보다 공식적인 조직과 프로젝트는 이러한 모든 유형의 문서를 문서로 작성하는 경향이 있는 반면 작고 덜 공식적인 조직과 프로젝트는 작문 된 작업 제품이 더 적습니다. 이 강의 계획서에서는 이러한 유형의 문서 각각을 개별적으로 설명하지만 실제로는 조직 및 프로젝트 컨텍스트가 각 유형의 올바른 활용도를 결정합니다.

2.4.1 테스트 정책

테스트 정책은 조직이 테스트하는 이유를 설명합니다. 조직에서 달성하고자 하는 테스트의 전반적인 목표를 정의합니다. 이 정책은 테스트 이해 관계자 그룹의 고위 관리자와 협력하여 조직의 수석 테스트 관리 직원이 개발해야 합니다.

 

경우에 따라 테스트 정책은 보다 광범위한 품질 정책의 보완책이 될 수도 있고 포괄적 인 품질 정책의 구성 요소가 될 수도 있습니다. 이 품질 방침은 품질과 관련된 경영의 전반적인 가치와 목표를 설명합니다.

서면 테스트 정책이 있는 곳은 간략하고 높은 수준의 문서 일 수 있습니다:

l  조직이 테스트에서 파생 한 가치를 요약합니다.

l  소프트웨어에 대한 신뢰 구축, 소프트웨어 결함 탐지 및 품질 위험 수준 감소와 같은 테스트 목적을 정의합니다 (2.3.1 절 참조)

l  이 테스트를 충족시키는 데있어 테스트의 효율성과 효율성을 평가하는 방법에 대해 설명합니다.

l  이러한 목표를 달성하는 데있어 테스트의 효율성과 효율성을 평가하는 방법에 대해 설명합니다.

l  ISTQB 기본 테스트 프로세스를 기본 테스트로 사용하여 일반적인 테스트 프로세스를 간략하게 설명합니다.

l  조직이 테스트 프로세스를 향상시키는 방법을 지정합니다 (5 장 참조).

테스트 정책은 새로운 개발 및 유지 보수를 위한 테스트 활동을 다루어야 합니다. 조직 전체에서 사용되는 테스트 작업 제품 및 용어에 대한 내부 표준 및 / 또는 외부 표준을 참조 할 수도 있습니다.

2.4.2 시험 전략

테스트 전략은 조직의 일반적인 테스트 방법론을 설명합니다. 여기에는 제품 및 프로젝트 위험을 관리하는 데 테스트를 사용하는 방법, 테스트를 수준으로 나누는 방법 및 테스트와 관련된 높은 수준의 활동이 포함됩니다. (동일한 조직은 서로 다른 소프트웨어 개발주기, 서로 다른 위험 수준 또는 서로 다른 규제 요구 사항과 같은 상황에 따라 다른 전략을 가질 수 있습니다.) 테스트 전략과 이에 설명 된 프로세스 및 활동은 테스트 정책과 일관되어야 합니다. 조직 또는 하나 이상의 프로그램에 대한 일반 테스트 항목 및 종료 기준을 제공해야 합니다.

l  위험 기반 테스트와 같은 분석 전략 - 테스트 팀이 테스트 조건을 분석하여 테스트 조건을 식별합니다. 예를 들어, 요구 사항 기반 테스트에서 테스트 분석은 요구 사항에서 테스트 조건을 추출한 다음 해당 조건을 포함하도록 테스트를 구현합니다. 테스트가 실행될 순서를 결정하기 위해 각 테스트에서 다루는 요구 사항의 우선 순위를 사용하여 종종 테스트가 실행됩니다. 테스트 결과는 요구 사항 상태 (예: 테스트 된 요구 사항 및 통과 됨, 요구 사항 테스트 및 실패, 아직 완전히 테스트되지 않은 요구 사항, 요구 사항 테스트 차단 등)로 보고 됩니다.

l  운영 프로파일 링과 같은 모델 기반 전략으로, 테스트 팀이 시스템이 존재하는 환경, 시스템이 받는 입력 및 조건 (실제 또는 예상 상황을 기반으로) 모델을 개발하고 시스템이 굴다. 예를 들어 빠르게 성장하는 모바일 장치 응용 프로그램의 모델 기반 성능 테스트에서 시간 경과에 따른 현재 사용량 및 프로젝트 성장을 기반으로 들어오고 나가는 네트워크 트래픽, 활성 및 비활성 사용자 모델 및 결과 처리 부하의 모델을 개발할 수 있습니다. 또한 현재 생산 환경의 하드웨어, 소프트웨어, 데이터 용량, 네트워크 및 인프라를 고려하여 모델을 개발할 수도 있습니다. 이상적, 예상 및 최소 처리량 속도, 응답 시간 및 자원 할당을 위해 모델을 개발할 수도 있습니다.

l  테스트 팀이 품질 표준 (예 : ISO 9126 [ISO9126]을 대체하는 ISO 25000 [ISO2500]), 체크리스트 또는 컬렉션과 같은 미리 정의 된 테스트 조건 세트를 사용하는 품질 특성 기반의 체계적인 전략 특정 도메인, 응용 프로그램 또는 유형의 테스트 (예 : 보안 테스트)와 관련 될 수 있는 일반화 된 논리적 테스트 조건을 생성하고 한 반복에서 다음 또는 한 릴리즈 사이의 테스트 조건 세트를 사용합니다. 예를 들어 간단하고 안정적인 전자 상거래 웹 사이트의 유지 관리 테스트에서 테스터는 각 페이지의 주요 기능, 속성 및 링크를 식별하는 체크리스트를 사용할 수 있습니다. 테스터는 사이트가 수정 될 때마다 이 체크리스트의 관련 요소를 다룰 것입니다.

l  테스트 팀이 표준위원회 또는 전문가의 다른 패널에 의해 정의 된 일련의 프로세스를 따르는 미국 식품 의약품 안전청 (Food and Drug Administration) 표준에 따라 의료 시스템과 같은 프로세스 또는 표준 준수 전략 테스트 기초와 테스트 오라클의 사용, 테스트 팀의 구성. 예를 들어, Scrum Agile 관리 기법을 따르는 프로젝트에서 각 반복마다 테스터는 특정 기능을 설명하는 사용자 스토리를 분석하고 반복을 위한 계획 프로세스의 일부로 각 기능의 테스트 노력을 예측하고 테스트 조건 (종종 인수 기준이라고 함)을 식별합니다. 각 사용자 스토리, 해당 조건을 포함하는 테스트 실행 및 테스트 실행 중 각 사용자 스토리 (테스트되지 않았거나 실패 또는 통과 중)의 상태를 보고합니다.

l  소프트웨어가 수신 될 때까지 테스트 팀이 테스트를 설계하고 구현하기를 기다리는 결함 기반 공격 사용과 같은 반응적 전략. 테스트중인 실제 시스템에 반응합니다. 예를 들어, 메뉴 기반 응용 프로그램에서 탐색 테스트를 사용할 때 기능, 메뉴 선택 및 화면에 해당하는 테스트 전세 세트가 개발 될 수 있습니다. 각 테스터에는 테스트 헌장 세트가 지정되며, 테스트 헌장 세트는 시험용 테스트 세션을 구성하는 데 사용됩니다. 테스터는 주기적으로 테스트 세션의 결과를 테스트 관리자에게 보고하며, 테스트 관리자는 결과에 따라 차터를 수정할 수 있습니다.

l  테스트 팀이 하나 이상의 주요 이해 관계자의 의견을 받아 테스트 조건을 결정하는 사용자 중심 테스트와 같은 컨설팅 전략. 예를 들어, 웹 기반 응용 프로그램의 아웃소싱 호환성 테스트에서 회사는 아웃소싱 테스트 서비스 공급자에게 브라우저 버전, 맬웨어 방지 소프트웨어, 운영 체제, 연결 유형 및 평가할 다른 구성 옵션의 우선 순위 목록을 제공 할 수 있습니다 그들의 응용. 그런 다음 테스트 서비스 제공 업체는 테스트를 생성하기 위해 페어 와이즈 테스트 (우선 순위가 높은 옵션의 경우) 및 동등한 파티셔닝 (낮은 우선 순위의 옵션)과 같은 기술을 사용할 수 있습니다.

l  테스트 팀이 다양한 기술을 사용하여 회귀, 특히 기능 및 / 또는 비 기능 회귀 테스트 자동화를 하나 이상의 수준에서 관리하는 광범위한 자동화와 같은 회귀 회피 테스트 전략입니다. 예를 들어, 웹 기반 응용 프로그램을 회귀 테스트하는 경우 테스터는 GUI 기반 테스트 자동화 도구를 사용하여 응용 프로그램의 일반적인 예외 사용 사례를 자동화 할 수 있습니다. 그런 다음 해당 테스트는 응용 프로그램이 수정 될 때마다 실행됩니다.

다른 전략이 결합 될 수 있습니다. 선택한 특정 전략은 조직의 필요와 수단에 적합해야 하며 조직은 특정 작업과 프로젝트에 적합한 전략을 수립 할 수 있습니다.

시험 전략은 수행 될 시험 수준을 기술 할 수 있다. 그러한 경우, 각 레벨에 대한 진입 기준 및 퇴장 기준과 레벨 간의 관계 (예: 테스트 커버리지 목표의 구분)에 대한 지침을 제공해야 합니다.

테스트 전략은 다음을 기술 할 수도 있다:

 

l  통합 절차

l  테스트 사양 기술

l  테스트의 독립성 (레벨에 따라 다를 수 있음)

l  필수 및 선택적 표준

l  테스트 환경

l  테스트 자동화

l  테스트 도구

l  소프트웨어 작업 제품 및 테스트 작업 제품의 재사용 성

l  확인 테스트 (재 테스트) 및 회귀 테스트

l  테스트 제어 및 보고

l  테스트 측정 및 항목

l  결함 관리

l  테스트웨어에 대한 구성 관리 접근법

l  역할과 책임

단기간 및 장기간에 걸친 다양한 테스트 전략이 필요할 수 있습니다. 다양한 테스트 전략은 여러 조직과 프로젝트에 적합합니다. 예를 들어, 보안 또는 안전성이 중요한 응용 프로그램이 관련된 경우 다른 응용 프로그램보다 더 집중적 인 전략이 더 적합 할 수 있습니다. 또한 테스트 전략은 다양한 개발 모델에 따라 다릅니다.

2.4.3 마스터 테스트 계획

마스터 테스트 계획은 수행 할 특정 레벨과 해당 레벨 간의 관계, 테스트 레벨과 해당 개발 활동 사이를 포함하여 특정 프로젝트에서 수행해야 할 모든 테스트 작업을 포함합니다. 마스터 테스트 계획은 테스터가 이 프로젝트의 테스트 전략 (즉, 테스트 방법)을 구현하는 방법을 논의해야 합니다. 마스터 테스트 계획은 테스트 정책 및 전략과 일관성이 있어야 하며 그렇지 않은 특정 영역에서는 편차로 인한 잠재적 영향을 포함하여 그러한 편차와 예외를 설명해야 합니다. 예를 들어, 릴리스 직전에 변경되지 않은 시스템에서 회귀 테스트를 한 번 수행하기 위한 조직의 테스트 전략이지만 현재 프로젝트에 회귀 테스트가 없는 경우 테스트 계획은 이것이 왜 계획되고 어떤 내용이 될지 설명해야 합니다. 이 전략으로 인해 발생하는 위험을 완화하기 위해 수행됩니다. 테스트 계획에는 이 차이로 인해 기대되는 다른 효과에 대한 설명도 포함되어야 합니다. 예를 들어, 회귀 테스트를 생략하면 초기 프로젝트가 릴리스 된 후 1 개월 후에 유지 보수 릴리스를 예약해야 할 수 있습니다. 마스터 테스트 계획은 대규모 프로젝트 또는 작업의 일부인 테스트 노력을 설명해야 한다는 점에서 프로젝트 계획 또는 운영 지침을 보완해야 합니다.

마스터 테스트 계획의 구체적인 내용과 구조는 조직, 문서 표준 및 프로젝트의 형식에 따라 다르지만 마스터 테스트 계획의 일반적인 주제에는 다음이 포함됩니다:

l  테스트 할 항목과 테스트하지 않을 항목

l  테스트되고 테스트되지 않을 품질 특성

l  테스트 일정 및 예산 (프로젝트 또는 운영 예산과 연계되어야 함)

l  테스트 실행주기 및 소프트웨어 릴리스 계획과의 관계

l  테스트 및 다른 사람 또는 부서 간의 관계 및 결과

l  설명 된 각 레벨의 범위와 범위에 있는 테스트 항목의 정의

l  특정 진입 기준, 지속 (일시 중지 / 재개) 기준, 각 레벨의 종료 기준 및 레벨 간의 관계

l  테스트 프로젝트 리스크들

l  테스트 노력의 전반적인 관리

l  각 테스트 레벨 실행에 대한 책임

l  각 테스트 레벨의 입력과 출력

한 레벨의 테스트 만 공식화 된 소규모 프로젝트 또는 운영에서는 마스터 테스트 계획과 해당 공식화 된 수준의 테스트 계획을 하나의 문서로 결합하는 경우가 많습니다. 예를 들어, 시스템 테스트가 개발자가 수행하는 비공식적 구성 요소 및 통합 테스트 및 베타 테스트 프로세스의 일부로 고객이 수행하는 비공식 수용 테스트가 있는 공식화 된 유일한 수준 인 경우 시스템 테스트 계획에 이 절에서 언급 한 요소가 포함될 수 있습니다.

또한 테스트는 일반적으로 프로젝트의 다른 활동에 따라 달라집니다. 이러한 활동이 특히 영향력 및 테스트와의 관계에서 충분히 문서화되지 않으면 해당 활동과 관련된 주제가 마스터 테스트 계획 (또는 적절한 레벨 테스트 계획)에서 다루어 질 수 있습니다. 예를 들어 구성 관리 프로세스가 문서화되지 않은 경우 테스트 계획은 테스트 개체를 테스트 팀에 전달하는 방법을 지정해야 합니다.

2.4.4 테스트 계획 레벨

레벨 테스트 계획은 각 테스트 레벨 또는 경우에 따라 테스트 유형 내에서 수행 할 특정 활동을 설명합니다. 테스트 계획 레벨은 문서화되는 특정 레벨 또는 테스트 유형에 대한 마스터 테스트 계획을 필요에 따라 확장합니다. 마스터 테스트 계획에서 다루지 않는 일정, 작업 및 중요 시점 세부 정보를 제공합니다. 또한 다양한 표준 및 템플릿이 여러 수준의 테스트 지정에 적용되는 정도까지 이러한 세부 사항은 테스트 계획 레벨에서 다룹니다.

 

덜 공식적인 프로젝트나 운영에서는 단일 테스트 계획이 종종 유일한 테스트 관리 문서로 작성됩니다. 이러한 상황에서 이 섹션의 앞부분에서 언급 한 정보 요소 중 일부는 이 테스트 계획 문서에서 다룰 수 있습니다.

애자일 프로젝트의 경우 스프린트 또는 반복 테스트 계획이 레벨 테스트 계획을 대신 할 수 있습니다.

2.4.5 프로젝트 리스크 관리

적절한 계획의 중요한 부분에는 프로젝트 위험 처리가 포함됩니다. 프로젝트 위험은 2.3 절에서 설명한 것과 유사한 프로세스를 사용하여 식별 할 수 있다. 프로젝트 리스크가 확인되면 프로젝트 관리자에게 전달되고 프로젝트 관리자가 이를 수행해야 합니다. 이러한 위험은 항상 테스트 조직의 권한 내에서 감소하는 것은 아닙니다. 그러나 일부 프로젝트 위험은 Test Manager에 의해 성공적으로 완화 될 수 있고 완화되어야 합니다.

l  테스트 환경 및 도구 준비

l  테스트 직원 가용성 및 자격

l  테스트 노력을 위한 표준, 규칙 및 기술 부족

프로젝트 위험 관리에 대한 접근법은 테스트웨어 준비, 테스트 환경 사전 테스트, 제품 초기 버전의 사전 테스트, 테스트에 대한 더 엄격한 진입 기준 적용, 테스트 가능성 요구 사항 적용, 초기 프로젝트 작업 제품 리뷰 참여, 변경 관리, 프로젝트 진척 상황 및 품질 모니터링.

 

프로젝트 위험이 확인되고 분석되면 위험을 관리하기 위한 네 가지 주요 옵션이 있습니다:

1. 가능성 및 / 또는 영향을 줄이기 위한 예방 조치를 통해 위험 완화

2. 위험이 현실이 될 경우 영향을 줄이기 위한 비상 계획 수립

3. 다른 당사자에게 위험을 전송하여 처리합니다.

4. 위험을 무시하거나 받아들이십시오.

가장 좋은 옵션을 선택하는 것은 옵션과 관련된 비용 및 잠재적으로 추가적인 위험뿐만 아니라 옵션에 의해 생성되는 이점과 기회에 따라 달라집니다. 프로젝트 위험에 대비하여 비상 계획이 식별되면 트리거(비상 계획이 언제 어떻게 호출되는지를 결정할 것) 및 소유자(비상 계획을 수행 할 사람)를 식별하는 것이 가장 좋습니다. 2.4.6 다른 시험 업무 제품

테스트에는 결함 보고서, 테스트 케이스 사양 및 테스트 로그와 같은 여러 가지 다른 작업 제품을 만드는 작업이 포함됩니다. 이러한 작업 제품의 대부분은 Test Analysts 및 Technical Test Analyst가 생산합니다. Test Analyst 교과 과정에서는 이러한 작업 결과물을 제작하고 문서화 할 때 고려해야 할 사항에 대해 설명합니다. 테스트 관리자는 다음 작업을 통해 이러한 작업 제품의 일관성과 품질을 보장해야 합니다:

l  거부 된 결함 보고서의 백분율과 같은 작업 결과물의 품질을 모니터링하는 메트릭스를 설정하고 모니터링합니다.

l  테스트 분석가 및 기술 테스트 분석가와 협력하여 이러한 작업 제품에 적합한 양식를 선택하고 원하는 대로 바꾸십시오.

l  테스트 분석가 및 기술 테스트 분석가와 협력하여 테스트, 로그 및 보고서에 필요한 세부 정도와 같은 작업 산출물에 대한 표준을 설정합니다.

l  적절한 기술과 적절한 참가자 및 이해 관계자가 테스트 작업 제품을 검토합니다.

테스트 문서의 범위, 유형 및 특수성은 선택된 소프트웨어 개발 라이프 사이클, 적용 가능한 표준 및 규정, 개발중인 특정 시스템과 관련된 제품 품질 및 프로젝트 위험, 다른 고려 사항 등의 영향을받을 수 있습니다.

 

IEEE 829 [IEEE829]와 같이 작업 결과를 테스트하기위한 다양한 템플릿 소스가 있습니다. Test Manager는 IEEE 829 문서가 모든 산업에서 사용하도록 설계된 것을 기억하는 것이 중요합니다. 따라서 템플릿에는 특정 조직에 적용될 수도 있고 적용되지 않을 수도있는 높은 수준의 세부 사항이 포함되어 있습니다. 특정 조직에서 사용하기 위해 표준 템플리트를 작성하기 위해 IEEE 829 문서를 조정하는 것이 가장 좋습니다. 템플릿의 일관된 응용 프로그램은 교육 요구 사항을 줄이고 조직 전체의 프로세스를 통합하는 데 도움이됩니다.

 

또한 테스트에는 일반적으로 Test Manager에서 생성되며이 장의 뒷부분에서 설명하는 테스트 결과 보고서 작성이 포함됩니다.

2.5 시험 평가

관리 활동으로서 추정은 특정 작업이나 프로젝트와 관련된 활동과 관련된 비용 및 완료 날짜에 대한 대략적인 목표를 작성하는 것입니다. 최고의 견적:

l  경험 많은 실무자들의 집단적 지혜를 대표하고 참여자들의 지원을 받는다.

l  비용, 자원, 작업 및 관련 사람들에 대한 구체적이고 상세한 카탈로그 제공

l  예상되는 각 활동에 대해 가장 가능성 있는 비용, 노력 및 기간

소프트웨어 및 시스템 엔지니어링에 대한 평가는 기술적 인 측면과 정치적인 측면 모두에서 어려움을 겪고 있는 것으로 오랫동안 알려져 왔지만, 프로젝트 관리의 모범 사례는 잘 정립되어 있습니다. 테스트 추정은 프로젝트 또는 작업과 관련된 테스트 활동에 이러한 모범 사례를 적용하는 것입니다. 테스트 추정은 1 장에서 설명한 테스트 프로세스와 관련된 모든 활동을 다루어야 합니다.

 테스트 실행은 일반적으로 프로젝트의 중요한 경로에 있기 때문에 예상되는 비용, 노력 및 테스트 실행 기간은 종종 관리에 가장 중요합니다. 그러나 소프트웨어의 전반적인 품질이 낮거나 알려지지 않은 경우 테스트 실행 예상치는 생성하기가 어렵고 신뢰할 수 없는 경향이 있습니다. 또한 시스템에 대한 친숙 함 및 경험은 예상 품질에 영향을 미칠 수 있습니다. 일반적인 방법은 테스트 실행 중에 필요한 테스트 케이스 수를 추정하는 것이지만, 테스트 할 소프트웨어의 결함 수가 적다고 가정 할 수 있는 경우에만 작동합니다. 평가 중 가정은 추정의 일부로 항상 문서화 되어야 한다.

시험 평가는 시험 활동의 비용, 노력 및 기간에 영향을 줄 수 있는 모든 요소를 고려해야 합니다. 이러한 요소에는 다음이 포함되지만 이에 국한되지는 않습니다:

l  요구되는 시스템 품질 수준

l  테스트 할 시스템의 크기

l  산업 데이터 또는 다른 조직의 벤치 마크 데이터로 보강 될 수 있는 이전 테스트 프로젝트에 대한 테스트의 내역 데이터 또는 다른 조직의 데이터 또는 벤치 마크 데이터

l  테스트 전략, 개발 또는 유지 보수 라이프 사이클 및 프로세스 성숙도 및 프로젝트 견적의 정확성을 포함한 프로세스 요소

l  테스트 자동화 및 도구, 테스트 환경, 테스트 데이터, 개발 환경, 프로젝트 문서 (예 : 요구 사항, 디자인 등) 및 재사용 가능한 테스트 작업 제품을 포함한 중요 요소

l  관리자 및 기술 리더, 프로젝트 팀의 임원 및 고위 경영진의 약속과 기대, 기술, 경험 및 태도, 프로젝트 팀의 안정성, 프로젝트 팀 관계, 테스트 및 디버깅 환경 지원, 숙련 된 계약자 및 컨설턴트의 가용성 등의 요인, 도메인 지식

l  프로세스, 기술, 조직, 테스트 관계자 수, 하위 팀 구성 및 위치의 복잡성

l  현저한 램프 업, 교육 및 방향 요구

l  새로운 도구, 기술, 프로세스, 기술, 관습의 동화 또는 개발

l  하드웨어 또는 많은 양의 테스트웨어

l  높은 수준의 세부 테스트 사양에 대한 요구 사항, 특히

익숙하지 않은 문서화 표준

l  구성 요소 도착의 복잡한 타이밍, 특히 통합 테스트 및 테스트 개발

l  깨지기 쉬운 테스트 데이터 (예 : 시간에 민감한 데이터)

 

테스트를 위해 제공되는 소프트웨어의 품질은 테스트 관리자가 자신의 추정에서 고려해야 할 주요 요소이기도 합니다. 예를 들어 개발자가 자동화 된 단위 테스트 및 지속적인 통합과 같은 모범 사례를 채택한 경우 코드를 테스트 팀에 전달하기 전에 결함의 50 %가 제거됩니다 (결함에 대한 자세한 내용은 [Jones11] 참조) 이러한 관행의 효과적 제거). 일부는 테스트 중심 개발을 비롯한 애자일 방법론이 테스트를 위해 더 높은 수준의 품질을 제공한다고 보고했습니다.

 

견적은 상향식 또는 하향식으로 수행 할 수 있습니다. 시험 추정에 단독으로 또는 조합하여 사용될 수 있는 기술은 다음을 포함한다.

l  직관, 추측 및 과거 경험

l  WBS (Work Breakdown Structures)

l  팀 견적 세션 (예 : Wide Band Delphi)

l  회사 표준 및 규범

l  전반적인 프로젝트 노력 또는 직원 수준 (예 : 테스터 - 개발자 비율)의 백분율

l  결함 수, 테스트주기 수, 테스트 사례 수, 각 테스트의 평균 노력 및 관련된 회귀 사이클 수를 측정하는 메트릭 기반 모델을 포함한 조직 내역 및 메트릭

l  기능 점수, 코드 라인, 개발자 예상 노력 또는 기타 프로젝트 매개 변수와 같은 업계 평균 및 예측 모델 (예 : [Jones07] 참조)

대부분의 경우, 일단 준비가 되면, 평가는 정당화와 함께 경영진에게 전달되어야 한다 (2.7 절 참조). 종종 협상이 진행되어 종종 견적을 수정하게 됩니다. 이상적으로 최종 테스트 견적은 품질, 일정, 예산 및 기능 분야에서 조직 및 프로젝트 목표의 최상의 균형을 나타냅니다.

 

모든 예상은 준비 당시의 정보를 기반으로 한다는 것을 기억하는 것이 중요합니다. 프로젝트 초기에 정보가 상당히 제한 될 수 있습니다. 또한 프로젝트 초기에 제공되는 정보는 시간이 지남에 따라 변경 될 수 있습니다. 정확성을 유지하기 위해 새로운 정보와 변경된 정보가 반영되도록 견적을 업데이트해야 합니다.

 

2.6 테스트 메트릭스의 정의와 사용

관리 상식은 측정되는 것이 완료된다고 말합니다. 또한, 측정되지 않는 것은 무시하기 쉽기 때문에 측정되지 않은 것은 완료되지 않습니다. 따라서 테스트를 포함하여 모든 노력에 대해 적절한 메트릭스 세트를 설정하는 것이 중요합니다.

 

테스트 메트릭은 다음 범주 중 하나 이상에 속하는 것으로 분류 할 수 있습니다.

l  실행, 통과 및 실패한 테스트 사례의 비율과 같은 확립 된 프로젝트 종료 기준으로 진행 상황을 측정하는 프로젝트 메트릭

l  제품의 특성 (예 : 테스트 범위 또는 결함 밀도)을 측정하는 제품 메트릭

l  테스트로 발견 된 결함의 비율 같은 테스트 메트릭은 테스트 또는 개발 프로세스의 성능을 측정합니다.

l  특정 일정 내의 테스트 사례 구현과 같이 개인 또는 그룹의 기능을 측정하는 사람 메트릭

모든 측정 항목은 2 개, 3 개 또는 4 개의 카테고리에 속할 수 있습니다. 예를 들어, 결함의 일일 도착률을 보여주는 추세 차트는 종료 기준 (1 주 동안 발견 된 새로운 결함 없음), 제품 품질 (테스트에서 더 이상 결함을 찾을 수 없음) 및 테스트 프로세스 (테스트는 테스트 실행 초기에 많은 수의 결함을 찾습니다).

 

사람 메트릭은 특히 민감합니다. 관리자는 주로 사람 메트릭의 프로세스 메트릭 인 메트릭을 실수로 잘못 해석하여 사람들이 자신에게 유리한 방식으로 메트릭을 왜곡하는 경우 재앙을 초래합니다. 시험 참가자의 적절한 동기 부여와 평가는 이 시험 계획서의 7 장과 전문가 시험 관리 계획서 [ISTQB ETL SYL]에서 논의됩니다.

 

고급 수준에서는 주로 테스트 진행 상황을 측정하는 측정 항목, 즉 프로젝트 측정 항목을 사용하는 데 관심이 있습니다. 테스트 진행 측정에 사용되는 일부 프로젝트 메트릭은 제품 및 프로세스와 관련이 있습니다. 제품 및 프로세스 측정 항목의 관리 사용에 대한 자세한 내용은 전문가 테스트 관리 개요를 참조하십시오. 프로세스 메트릭 사용에 대한 자세한 내용은 전문가 프로세스 테스트 과정 요약 [ISTQB ITP SYL]에 나와 있습니다.

 

메트릭을 사용하면 테스터가 일관된 방식으로 결과를 보고하고 시간 경과에 따른 진행 상황을 일관성 있게 추적 할 수 있습니다. 테스트 관리자는 기술 직원부터 경영진에 이르기까지 여러 수준의 이해 관계자가 참석할 수 있는 다양한 회의에서 메트릭스를 제시해야 합니다. 메트릭은 프로젝트의 전반적인 성공 여부를 결정하는 데 사용되기 때문에 추적 할 대상, 보고 빈도 및 정보를 표시하는 데 사용할 방법을 결정할 때 주의해야 합니다. 특히, 시험 관리자는 다음을 고려해야 합니다.

l  측정 항목의 정의. 제한된 유용한 메트릭스가 정의되어야 합니다. 측정 기준은 프로젝트, 프로세스 및 / 또는 제품의 특정 목표에 따라 정의되어야 합니다. 단일 측정 항목은 상태 또는 추세에 대한 잘못된 인상을 줄 수 있으므로 측정 항목을 균형에 맞게 정의해야 합니다.

이러한 측정 기준을 정의한 후에는 측정 결과를 논의 할 때 혼란을 피하기 위해 모든 이해 관계자가 해석해야 합니다. 대부분의 관련 통계에 집중하는 대신 너무 많은 통계를 정의하는 경향이 있습니다.

l  측정 항목 추적. 메트릭 보고 및 병합은 측정을 처리하고 처리하는 데 소요되는 시간을 줄이기 위해 가능한 한 자동화되어야 합니다. 특정 측정 항목에 대한 시간 경과에 따른 측정 값의 변이는 측정 항목 정의 단계에서 합의 된 해석 이외의 정보를 반영 할 수 있습니다. 시험 관리자는 기대치의 측정에서 발생할 수 있는 발산과 그 발산 이유를 신중하게 분석 할 준비가 되어 있어야 합니다.

l  측정 항목에 대한 보고. 목적은 관리 목적을 위해 정보를 즉각적으로 이해하는 것입니다. 프레젠테이션은 특정 시간에 메트릭의 스냅 샷을 표시하거나 추세를 평가할 수 있도록 시간 경과에 따른 메트릭의 진화를 나타낼 수 있습니다.

l  측정 항목의 유효성. 테스트 매니저는 또한 보고되는 정보를 검증해야 합니다. 메트릭에 대해 수행 된 측정은 프로젝트의 실제 상태를 반영하지 않거나 지나치게 긍정적 또는 부정적 경향을 전달할 수 있습니다. 데이터가 제시되기 전에 테스트 관리자는 정확성과 전달할 수 있는 메시지에 대해 검토해야 합니다.

테스트 진행 상황을 모니터링 하는 데는 5 가지 기본 차원이 있습니다:

l  제품 (품질) 리스크

l  결함

l  테스트

l  커버리지

l  신뢰도

제품 위험, 결함, 테스트 및 적용 범위는 프로젝트 또는 운영 중에 특정 방법으로 측정되고  보고 될 수 있습니다. 이러한 측정치가 테스트 계획의 정의 된 종료 기준과 관련이 있다면, 테스트 노력의 완료를 판단 할 객관적인 표준을 제공 할 수 있습니다. 신뢰는 설문 조사를 통해 또는 대리 메트릭으로 적용 범위를 사용하여 측정 할 수 있습니다. 그러나 신뢰도는 종종 주관적으로 보고 되기도 합니다.

 

제품 위험과 관련된 측정 항목은 다음과 같습니다:

l  테스트를 통과하여 완전히 채워지는 위험의 비율

l  일부 또는 모든 검사가 실패하는 위험의 비율

l  아직 완전히 테스트되지 않은 위험의 백분율

l  위험 범주 별로 분류 된 위험 비율

l  초기 품질 위험 분석 후 확인 된 위험의 백분율

결함과 관련된 측정 항목은 다음과 같습니다:

l  보고 된 누적 개수 대 발견 된 누적 개수 대 고정 된 누적 개수

l  평균 실패 율 또는 실패 횟수

l  다음에 의해 분류 된 결함의 수 또는 백분율에 대한 분류 :

¡  특정 테스트 항목 또는 구성 요소

¡  근본 원인

¡  결함 소스 (예 : 요구 사양, 새로운 기능, 회귀 등)

¡  시험판

¡  도입, 감지 및 제거 된 단계

¡  우선 순위 / 심각도

¡  보고 거부 또는 중복 된 보고

l   결함보고에서 해결까지의 지연 시간 동향

l  새로운 결함을 도입 한 결함 수정 수 (딸 버그라고도 함)

테스트와 관련된 측정 항목은 다음과 같습니다:

계획된 테스트, 지정 (구현), 실행, 전달, 실패, 차단 및 건너 뛴 총 테스트 수

l  회귀 테스트 및 확인 테스트 실패의 추세 및 총계를 포함한 회귀 및 확인 테스트 상태

l  달성 된 실제 시간 대 일일 계획된 테스트 시간

l  테스트 환경의 가용성 (테스트 환경에서 테스트 팀이 사용할 수있는 계획 테스트 시간의 백분율)

테스트 범위와 관련된 측정 항목은 다음과 같습니다:

l  요구 사항 및 디자인 요소 적용 범위

l  위험 관리 범위

l  환경 / 구성 범위

l  코드 적용 범위

테스트 매니저는 테스트 상태를 이해하고 보고하기 위해 커버리지 메트릭을 해석하고 사용하는 방법을 이해하는 것이 중요합니다. 시스템 테스트, 시스템 통합 테스트 및 수락 테스트와 같은 높은 수준의 테스트의 경우 기본 테스트 기반은 일반적으로 요구 사항 사양, 디자인 사양, 사용 사례, 사용자 사례, 제품 위험, 지원되는 환경 및 지원되는 구성 등의 작업 제품입니다. 구조 코드 커버리지 메트릭스는 단위 테스트 (예 : 명세서 및 분기 커버리지) 및 컴포넌트 통합 테스트 (예 : 인터페이스 커버리지)와 같은 더 낮은 레벨의 테스트에 더 많이 적용됩니다. 테스트 매니저는 코드 커버리지 메트릭을 사용하여 테스트에서 테스트중인 시스템의 구조를 실행하는 정도를 측정 할 수 있지만 일반적으로 상위 레벨 테스트 결과는 코드 커버리지 메트릭을 포함하지 않아야 합니다. 또한 테스트 관리자는 단원 테스트 및 구성 요소 통합 테스트가 구조적 적용 범위 목표의 100 %를 달성하더라도 더 높은 수준의 테스트에서 결함 및 품질 위험이 해결되어야 한다는 것을 이해해야 합니다.

 

메트릭은 기초 테스트 프로세스 (Foundation Syllabus 및 이 강의 계획서에 설명되어 있음)의 활동과 연결될 수도 있습니다. 이를 통해 테스트 프로세스 전반에 걸쳐 메트릭을 사용하여 테스트 프로세스 자체는 물론 프로젝트 목표를 향한 진행 상황을 모니터링 할 수 있습니다.

 

테스트 계획 및 통제 활동을 모니터링 하기 위한 지표에는 다음이 포함될 수 있습니다:

l  위험 요소, 요구 사항 및 기타 테스트 베이시스 요소 범위

l  결함 발견

l  테스트웨어 개발 및 테스트 사례 실행에 대한 계획 시간 대 실제 시간

테스트 분석 활동을 모니터링하는 메트릭에는 다음이 포함될 수 있습니다:

l  식별 된 테스트 조건의 수

l  테스트 분석 중에 발견 된 결함 수 (예: 테스트 기준을 사용하여 위험 또는 기타 테스트 조건을 식별함으로써)

 

테스트 디자인 활동을 모니터링 하기 위한 측정 기준에는 다음이 포함될 수 있습니다.

l  테스트 케이스가 차지하는 테스트 조건의 백분율

l  테스트 설계 중에 발견 된 결함 수 (예: 테스트 기준에 따라 테스트를 개발하여)

 

테스트 구현 활동을 모니터링하기 위한 측정 기준에는 다음이 포함될 수 있습니다:

l  구성된 테스트 환경의 백분율

l  로드 된 테스트 데이터 레코드의 백분율

l  자동화 된 테스트 케이스 비율

 

테스트 실행 활동을 모니터링 하는 메트릭에는 다음이 포함될 수 있습니다:

l  계획된 테스트 사례의 실행, 통과 및 실패 백분율

l  실행 된 (및 / 또는 합격 된) 테스트 케이스가 커버하는 테스트 조건의 백분율

l  계획된 결함과 보고 된 실제 결함 비교

l  계획 대비 실제 달성 범위

테스트 진행 및 완료 활동을 모니터링하는 메트릭에는 다음을 포함 할 수 있는 마일스톤, 항목 기준 및 종료 기준 (테스트 계획에서 정의되고 승인 된)에 대한 매핑이 포함됩니다:

l  계획된 테스트 조건, 테스트 케이스 또는 테스트 사양의 수 및 통과 또는 실패 여부에 따라 분류 된 테스트 사양

l  심각도, 우선 순위, 현재 상태, 영향을 받는 하위 시스템 또는 기타 분류 (4 장 참조)로 분류되는 총 결함

l  필요한 변경, 수락, 빌드 및 테스트 된 변경 수

l  계획 대비 실제 비용

l  계획 기간 대 실제 기간

l  이정표를 테스트하기 위해 계획된 날짜와 실제 날짜 비교

l  테스트 관련 프로젝트 마일스톤 (예 : 코드 동결)에 대한 계획된 날짜와 실제 날짜 대충 완화되지 않은 주요 위험 영역, 테스트 분석 후 발견 된 새로운 위험 등으로 분류되는 제품 (품질) 위험 상태

l  차단 이벤트 또는 계획된 변경으로 인한 테스트 노력, 비용 또는 시간의 손실률

l  확인 및 회귀 테스트 상태

테스트 클로저 활동을 모니터링하는 메트릭에는 다음이 포함될 수 있습니다:

l  테스트 실행 중에 실행, 통과, 실패, 차단 및 건너 뛴 테스트 사례 백분율

l  재사용 가능한 테스트 사례 저장소에 체크인 된 테스트 사례 백분율

l  자동화 된 테스트 케이스 또는 계획된 테스트 케이스 대 자동화 된 실제 테스트 케이스의 백분율

l  회귀 테스트에 통합 된 테스트 케이스의 백분율

l  해결 된 / 해결되지 않은 결함 보고서의 백분율

l  확인되고 보관 된 테스트 작업 제품의 백분율

또한 테스트 프로세스를 모니터링하기 위해 작업 분류 체계와 같은 표준 프로젝트 관리 기술이 종종 사용됩니다. 애자일 팀에서 테스트는 번 - 다운 차트에서 사용자 스토리가 진행되는 과정의 일부입니다. 린 (Lean) 관리 기법을 사용하는 경우 사용자 이야기 카드를 간판 보드의 칼럼을 통해 이동함으로써 스토리별로 진전 상황을 모니터링하는 경우가 종종 있습니다.

 

정의 된 메트릭 세트가 주어지면 측정은 구술 형식으로, 구두로 표로, 또는 그림으로 그래프로 보고 될 수 있습니다. 측정은 다음과 같은 다양한 목적으로 사용될 수 있습니다.

l  분석을 통해 테스트 결과를 통해 어떤 추세와 원인을 식별 할 수 있는지 알아 봅니다.

l  보고 결과를 관심 있는 프로젝트 참여자와 이해 관계자들에게 전달

l  테스트 또는 프로젝트 전체를 변경하고 해당 과정의 결과를 모니터링 하기 위한 제어

이러한 테스트 측정을 수집, 분석 및 보고하는 올바른 방법은 측정을 사용할 사용자의 특정 정보 요구 사항, 목표 및 능력에 따라 다릅니다. 또한 테스트 보고서의 구체적인 내용은 청중에 따라 달라집니다.

 

테스트 제어를 위해서는 테스트 프로세스 전반에 걸친 메트릭 (테스트 계획이 완료되면)을 통해 테스트 관리자가 테스트 임무, 전략 및 목표를 성공적으로 완료하는 데 필요한 테스트 노력을 안내하는 데 필요한 정보를 제공해야 합니다. 따라서 계획은 이러한 정보 요구를 고려해야 하며 모니터링에는 필요한 작업 산출물 메트릭 수집이 포함되어야 합니다. 필요한 정보의 양과 그것을 모으기 위해 소비되는 노력은 크기, 복잡성 및 위험을 포함한 다양한 프로젝트 요소에 달려 있습니다.

 

테스트 컨트롤은 테스트 또는 프로젝트 또는 노력이 존재하는 변화하는 조건에 의해 생성 된 정보에 응답해야 합니다. 예를 들어 동적 테스트가 많은 결함을 포함하지 않을 것으로 예상되는 영역의 결함 클러스터를 표시하거나 테스트 시작 지연으로 인해 테스트 실행 기간이 단축되는 경우 위험 분석 및 계획을 수정해야 합니다. 이로 인해 테스트가 다시 우선 순위 지정되고 나머지 테스트 실행 노력이 다시 할당 될 수 있습니다.

테스트 진행 보고서를 통해 테스트 계획의 차이가 발견되면 테스트 제어를 수행해야 합니다. 테스트 제어는 프로젝트 및 / 또는 테스트를 보다 성공적인 방향으로 리디렉션 하는 것을 목표로 합니다. 테스트 결과를 사용하여 프로젝트의 통제 노력에 영향을 미치거나 측정 할 때 다음 옵션을 고려해야 합니다.

l  품질 위험 분석, 테스트 우선 순위 및 / 또는 테스트 계획 수정

l  리소스 추가 또는 프로젝트 또는 테스트 노력 증가

l  릴리스 날짜 연기 테스트 종료 기준 완화 또는 강화

l  프로젝트의 범위 (기능적 또는 비 기능적) 변경하기

이러한 옵션을 구현하려면 일반적으로 프로젝트 또는 운영 이해 관계자 간의 합의와 프로젝트 또는 운영 관리자의 동의가 필요합니다.

 

테스트 보고서에 제공된 정보는 주로 프로젝트 관리 또는 비즈니스 관리와 같이 대상 고객의 정보 요구에 따라 달라집니다. 프로젝트 관리자에게는 결함에 대한 자세한 정보가 있는 것이 중요합니다. 비즈니스 관리자의 경우 제품 위험 상태가 중요한 보고 문제 일 수 있습니다.

2.7 테스트의 비즈니스 가치

테스트 관리자는 테스트를 최적화하여 올바른 비즈니스 가치를 제공하도록 노력해야 합니다. 테스트가 불합리한 지연을 초래하고 비용이 절약되는 것보다 많은 비용이 소요되기 때문에 지나치게 테스트해도 좋은 비즈니스 가치는 제공되지 않습니다. 너무 많은 결함이 사용자에게 전달 될 것이므로 너무 적은 테스트는 좋은 비즈니스 가치를 제공하지 못합니다. 이 두 극단 사이의 최적의 상태가 있습니다. 테스트 관리자는 테스트 담당자가 테스트 최적 값과 가치를 이해하도록 도와야 합니다.

 

대부분의 조직에서는 테스팅을 가치 있게 생각하지만 테스트 관리자를 비롯한 일부 관리자는 그 가치를 정량화하고 설명하거나 표현할 수 있습니다. 또한 많은 테스트 관리자, 테스트 리드 및 테스터는 테스트의 전술적 세부 사항 (태스크 또는 테스트 레벨과 관련된 측면)에 중점을 두는 반면 다른 프로젝트 참여자, 특히 관리자가 테스트하는 것과 관련된 보다 큰 전략적 (상위) 문제는 무시합니다. , 걱정해라.

테스팅은 양적 및 질적 인 방식으로 조직, 프로젝트 및 / 또는 운영에 가치를 제공합니다:

l  정량적 인 값에는 릴리스 이전에 방지되거나 수정 된 결함을 찾아 내고, 릴리스 이전에 알려진 결함을 찾고 (해결되지는 않았지만 문서화되어 있음), 테스트를 실행하여 위험을 줄이며 프로젝트, 프로세스 및 제품 상태에 대한 정보를 제공합니다.

l  품질 적 가치에는 품질에 대한 평판이 향상되었고,더 부드럽고 예측 가능한 릴리즈, 증가 된 자신감, 법적 책임으로부터의 보호, 그리고 전체 미션들 또는 삶의 손실 위험을 줄입니다.

시험 관리자는 조직, 프로젝트 및 / 또는 운영에 이러한 가치 중 어느 것이 적용되는지 이해해야 하며 이러한 가치 측면에서 테스트에 관해 의견을 나눌 수 있어야 합니다.

테스트의 양적 가치와 효율성을 측정하기 위한 잘 정립 된 방법을 비용 (때로는 품질 저하 비용)이라고 합니다. 품질 원가에는 프로젝트 및 운영 비용을 제품 결함 비용과 관련된 네 가지 범주로 분류합니다.

l  예방 비용 (예 : 교육 개발자가 유지 관리가 가능하거나 보안 코드를 작성하는 등)

l  탐지 비용 (예 : 테스트 사례 작성, 테스트 환경 구성 및 요구 사항 검토)

l  납품 전에 테스트 또는 검토 중 감지 된 결함 수정과 같은 내부 오류 비용

l  외부 결함 비용 (예 : 고객에게 제공되는 결함 소프트웨어와 관련된 비용 지원)

테스트 예산의 일부는 탐지 비용입니다 (즉 테스터가 테스트를 개발하는 데 지출 한 돈과 같은 결함이 없는 경우에도 지출되는 비용). 나머지는 내부 실패 비용입니다 (즉 실제 비용과 관련된 결함 발견). 탐지 및 내부 오류의 총 비용은 일반적으로 외부 오류 비용보다 훨씬 적으며 우수한 가치를 테스트합니다. 이 네 가지 범주의 비용을 결정함으로써 테스트 관리자는 테스트를 위해 설득력 있는 비즈니스 사례를 만들 수 있습니다.

품질 비용을 포함한 테스트의 비즈니스 가치에 대한 자세한 내용은 [Black03]에 나와 있습니다.

 

2.8 분산, 아웃소싱 및 인소싱 테스트

많은 경우, 테스트 노력의 일부 또는 전부는 다른 지역의 사람들, 다른 회사의 직원 또는 프로젝트 팀과 분리되어 수행됩니다. 테스트 노력이 여러 위치에서 발생하면 테스트 노력이 분산됩니다. 회사 직원이 아니고 프로젝트 팀과 같은 위치에 있지 않은 사람들이 테스트 노력을 한 곳 이상에서 수행하면 해당 테스트 노력이 아웃소싱됩니다. 테스트 노력이 프로젝트 팀과 함께 있지만 동료 직원이 아닌 사람들에 의해 수행되는 경우, 해당 테스트 노력은 인소싱됩니다.

이러한 모든 테스트 노력에 공통적 인 점은 의사 소통의 명확한 채널과 임무, 업무 및 결과물에 대한 명확한 기대가 필요하다는 것입니다. 프로젝트 팀은 소셜 시간을 함께 보내는 복도 대화 및 동료와 같은 비공식 커뮤니케이션 채널에 덜 의존해야 합니다. 문제의 단계적 확대, 의사 소통 될 정보의 유형 및 사용될 의사 소통 방법과 같은 주제를 다루는 것을 포함하여 의사 소통이 이루어져야 하는 방법을 정의하는 것이 중요합니다. 팀 관계의 모든 측면에서 모든 사람들은 오해와 비현실적인 기대를 피하기 위해 상대방의 역할과 책임뿐만 아니라 상대방의 역할과 책임을 분명히 이해해야 합니다. 위치, 시간대, 문화 및 언어의 차이로 인해 의사 소통 및 기대 문제가 더욱 쉽게 제기 될 수 있습니다.

또한 이러한 모든 테스트 노력에서 공통적 인 것은 방법론의 정렬에 대한 필요성입니다. 방법론의 잘못된 정렬은 어떤 프로젝트에서도 발생할 수 있지만, 작업이 외부 실체에 의해 배포 및 / 또는 수행되는 상황에서 발생할 가능성이 더 큽니다. 두 개의 테스트 그룹이 서로 다른 방법론을 사용하거나 테스트 그룹이 개발 또는 프로젝트 관리와 다른 방법론을 사용하면 테스트 실행 중 특히 심각한 문제가 발생할 수 있습니다. 예를 들어, 클라이언트가 민첩한 개발을 사용하는 경우 테스트 서비스 공급자가 순차적 수명주기를 가정하는 사전 정의 된 테스트 방법을 가지고 있는 반면 테스트 서비스 공급자에게 테스트 항목을 배달하는 시기와 특성은 논점입니다.

분산 테스트의 경우 여러 위치에서 테스트 작업을 구분하는 것이 명확하고 지능적으로 결정되어야 합니다. 그러한 지침이 없다면, 가장 유능한 그룹은 자격을 갖춘 시험 작업을 수행하지 못할 수도 있습니다. 또한, 각 팀이 자신이 무엇을 책임지고 있는지 모를 경우, 그들이 해야 할 일을 하지 못할 수도 있습니다. 각 팀에 대한 기대는 명확하게 전달되어야 합니다. 신중한 관리가 없다면 전체적으로 시험 작업은 갭 (배달 시 잔여 품질 위험이 증가)과 겹침 (효율성 감소)으로 어려움을 겪을 수 있습니다.

마지막으로 이러한 모든 테스트 노력에 있어 전체 프로젝트 팀이 모든 테스트 팀이 조직, 문화, 언어 및 지리적 경계에도 불구하고 제대로 역할을 수행 할 것이라는 신뢰를 개발하고 유지하는 것이 중요합니다. 신뢰의 부족은 활동 확인, 문제에 대한 책임 분배 및 조직 정치와 관련된 비효율 성과 지연을 초래합니다.

2.9 산업 표준의 응용 관리

파운데이션과 고급 레벨의 강의 계획서에는 여러 가지 기준이 언급되어 있습니다. 이러한 참조 표준은 소프트웨어 개발 수명주기, 소프트웨어 테스팅, 소프트웨어 품질 특성, 검토 및 결함 관리를 다룹니다. 시험 관리자는 표준, 표준 사용에 대한 조직의 정책, 표준 사용, 필요 또는 유용 여부에 대해 알고 있어야 합니다.

표준은 다음과 같은 다양한 출처에서 나올 수 있습니다:

l  국제적 또는 국제적 목표

l  국제 표준의 국가적 적용과 같은 국가 별 국제 또는 국가 표준

l  특정 도메인에 적용되거나 특정 도메인 용으로 개발 된 경우와 같이 특정 도메인

 

국제 표준기구에는 ISO 및 IEEE가 포함됩니다. ISO는 국제 표준화기구 (IOS)라고도 하는 국제 표준기구입니다. 자국의 경우 표준화 된 지역과 가장 관련이 있는 국가기구를 대표하는 회원들로 구성됩니다. 이 국제기구는 ISO 9126 (ISO 25000으로 대체 됨), ISO 12207 [ISO 12207] 및 ISO 15504 [ISO 15504]와 같은 소프트웨어 테스터에게 유용한 많은 표준을 홍보했습니다.

IEEE는 미국에 본사를 두고 있지만 100 개국 이상의 국가 대표자들로 구성된 전문 기관인 전기 전자 기술자 협회 (Institute of Electrical and Electronics Engineers)입니다. 이 조직은 IEEE 829 [IEEE829] 및 IEEE 1028 [IEEE1028]과 같은 소프트웨어 테스터에게 유용한 많은 표준을 제안했습니다.

많은 국가들이 자체 국가 표준을 가지고 있습니다. 이러한 표준 중 일부는 소프트웨어 테스팅에 유용합니다. 그 중 하나가 Advanced Test Analyst와 Advanced Technical Test Analyst Syllabi에 설명 된 많은 테스트 설계 기술과 관련된 정보를 제공하는 영국 표준 BS 7925-2 [BS7925-2]입니다.

일부 표준은 특정 도메인에만 적용되며 이러한 표준 중 일부는 소프트웨어 테스트, 소프트웨어 품질 및 소프트웨어 개발에 영향을 미칩니다. 예를 들어, 항공 전자 공학 영역에서 미국 연방 항공국 (Federal Aviation Administration)의 표준 DO-178B (및 EU 해당 ED 12B)가 민간 항공기에 사용되는 소프트웨어에 적용됩니다. 이 표준은 테스트중인 소프트웨어의 중요도 수준을 기반으로 일정 수준의 구조적 적용 범위 기준을 규정합니다.

도메인 특정 표준의 또 다른 예는 미국 식품의 약국 (FDA) Title 21 CFR Part 820 [FDA21]이 있는 의료 시스템에서 찾아 볼 수 있습니다. 이 표준은 특정 구조 및 기능 테스트 기술을 권장합니다. 이 표준은 ISTQB 강의 계획서와 일치하는 전략 및 원칙을 테스트 할 것을 권장합니다.

경우에 따라 테스트는 주로 테스트와 관련이 없지만 테스트가 발생하는 소프트웨어 프로세스 컨텍스트에 크게 영향을 미치는 표준 또는 광범위한 방법에 의해 영향을 받습니다. 한 가지 예가 CMMI® 소프트웨어 프로세스 개선 프레임 워크입니다. 여기에는 검증 및 검증이라는 두 가지 핵심 프로세스 영역이 포함되어 있으며, 이러한 영역은 종종 시스템 테스트 및 수락 테스트와 같은 테스트 수준을 참조하는 것으로 해석됩니다. 또한 테스트 전략 측면에서 의미를 가지며 종종 분석 요구 사항 기반 테스트를 테스트 전략의 일부로 포함해야 한다고 해석됩니다.

세 가지 다른 중요한 예는 PMI의 PMBOK, PRINCE2® 및 ITIL®입니다. PMI 및 PRINCE2는 북미 및 유럽에서 일반적으로 사용되는 프로젝트 관리 프레임 워크입니다. ITIL은 IT 그룹이 존재하는 조직에 가치 있는 서비스를 제공 할 수 있도록 하기 위한 프레임 워크입니다.

이 프레임 워크에 지정된 용어 및 활동은 ISTQB 강의 계획서 및 용어집과 상당히 다릅니다. PMI의 PMBOK, PRINCE2 및 / 또는 ITIL을 사용하는 조직에서 작업 할 때 테스트 관리자는 선택한 프레임 워크, 구현 및 용어가 해당 상황에서 효과적으로 작동 할 수 있을 만큼 충분히 이해해야 합니다.

채택되는 표준이나 방법론이 무엇이든 관계없이 전문가 집단에 의해 만들어 졌음을 기억하는 것이 중요합니다. 표준은 근원 집단의 집단적 경험과 지혜뿐만 아니라 약점도 반영합니다. 시험 관리자는 공식 표준 (국제, 국가 또는 도메인 별) 또는 자체 표준 및 권장 관행에 상관없이 해당 환경 및 컨텍스트에 적용되는 표준을 인식하고 있어야 합니다.

여러 표준의 사용을 고려할 때 일부 표준은 다른 표준과 일치하지 않거나 상충되는 정의를 제공한다는 점을 명심하십시오. 테스트 관리자는 테스트가 진행되는 특정 상황에 대해 서로 다른 표준의 유용성을 판단해야 합니다. 표준에 명시된 정보는 프로젝트에 유용하거나 방해가 될 수 있습니다. 그러나 표준은 입증 된 모범 사례에 대한 참조를 제공하고 테스트 프로세스를 구성하기 위한 기초를 제공 할 수 있습니다.

경우에 따라 표준 준수가 필수적이며 테스트에 영향을 미칩니다. 시험 관리자는 표준을 준수하고 적절한 준수가 유지되는지 확인해야 합니다.

3. 리뷰 - 180 분.

키워드

감사, 비공식 검토, 검사, 경영 검토, 운영자, 검토, 검토 계획, 검토 자,

기술 검토, 연습

리뷰를위한 학습 목표

3.2 경영 검토 및 감사

TM-3.2.1 (K2) 경영 검토 및 감사의 주요 특징 이해

3.3 리뷰 관리

TM-3.3.1 (K4) 프로젝트를 분석하여 적절한 검토 유형을 선택하고 적절한 실행, 후속 조치 및 책임을 지키기 위해 검토 수행 계획을 정의합니다.

TM-3.3.2 (K2) 검토 참여에 필요한 요소, 기술 및 시간을 이해한다.

3.4 리뷰를위한 메트릭스

TM-3.4.1 (K3) 검토에 사용될 프로세스 및 제품 메트릭스 정의

3.5 정식 리뷰 관리

TM-3.5.1 (K2) 사례를 사용하여 공식 검토의 특징을 설명하십시오.

3.1 서론

제품에 대한 정적 테스트 활동으로 ISTQB Foundation Level 강의에 리뷰가 도입되었습니다. 감사 및 관리 검토는 소프트웨어 작업 제품보다는 소프트웨어 프로세스에 더 중점을 둡니다.

리뷰는 정적 테스트의 한 형태이기 때문에 테스트 매니저는 특히 테스트웨어 제품과 관련하여 전반적인 성공에 대한 책임을 질 수 있습니다. 그러나 소프트웨어 프로젝트의 광범위한 맥락에서 이 책임은 조직 정책의 문제여야 합니다. 책임 있는 당사자는 소프트웨어 프로젝트 전과 과정에서 여러 분야의 정식 리뷰를 광범위하게 적용 할 수 있으므로 테스트 관리자 또는 품질 보증 관리자 또는 숙련 된 검토 코디네이터가 될 수 있습니다. 이 강의 계획서에서 책임 있는 당사자 (그 사람이 누구인지)는 검토 책임자라고합니다.

검토 지도자는 ISTQB Foundation Level 강의에 정의 된 성공 요인을 구현하는 데 도움이 되는 환경이 존재하는지 확인해야 합니다. 또한 리뷰 리더는 리뷰가 효과적인 가치를 제공 할 수 있도록 측정 계획을 수립해야 합니다.

테스터는 작동 방식과 소프트웨어 시스템의 요구 특성을 철저히 이해하고 있으므로 테스터의 검토 프로세스 참여가 중요합니다.

검토 과정에 참여한 참가자는 검토 과정에서 각자의 역할을 더 잘 이해할 수 있도록 검토 교육을 받아야 합니다. 모든 검토 참가자는 잘 수행 된 검토의 이점을 위해 최선을 다해야 합니다.

제대로 완료되면 리뷰는 전반적으로 제공되는 품질에 가장 큰 단일 비용으로 가장 효과적입니다. 따라서 검토 리더가 프로젝트에서 효율적인 검토를 수행하고 이러한 검토의 이점을 입증 할 수 있는 것이 가장 중요합니다.

프로젝트 내의 가능한 리뷰에는 다음이 포함됩니다:

l  프로젝트 시작과 주요 프로젝트 일정에서 시작된 계약 검토.

 

l  기능 요구 사항과 비 기능 요구 사항을 모두 충족하는 검토 요구 사항을 검토 할 수 있을 때 시작된 요구 사항 검토

 

l  전체적인 아키텍처 디자인을 검토 할 수 있을 때 시작된 최상위 수준의 디자인 검토.

 

l  상세한 디자인 검토가 가능하며 자세한 디자인을 검토 할 수 있을 때 시작됩니다.

 

l  소프트웨어의 개별 모듈로 수행되는 코드 검토가 생성되며 단위 테스트 및 결과뿐만 아니라 코드 자체가 포함될 수 있습니다.

 

l  테스트 계획, 테스트 조건, 품질 위험 분석 결과, 테스트, 테스트 데이터, 테스트 환경 및 테스트 결과를 포함 할 수 있는 테스트 작업 제품 검토

 

l  테스트 항목 (테스트 준비)은 테스트 실행을 시작하기 전에 테스트 항목 기준과 테스트를 완료하기 전에 테스트 종료 조건을 각각 확인하는 각 테스트 수준에 대한 종료 검토를 검토하고 테스트합니다.

 

l  시스템에 대한 고객 또는 이해 관계자의 승인을 얻는 데 사용되는 수락 검토

여러 검토 유형을 제품에 적용하는 것 외에도 검토 책임자는 검토에서 정적 문서의 결함을 찾을 수 있지만 다른 양식의 정적 테스트 (정적 분석 등) 및 동적 테스트를 통해 검토를 강화해야 한다는 것을 기억해야 합니다. 코드의 이러한 기술을 함께 사용하면 테스트 적용 범위가 향상되고 더 많은 결함을 찾을 수 있습니다.

서로 다른 기술에는 다른 초점이 있습니다. 예를 들어 검토를 통해 문제가 코드에 구현되기 전에 요구 사항 수준의 문제를 제거 할 수 있습니다. 정적 분석은 코딩 표준을 적용하고 작업 제품을 조사하여 팀이 찾기에 너무 어려울 수 있는 문제를 확인하는 데 도움이 될 수 있습니다. 검사는 결함 발견 및 제거로 이어질 뿐만 아니라 제작자가 작업 결과물에 결함이 발생하지 않도록 하는 방법을 교육 할 수 있습니다.

ISTQB Foundation Level 실러버스에는 다음과 같은 유형의 검토가 도입되었습니다:

l  비공식 검토

l  연습

l  기술 검토

l  검사

이 외에도 다음과 같은 시험 관리자도 참여할 수 있습니다.

l  관리 리뷰

* 감사

3.2 경영 검토 및 감사

관리 검토는 진행 상황을 모니터링하고 상태를 평가하며 향후 작업에 대한 결정을 내리는 데 사용됩니다. 이러한 검토는 자원 수준의 조정, 시정 조치의 실행 또는 프로젝트의 범위 변경과 같은 프로젝트의 미래에 대한 결정을 뒷받침합니다.

다음은 경영 검토의 주요 특징입니다:

l  프로젝트 또는 시스템에 대한 직접적인 책임이 있는 관리자가 수행 한 것.

l  이해 관계자 또는 의사 결정자 (예 : 상위 관리자 또는 이사)가 수행합니다.

l  계획과의 일관성 및 편차를 점검하십시오.

l  관리 절차의 적절성을 점검하십시오.

l  프로젝트 위험을 평가하십시오.

l  행동의 영향과 이러한 영향을 측정하는 방법을 평가하십시오.

l  작업 항목 목록, 해결해야 할 문제 및 결정을 내립니다.

 

3.3 리뷰 관리

리뷰는 소프트웨어 프로젝트 내의 자연적 브레이크 포인트 또는 마일스톤에서 수행되도록 계획되어야 합니다. 일반적으로 검토는 요구 사항 및 디자인 정의 다음에 수행되어야 하며 관련 검토는 비즈니스 목표에서 시작하여 가장 낮은 수준의 설계로 진행해야 합니다. 관리 검토는 주요 프로젝트 이정표에서 수행해야 하며, 종종 테스트 실행 전과 테스트 중 및 테스트 실행 중 및 기타 중요한 프로젝트 단계에서 검증 활동의 일부로 수행되어야 합니다. 검토 전략은 테스트 정책 및 전체 테스트 전략과 조정되어야 합니다.

프로젝트 수준에서 전반적인 검토 계획을 공식화하기 전에 검토 책임자 (테스트 관리자 일 수 있음)가 고려해야 합니다:

l  검토 대상 (제품 및 프로세스).

l  특정 리뷰에 참여해야 하는 사람

l  어떤 관련 위험 요인을 다루어야 하는가?

프로젝트 기획 단계의 초기 단계에서 검토 리더는 검토 할 항목을 식별하고 적절한 검토 유형 (비공식 검토, 둘러보기, 기술 검토 또는 검사 또는 두 가지 또는 세 가지 유형의 혼합) 및 형식 수준을 선택해야 합니다. 이것이 추가 검토 교육을 권장 할만한 시점입니다. 거기에서 검토 프로세스를 위한 예산 (시간 및 자원)을 할당 할 수 있습니다. 예산 결정에는 위험 평가와 투자 수익 계산이 포함되어야 합니다.

검토를 위한 투자 수익은 검토 수행 비용과 검토가 완료되지 않은 경우 동일한 결함을 나중에 처리하는 비용 (또는 모두 누락 된 비용)의 차이입니다. 2.7 절에 설명 된 품질 비용 계산을 사용하여 이 번호를 결정할 수 있습니다.

검토를 수행하기 위한 최적의 시간 결정은 다음 사항에 달려 있습니다:

l  충분히 최종 형식으로 검토 할 항목의 가용성.

l  검토에 필요한 인원의 가용성.

l  항목의 최종 버전을 사용할 수 있는 시간

l  특정 항목의 검토 프로세스에 필요한 시간.

검토 평가를 위한 적절한 측정 기준은 시험 계획 중에 검토 책임자가 정의해야 합니다. 검사가 사용되는 경우, 문서 단편 (예 : 개별 요구 사항 또는 섹션)이 완성되면 작성자의 요청에 따라 간단한 검사가 수행되어야 합니다.

검토 프로세스의 목표는 테스트 계획 중에 정의되어야 합니다. 여기에는 효과적이고 효율적인 검토를 수행하고 검토 피드백에 관한 합의 결정에 도달하는 것이 포함됩니다.

프로젝트 검토는 전체 시스템에 대해 자주 개최되며 하위 시스템 및 개별 소프트웨어 요소에 필요할 수도 있습니다. 리뷰 수, 리뷰 유형, 리뷰 구성 및 관련된 모든 사람들은 프로젝트 크기와 복잡성 및 제품 위험에 따라 다릅니다.

효율성을 높이기 위해서는 리뷰 참여자가 기술 및 절차 적 지식의 적절한 수준을 갖추어야 합니다. 검토에 철저하고 세심한 주의가 필요한 것은 검토자가 필요로 하는 기술 중 일부입니다. 선명도와 올바른 우선 순위는 좋은 리뷰 의견에서 찾는 속성입니다. 절차 적 지식의 필요성은 검토 과정에서 검토자가 자신의 역할과 책임을 이해할 수 있도록 일부 훈련이 필요함을 의미 할 수 있습니다.

검토 계획은 검토를 수행 할 때 기술 요인, 조직 요인 및 인력 문제와 관련된 위험을 처리해야 합니다. 충분한 기술적 지식을 가진 검토 자의 가용성은 성공적인 검토에 중요합니다. 프로젝트의 모든 팀은 검토 계획 수립에 참여해야 하며, 이는 각 팀이 검토 프로세스의 성공을 위해 최선을 다해야 합니다. 계획은 각 조직이 필요한 검토자가 프로젝트 일정의 적절한 시점에서 검토를 준비하고 참여할 수 있는 충분한 시간을 할당해야 합니다. 시간은 또한 검토 자에게 필요한 기술 또는 프로세스 교육을 계획해야 합니다. 핵심 검토자가 개인 또는 사업 계획 변경으로 인해 사용할 수 없게 될 경우 백업 검토자를 식별해야 합니다.

공식적인 검토를 실제로 수행하는 동안 검토 책임자는 이를 확인해야 합니다:

l  검토 효율성에 대한 평가를 허용하기 위해 리뷰 참가자들의 적절한 측정이 제공됩니다.

l  향후 검토를 개선하기 위해 점검 목록이 작성 및 유지됩니다.

결함 심각도 및 우선 순위 평가는 검토 중에 발견 된 문제점의 결함 관리에 사용하도록 정의됩니다 (4 장 참조).

각 검토 후에 검토 지도자는 다음을 수행해야 합니다:

l  검토 측정 항목을 수집하고 확인 된 문제가 리뷰의 특정 테스트 목적을 충족 할 만큼 충분히 해결되었는지 확인하십시오.

l  리뷰를 위한 투자 수익 (ROI)을 결정할 때 검토 메트릭을 입력으로 사용하십시오.

l  관련 이해 관계자에게 피드백 정보를 제공하십시오.

l  참가자를 검토 할 수 있는 피드백을 제공하십시오.

 

리뷰의 효과를 평가하기 위해 테스트 매니저는 이후 테스트 (즉, 리뷰 이후)에서 발견 된 실제 결과를 검토 보고서의 결과와 비교할 수 있습니다. 작업 제품이 검토되고 검토를 기반으로 승인되었지만 나중에 결함이 있는 것으로 발견되는 경우 검토 책임자는 검토 프로세스에서 결함이 빠져 나올 수 있는 방법을 고려해야 합니다. 가능한 원인으로는 검토 과정 (예 : 입국 / 출입 조건 불량), 부적절한 검토 팀 구성, 부적절한 검토 도구 (점검 목록 등), 검토 자 훈련 및 경험 부족, 준비 및 검토 회의 시간 부족 등이 있습니다.

여러 프로젝트에서 반복되는 이스케이프 된 결함 패턴 (특히 주요 결함)은 검토 수행에 심각한 문제가 있음을 나타냅니다. 이러한 상황에서 검토 책임자는 프로세스를 검토하고 적절한 조치를 취해야 합니다. 다양한 이유들로 리뷰가 시간이 지남에 따라 효과를 잃을 수도 있습니다. 이러한 효과는 검토를 위한 결함 탐지 효율성을 감소시킴으로써 프로젝트 회고에서 드러날 것입니다. 여기에서 다시 검토 지도자는 원인을 조사하고 고쳐야 합니다. 어쨌든, 검토 기준은 개별적인 검토 자나 저자를 처벌하거나 보상하는 데 사용되어서는 안되며, 검토 과정 자체에 초점을 맞추어야 합니다.

 

3.4 리뷰를 위한 메트릭스

검토 리더 (이전 섹션에서 언급했듯이 테스트 관리자 일 수 있음)는

해당 측정 항목을 사용할 수 있는 위치 :

l  검토 된 항목의 품질 평가

l  리뷰 실시 비용 평가

l  검토를 수행 한 다운 스트림 혜택 평가

검토 리더는 측정 값을 사용하여 투자 수익 및 검토 효율성을 결정할 수 있습니다. 이러한 측정 기준은보고 및 프로세스 개선 활동에도 사용할 수 있습니다.

검토 된 각 작업 결과에 대해 다음과 같은 측정 항목을 측정하고 제품 평가를 위해보고 할 수 있습니다:

l  작업 제품 크기 (페이지, 코드 줄 등)

l  준비 시간 (검토 전)

l  검토를 수행 할 시간

l  결함 수정을 위한 재 작업 시간

l  검토 프로세스 기간

l  발견 된 결함 수 및 심각도

l  작업 제품 내의 결함 클러스터 식별 (즉,보다 높은 결함 밀도를 갖는 영역)

l  검토 유형 (비공식 검토, 둘러보기, 기술 검토 또는 검사)

l  평균 결함 밀도 (예 : 페이지 당 또는 1,000 줄의 코드 당 결함)

l  추정 잔여 결함 (또는 잔류 결함 밀도)

각 검토에 대해 다음과 같은 측정 항목을 측정하고 프로세스 평가를 위해보고 할 수 있습니다:

l  결함 감지 효과 (수명주기의 뒷부분에서 발견 된 결함을 고려)

l  검토 프로세스 노력 및 타이밍 향상

l  계획된 작업 산출물의 비율

l  발견 된 결함 유형 및 심각성

l  검토 프로세스의 효율성과 효율성에 대한 참가자 설문 조사

l  검토 결함 및 동적 테스트 결함 및 생산 결함에 대한 품질 메트릭 비용

l  검토 효율성의 상관 관계 (검토 유형 대 결함 탐지 효과)

l  리뷰어의 수

l  작업 시간당 결함 발견

l  예상 프로젝트 시간 절약

l  평균 결함 노력 (즉, 전체 탐지 및 고정 시간을 결함 수로 나눈 값)

또한 위의 제품 평가에 언급 된 측정 지표는 프로세스 평가에도 유용합니다.

 

3.5 정식 리뷰 관리

ISTQB Foundation Level 강의 계획서는 기획, 시작, 개별 준비, 검토 회의, 재 작업 및 후속 작업과 같은 공식 검토의 여러 단계를 설명합니다. 공식 검토를 올바르게 수행하기 위해 검토 책임자는 검토 프로세스의 모든 단계를 준수해야 합니다.

정식 리뷰에는 다음과 같은 여러 가지 특성이 있습니다:

l  정의 된 진입 및 퇴출 기준

l  리뷰어가 사용할 체크리스트

l  보고서, 평가 시트 또는 기타 검토 요약 시트와 같은 산출물

l  검토 효율성, 효율성 및 진행 상황을 보고 하는 지표

공식 검토를 시작하기 전에 검토 요구 사항 (절차 또는 진입 기준 목록에 정의 된 대로)의 충족 여부는 검토 책임자가 확인해야 합니다.

정식 검토를 위한 전제 조건이 충족되지 않은 경우, 검토 책임자는 최종 결정을 위해 다음 중 하나를 검토 기관에 제안 할 수 있습니다:

l  수정 된 목표로 검토 재정의

l  검토가 진행되는 데 필요한 시정 조치

l  검토 연기

공식적인 검토를 통제하는 일환으로 이 리뷰는 전반적인 (상위 레벨) 프로그램의 맥락에서 모니터링되며 프로젝트 품질 보증 활동과 관련됩니다. 정식 리뷰 제어에는 제품 및 프로세스 메트릭을 사용한 피드백 정보가 포함됩니다.

4. 결함 관리 - 150 분.

키워드

비정상, 결함, 결함 선별위원회, 실패, 거짓음성 결과, 거짓양성 결과, 단계 봉쇄, 우선 순위, 근본 원인, 심각도

결함 관리 학습 목표

4.2 결함 수명주기 및 소프트웨어 개발 수명주기

TM-4.2.1 (K3) 테스트 라이프 사이클 전반에 걸쳐 프로젝트의 결함을 모니터링하고 제어하는 데 사용할 수 있는 결함 보고서 워크 플로를 포함하여 테스트 조직을 위한 결함 관리 프로세스를 개발합니다.

TM-4.2.2 (K2) 효과적인 결함 관리에 필요한 프로세스와 참가자를 설명하십시오.

4.3 결함 보고서 정보

TM-4.3.1 (K3) 결함 관리 프로세스 중에 수집해야 하는 데이터 및 분류 정보를 정의합니다.

4.4 결함 보고서 정보로 프로세스 기능 평가

TM-4.4.1 (K2) 결함 보고서 통계를 사용하여 테스트 및 소프트웨어 개발 프로세스의 프로세스 기능을 평가하는 방법을 설명하십시오.

4.1 소개

조직의 결함 관리 프로세스와 이 작업을 관리하는 데 사용되는 도구는 테스트 팀뿐만 아니라 소프트웨어 개발과 관련된 모든 팀에게 매우 중요합니다. 효과적인 결함 관리로 수집 된 정보를 통해 Test Manager 및 기타 프로젝트 이해 관계자는 개발 라이프 사이클 전반에 걸쳐 프로젝트 상태에 대한 통찰력을 얻을 수 있으며 시간 경과에 따른 데이터 수집 및 분석을 통해 테스트 및 개발 프로세스를 위한 잠재적 개선 영역을 찾을 수 있습니다.

전반적인 결함 수명주기를 이해하고 테스트 및 소프트웨어 개발 프로세스를 모니터링하고 제어하는 데 사용되는 방법 이외에도 Test Manager는 캡처에 중요한 데이터가 무엇인지 잘 알고 있어야 하며 두 가지 모두의 올바른 사용을 지지해야 합니다. 프로세스 및 선택된 결함 관리 툴을 포함한다.

4.2 결함 수명주기 및 소프트웨어 개발 수명주기

Foundation Level 강의에서 설명한 것처럼 작업 제품을 만드는 동안 사람이 실수를 하면 결함이 발생합니다. 이 작업 결과물은 요구 사항 사양, 사용자 스토리, 기술 문서, 테스트 케이스, 프로그램 코드 또는 소프트웨어 개발 또는 유지 관리 프로세스 중에 생성 된 기타 작업 제품이 될 수 있습니다.

결함은 소프트웨어 개발 라이프 사이클의 어느 시점에서나 소프트웨어 관련 작업 제품에 도입 될 수 있습니다. 따라서 소프트웨어 개발 라이프 사이클의 각 단계에는 잠재적 인 결함을 감지하고 제거하는 활동이 포함되어야 합니다. 예를 들어, 정적 테스트 기술 (즉, 검토 및 정적 분석)은 설계 사양, 요구 사항 사양 및 코드에서 이러한 작업 제품을 후속 작업에 제공하기 전에 사용할 수 있습니다. 초기에 각 결함이 감지되고 제거 될수록 시스템의 전반적인 품질 비용은 낮아집니다. 주어진 결함 레벨에 대한 품질 비용은 그것이 도입 된 동일한 단계에서 (즉, 소프트웨어 프로세스가 완벽한 위상 억제를 달성 할 때) 각 결함이 제거 될 때 최소화된다. 또한 Foundation Level 강의에서 설명한 것처럼 정적 테스트는 오류를 찾는 것이 아니라 직접 결함을 찾아내어 결함을 분리하는 데 디버깅 활동이 필요하지 않으므로 결함 제거 비용이 낮습니다.

단위 테스트, 통합 테스트 및 시스템 테스트와 같은 동적 테스트 활동에서 결함이 발생하면 실제 결과와 예상되는 테스트 결과간에 불일치가 발생합니다 (예: 비 정상적인 ). 경우에 따라 테스터가 예외를 관찰하지 않을 때 거짓음성 결과가 발생합니다. 테스터가 이 예외를 관찰하면 추가 조사가 필요한 상황이 발생했습니다. 이 조사는 결함 보고서를 제출하는 것으로 시작됩니다.

테스트 주도 개발에서는 자동화 된 단위 테스트가 실행 가능한 설계 사양의 한 형태로 사용됩니다. 코드가 개발되면 이러한 테스트를 사용하여 즉시 실행됩니다. 유닛의 개발이 완료 될 때까지 일부 또는 모든 테스트가 실패합니다. 따라서 이러한 테스트의 실패는 결함을 구성하지 않으며 일반적으로 추적되지 않습니다.

4.2.1 결함 워크 플로 및 상태

대부분의 테스트 조직은 결함 수명주기를 통해 결함 보고서를 관리하는 도구를 사용합니다. 결함 보고서는 일반적으로 워크 플로우를 통해 진행되며 결함 라이프 사이클을 거치면서 상태 시퀀스를 따라 이동합니다. 이 상태의 대부분에서 단일 결함주기 참가자가 보고서를 소유하고 완료되면 결함 보고서를 다음 상태로 이동시키고 다음 책임자에게 할당하는 작업을 수행 할 책임이 있습니다.

결함 보고서가 닫히는 (일반적으로 기본 결함이 고정되어 있고 확인 테스트를 통해 수정이 확인되었음을 의미), 취소 된 (일반적으로 결함 보고서가 유효하지 않음을 의미), 재생 불가능한 경우 (일반적으로 이례적 더 이상 관찰 할 수 없거나 지연됨 (일반적으로 이 예외가 실제 결함과 관련되어 있음을 의미하지만 프로젝트 중에 결함이 수정되지 않음), 더 이상의 조치가 필요하지 않으므로 보고서에 소유자가 없습니다. 테스트 도중 테스터가 발견 한 결함의 경우 테스트 팀과 함께 작업하는 세 가지 상태가 있습니다.

l  초기 상태

o이 상태에서 한 명 이상의 테스터가 사람에게 필요한 정보를 수집합니다.

결함을 해결하여 그 이상을 재현 할 책임이 있다 (4.3 절 참조).

결함 보고서에 포함될 정보에 대한 자세한 정보).

o 이것은 "열린"또는 "새"상태라고도 합니다.

리턴 된 상태

o이 상태에서 보고서 수신자가 보고서를 거부했거나 테스터에게

추가 정보를 제공하십시오. 이 상태는 초기 정보의 부족을 나타낼 수 있습니다.

프로세스 자체 또는 테스트 자체를 수집하고 테스트 매니저는

과도한 수익률. 테스터 (들)는 추가 정보를 제공해야 합니다.

보고서가 실제로 거부되어야 함을 확인하십시오.

o "거부"또는 "설명"상태라고도 합니다.

확인 테스트 상태

o이 상태에서 테스터는 확인 테스트를 실행합니다.

결함 보고서 자체에서 오류를 재현) 수정 프로그램의 수정 여부를 결정합니다

실제로 문제를 해결했습니다. 결함 확인 테스트에서 결함이 발견되면

테스터는 보고서를 닫아야 합니다. 확인 테스트에서 결함이 복구되지 않았다고 표시되면 테스터는 보고서를 다시 열어야 이전 소유자에게 재 할당되어 결함을 복구하는 데 필요한 작업을 완료 할 수 있습니다.

o이는 "해결 된"또는 "확인"상태라고도 합니다.

4.2.2 잘못되었거나 중복 된 결함 보고서 관리

경우에 따라 결함은 결함의 증상이 아닌 테스트 환경, 테스트 데이터, 테스트웨어의 다른 요소 또는 테스터 자체의 오해로 인해 발생합니다. 테스터가 결함 보고서를 열면 나중에 테스트중인 작업 제품의 결함과 관련이 없는 것으로 밝혀지며 이는 잘못된 결과입니다. 이러한 보고서는 일반적으로 취소되거나 유효하지 않은 결함 보고서로 마감됩니다. 또한, 어떤 경우에는 결함이 테스터에게 전혀 관련이 없는 것으로 보이는 다른 증상을 나타낼 수 있습니다. 동일한 근본 원인과 관련된 것으로 발견 된 둘 이상의 결함 보고서가 제출되면 일반적으로 결함 보고서 중 하나는 유지되고 다른 결함 보고서는 중복 된 결함 보고서로 닫힙니다.

무효하고 중복 된 결함 보고서는 일정 수준의 비효율을 나타내지 만, 그러한 보고서의 일부는 피할 수 없으며 시험 관리자가 이를 받아 들여야 합니다. 관리자가 유효하지 않은 모든 중복 된 결함 보고서를 제거하려고 하면 테스터가 결함 보고서를 제출하지 않기 때문에 가짜 전취 횟수가 증가합니다. 이는 대부분의 경우 주요 테스트 조직의 목표와 관련된 테스트 조직의 결함 탐지 효율성을 감소시킵니다.

4.2.3 교차 기능 결함 관리

테스트 조직과 테스트 관리자는 일반적으로 전체 결함 관리 프로세스와 결함 관리 도구를 소유하지만 일반적으로 교차 기능 팀은 주어진 프로젝트의보고 된 결함을 관리해야 합니다. 결함 관리 (또는 결함 분류)위원회의 참가자는 일반적으로 개발, 소프트웨어 관리에 관심이 있는 개발, 프로젝트 관리, 제품 관리 및 기타 이해 관계자를 포함합니다.

결함 관리 도구에 이상이 발견되어 입력되면 결함 관리위원회는 각 결함 보고서가 유효한 결함인지 여부와 고정 또는 지연 여부를 결정하기 위해 충족해야 합니다. 이 결정은 결함 관리위원회가 결함을 수정하거나 수정하지 않은 것과 관련된 이익, 위험 및 비용을 고려할 것을 요구합니다. 결함을 수정해야 하는 경우 팀은 다른 프로젝트 작업과 관련하여 결함을 수정하는 우선 순위를 설정해야 합니다. 테스트 관리자와 테스트 팀은 결함의 상대적 중요성에 대해 상담하고 이용 가능한 객관적인 정보를 제공해야 합니다.

결함 추적 도구를 올바른 의사 소통의 대체물로 사용해서는 안되며 결함 관리 도구 회의를 결함 추적 도구의 효과적인 사용 대신 사용할 수 없도록 해야 합니다. 효과적이고 효율적인 결함 관리를 위해서는 통신, 적절한 도구 지원, 잘 정의 된 결함 수명주기 및 약정 된 결함 관리위원회가 모두 필요합니다.

 

4.3 결함 보고서 정보

(정적 테스트의 일부로) 결함이 발견되거나 (동적 테스트의 일부로) 결함이 관찰되면 관련자가 데이터를 수집하여 결함 보고서에 포함시켜야 합니다. 이 정보는 세 가지 목적으로 충분합니다:

l  결함 수명주기를 통한 보고서 관리

l  프로젝트 품질, 특히 제품 품질 및 테스트 진행 상황에 대한 평가

l  프로세스 능력 평가 (아래 4.4 절에서 논의 됨)

결함 보고서 관리 및 프로젝트 상태에 필요한 데이터는 수명주기에서 결함이 발견되는 시기 (일반적으로 요구 사항 검토 및 단위 테스트와 같이 이전에 필요한 정보가 적음)에 따라 달라질 수 있습니다. 그러나 수집 된 핵심 정보는 프로젝트 전체 및 모든 프로젝트에서 프로세스 결함 데이터를 의미 있는 방식으로 비교할 수 있도록 모든 프로젝트에서 수명주기 전반에 걸쳐 일관성을 유지해야 합니다.

결함 데이터 수집은 테스트 진행 모니터링, 제어 및 종료 기준 평가를 지원할 수 있습니다. 예를 들어, 결함 정보는 결함 밀도 분석, 검출 및 해결 된 결함의 경향 분석, 결함 검출에서 분해능 까지의 평균 시간 및 결함 강도 (예 : MTBF 분석)를 지원해야 한다.

수집 될 결함 데이터에는 다음이 포함될 수 있습니다:

l  결함을 발견 한 사람의 이름

l  사람의 역할 (예 : 최종 사용자, 비즈니스 분석가, 개발자, 기술 지원 담당자)

l  수행되는 테스트의 유형 (예 : 사용성 테스트, 성능 테스트, 회귀

테스트)

l  문제 요약

l  문제에 대한 자세한 설명

l  실제 및 예상 결과와 함께 오류를 재현하는 단계 (결함의 경우)

l  스크린 샷, 데이터베이스 덤프 및 로그 (해당되는 경우)를 포함하여 실제 및 예상 결과 (결함 강조 표시)와 함께 오류를 재현하는 단계

l  테스트 레벨을 포함하여 결함의 도입, 탐지 및 제거의 라이프 사이클 단계 해당되는 경우 입니다.

l  시스템 및 / 또는 제품 이해 관계자에 대한 영향의 심각도 (보통 결정됨, 시스템의 기술적 인 행동에 의해)

l  문제를 해결하기 위한 우선 순위 (일반적으로 장애로 인한 비즈니스 영향으로 결정됨)

l  결함이 있는 하위 시스템 또는 구성 요소 (결함 클러스터 분석 용)

문제가 발견되었을 때 발생하는 프로젝트 활동

l  문제를 드러내는 식별 방법 (예 : 검토, 정적 분석, 동적

테스트, 생산 사용)

l  결함 유형 (일반적으로 결함 분류에 해당)

l  결함의 영향을 받는 품질 특성

l  결함이 관찰 된 테스트 환경 (동적 테스트 용)

l  문제가 있는 프로젝트 및 제품

l  현재 소유자. 즉 보고서가 최종 상태가 아니라고 가정하고 현재 문제에 대한 작업에 할당 된 사람

l  보고서의 현재 상태 (일반적으로 수명주기의 일부로 결함 추적 도구로 관리됨)

l  문제점이 궁극적으로 해결 된 특정 작업 제품과 함께 문제점이 관찰 된 특정 작업 제품 (예 : 테스트 항목 및 해당 릴리스 번호)

l  프로젝트 및 제품 이해 관계자의 이익에 미치는 영향

l  문제를 해결하기 위해 취해진 조치 또는 취해지지 않은 조치에 대한 결론, 권고 및 승인

l  결함 수정 또는 수정과 관련된 위험, 비용, 기회 및 이점

l  다양한 결함 수명주기가 발생한 날짜, 각 전환에 따른 보고서 소유자 및 프로젝트 팀 구성원이 결함 수정을 분리, 복구 및 확인하기 위해 취한 조치

l  결함이 궁극적으로 해결 된 방법에 대한 설명 및 수정 프로그램 테스트를위한 권장 사항 (소프트웨어 변경으로 결함이 해결 된 경우)

l  결함을 밝혀내는 시험 및 결함과 관련된 위험, 요구 사항 또는 기타 시험 기본 요소 (동적 시험의 경우)와 같은 기타 참조 사항.

테스트 관리자가 결함보고를 위해 수집 할 정보를 결정하는 데 도움이 되는 ISO 9126 [ISO9126] (ISO 25000으로 대체 됨), IEEE 829 [IEEE829], IEEE 1044 [IEEE1044] 및 직교 결함 분류와 같은 다양한 표준 및 문서가 존재합니다 .

결함 보고서에 필요한 특정 정보가 무엇이든 간에 테스터는 완전하고 간결하며 정확하고 객관적이며 적절하고 시기 적절한 정보를 입력하는 것이 중요합니다. 수동 개입과 직접 대면 통신이 개별 결함을 해결한다는 측면에서 결함 보고서 데이터의 문제점을 극복하더라도 결함 보고서 데이터의 문제점은 프로젝트 상태, 테스트 진행 및 프로세스 기능을 적절히 평가하는 데 극복 할 수 없는 장애물이 될 수 있습니다.

 

4.4 결함 보고서 정보로 프로세스 기능 평가

2 장에서 설명한 것처럼 결함 보고서는 프로젝트 상태 모니터링 및 보고에 유용 할 수 있습니다. 메트릭의 프로세스 의미가 주로 고급 테스트 관리 강의 계획서 [ISTQB ETM SYL]에 설명되어 있지만 고급 수준에서 테스트 관리자는 테스트 및 소프트웨어 개발 프로세스의 기능을 평가할 때 결함 보고서가 의미하는 바를 알고 있어야 합니다.

2 장 및 4.3 절에서 언급 된 테스트 진행 모니터링 정보 외에도 결함 정보는 프로세스 개선 이니셔티브를 지원해야 합니다. 예제에는 다음이 포함됩니다.

l  도입, 탐지 및 제거 정보의 단계를 단계별로 사용하여 단계 억제를 평가하고 각 단계의 결함 탐지 효율성을 개선 할 수 있는 방법을 제안합니다.

l  가장 많은 수의 결함이 도입 된 단계의 파레토 (Pareto) 분석에 대한 소개 정보 단계를 사용하여 목표로 개선 된 결함 수를 줄입니다.

l  결함 근본 원인 정보를 사용하여 결함 도입의 근본적인 원인을 판별하여 전체 결함 수를 줄이는 프로세스 개선을 가능하게 합니다.

l  도입, 탐지 및 제거 정보의 단계를 사용하여 품질 분석 비용을 수행하여 결함과 관련된 비용을 최소화합니다.

결함 구성 요소 정보를 사용하여 결함 클러스터 분석을 수행하고 기술적 위험을 보다 잘 이해하고 (위험 기반 테스트의 경우) 문제가 있는 구성 요소를 다시 엔지니어링 할 수 있습니다.

 

테스트 프로세스의 효율성과 효율성을 평가하기 위한 메트릭스의 사용은 전문가 테스트 관리 요목 [ISTQB ETM SYL]에서 논의됩니다.

경우에 따라 팀에서 소프트웨어 개발 수명주기의 일부 또는 전체 동안 발견 된 결함을 추적하지 않도록 선택할 수 있습니다. 이것은 종종 효율성의 이름으로 이루어지며 프로세스 오버 헤드를 줄이기 위해 실제로 테스트 및 소프트웨어 개발의 프로세스 기능에 대한 가시성을 크게 떨어 뜨립니다. 따라서 신뢰할 수 있는 데이터가 없어 위에서 제시 한 개선 사항을 수행하기가 어렵습니다.

5. 시험 과정 개선 - 135 분.

키워드

CMMI (Capability Maturity Model Integration), CTP (Critical Testing Processes), 체계적인 테스트 및 평가 프로세스 (STEP), 테스트 성숙도 모델 통합 (TMMi), TPI 다음

테스트 프로세스 개선을위한 학습 목표

5.2 시험 개선 프로세스

TM-5.2.1 (K2) 예제를 사용하여 테스트 프로세스를 개선하는 것이 중요한 이유를 설명하십시오.

5.3 테스트 프로세스 개선

TM-5.3.1 (K3) IDEAL 모델을 사용하여 테스트 프로세스 개선 계획을 정의합니다.

5.4 TMMi를 사용한 테스트 프로세스 개선

TM-5.4.1 (K2) TMMi 테스트 프로세스 개선 모델의 배경, 범위 및 목표를 요약합니다.

5.5 TPI를 사용하여 테스트 프로세스 개선

TM-5.5.1 (K2) TPI의 배경, 범위 및 목표 요약 다음 테스트 프로세스 개선 모델

5.6 CTP로 테스트 프로세스 개선

TM-5.6.1 (K2) CTP 테스트 프로세스 개선 모델의 배경, 범위 및 목표를 요약합니다.

5.7 STEP을 통한 테스트 프로세스 개선

TM-5.7.1 (K2) STEP 테스트 프로세스 개선 모델의 배경, 범위 및 목표를 요약합니다.

 5.1 서론

일단 조직이 조직되면 전반적인 테스트 프로세스가 지속적으로 개선되어야 합니다. 이 장에서는 일반적인 개선 문제를 먼저 다루고 테스트 프로세스 개선에 사용할 수 있는 특정 모델을 소개합니다. 테스트 관리자는 테스트 프로세스 변경 및 개선의 원동력이 될 것으로 가정해야 하며 이 장에서 논의 된 업계에서 인정하는 기술에 익숙해야 합니다. 테스트 개선 프로세스에 대한 자세한 내용은 전문가 수준의 테스트 프로세스 개선 요령에서 설명합니다.

 

5.2 시험 개선 프로세스

조직에서 소프트웨어를 개선하기 위해 테스트를 사용하는 것처럼 프로세스 개선 기술을 선택하여 소프트웨어 개발 프로세스 및 소프트웨어 결과물을 개선하는 데 사용할 수 있습니다. 프로세스 개선은 테스트 프로세스에도 적용될 수 있습니다. 소프트웨어 및 소프트웨어가 포함 된 시스템의 테스트를 개선하기 위해 다양한 방법과 방법을 사용할 수 있습니다. 이 방법들은 개선을 위한 지침과 영역을 제공함으로써 프로세스 및 결과물을 개선하는 것을 목표로 합니다.

테스트는 종종 총 프로젝트 비용의 주요 부분을 설명합니다. 그러나 CMMI® (자세한 내용은 아래 참조)와 같은 다양한 소프트웨어 프로세스 개선 모델의 테스트 프로세스에는 제한된 주의 만 기울입니다.

테스트 성숙도 모델 통합 (TMMi®), 체계적인 테스트 및 평가 프로세스 (STEP), 중요 테스트 프로세스 (CTP) 및 TPI Next®와 같은 테스트 개선 모델은 대부분의 소프트웨어 프로세스 개선 모델에서 테스트에 대한 관심 부족을 해결하기 위해 개발되었습니다. 이 모델을 적절하게 사용하면 벤치 마크 비교에 사용할 수 있는 조직 간 메트릭의 정도를 제공 할 수 있습니다.

이 강의 계획서에 제시된 모델은 사용을 권장하기 위한 것이 아니며, 모델의 작동 방식과 포함 방법에 대한 대표적인 견해를 제공하기 위해 여기에 제시됩니다.

 

5.2.1 프로세스 개선 소개

프로세스 개선은 소프트웨어 개발 프로세스 및 테스트 프로세스와 관련이 있습니다. 실수로 학습하면 조직에서 소프트웨어를 개발하고 테스트하는 프로세스를 향상시킬 수 있습니다. Deming 개선주기: Plan, Do, Check, Act는 수십 년 동안 사용되어 왔으며 테스터가 현재 사용중인 프로세스를 개선해야 할 때 여전히 관련이 있습니다.

프로세스 개선을 위한 전제 중 하나는 시스템의 품질이 소프트웨어를 개발하는 데 사용 된 프로세스의 품질에 크게 영향을 받았다는 믿음입니다. 소프트웨어 업계의 품질이 향상되면 소프트웨어를 유지 관리하는 데 필요한 리소스가 줄어들어 향후 더 많은 솔루션을 만들 수 있는 시간이 늘어납니다. 프로세스 모델은 모델에 대한 조직의 프로세스 기능을 측정하여 개선을 시작할 수 있는 곳을 제공합니다. 이 모델은 또한 평가 결과에 따라 조직의 프로세스를 개선하기 위한 프레임 워크를 제공합니다.

프로세스 평가는 프로세스 능력 결정을 이끌어 내며 프로세스 개선을 유도합니다. 이것은 개선 효과를 측정하기 위해 후속 공정 평가를 요구할 수 있다.

 5.2.2 프로세스 개선의 유형

평가 모델의 사용은 시도되고 신뢰할 수 있는 방법을 사용하여 테스트 프로세스를 개선하기 위한 표준화 된 접근 방식을 보장하는 일반적인 방법입니다.

프로세스 개선 모델은 두 가지 유형으로 분류됩니다.

1. 모델과 비교하여 조직의 역량을 평가하고 프레임 워크 내에서 조직을 평가하며 프로세스 개선을 위한 로드맵을 제공하기 위해 평가의 일부로 성숙도 측정을 제공하는 프로세스 참조 모델.

2. 객관적 측정을 사용하여 산업 평균에 대한 벤치마킹을 포함하여 조직의 개선 기회에 대한 비즈니스 중심 평가를 제공하는 컨텐츠 참조 모델. 이 평가는 프로세스 개선을 위한 로드맵을 작성하는 데 사용할 수 있습니다.

테스트 프로세스 개선은 예를 들어 분석적 접근법과 소급 회의를 사용하여 모델 없이 수행 할 수도 있습니다.

 

5.3 테스트 프로세스 개선

IT 업계는 테스트 프로세스 개선 모델을 사용하여 높은 성숙도와 전문성을 확보 할 수 있습니다. 업계 표준 모델은 비교에 사용할 수 있는 조직 간 메트릭 및 측정 값을 개발하는 데 도움이 됩니다. 테스트 산업에서 프로세스 개선의 필요성에서 권장 프로세스의 여러 세트가 구체화되었습니다. 여기에는 STEP, TMMi, TPI Next 및 CTP가 포함됩니다. TMMi 및 CMMI와 같은 단계별 모델은 여러 회사 및 조직에서 비교할 표준을 제공합니다. CTP, STEP 및 TPI Next와 같은 연속 모델을 통해 조직은 우선 순위가 가장 높은 문제를 구현 순서대로 자유롭게 처리 할 수 ​​있습니다. 이것들은 이 절에서 더 자세히 논의됩니다.

이 모든 모델을 통해 조직은 현재 테스트 프로세스의 관점에서 어느 위치에 있는지 확인할 수 있습니다. 평가가 수행되면 TMMi 및 TPI Next는 테스트 프로세스를 개선하기 위한 로드맵을 제안합니다. 또는 STEP 및 CTP를 통해 조직은 가장 큰 프로세스 개선 투자 수익을 얻을 수있는 곳을 결정하고 적절한 로드맵을 선택하기 위해 조직에 맡길 수 있습니다.

 

테스트 프로세스를 검토하고 개선해야 한다는 데 동의하면 IDEALSM 모델 [IDEAL96]에서 정의 된대로 이 활동에 적용 할 프로세스 개선 구현 단계를 정의 할 수 있습니다:

l  개선 프로세스 시작

l  현재 상황 진단

l  테스트 프로세스 개선 설정 계획

l  개선을 실행하는 행동 개선

l  프로그램에서 배우기

 

개선 프로세스 시작

프로세스 개선 활동이 시작되기 전에 프로세스 개선의 목적, 목표, 범위 및 적용 범위가 이해 관계자에 의해 합의됩니다. 이 때 프로세스 개선 모델을 선택할 수도 있습니다. 모델은 공개적으로 사용 가능한 옵션 (예 : CTP, STEP, TMMi 및 TPI Next) 중에서 선택하거나 내부적으로 개발할 수 있습니다. 또한 성공 기준을 정의하고 개선 활동 전반에 걸쳐 측정 할 방법을 결정해야 합니다.

현재 상황 진단

합의 된 평가 접근법이 착수되고 현재의 시험 실시에 대한 평가 및 가능한 공정 개선 목록이 포함 된 시험 평가 보고서가 작성됩니다.

 

테스트 프로세스 개선 계획 수립

가능한 프로세스 개선 목록이 우선 순위가 부여됩니다. 우선 순위 결정은 투자 수익, 위험, 조직 전략과의 정렬 및 / 또는 측정 가능한 양적 또는 질적 이점을 기반으로 할 수 있습니다. 우선 순위를 수립하면 개선 사항 전달 계획이 수립됩니다.

 

개선을 위한 행동

개선 사항 전달을 위한 테스트 프로세스 개선 계획이 구현됩니다. 여기에는 필요한 교육이나 멘토링, 프로세스 조종 및 궁극적으로 완전한 배포가 포함될 수 있습니다.

 

개선 프로그램에서 배우기

프로세스 개선을 완전히 전개 한 후에 잠재적으로 예상치 못한 이익에 추가하여 이전에 수립 한 혜택 중 어떤 혜택을 받았는지 확인하는 것이 필수적입니다. 또한 프로세스 개선 활동에 대한 성공 기준 중 어느 것이 충족되었는지 확인하는 것도 중요합니다.

 

사용되는 프로세스 모델에 따라 프로세스의 이 단계에서는 다음 단계의 성숙도 모니터링이 시작되고 개선 프로세스를 다시 시작하거나 이 시점에서 활동을 중지하기로 결정합니다.

 

5.4 TMMi로 테스트 프로세스 개선하기

테스트 성숙도 모델 통합 (TMMi)은 5 개의 성숙도 레벨로 구성되며 CMMI를 보완하기 위한 것입니다. 각 성숙도 수준에는 조직이 다음 단계로 진출하기 전에 구체적이고 일반적인 목표를 달성함으로써 85 % 완료되어야 하는 정의 된 프로세스 영역이 포함됩니다.

TMMi 완성 수준은 다음과 같습니다:

l  수준 1: 초기

초기 레벨은 형식적으로 문서화되거나 구조화 된 테스트 프로세스가 없는 상태를 나타냅니다. 테스트는 일반적으로 코딩 후 임의의 방식으로 개발되며 테스트는 디버깅과 동일하게 간주됩니다. 테스트의 목적은 소프트웨어가 작동 함을 증명하는 것으로 이해됩니다.

l  수준2: 관리 됨

두 번째 단계는 테스트 프로세스가 디버깅과 명확하게 구분되어있을 때 수행됩니다. 테스트 정책 및 목표 설정, 기본 테스트 프로세스 (예 : 테스트 계획)에서 발견 된 단계 소개, 기본 테스트 기술 및 방법 구현을 통해 접근 할 수 있습니다.

l  수준 3: 정의 됨

세 번째 레벨은 테스트 프로세스가 소프트웨어 개발 라이프 사이클에 통합되고 공식 표준, 절차 및 방법으로 문서화 될 때 도달됩니다. 검토가 수행되며 제어 및 모니터링 할 수 있는 별개의 소프트웨어 테스팅 기능이 있어야 합니다.

l  수준 4: 측정 됨

4 단계는 테스트 프로세스가 특정 프로젝트의 이익을 위해 조직 차원에서 효과적으로 측정되고 관리 될 수 있을 때 달성됩니다.

l  수준5 : 최적화 됨

최종 레벨은 테스트 프로세스의 데이터가 결함을 예방하는 데 사용될 수 있는 테스트 프로세스 성숙도의 상태를 나타내며, 초점은 확립 된 프로세스를 최적화하는 데 있습니다.

 

TMMi에 대한 자세한 내용은 [vanVeenendaal11] 및 [www.tmmi.org]를 참조하십시오.

5.5 TPI를 사용하여 테스트 프로세스 개선

TPI Next 모델은 테스트 전략, 메트릭, 테스트 도구 및 테스트 환경과 같은 테스트 프로세스의 특정 측면을 다루는 16 가지 핵심 영역을 정의합니다.

모델에는 다음 4 가지 성숙도가 정의됩니다:

l  머리 글자

l  제어 됨

l  실력 있는

l  최적화

각 성숙 단계에서 각 핵심 영역을 평가하기 위해 특정 검사 점을 정의합니다. 조사 결과는 모든 주요 영역을 다루는 성숙도 매트릭스를 통해 요약되고 시각화됩니다. 개선 목표와 그 실행의 정의는 시험 조직의 필요와 능력에 따라 조정될 수 있다.

일반적인 접근 방식은 TPI Next를 모든 소프트웨어 프로세스 개선 모델과 독립적으로 만듭니다. 이는 테스트 엔지니어링 측면뿐만 아니라 경영 의사 결정 지원 [deVries09]을 다룹니다.

TPI Next에 대한 자세한 내용은 [www.tpinext.com]을 참조하십시오.

 

5.6 CTP로 테스트 프로세스 개선

Critical Testing Processes (CTP) 평가 모델의 기본 전제는 특정 테스트 프로세스가 중요하다는 것입니다. 이러한 중요한 프로세스가 잘 수행되면 성공적인 테스트 팀을 지원할 것입니다. 반대로 이러한 활동이 제대로 수행되지 않으면 재능 있는 개인 테스터 및 테스트 관리자조차도 성공하지 못할 수 있습니다. 이 모델은 12 가지 중요한 테스트 프로세스를 식별합니다. CTP는 주로 콘텐츠 참조 모델입니다.

CTP 모델은 다음을 포함하여 모델을 조정할 수 있는 문맥에 민감한 접근 방식입니다:

l  특정 과제 식별

l  양호한 프로세스의 속성 인식

l  주문 선택 및 프로세스 개선 구현의 중요성

CTP 모델은 모든 소프트웨어 개발 라이프 사이클 모델의 맥락에서 적용 가능합니다.

참가자 인터뷰 외에도 CTP 모델에는 산업 평균 및 모범 사례에 대한 벤치마킹을 위한 메트릭스 사용이 포함됩니다.

CTP에 대한 자세한 내용은 [Black03]을 참조하십시오.

 

5.7 STEP을 통한 테스트 프로세스 개선

STEP (체계적인 테스트 및 평가 프로세스)는 CTP와 유사하며 TMMi 및 TPI와는 달리 다음 단계에서는 특정 순서로 개선이 필요하지 않습니다.

STEP은 주로 테스트가 요구 사항 공식화 과정에서 시작하여 시스템이 폐기 될 때까지 계속되는 라이프 사이클 활동이라는 아이디어를 기반으로 하는 컨텐츠 참조 모델입니다. STEP 방법론은 요구 사항 기반 테스트 전략을 사용하여 테스트 사례의 초기 생성이 설계 및 코딩 전에 요구 사항 사양의 유효성을 확인하도록 "테스트 후 코드"에 강조합니다.

 방법론의 기본 전제는 다음과 같습니다:

l  요구 사항 기반 테스트 전략

l  테스트는 라이프 사이클의 시작 부분에서 시작됩니다.

l  테스트는 요구 사항 및 사용 모델로 사용됩니다.

l  소프트웨어 디자인을 주도하는 테스트웨어 디자인

l  결함은 이전에 감지되거나 모두 차단됩니다.

l  결함은 체계적으로 분석됩니다.

l  테스터와 개발자가 함께 작업합니다.

 

어떤 경우에는 STEP 평가 모델이 TPI Next 성숙도 모델과 혼합됩니다.

STEP에 대한 자세한 내용은 [Craig02]를 참조하십시오.

6. 테스트 도구 및 자동화 - 135 분

키워드

오픈 소스 도구, 사용자 정의 도구

테스트 도구 및 자동화 학습 목표

6.2 공구 선택

TM-6.2.1 (K2) 오픈 소스 도구를 선택할 때의 관리 문제 설명

TM-6.2.2 (K2) 사용자 정의 도구를 결정할 때의 관리 문제 설명

TM-6.2.3 (K4) 위험, 비용 및 이점을 포함하여 도구 선택을 위한 계획을 수립하기 위해 주어진 상황을 평가하십시오.

6.3 공구 수명주기

TM-6.3.1 (K2) 공구 수명주기의 여러 단계 설명

6.4 도구 메트릭

TM-6.4.1 (K2) 도구를 사용하여 메트릭 수집 및 평가를 향상시킬 수 있는 방법 설명

6.1 서론

이 섹션에서는 도구 및 자동화와 관련하여 Test Manager에서 고려해야 하는 여러 가지 일반적인 개념을 다루면서 Foundation Level 강의를 확장합니다.

6.2 공구 선택

테스트 도구를 선택할 때 테스트 관리자가 고려해야 하는 다양한 문제가 있습니다.

역사적으로 가장 보편적 인 선택은 상업용 공급 업체에서 도구를 구입하는 것입니다. 어떤 경우에는 이것이 유일한 실용적인 선택 일 수 있습니다. 그러나 오픈 소스 도구 및 사용자 지정 도구와 같은 다른 가능성도 있으며 이는 실현 가능한 옵션입니다.

도구 유형에 관계없이 시험 관리자는 비용 편익 분석을 수행하여 도구의 예상 수명 동안 총 소유 비용을 조사해야 합니다. 이 주제는 투자 수익 (ROI) 섹션에서 아래에서 다룹니다.

 

6.2.1 오픈 소스 도구

오픈 소스 도구는 테스트 사례 관리에서부터 결함 추적, 테스트 케이스 자동화에 이르는 테스트 프로세스의 거의 모든 측면에 사용할 수 있습니다. 오픈 소스 도구의 중요한 차이점은 도구 자체는 일반적으로 초기 구입 비용이 높지 않지만 도구에 사용할 수 있는 공식적인 지원이 없을 수도 있다는 것입니다. 그러나 많은 오픈 소스 도구에는 비 전통적이거나 비공식적 인 사용자 지원을 기꺼이 제공 할 헌신적 인 도구가 있습니다.

또한 많은 오픈 소스 도구는 원래 특정 문제를 해결하거나 단일 문제를 해결하기 위해 만들어졌습니다. 따라서 이 도구는 유사한 공급 업체 도구의 모든 기능을 수행하지 못할 수도 있습니다. 이 때문에 오픈 소스 도구를 선택하기 전에 테스트 그룹의 실제 요구 사항에 대한 신중한 분석을 수행해야 합니다.

오픈 소스 도구를 사용하는 한 가지 이점은 대개 사용자가 수정하거나 확장 할 수 있다는 것입니다. 테스트 조직에 핵심 역량이 있는 경우 도구를 수정하여 다른 도구와 함께 작동하거나 테스트 팀의 요구에 맞게 변경할 수 있습니다. 여러 도구를 결합하여 공급 업체 도구가 해결할 수 없는 문제를 해결할 수 있습니다. 물론 사용 된 도구가 많을수록 수정 사항이 많을수록 복잡성과 오버 헤드가 추가됩니다. 테스트 관리자는 팀이 오픈 소스 도구를 사용하기 시작했는지 확인해야 합니다. 다른 도구와 마찬가지로 긍정적 인 ROI를 유도하기 위한 노력이 항상 필요합니다.

테스트 관리자는 선택한 도구의 라이센스 체계를 이해해야 합니다. 많은 오픈 소스 도구에는 GNU 일반 공중 사용 허가서 (General Public License)가 다양하게 포함되어 있습니다.이 소프트웨어는 배포 당시와 동일한 조건으로 제공되어야 합니다. 테스트 팀이 테스트를 보다 잘 지원하기 위해 툴을 변경해야 하는 경우 툴 라이선스 하에 툴의 모든 외부 사용자가 이러한 변경 사항을 사용할 수 있어야 합니다. 테스트 매니저는 조직을 위해 소프트웨어를 재배포하는 법적 파급 효과를 확인해야 합니다.

안전 또는 업무용 소프트웨어를 개발하거나 규제 준수 대상인 조직은 오픈 소스 도구를 사용하는 데 문제가 있을 수 있습니다. 많은 오픈 소스 도구가 매우 높은 품질을 제공하지만 주어진 오픈 소스 도구의 정확성은 인증되지 않았을 가능성이 큽니다. 공급 업체 도구는 특정 작업 (예 : DO-178B)에 대한 정확성 및 적합성에 대해 인증을 받는 경우가 많습니다. 오픈 소스 도구가 그만큼 좋을 수도 있지만, 인증은 추가 오버 헤드를 발생시키는 그룹의 책임 일 수 있습니다.

 6.2.2 사용자 정의 도구

테스트 조직은 벤더 또는 오픈 소스 툴을 사용할 수 없는 구체적인 필요성을 느낄 수 있습니다. 이유는 독점적 인 하드웨어 플랫폼, 사용자 지정 환경 또는 비정상적인 방법으로 수정 된 프로세스 일 수 있습니다. 이러한 경우 핵심 역량이 팀에 존재하면 시험 관리자는 맞춤 도구 개발을 고려할 수 있습니다.

맞춤 도구 개발의 이점은 팀의 요구 사항을 정확하게 충족 할 수 있고 팀이 요구하는 상황에서 효율적으로 운영 할 수 있다는 것입니다. 이 도구는 사용중인 다른 도구와의 인터페이스를 작성하고 팀이 필요로 하는 정확한 형식으로 데이터를 생성 할 수 있습니다. 또한 이 도구는 즉각적인 프로젝트 이상으로 조직에 응용 프로그램을 포함 할 수 있습니다. 그러나 다른 프로젝트를 위해 도구를 공개하기 전에 목적, 목표, 이점 및 가능한 단점을 먼저 검토하는 것이 중요합니다.

맞춤 도구를 만드는 것을 고려하는 테스트 관리자는 부정적인 문제도 고려해야 합니다. 사용자 정의 도구는 대개 도구를 만드는 사람에 따라 다릅니다. 따라서 사용자 지정 도구는 다른 사용자가 유지 관리 할 수 ​​있도록 적절하게 문서화 되어야 합니다. 이 작업이 완료되지 않으면 도구 작성자가 프로젝트를 종료 할 때 고아가 될 수 있습니다. 시간이 지남에 따라 사용자 정의 도구의 범위가 초기 의도 이상으로 확장되어 도구의 품질 문제가 발생하여 가양 성 결함 보고서 또는 부정 확한 데이터 작성이 발생할 수 있습니다. 테스트 관리자는 사용자 정의 도구가 다른 소프트웨어 제품 일 뿐이므로 다른 소프트웨어 제품과 동일한 개발 문제가 발생할 수 있음을 명심해야 합니다. 사용자 정의 도구는 예상대로 작동하도록 설계되고 테스트 되어야 합니다.

 

6.2.3 투자 수익 (ROI)

테스트 관리자는 테스트 조직에 도입 된 모든 도구가 팀 작업에 가치를 더하고 조직에 긍정적 인 ROI를 보여줄 수 있도록 하는 것이 테스트 관리자의 책임입니다. 도구가 실제적이고 지속적인 이익을 얻는 지 확인하려면 도구를 구입하거나 구축하기 전에 비용 편익 분석을 수행해야 합니다. 이 분석에서 ROI는 반복적 및 비 반복적 비용 중 일부는 화폐 단위이며 일부는 자원 또는 시간 비용이며 도구의 가치를 저하시킬 수 있는 위험을 고려해야 합니다.

비 반복 비용에는 다음이 포함됩니다. 목표 및 목표를 충족시키기 위한 도구 요구 사항 정의 올바른 도구 및 도구 공급 업체 평가 및 선택 도구 구입, 적용 또는 개발 도구 초기 교육 수행 도구를 다른 도구와 통합 하드웨어 / 도구를 지원하는 데 필요한 소프트웨어

반복 비용에는 다음이 포함됩니다.

o 라이센스 및 지원 비용

도구 자체의 유지 보수 비용

o 도구로 생성 된 아티팩트 유지 관리

o 지속적인 교육 및 멘토링 비용 도구를 다른 환경으로 이식 미래의 필요에 맞게 도구 적용 선택한 도구의 최적 사용을 보장하기 위해 품질 및 프로세스 개선

또한 테스트 관리자는 모든 도구의 고유 한 기회 비용을 고려해야 합니다. 도구를 획득, 관리, 교육 및 사용하는 데 소요 된 시간은 실제 테스트 작업에 소비되었을 수 있습니다. 따라서 도구가 온라인 상태가 될 때까지 더 많은 테스트 리소스가 필요할 수 있습니다.

도구 사용에는 많은 위험이 있습니다. 모든 도구가 실제로 위험보다 중요한 이익을 제공하는 것은 아닙니다. 도구 위험은 Foundation Level 강의에서 논의되었습니다. 테스트 관리자는 ROI를 고려할 때 다음과 같은 위험을 고려해야 합니다.

l  조직의 미숙 (도구를 사용할 준비가 되지 않았습니다)

l  도구로 생성 된 아티팩트는 유지하기 어려울 수 있으며 테스트중인 소프트웨어가 변경 될 때 여러 번 수정해야 합니다.

l  테스트 분석가의 테스트 작업 참여는 테스트의 가치를 떨어뜨릴 수 있습니다 (예: 자동화 된 스크립트 만 실행하면 결함 탐지 효율성이 떨어질 수 있음)

마지막으로, 테스트 관리자는 도구 사용으로 인해 발생할 수 있는 이점을 조사해야 합니다. 도구 도입 및 사용의 이점에는 다음이 포함될 수 있습니다:

l  반복 작업의 감소

l  테스트주기 시간 감소 (예 : 자동 회귀 테스트 사용)

l  테스트 실행 비용 감소

l  특정 유형의 테스트 증가 (예 : 회귀 테스트)

l  다른 유형의 인적 오류 감소 테스트 단계. 예:

o 테스트 데이터는 데이터 생성 도구를 사용하여 더 유효 할 수 있습니다.

o 비교 도구를 사용하면 테스트 결과 비교가 더 정확해질 수 있습니다.

o 스크립팅 도구로 입력하여 테스트 데이터 입력이 더 정확할 수 있습니다.

l  테스트에 대한 정보에 액세스하는 데 필요한 노력을 줄입니다. 예 :

o 도구로 생성 된 보고서 및 메트릭

o 테스트 케이스, 테스트 스크립트 및 테스트 데이터와 같은 테스트

l  자산 재사용 도구 없이는 불가능했던 테스트의 증가 (예: 성능 테스트, 로드 테스트)

l  자동화 및 테스트 조직 전체를 작성하는 테스터의 상태 개선 정교한 도구의 이해와 사용을 보여주는

일반적으로 테스트 그룹은 단일 도구를 사용하지 않습니다. 테스트 팀이 얻을 수 있는 총 투자 수익 (ROI)은 일반적으로 사용되는 모든 도구의 기능입니다. 도구는 정보를 공유하고 함께 협력해야 합니다. 장기적이고 포괄적 인 테스트 툴 전략이 바람직합니다.

 

6.2.4 선정 과정

테스트 도구는 장기 투자로 단일 프로젝트의 많은 반복 작업에 적용될 수 있으며 많은 프로젝트에 적용될 수 있습니다. 시험 관리자는 여러 가지 관점에서 장래성 있는 도구를 고려해야 합니다.

l  비즈니스에 긍정적 인 ROI가 필요합니다. 투자 가치를 높이려면 조직에서 상호 운용해야 하는 도구 (테스트 도구와 비 테스트 도구를 모두 포함 할 수 있음)가 함께 작동하도록 해야합니다. 경우에 따라 이러한 상호 운용성을 위해 도구 사용을 위한 프로세스와 연결성을 향상시켜야 하며 이를 달성하는 데는 다소 시간이 걸릴 수 있습니다.

l  프로젝트에 도구가 효과적이어야 합니다 (예 : 데이터 입력 중 입력 오류와 같은 수동 테스트를 수행하는 동안 실수를 피하려면). 긍정적 인 투자 수익 (ROI)을 얻기 위해서는 상당한 시간이 필요합니다. 대부분의 경우 ROI는 자동화가 구현 된 초기 프로젝트가 아니라 두 번째 릴리스 또는 유지 관리 중에 발생할 수 있습니다. Test Manager는 응용 프로그램의 전체 수명주기를 고려해야 합니다.

도구를 사용하는 사람에게 도구는 프로젝트 구성원이 작업을 보다 효율적이고 효과적으로 수행 할 수 있도록 지원해야 합니다. 사용자가 최소의 스트레스로 신속하게 도구를 배울 수 있도록 학습 곡선을 고려해야 합니다. 처음 소개 된 테스트 도구는 사용자를 위해 교육 및 멘토링을 필요로 합니다.

 

모든 관점을 고려하기 위해서는 테스트 도구 소개를 위한 로드맵을 작성하는 것이 중요합니다.

 

테스트 도구 선택 프로세스는 Foundation Level 강의에서 다음과 같이 이미 논의되었습니다:

l  조직 성숙도

l  평가 도구

l  요구 사항 확인 도구

l  평가 벤더 또는 서비스 지원 평가 (오픈 소스 도구, 사용자 지정 도구)

l  코칭 및 멘토링을 위한 내부 요구 사항 파악 도구

l  사용 현재 테스트 팀의 테스트 자동화 기술을 고려하여 교육 필요성

l  평가 비용 편익 예측 (6.2.3 ROI 섹션 참조)

각 도구 유형에 대해 사용되는 테스트 단계에 관계없이 테스트 관리자는 아래 나열된 기능을 고려해야 합니다.

l  분석

o이 도구는 입력 내용을 "이해"할 수 있습니까?

o 도구가 목적에 적합한가?

l  디자인

o이 도구는 기존 정보 (예 : 요구 사항에서 테스트 케이스를 작성하는 테스트 디자인 도구)를 기반으로 테스트웨어를 설계하는 데 도움이 됩니까?

o 설계가 자동으로 생성 될 수 있습니까?

o 실제 테스트웨어 코드가 생성되거나 부분적으로 관리 가능하고 사용 가능한 형식으로 생성 될 수 있습니까?

o 필요한 테스트 데이터가 자동으로 생성 될 수 있습니까 (예 : 코드 분석에서 생성 된 데이터)?

l  데이터 및 테스트 선택

o 도구는 필요한 데이터를 어떻게 선택합니까? (예 : 어떤 데이터 집합으로 실행할 테스트 사례)?

o 도구가 수동 또는 자동으로 입력 된 선택 기준을 수락 할 수 있습니까?

o 선택한 입력에 따라 생산 데이터를 "스크럽"하는 방법을 도구가 결정할 수 있습니까?

o 도구는 적용 범위 기준에 따라 필요한 테스트를 결정할 수 있습니까 (예: 도구가 추적 테스트를 통과하여 실행에 필요한 테스트 사례를 결정할 수 있습니까?).

l  실행

o 도구가 자동으로 실행되거나 수동 개입이 필요합니까?

o 도구는 어떻게 멈추고 다시 시작됩니까?

o 도구가 관련 이벤트를 "청취"할 수 있어야 합니까 (예 : 테스트 사례에 대해보고 된 결함이 종료 된 경우 테스트 관리 도구가 자동으로 테스트 사례 상태를 업데이트 해야 합니까?).

l  평가

o 도구가 적절한 결과를 얻었는지 여부를 도구가 어떻게 결정할 것입니까? (예: 도구가 응답의 정확성을 결정하기 위해 테스트 오라클을 사용합니다)?

o이 도구에는 어떤 유형의 오류 복구 기능이 있습니까?

o 도구가 적절한 기록 및 보고 기능을 제공합니까?

 

6.3 도구 수명주기

다음과 같이 Test Manager에서 관리해야 하는 도구의 유용한 수명주기에는 네 가지 단계가 있습니다.

1. 취득. 도구는 위에서 설명한대로 획득해야 합니다 (6.2 절 도구 선택 참조). 도구를 가져 오는 결정이 내려지면 테스트 관리자는 누군가 (종종 테스트 분석가 또는 기술 테스트 분석가)를 도구 관리자로 지정해야 합니다.

이 사람은 도구를 언제, 언제, 어떻게 사용할 것인지, 생성 된 아티팩트가 저장 될 위치, 명명 규칙 등을 결정해야 합니다. 이러한 결정을 임시 방편으로 수행하는 것보다 먼저 결정하는 것이 도구의 최종 ROI에 중요한 차이를 만들 수 있습니다. 교육은 도구 사용자에게 제공되어야 합니다.

2. 지원 및 유지 관리. 도구 지원 및 유지 보수를 위한 진행중인 프로세스가 필요합니다. 도구 유지 관리는 도구 관리자에게 맡기거나 전용 도구 그룹에 할당 할 수 있습니다. 도구가 다른 도구와 함께 작동하려면 데이터 교환 및 협력 프로세스를 고려해야 합니다. 도구 및 그 출력의 백업 및 복원에 대한 결정을 고려해야 합니다.

3. 진화. 전환을 고려해야 합니다. 시간이 지남에 따라 환경, 비즈니스 요구 사항 또는 공급 업체 문제로 인해 도구 또는 도구의 주요 변경 사항이 필요할 수 있습니다. 예를 들어 도구 공급 업체는 협력 도구로 문제를 일으키는 도구를 업데이트해야 할 수 있습니다. 비즈니스상의 이유로 환경을 변경해야 도구에 문제가 발생할 수 있습니다. 도구의 운영 환경이 복잡할수록 진화 적 변화가 더 커질 수 있습니다. 이 시점에서 도구가 테스트에서 수행하는 역할에 따라 테스트 관리자는 조직에 서비스의 연속성을 보장 할 수 있는 방법이 있는지 확인해야 할 수 있습니다.

4. 은퇴. 공구 수명이 오래 지속될 때가 왔습니다. 이 시점에서 도구는 정상적으로 폐기되어야 합니다. 도구에서 제공하는 기능을 대체해야 하고 데이터를 보존하고 보관해야 합니다. 이는 툴의 라이프 사이클이 끝났거나 새 툴로의 전환의 이점과 기회가 비용과 위험을 초과하는 지점에 도달했기 때문에 발생할 수 있습니다.

도구 수명주기 전반에 걸쳐 도구가 테스트 팀에 제공하는 서비스의 원활한 작동과 원활한 유지를 보장하는 것은 테스트 관리자의 책임입니다.

 

6.4 도구 메트릭

테스트 관리자는 기술 테스트 분석가와 테스트 분석가가 사용하는 도구에서 객관적인 메트릭을 설계하고 수집 할 수 있습니다. 서로 다른 도구를 사용하여 유용한 실시간 데이터를 수집 할 수 있으며 데이터 수집 노력을 줄일 수 있습니다. 이 데이터는 테스트 관리자가 전체 테스트 노력을 관리하는 데 사용할 수 있습니다.

서로 다른 도구는 여러 유형의 데이터를 수집하는 데 중점을 둡니다. 예를 들면 다음과 같습니다. 테스트 관리 도구는 다양한 메트릭을 제공 할 수 있습니다. 요구 사항에서부터 테스트 케이스 및 자동화 된 스크립트에 이르는 추적 성은 커버리지 메트릭을 얻을 수 있게 합니다. 현재 사용 가능한 테스트, 계획된 테스트 및 현재 실행 상태 (통과, 실패, 건너 뛰기, 대기열에서 차단됨)의 스냅 샷을 언제든지 가져올 수 있습니다. 결함 관리 도구는 현재 상태, 심각도 및 우선 순위, 시스템 전반의 배포 등 결함에 대한 풍부한 정보를 제공 할 수 있습니다. 결함이 발견되고 발견되는 단계, 탈출 속도 등과 같은 기타 조명 데이터는 테스트에 도움이 됩니다 관리자 드라이브 프로세스 개선. 정적 분석 도구는 유지 관리 문제를 감지하고 보고하는 데 도움이 될 수 있습니다. 성능 도구는 시스템의 확장성에 대한 중요한 정보를 제공 할 수 있습니다. 커버리지 도구는 테스트 관리자가 실제로 테스트를 통해 얼마나 많은 시스템이 실행되었는지를 이해하는 데 도움을 줄 수 있습니다.

도구의 보고 요구 사항은 도구 선택 프로세스 중에 정의되어야 합니다. 이러한 요구 사항은 도구로 추적 된 정보가 이해 관계자가 이해할 수 있는 방식으로 보고 될 수 있도록 도구 구성 중에 적절하게 구현되어야 합니다.

 7. 사람 기술 - 팀 구성 - 210 mins.

키워드

테스트의 독립성

사람들의 기술 학습 목표 - 팀 구성

7.2 개인 기술

TM-7.2.1 (K4) 기술 평가 스프레드 시트를 사용하여 소프트웨어 시스템, 도메인 및 비즈니스 지식, 시스템 개발 영역, 소프트웨어 테스팅 및 대인 관계 기술 사용과 관련된 팀 구성원의 강점과 약점을 분석합니다.

TM-7.2.2 (K4) 훈련 및 기술 개발 계획을 수립하기 위해 팀의 주어진 기술 평가를 분석합니다.

7.3 시험 팀 역 동성

TM-7.3.1 (K2) 주어진 상황에 대해, 테스트 팀을 이끌기 위해 필요한 하드 스킬과 소프트 스킬에 대해 토론하십시오.

7.4 조직 내 피팅 테스트

TM-7.4.1 (K2) 독립적 인 테스트를 위한 옵션 설명

7.5 동기 부여

TM-7.5.1 (K2) 테스터에 대한 동기 부여 및 탈력 유발 요인의 예를 제공합니다.

7.6 의사 소통

TM-7.6.1 (K2) 테스트 팀 내에서, 그리고 테스트 팀과 이해 관계자 간의 의사 소통의 효율성에 영향을 미치는 요인을 설명하십시오.

 7.1 서론

성공적인 테스트 매니저는 기술을 적절히 혼합하여 팀을 채용, 채용 및 유지합니다. 기술 요구 사항은 시간이 지남에 따라 변경 될 수 있으므로 테스트 팀을 유지하고 최고 수준의 성능을 유지하려면 적절한 교육 및 성장 기회를 제공하는 것이 중요합니다. 팀의 기술 외에도 시험 관리자는 고압의 빠른 진행 환경에서 효과적인 기능을 수행 할 수 있는 일련의 기술을 유지해야 합니다.

이 장에서는 기술을 평가하는 방법, 내부적으로 응집력이 있고 조직에서 효과적인 시너지 효과를 창출하는 팀을 만드는 방법, 팀에 동기를 부여하고 효과적으로 의사를 전달하는 방법에 대해 살펴 봅니다.

 

7.2 개인 기술

개인의 소프트웨어 테스트 능력은 경험이나 교육 및 훈련을 통해 얻을 수 있습니다. 다음 각 요소는 테스터의 지식 기반에 기여할 수 있습니다:

l  소프트웨어 시스템 사용

l  도메인 또는 비즈니스에 대한 지식

l  분석, 개발 및 기술 지원을 포함한 소프트웨어 개발 프로세스 활동의 다양한 단계에 참여

l  소프트웨어 테스팅 활동에 참여

소프트웨어 시스템의 최종 사용자는 시스템의 작동 방식, 장애가 가장 큰 영향을 미치는 방식 및 다양한 상황에서 시스템이 어떻게 반응해야 하는지 잘 알고 있습니다. 도메인 전문 지식을 가진 사용자는 비즈니스에 가장 중요한 영역과 해당 영역이 비즈니스 요구 사항을 충족시키는 방법에 어떤 영향을 미치는지 파악합니다. 이 지식은 테스트 활동의 우선 순위를 지정하고 현실적인 테스트 데이터 및 테스트 사례를 작성하고 유스 케이스를 확인하거나 작성하는 데 사용될 수 있습니다.

 

소프트웨어 개발 프로세스 (요구 사항 분석, 아키텍처, 디자인 및 코딩)에 대한 지식은 오류로 인해 결함이 도입되는 방법, 결함이 탐지 될 수 있는 방법 및 결함 도입을 방지하는 방법에 대한 통찰력을 제공합니다. 기술 지원 경험은 사용자 경험, 기대 및 유용성 요구 사항에 대한 지식을 제공합니다. 소프트웨어 개발 경험은 프로그래밍 및 디자인 전문 지식이 필요하고 정적 코드 분석, 코드 검토, 단위 테스트 및 기술적으로 초점을 맞춘 통합 테스트에 참여하는 테스트 도구를 사용하는 데 중요합니다.

 

특정 소프트웨어 테스팅 기술에는 Foundation에서 논의 된 기능, Advanced Test Analyst 및 Advanced Technical Test Analyst 강의 요강이 포함됩니다 (예 : 사양 분석, 위험 분석 참여, 테스트 케이스 설계, 테스트 실행, 결과 기록 및 테스트 수행을 위한 부지런함).

특히 프로젝트 관리에 대한 지식, 기술 및 경험을 갖춘 테스트 매니저는 테스트 관리가 계획 수립, 진행 상황 추적 및 이해 관계자보고 등과 같은 많은 프로젝트 관리 활동을 포함하기 때문에 중요합니다.

 

프로젝트 관리자가 없을 경우, 특히 프로젝트의 후반 단계에서 Test Manager는 Test Manager와 프로젝트 관리자의 역할을 모두 수행 할 수 있습니다. 이러한 기술은 기초 요강과 이 요강에서 논의 된 능력에 추가됩니다.

 

기술 스킬 외에도 건설적인 비판을 주고 받고, 영향을 주고 협상하는 것과 같은 대인 관계 기술은 테스트의 역할에서 모두 중요합니다. 기술적으로 유능한 테스터는 필요한 소프트 기술을 소유하고 사용하지 않는 한 실패 할 것입니다.

성공적인 시험 전문가는 다른 사람들과 효과적으로 일하는 것 외에도 조직적이고 세밀하고 세심한 서면 의사 소통 기술을 갖추어야 합니다.

 

이상적인 테스트 팀은 기술과 경험 수준이 혼합되어 있으며 팀 구성원은 동료와의 교습 및 학습을 위한 의지와 능력이 있어야 합니다. 일부 환경에서는 일부 기술이 다른 기술보다 더 중요하거나 존중됩니다. 예를 들어, API 테스트 및 프로그래밍 기술이 필요한 기술 테스트 환경에서 기술적 인 기술은 영역 지식 이상의 가치가 있을 수 있습니다. 블랙 박스 테스트 환경에서 도메인 전문성이 가장 가치가 있을 수 있습니다. 환경과 프로젝트가 변화한다는 것을 기억하는 것이 중요합니다.

 

기술 평가 스프레드 시트를 작성할 때 테스트 관리자는 직무에 중요하고 직위에 적합한 모든 기술을 나열해야 합니다. 이러한 기술이 항목별로 분류되면 팀의 각 개인을 점수 시스템 (예: 점수가 1에서 5로 등급이 매겨지며 해당 지역에서 예상되는 최고 기술 수준이 5 점임)에 대해 평가할 수 있습니다. 개인은 자신의 강점과 약점을 파악하기 위해 평가를 받을 수 있으며, 그 정보를 바탕으로 개별 또는 그룹 교육 계획을 수립 할 수 있습니다. 시험 관리자는 개인이 특정 영역에서 자신의 기술을 향상시키는 성과 목표를 세울 수 있으며 개인의 기술을 평가하는 데 사용되는 특정 기준을 정의해야 합니다.

 

사람들은 단일 프로젝트에 대한 기여가 아니라 장기 고용되어야 합니다. 테스트 관리자가 테스터에게 투자하고 지속적인 학습 환경을 조성하면 팀 구성원은 자신의 기술과 지식을 향상시켜 다음 기회를 준비 할 동기를 부여 받게 됩니다.

 

테스트 매니저는 거의 완벽한 팀원을 고용 할 수 없습니다. 팀 구성원이 현재 프로젝트에 적합하다고 하더라도 다음 프로젝트의 완벽한 조합이 아닐 수도 있습니다. Test Manager는 지적이고 호기심이 풍부하고 적응력이 있으며 일할 의사가 있으며 팀의 일원으로 효과적으로 일할 수 있고 기꺼이 배우고 배울 수 있는 사람들을 고용해야 합니다. 그 완벽한 개인의 집합은 아마 이용 가능하지 않더라도, 개인의 강점과 약점을 균형 잡아 강건한 팀을 구성 할 수 있습니다.

 

기술 평가 스프레드 시트를 사용하여 테스트 관리자는 팀의 위치와 취약한 위치를 식별 할 수 있습니다. 이 정보는 훈련 및 기술 개발 계획의 기초를 형성합니다. 팀의 효율성과 효율성에 가장 큰 영향을 미치는 약점부터 테스트 관리자는 이러한 영역을 처리하는 방법을 결정해야 합니다. 한 가지 접근법은 교육을 실시하는 것입니다 (예: 교육 과정에 사람들을 보내고 사내에서 교육 세션을 가지며 맞춤식 교육을 개발하고 전자 학습 과정을 사용합니다). 또 다른 접근법은 독서, 웹 세미나, 인터넷 자원과 같은 자체 학습입니다. 또 다른 접근 방법은 교차 훈련입니다. 예를 들어, 누군가가 기술을 습득해야 하는 작업에 이미 기술을 가지고 있는 사람과 함께 일하는 기술을 배우는 데 관심이 있는 사람을 할당하고, 지역 전문가가 자신의 전문 분야 등에 관한 간단한 프레젠테이션을 하는 등의 방법이 있습니다. 멘토링은 비슷한 접근법으로 새로운 역할을 맡은 사람은 그 역할을 맡은 고위 사람과 짝을 지어 고위 사람은 조언과 도움을 제공하는 지속적인 자원으로 활동합니다.) 약점을 해결 할 뿐 아니라 Test Manager는 교육 ​​및 기술 개발 계획의 일환으로 기술 평가에서 확인 된 강점을 활용해야 합니다. 이러한 테스트 팀 개발 계획에 대한 자세한 내용은 [McKay07]을 참조하십시오.

 

7.3 시험 팀 역 동성

최상의 팀 구성을 위해 직원 선택은 조직의 관리 역할에서 가장 중요한 기능 중 하나입니다. 직업에 필요한 구체적인 개인 능력 외에도 많은 항목을 고려해야 합니다. 팀에 가입 할 개인을 선택할 때 팀의 역 동성을 고려해야 합니다. 이 팀원이 이미 테스트 팀 내에 존재하는 기술과 특성 유형을 보완 할 것입니까? 테스트 팀에서 다양한 성격 유형의 장점과 기술력의 혼합을 고려하는 것이 중요합니다. 강력한 테스트 팀은 다른 프로젝트 팀원과 대인 관계 상호 작용을 성공적으로 처리하는 동시에 다양한 복잡성을 가진 여러 프로젝트를 처리 할 수 있습니다.

 테스트는 종종 높은 압력 활동입니다. 소프트웨어 개발 일정은 종종 비현실적이더라도 압축됩니다. 이해 관계자는 테스트 팀에 대한 높은 기대치를 가지고 있으며 가끔 부당하게 그렇게 합니다. 시험 관리자는 고압 상황에 잘 대처할 사람을 고용해야 하며, 좌절을 막을 수 있고 일정이 불가능할 때라도 작업에 집중할 수 있습니다.

 

Test Manager는 일정 및 예상 문제를 처리하기 위해 Test Manager에게 달려 있지만 Test Manager는 이러한 압력이 팀 구성원들도 느낄 수 있음을 이해해야 합니다. Test Manager가 팀원을 확보 할 때 작업 환경을 고려하고 성격 유형을 해당 환경과 일치시키는 것이 중요합니다. 시간보다 많은 일이 있는 환경에서, 테스트 관리자는 자신의 업무를 끝내고 다음에 무엇을 할 수 있는지 물어 보는 사람들을 찾아야 합니다.

 

개인은 더 열심히 일할 것이고, 그들이 가치 있고 필요하다고 느낀다면 그들이 하는 일에 더 많은 주의를 기울일 것입니다. 개인은 그들이 팀의 중요한 구성원이고 팀의 기여가 팀 전체의 성공에 결정적으로 중요하다는 것을 이해해야 합니다. 이 동적이 생성되면 비공식적으로 교차 트레이닝이 이루어지며 팀원이 작업 부하 분산을 수행하게 되고 Test Manager는 외부 문제를 처리하는 데 더 많은 시간을 갖게 됩니다.

 

새로운 팀 구성원은 신속하게 팀에 동화시켜야 하며 적절한 감독과 지원을 제공해야 합니다. 각 사람은 팀에서 정의 된 역할을 부여 받아야 합니다. 이는 개별 평가 프로세스를 기반으로 할 수 있습니다. 목표는 팀의 전반적인 성공에 기여하는 동시에 각 개인을 개인으로 성공시키는 것입니다. 이것은 주로 성격 유형을 팀 역할과 일치시키고 개인의 타고난 기술을 구축하고 기술 포트폴리오를 향상시킴으로써 이루어집니다.

 

고용 할 사람을 결정하거나 테스트 팀에 추가 할 때 기술에 대한 객관적인 평가가 도움이 될 수 있습니다. 인터뷰, 후보자 테스트, 작업 샘플 검토 및 참조 확인을 통해 수행 할 수 있습니다.

평가해야 할 기술은 다음과 같습니다:

l  기술 문서 (요구 사항, 코드 등) 검토

l  명확하고 이해하기 쉽고 객관적인 방식으로 검토 의견 쓰기

l  주어진 시나리오에 다양한 테스트 기술을 적절하게 적용합니다 (예 : 요구 사항, 코드 등). ,

l  의사 결정 테이블을 사용하여 일련의 비즈니스 규칙 테스트)

l  결함 평가 및 정확하게 문서화 결함 분류 정보에 대한 이해

l  입증 결함의 근본 원인에 대한 이해

l  입증 긍정 및 부정 테스트를 포함하여 툴을 사용하여 주어진 API 테스트

l  SQL 주어진 시나리오를 테스트하기 위해 데이터베이스 정보를 찾고 변경하기

l  여러 테스트를 실행하고 테스트 결과를 수집 할 테스트 자동화, 하네스 설계

l  자동화 된 테스트 실행 및 오류 해결

l  테스트 계획 / 사양 작성

l  테스트 결과 평가를 포함하는 테스트 요약 보고서 작성

대인 관계 기술 (소프트 스킬)은 다음과 같이 입증 될 수 있습니다:

l  일정이 뒤진 테스트 프로젝트 관련 정보 제공.

l  결함이 없다고 생각하는 개발자에게 결함 보고서를 설명합니다.

l  동료 교육

l  효과적이지 않은 프로세스에 관한 경영진에게 문제점 제시.

l  동료가 작성한 테스트 케이스를 검토하고 그 사람에게 주석을 제공

l  동료와의 인터뷰

l  개발자에게 호소

 이 목록은 완전한 목록은 아니며 특정 원하는 기술은 환경과 조직에 따라 다를 수 있지만 일반적으로 필요한 기술 목록입니다. 효과적인 면접 질문을 작성하고 기술 시연을 허용함으로써 시험 관리자는 응시자의 기술을 평가하고 강점과 약점 영역을 결정할 수 있습니다. 훌륭한 평가 세트가 만들어지면 성장 및 훈련 분야를 결정하기 위해 모든 기존 직원에게도 적용되어야 합니다.

개별 기여자가 필요로 하는 기술 외에도, 시험 관리자는 우수한 의사 소통 및 외교 기술을 갖추고 있어야 합니다. Test Manager는 논쟁의 여지가 없는 상황을 해소하고 필요한 의사 소통에 사용할 올바른 미디어를 알아야 하며 조직 내 관계 구축 및 유지 관리에 집중할 수 있어야 합니다.

 

7.4 조직 내 피팅 테스트

조직은 여러 가지 방법으로 테스트를 조직 구조에 맞게 조정할 수 있습니다. 품질은 소프트웨어 개발 수명주기 전반에 걸쳐 모든 사람의 책임이지만 독립적 인 테스트 팀은 품질이 우수한 제품에 크게 기여할 수 있습니다. 테스트 기능의 독립성은 다음 목록에서 볼 수 있듯이 실제로는 가장 독립적 인 순서로 다양합니다.

l  독립적 인 테스터가 없습니다.

o이 경우 독립성이 없으며 코드를 작성한 개발자가 코드를 테스트하고 있습니다.

o 개발자는 테스트를 수행 할 시간이 허용되면 코드가 의도 한대로 작동하는지 결정하며 실제 요구 사항과 다를 수도 있습니다

o 개발자는 발견 된 결함을 신속하게 수정할 수 있습니다.

l  코드를 작성한 개발자가 아닌 다른 개발자가 테스트를 수행합니다.

o 개발자와 테스터간에 독립성이 거의 없다.

o 다른 개발자의 코드를 테스트하는 개발자는 결함보고를 꺼릴 수 있습니다.

o 테스트를 위해 설정된 개발자의 마음은 일반적으로 긍정적 인 테스트 케이스에 초점을 맞춥니다.

l  테스트는 개발 팀의 일부인 테스터 (또는 테스트 팀)가 수행합니다

o 테스터 (또는 테스트 팀)는 프로젝트 관리자에게 보고하거나 개발 관리자에게 보고 할 수 있습니다

o 테스터 마인드 세트는 요구 사항을 준수하는지 확인하는 데 더 중점을 둡니다.

o 테스터는 개발 팀의 구성원이기 때문에 테스터는 테스트 이외에 개발 책임이 있을 수 있습니다

o 테스터의 관리자는 품질 목표를 달성하는 것보다 일정을 맞추는 데 더 집중할 수 있습니다.

o 시험은 개발보다는 팀에서 더 낮은 지위를 부여 받을 수 있다.

o 테스터는 품질 목표 또는 해당 목표 준수에 영향을 줄 권한이 없습니다.

l  테스트는 비즈니스 조직, 사용자 커뮤니티 또는 기타 비 개발 기술 기관의 테스트 전문가가 수행합니다

o 시험 결과 정보는 이해 관계자에게 객관적으로 보고됩니다.

o이 팀의 주요 관심사는 품질입니다.

o 기술 개발 및 훈련은 테스트에 초점을 맞춥니다.

o 시험은 출세의 길로 간주됩니다.

o 품질에 중점을 둔 테스트 그룹에 특별한 관리가 있습니다.

l  외부 테스트 전문가가 특정 테스트 유형에 대한 테스트를 수행합니다.

o 일반화 된 테스트가 불충분 한 특정 분야에 전문 기술이 적용됩니다.

o 테스트 유형은 유용성, 보안성, 성능 또는 전문화가 필요한 기타 분야 일 수 있습니다

o 품질은 이들 개인의 초점이어야 하지만, 그들의 견해는 그들의 전문 분야에 국한된다. 성능이 우수한 제품은 기능 요구 사항을 충족하지 못할 수도 있지만 성능 전문가가 감지하지 못할 수 있습니다.

테스트는 회사 외부의 조직에서 수행합니다.

o 이 모델은 테스터와 개발자 간의 최대한의 독립성을 달성합니다.

o 기술 이전은 테스터가 능숙하게 시험하기에 충분하지 않을 수 있다.

o 명확한 요구 사항과 잘 정의 된 커뮤니케이션 구조가 필요합니다.

o 외부 조직의 품질을 정기적으로 감사해야 합니다.

 

이 목록은 개인의 일반적인 초점을 기반으로 하지만 특정 조직에서는 그렇지 않을 수도 있습니다. 위치와 제목이 반드시 사람의 초점을 결정하지는 않습니다. 개발 관리자는 품질에 중점을 둘 수 있으므로 좋은 테스트 관리자가 될 수 있습니다. 독립적 인 테스트 관리자는 일정 중심의 관리 체인에 보고 할 수 있으므로 품질에 중점을 둔 것보다 일정 중심적 일 수 있습니다. 조직 내의 테스트 팀에 가장 적합한 위치를 결정하려면 테스트 관리자가 조직의 목표를 이해해야 합니다.

 

개발 및 테스트 조직 간에는 다양한 정도의 독립성이 있습니다. 더 많은 독립성으로 인해 더 많은 고립과 지식 이전이 이루어지는 경우에는 균형이 맞을 수 있음을 이해하는 것이 중요합니다. 낮은 수준의 독립성은 지식을 증가시킬 수 있지만 상충되는 목표를 제시 할 수도 있습니다. 독립성의 수준은 소프트웨어 개발 모델에 의해 결정됩니다. 예를 들어 애자일 개발 내에서 테스터는 개발 팀의 일원이 될 수 있습니다.

 

위의 옵션 중 하나라도 조직에 있을 수 있습니다. 독립적 인 테스트 조직뿐만 아니라 개발 조직 내에서 테스트가 수행 될 수 있으며 외부 조직의 최종 인증이 있을 수 있습니다. 테스트의 각 단계에 대한 책임과 기대를 이해하고 일정 및 예산 제약 조건을 유지하면서 완제품의 품질을 극대화하기 위해 요구 사항을 설정하는 것이 중요합니다.

 

7.5 동기 부여

시험 위치에 있는 개인에게 동기를 부여하는 데는 여러 가지 방법이 있습니다. 여기에는 다음과 같은 것들이 포함 됩니다:

l  직무에 대한 인정

l  경영진의 승인

l  프로젝트 팀 내 및 동료 간의 존중

l  책임 및 자율성 향상

l  업무 수행에 대한 적절한 보상 (급여, 책임 증가, 인정 등)

이러한 동기 부여 도구를 적용하기 어려울 수 있는 프로젝트 영향이 있습니다. 예를 들어, 테스터는 불가능한 기한이 있는 프로젝트에서 매우 열심히 일할 수 있습니다. 테스터는 가능한 한 모든 작업을 수행하여 팀의 품질 관리를 강화하고 추가 시간과 노력을 투입 할 수 있습니다. 그러나 제품은 외부 영향으로 인해 출하 될 수 있습니다. 테스터의 최선의 노력에도 불구하고 품질이 떨어지는 제품 일 수 있습니다. 최종 제품의 성공 여부에 관계없이 테스터의 기여가 이해되고 측정되지 않으면 쉽게 동기상실자가 될 수 있습니다.

 

테스트 팀은 테스트를 수행하고 위험을 완화하며 결과를 정확하게 기록하기 위해 올바른 작업이 수행되었음을 증명하기 위해 적절한 측정 항목을 추적해야 합니다. 이 데이터가 수집되고 게시되지 않는 한, 잘 수행 된 일로 인해 기분이 들지 않는다는 인식을 받지 못하면 팀이 탈 집중화되기 쉽습니다.

 

인정은 무형의 존중과 승인에 의해서만 결정되는 것이 아니라 승진 기회와 책임감 및 공로의 증가로 분명합니다. 테스트 그룹이 존중되지 않으면 이러한 기회를 이용할 수 없을 수도 있습니다.

 

테스터가 프로젝트의 점진적 가치에 기여하는 것이 확실 할 때 인식과 존중이 획득됩니다. 개별 프로젝트에서 이것은 테스터를 프로젝트 초기에 참여시키고 수명주기 전반에 걸쳐 지속적으로 관여시킴으로써 가장 잘 이루어집니다.

시간이 지남에 따라 테스터는 프로젝트에 대한 긍정적 인 기여로 다른 프로젝트 이해 관계자의 존경을 얻습니다. 이 기여도는 품질 감소 및 위험 완화 비용 측면에서 계량화 되어야 합니다.

테스트 매니저는 테스트 팀의 개인에게 동기를 부여하고 더 큰 조직에 테스트 팀의 챔피언 역할을 하는 데 중요한 역할을 합니다. 테스트 관리자는 개별 테스터의 업적을 인정해야 하며 실수에 대한 공정하고 정직한 평가를 제공해야 합니다. 공정하고 일관된 Test Manager가 팀 구성원에게 동기를 부여합니다.

 

7.6 의사 소통

테스트 팀 커뮤니케이션은 주로 다음과 같은 방법으로 수행됩니다:

l  테스트 제품 문서화 - 테스트 전략, 테스트 계획, 테스트 사례, 테스트 요약 보고서, 결함 보고서 등

l  검토 된 문서에 대한 피드백 - 요구 사항, 기능 사양, 사용 사례, 구성 요소 테스트 문서화 등

l  정보 수집 및 보급 – 개발자, 다른 테스트 팀원, 경영진 등과의 상호 작용

테스터와 다른 이해 관계자 간의 의사 소통은 테스트 팀에 대한 존중을 구축하고 유지하기 위해 전문적이고 객관적이며 효과적이어야 합니다. 외교와 객관성은 타인의 작업 산출물에 대한 피드백, 특히 건설적인 피드백을 제공 할 때 필요합니다. 또한 테스트 목표를 달성하고 소프트웨어 시스템을 생산하는 데 사용되는 제품 및 프로세스에서 품질을 향상시키는 데 중점을 두어야 합니다.

 

테스트 관리자는 사용자, 프로젝트 팀원, 관리, 외부 테스트 그룹 및 고객을 포함하여 광범위한 대상과 커뮤니케이션 합니다. 커뮤니케이션은 대상 고객에게 효과적이어야 합니다. 예를 들어 발견 된 결함의 수와 심각도에 대한 추세와 경향을 보여주는 개발 팀 용 보고서는 경영진 브리핑에 적합하지 않을 수 있습니다. 모든 커뮤니케이션에서, 특히 프레젠테이션 중에는 전송되는 메시지, 메시지 수신 방법 및 메시지 수신을 위한 올바른 환경을 만드는 데 필요한 설명을 이해하는 것이 중요합니다. Test Manager는 종종 프로젝트 상태 정보를 표시 할 수 있는 위치에 있기 때문에 이 정보가 적절한 세부 수준에 있어야 합니다 (예 : 관리자는 일반적으로 개별 결함이 아닌 결함 경향을 보고 싶어합니다). (예: 간단한 차트 및 다채로운 그래프). 효율적으로 의사 소통을 하면 올바른 메시지를 전달하면서 청중의 주의를 끌 수 있습니다. 각 프레젠테이션은 품질 및 품질 프로세스를 홍보 할 수 있는 기회로 Test Manager에서 검토해야 합니다.

 

Test Manager는 부서 외부의 사람들과 의사 소통하는 것은 아닙니다 (외부 의사 소통). 테스트 매니저의 임무 중 중요한 부분은 테스트 그룹 (내부 커뮤니케이션) 내에서 효과적으로 통신하여 뉴스, 지침, 우선 순위의 변경 사항 및 테스트의 정상 프로세스에서 부여되는 기타 표준 정보를 전달하는 것입니다. 또한 시험 관리자는 조직의 관리 체인을 위로 (상향 통신) 및 아래로 (하향 통신) 특정 개인과 통신 할 수 있습니다. 의사 소통의 방향에 관계없이 동일한 규칙이 적용됩니다. 의사 소통은 청중에게 적절해야 하며, 메시지는 효과적으로 전달되어야 하며 이해는 확인되어야 한다.

 

테스트 매니저는 다양한 의사 소통 수단의 주인이어야 합니다. 많은 정보가 전자 메일, 구두 상호 작용, 공식 또는 비공식 회의, 공식 또는 비공식 보고서를 통해 그리고 결함 관리 도구와 같은 테스트 관리 도구의 사용을 통해 전달됩니다. 모든 의사 소통은 전문적이고 객관적이어야 합니다. 교정은 품질과 내용면에서 가장 긴급한 의사 소통에서도 필요한 단계입니다. 서면 통신은 종종 실제 프로젝트를 훨씬 넘어서 산다. Test Manager가 품질을 향상시키는 조직을 대표하는 전문적인 품질의 문서를 작성하는 것이 중요합니다.

 

 8. 참고 문헌

8.1 표준

[BS7925-2] BS 7925-2, 소프트웨어 구성 요소 테스트 표준.

제 2 장

[FDA21] FDA Title 21 CFR Part 820, 미국 식품의 약국 (FDA)

제 2 장

[IEEE829] 소프트웨어 및 시스템 테스트 문서 용 IEEE 표준

2 장과 4 장

[IEEE1028] 소프트웨어 검토 및 감사를위한 IEEE 표준

제 2 장

[IEEE1044] 소프트웨어 비정상에 대한 IEEE 표준 분류

제 4 장

[ISO9126] ISO / IEC 9126-1 : 2001, 소프트웨어 엔지니어링 - 소프트웨어 제품 품질,

2 장과 4 장

[ISO12207] ISO 12207, 시스템 및 소프트웨어 엔지니어링, 소프트웨어 수명주기 프로세스

제 2 장

[ISO15504] ISO / IEC 15504, 정보 기술 - 프로세스 평가

제 2 장

[ISO25000] ISO / IEC 25000 : 2005, 소프트웨어 엔지니어링 - 소프트웨어 제품 품질

요구 사항 및 평가 (SQuaRE)

2 장과 4 장

[RTCA DO-178B / ED-12B] : 공수 시스템 및 장비의 소프트웨어 고려 사항

인증, RTCA / EUROCAE ED12B.1992.

제 2 장

8.2 ISTQB 문서

[ISTQB_AL_OVIEW] ISTQB 고급 수준 개요, 버전 1.0

[ISTQB_ALTM_SYL] ISTQB 고급 레벨 테스트 매니저 강의 계획서, 버전 1.0

[ISTQB_ALTTA_SYL] ISTQB 고급 수준의 기술 테스트 분석가, 실러버스, 버전 1.0

[ISTQB ETM SYL]

ISTQB 전문가 시험 관리 계획서, 버전 1.0

[ISTQB_FL_SYL]

ISTQB Foundation 레벨 강의 계획서, 버전 2011

[ISTQB_GLOSSARY] 소프트웨어 테스팅 2.2 버전에서 사용되는 용어의 표준 용어집.

2012 년

[ISTQB ITP SYL]

ISTQB Expert 시험 과정 개선 SYSLAVS, 버전 1.0

8.3 상표

이 문서에는 다음과 같은 등록 상표 및 서비스 마크가 사용됩니다.

CMMI®, IDEAL SM , ISTQB®, ITIL®, PRINCE2®, TMMi®, TPI Next®

CMMI는 Carnegie Mellon University에서 미국 특허청에 등록되어 있습니다.

IDEAL은 카네기 멜론 대학교 (SEI)의 서비스 마크입니다.

ISTQB는 국제 소프트웨어 테스터 자격 심사위원회 (International Software Testing Qualifications Board)의 등록 상표입니다.

ITIL은 등록 된 상표이며 Office of Community의 등록 된 커뮤니티 상표입니다.

Government Commerce에 있으며 미국 특허청에 등록되어 있습니다.

PRINCE2는 내각부의 등록 상표입니다.

TMMi는 TMMi Foundation의 등록 상표입니다.

TPI 다음은 Sogeti Nederland BV의 등록 상표입니다.

8.4 서적

[Black03] : Rex Black, "Critical Testing Processes", Addison-Wesley, 2003, ISBN 0-201-74868-1

[Black09] : Rex Black, "Testing Process, 제 3 판 관리", John Wiley & Sons, 2009, ISBN

0-471-22398-0

[Black11] : Rex Black, Erik van Veenendaal, Dorothy Graham, "소프트웨어 테스팅의 기초"

Thomson Learning, 2011, ISBN 978-1-84480-355-2

[Craig02] : Rick Craig, Stefan Jaskiel, "체계적인 소프트웨어 테스팅", Artech House, 2002, ISBN 1-580-

53508-9

[Crispin09] : Lisa Crispin, Janet Gregory, "민첩한 테스트 : 테스터와 민첩한 실용 가이드

팀 ", Addison-Wesley, 2009, ISBN 0-321-53446-8

[de Vries09] : Gerrit de Vries 외, "TPI Next", UTN Publishers, 2009, ISBN 90-72194-97-7

[Goucher09] : Adam Goucher, Tim Riley (편집자), "아름다운 테스트", O'Reilly, 2009, ISBN 978-

0596159818

[IDEAL96] : Bob McFeeley, "이상 : 소프트웨어 프로세스 개선을위한 사용 설명서", 소프트웨어

공학 연구소 (SEI), 1996, CMU / SEI-96-HB-001

[Jones07] : Capers Jones, "소프트웨어 비용 견적, 초판", McGraw-Hill, 2007, ISBN 978-

0071483001

[Jones11] : Capers Jones와 Olivier Bonsignour, "소프트웨어 품질의 경제", Pearson, 2011,

ISBN 978-0132582209

[McKay07] : Judy McKay, "시험 사람들을 관리하다", Rocky Nook, 2007, ISBN 978-1933952123

[Musa04] : John Musa, "Software Reliability Engineering, 초판", 저자 집, 2004 ISBN

978-1418493882

[Stamatis03] : DH Stamatis, "고장 모드 및 효과 분석", ASQC Quality Press, 2003, ISBN 0-

873-89300

[vanVeenendaal11] Erik van Veenendaal, "The Little TMMi", UTN Publishers, 2011, ISBN 9-490-

986038

[vanVeenendaal12] Erik van Veenendaal, "실제 위험 기반 테스트", UTN Publishers, 2012, ISBN

978-9490986070

[Whittaker09] : James Whittaker, "Exploratory Testing,"Addison-Wesley, 2009, ISBN 978-0321636416

[Wiegers03] : Karl Wiegers, "Software Requirements 2", Microsoft Press, 2003, ISBN 978-0735618794

8.5 기타 참고 문헌

다음 참조 자료는 인터넷에서 사용할 수있는 정보를 가리 킵니다. 이 참고 문헌은

이 고급 레벨 요강의 발행 시점에 확인.

http://www.istqb.org

http://www.sei.cmu.edu/cmmi/

http://www.tmmi.org/

http://www.tpinext.com/