New World

[ISTQB-CTFL] CTFL(Foundation Level) 정리 #5 테스트 관리 본문

Self-Study/자격증

[ISTQB-CTFL] CTFL(Foundation Level) 정리 #5 테스트 관리

hyeovi 2021. 4. 23. 20:46
728x90
반응형

5장 테스트 관리

5.1 테스트 조직

5.1.1      독립적인 테스팅

테스팅의 독립성 수준

독립적인 테스터 없음

개발팀/프로젝트팀 독립적인 개발자나 테스터

조직 내 독립적 테스트팀/그룹이 프로젝트 관리자나 상위 관리자에게 직접 보고

비즈니스 조직/사용자 커뮤니티 소속/사용성, 보안성, 성능, 준수성, 이식성 등 특정 테스트 분야를 전문으로 하는 독립적인 테스터

현장/현장 외 조직 외부의 독립적인 테스터

 

테스트 독립성의 잠재적 이점

다양한 배경, 기술적인 관점, 성향이 달라 개발자와 다른 유형의 장애

이해관계자가 시스템 명세를 정의, 구현하면서 만든 가정을 확인/이의 제기/틀렸음을 입증

테스트할 시스템을 고용한 회사의 압박 없이 똑바로/객관적으로 보고

 

테스트 독립성의 잠재적 단점

개발팀과의 고립으로 협업의 어려움/늦은 피드백 전달/적대적인 관계 형성

개발자가 품질에 대한 책임감을 잃음

병목 현상의 장본인/중요한 정보를 전달받지 못함

 

5.1.2      테스트 관리자 및 테스터의 역할

테스트 관리자

업무: 테스트 프로세스에 대한 전반적인 책임과 테스트 활동을 성공적으로 이끔

책임: 전문 테스트 관리자, 개발 관리자, 품질 보증 관리자

규모가 큰 프로젝트나 조직인 경우 테스트 관리자/코치/코디네이터에게 보고, 테스트 리더나 리드 테스터

소프트웨어 개발 수명주기의 영향을 받음

 

테스터

업무: 제품과 프로젝트의 리스크나 선택한 소프트웨어 개발 수명주기 모델에 따라

 

5.2 테스트 계획과 추정

5.2.1      테스트 계획의 목적과 내용

테스트 계획: 개발 및 유지보수 프로젝트의 테스트 활동에 대한 전반적인 내용

영향: 조직의 테스트 정책과 테스트 전략, 사용하는 개발 수명주기 및 방법, 테스팅의 범위, 목적, 리스크, 제약, 심각도, 테스트 용이성, 자원의 가용성

테스트 활동의 피드백으로 리스크의 변화를 인지, 테스트 계획 수정

분석된 시스템 또는 소프트웨어의 리스크를 반영해 테스트 종료 조건을 결정

테스트 리포트에 어떤 내용을 담을 것인지, 테스트 결과를 어떻게 평가할 것인지 결정

테스트 수명주기에 걸쳐 정의된 다양한 업무에 소요되는 비용을 추정, 테스트 수행에 필요한 자원 할당

테스트 설계 기법 및 테스트 대상 시스템의 테스트 베이시스 결정

테스트 범위와 테스를 위한 리스크에 대해 결정, 테스트 접근

테스트에 필요한 인력과 기간을 산정, 이해관계자와 협의

 

테스트 정책: 조직 구조 형태와 핵심 역할, 핵심 테스트 프로세스, 예산 규모, 주요 테스트 레벨 결정

 

 

5.2.2      테스트 전략과 테스트 접근법

분석적: 특정 요소에 대한 분석을 전략/리스크 수준에 따라 설계, 우선순위 결정 리스크 기반

모델 기반: 요구되는 제품의 특정 측면에 대한 모델을 기반

방법론적: 테스트 셋이나 테스트 컨디션을 체계적으로 사용하는 데 의존

프로세스 준수: 외부 규정이나 표준을 기반으로 테스트 분석, 설계, 구현

전문가 조언: 이해관계자, 비즈니스 도메인 전문가, 기술 전문가 등의 조언, 지도, 지시를 바탕

리그레션-기피: 기존 기능에 대한 리그레션 테스트 기피

반응적: 테스트 대상 컴포넌트나 시스템에 따라, 테스트 실행 중 발생하는 이벤트에 따라 수행

동적/발견적: 테스팅 미리 계획 X, 기능적 리스레션 테스팅의 광범위한 자동화와 표준적 테스트 스위트를 재사용

 

테스트 전략: 테스트 프로세스를 종합해 개괄적으로 설명

테스트 접근법: 테스트 기법/레벨/유형을 선택, 시작 조건과 종료 조건을 정의하는 출발점

정황 기반, 특정 프로젝트나 릴리스용으로 테스트 전략을 조정

 

5.2.3      시작 조건과 종료 조건 (준비의 정의와 완료의 정의)

시작 조건(준비의 정의): 특정 테스트 활동을 시작하기 위해 정의한 사전 조건

종료 조건(완료의 정의): 특정 테스트 레벨이나 테스트 세트가 끝났음을 선언하기 위한 조건

 

5.2.4      테스트 실행 일정

테스트 케이스와 테스트 프로시저 작성 -> 테스트 스위트 생성 -> 순서를 결정

 

테스트 실행 일정: 우선순위/종속 관계/확인 테스트/리그레션 테스트/테스트 실행 순서 고려

 

5.2.5      테스트 노력에 영향을 미치는 요소

테스트 노력 추정: 테스트 관련 작업에 필요한 노력의 양을 예측하는 활동

제품 특성

개발 프로세스 특성

인력 특성

테스트 결과

 

테스팅 전에 공식성이 높은 기술적 리뷰 수행

독립적인 테스트 팀 운영 고려

리스크 기반 테스트 전략으로 전략적이고 방향성 있게 테스트 진행

 

5.2.6      테스트 추정 기법

메트릭 기반: 기존 유사한 프로젝트에서 얻은 메트릭에 기반, 보편적인 값을 바탕으로

                      Ex) 애자일 개발의 번다운 차트, 순차적 개발의 결함 제거 모델

전문가 기반: 테스팅 작업의 책임자나 전문가의 경험을 기반으로

                      Ex) 플래닝 포커, 와이드밴드 델파이

 

5.3 테스트 모니터링과 제어

테스트 모니터링: 정보 수집 및 테스트 활동에 대한 피드백과 가시성 제공

대상 정보: 수동 혹은 자동으로 수집, 테스트 진행 상황을 평가하는 데 활동

테스트 종료 조건 만족하는지 측정

 

테스트 제어: 수집하고 보고된 정보와 메트릭의 결과로 취해진 수정 조치나 가이드 의미

수정은 어떤 테스트 활동을 커버하거나 소프트웨어 수명주기 활동에 영향

 

5.3.1      테스팅에 사용하는 메트릭

테스팅 활동 중이나 종료 시점에 수집

 

5.3.2      테스트 보고의 목적, 내용, 독자

목적: 테스트 활동 중이나 마무리 시점의 테스트 활동 정보 요약과 공유

테스트 진행 상황 보고서: 테스트 활동 중 작성하는 테스트 보고서

테스트 요약 보고서: 테스트 활동 종료 시점에 작성하는 테스트 보고서

 

테스트 관리자: 테스트 모니터링과 제어 과정 중 이해관계자에게 정기적 테스트 진행 상황 보고

 

5.4 형상 관리

목적: 프로젝트와 제품 수명주기 동안 컴포넌트나 시스템, 테스트웨어와의 관계 통합 수립/유지

테스트 계획을 수립하면서 형상관리 절차와 인프라를 식별하고 구현

테스트웨어의 모든 품목 식별, 버전이 제어되며 추적성 유지

 

5.5 리스크와 테스팅

5.5.1      리스크의 정의

리스크: 미래에 부정적 결과를 가져오는 이벤트의 발생 가능성 (사용빈도 x 결함 가능성 x 손실)

리스크 수준: 이벤트 발생 가능성과 이벤트로 인한 영향도로 결정

 

5.5.2      제품 및 프로젝트 리스크

제품 리스크: 작업 산출물이 사용자나 이해관계자의 합당한 니즈를 충족하지 못할 가능성

품질 리스크: 제품 리스크가 제품의 특정 품질 특성과 연관

프로젝트 리스크: 개발/테스트 활동에 영향, 프로젝트 목적 달성 능력에 부정적인 영향

                      프로젝트 이슈, 조직 이슈, 정치적 이슈, 기술적 이슈, 공급자 이슈

 

5.5.3      리스크 기반 테스팅과 제품 품질

리스크: 테스팅을 언제, 어디서 시작할지 결정하고 관심 영역을 식별

테스팅: 리스크 완화 활동, 부정적인 이벤트의 발생 가능성을 줄이거나 영향을 줄이기 위해 사용

           식별/잔존 리스크에 대한 정보 제공

리스크 기반 접근법: 제품 리스크 식별과 리스크 발생 가능성과 영향을 평가 제품 리스크 분석

제품 리스크 정보: 테스트 계획, 명세, 테스트 케이스 준비와 실행, 테스트 모니터링에 사용

리스크 기반 테스팅: 프로젝트 이해관계자의 집단 지식과 통찰력을 기반으로 제품 리스크 분석

                      분석: 리스크의 우선순위 결정, 계획: 리스크를 줄이는 테스트 전략 수립

                      장애 발생 가능성: 개발(하위) 테스팅, 장애 영향: 인수(상위) 테스팅

통합 리스크(↑효율↓): 백본/상향/하향, 효율 효과

간단 통합, 유지보수 단계 통합: 빅뱅 통합 방식

 

5.6 결함 관리

인시던트: 이슈, 결함과 기획의도, 개선 요청 사항 등

테스팅 중 발견한 결함은 반드시 기록

찾아낸 모든 결함은 조사하고 발견에서 결함 분류까지 추적

결함 관리 도구를 사용하면 동적 테스팅에서 작성하는 결함 보고서의 일부는 자동으로 작성

정적 테스팅으로 리뷰에서 발견하는 결함은 다양한 방법으로 문서화

반응형
Comments