[ISTQB] Chapter 5. 테스트 관리

🟡5.1 테스트 조직

✅ 5.1.1 독립적인 테스팅

 

<테스팅의 독립성 수준>

- 독립적인 테스터 없음 : 개발자가 자신의 코드를 직접 테스트

- 개발팀이나 프로젝트 팀에 속한 독립적인 개발자나 테스터 : 개발자가 동료의 제품을 테스트

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

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

- 현장 또는 현장 외에서 일하는 조직 외부의 독립적인 테스터

 

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

- 독립적인 테스터는 그들이 가지고 있는 다양한 배경, 기술적인 관점, 성향이 달라 개발자와는 다른 유형의 장애를 찾아낼 수 있음.

- 독립적인 테스터는 이해관계자가 시스템 명세를 정의하고 구현하면서 만든 가정에 대해 확인하고 이의를 제기하고 틀렸음을 입증할 수 있음.

- 벤더의 독립 테스터는 테스트할  시스템을 고용한 회사의 압박 없이 똑바로 그리고 객관적으로 보고 가능.

 

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

- 개발팀과의 고립으로 협업이 어려울 수 있고, 개발팀에 피드백 전달이 늦어지고, 개발팀과 적대적인 관계가 형성될 수 있음.

- 개발자가 품질에 대한 책임감을 잃을 수 있음.

- 독립적인 테스터가 병목 현상의 장본인으로 비춰질 수 있음.

- 독립적인 테스터는 중요한 정보를 전달받지 못할 수 있음.

 

 

 

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

 

테스트 관리자 : 테스트 프로세스에 대한 전반적인 책임과 테스트 활동을 성공적으로 이끄는 것

<테스트 관리자의 역할과 업무>

 

 

<테스터의 역할과 업무>

 

 

 

🟡5.2 테스트 계획과 추정

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

 

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

-> 조직의 테스트 정책과 테스트 전략, 사용하는 개발 수명주기 밀 방법, 테스팅이 범위, 목적, 리스크, 제약, 심각도, 테스트 용이성, 자원의 가용성 등이 계획에 영향을 줌.

 

<테스트 계획의 활동>

 

 

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

 

<테스트 전략 유형>

- 분석적(Analytical) : 특정 요소에 대한 분석을 기반으로 함. (리스크 기반 테스트)

- 모델 기반(Model-Based) : 요구되는 제품의 특정 측면에 대한 모델을 기반으로 만들어짐. 

- 방법론적(Methodical) : 사전에 정의한 테스트 셋이나 테스트 컨디션을 체계적으로 사용하는 데 의존

- 프로세스 준수(Process-compliant) : 외부 규정이나 표준을 기반으로 테스트를 분석, 설계 구현.

- 전문가 조언(Consultative) : 이해관계자, 비즈니스 도메인 전문가, 기술 전문가 등의 조언, 지도, 지시를 바탕으로 이루어짐.

- 리그레션-기피(Regression-averse) : 기존 기능에 대한 리그레션 테스트 기피를 목표로 함. 기존 테스트 웨어의 재사용, 리그레션 테스트 자동화 확대, 테스트 스위트 표준화를 포함함.

- 반응적(Reactive) : 테스트 대상 컴포넌트나 시스템에 따라 대응하고 테스트 실행 중 발생하는 이벤트에 따라 반응적으로 수행하는 테스트 접근법. 탐색적 테스팅이 일반적으로 사용함. (경험 기반 테스트)

 

<테스트 접근법>

테스트 전략은 테스트 프로세스를 종합해 개괄적으로 설명하는 반면, 테스트 접근법은 특정 프로젝트나 릴리즈 용으로 테스트 전략을 조정(tailoring)한 것.

 

 

 

✅ 5.2.3 시작 조건과 종료 조건

 

<시작 조건>

- 테스트 가능한 요구사항, 사용자 스토리나 모델의 가용 여부

- 이전 테스트 레벨의 종료 조건을 충족한 테스트 항목의 가용 여부

(ex) 세율 계산 컴포넌트의 단위 테스트가 통과됐다.

- 테스트 환경 가용 여부

(ex) 거래 성능 테스트 환경을 설계, 셋업하고 확인했다.

- 필요한 테스트 도구 가용 여부

- 테스트 데이터와 기타 필요한 자원의 가용 여부

(ex) 자동조종장치 설계 명세를 리뷰하고 재작업했다.

 

<종료 조건>

- 계획한 테스트 실행 완료

- 정의한 커버리지 수준의 도달

- 해결하지 못한 결함 수가 합의된 수보다 적음

- 추정 잔존 결함의 수가 충분히 적음

- 신뢰성, 수행 효율성, 사용성, 보안성, 기타 관련된 품질 특성의 수준이 원하는 수준에 도달

 

 

 

✅ 5.2.4 테스트 실행 일정

테스트 실행 일정 : 테스트 케이스와 테스트 프로시저를 작성하고 테스트 프로시저와 테스트 케이스를 조합해 테스트 스위트를 생성한 후 테스트 스위트의 순서를 정해 실행 일정을 만들 수 있음.

=> 우선순위가 높은 테스트 케이스를 먼저 실행해야 함. BUT! 테스트 케이스가 서로 종속 관계를 가지고 있다면 우선순위와 상관없이 필요에 따라 배치할 수 있음.

 

우선 순위 고려 후 -> 기술적/논리적 종속성 고려 -> 다시 우선 순위로 돌아오기

 

 

 

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

• 제품 특성 : 제품과 관련된 리스크, 테스트 베이시스의 품질, 제품의 크기, 제품 도메인의 복잡도, 품질 특성 요구사항, 요구되는 테스트 문서의 상세화 정도, 법적/규제 준수 요구사항
• 개발 프로세스 특성 : 조직의 안정성과 성숙도, 사용하는 개발 모델, 테스트 접근법, 사용하는 도구, 테스트 프로세스, 시간적 압박
• 인력 특성 : 관련된 인원의 역량과 경험, 팀 응집력과 리더십
• 테스트 결과 : 발견한 결함 수와 심각도, 필요한 재작업 규모

 

 

 

✅ 5.2.6 테스트 추정 기법

 

1) 메트릭 기반 기법 : 기존 유사한 프로젝트에서 얻은 메트릭에 기반하거나 보편적인 값을 바탕으로 테스트 노력 예측

- 과거의 유사한 테스트 프로젝트의 예산을 참고

ex) 번다운 차트(Burndown charts) : 남아있는 노력을 파악하고 보고함으로써 팀이 다음 반복 주기에서 할 수 있는 작업의 양을 산정하는 데 사용할 팀의 업무 진행 속도를 계산할 수 있음.

 

* 결함 제거 모델 : 결함의 양과 결함을 제거하는 데 드는 시간을 파악하고 보고해서 차후 비슷한 성격의 프로젝트를 추정하는 기준으로 사용

 

 

2) 전문가 기반 기법 : 테스팅 작업의 책임자나 전문가의 경험을 기반으로 테스트 노력 예측

- 테스트 관리자를 인터뷰하여 전반적인 경험을 수집

- 테스트 자동화를 위한 노력의 추정은 테스트 팀에서 합의로 도출

- 비즈니스 전문가가 수집한 계산의 평균치를 사용

- 다양한 테스팅 활동을 담당하는 리더들이 예상 테스팅 노력을 예측

ex) 플래닝 포커(Planning poker) : 팀원이 자신의 경험을 기반으로 특정 기능을 인도하는 데 드는 노력을 추정

 

* 와이드밴드 델파이 : 전문가 집단의 경험을 기반으로 추정치를 제공

 

 

 

 

🟡5.3 테스트 모니터링과 제어

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

 

 

 

 

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

 

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

 

- 테스트 진행 상황 보고서에 들어가는 정보 : 테스트 계획 대비 테스트 활동과 진행 상황, 진행을 방해하는 요소, 다음 보고 기간에 진행하기로 계획한 테스팅, 테스트 대상의 품질

 

- 테스트 요약 보고서에 들어가는 정보

 

 

 

🟡5.4 형상 관리

형상관리의 목적 : 프로젝트와 제품 수명주기 동안 컴포넌트나 시스템, 테스트웨어와 이들 서로 간의 관계 통합을 수립하고 유지하기 위함.

 

1) 모든 테스트 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경 이력을 기록

2) 모든 테스트웨어 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경사항을 추적하고, 서로 연결하여 테스트 항목 버전과도 연결 되도록 해서 테스트 프로세스 전반에 걸쳐 추적성을 유지할 수 있게 함

3) 식별한 모든 문서와 소프트웨어 아이템은 테스트 문서 내에서 명확하게 상호 참조 되도록 함.

 

 

 

🟡5.5 리스크와 테스팅

 

✅ 5.5.1 리스크의 정의

 

리스크 : 미래에 부정적 결과를 가져오는 이벤트의 발생 가능성.

리스크 수준 = 이벤트 발생 가능성과 이벤트로 인한 영향도(피해)로 결정함.

 

 

 

✅ 5.5.2 제품 및 프로젝트 리스크

 

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

 

<제품 리스크의 예>

- 소프트웨어가 명세에서 의도한 기능을 수행하지 못함.

- 소프트웨어가 사용자, 고객이나 이해관계자가 요구하는 기능을 수행하지 못함.

- 시스템 아키텍처가 일부 비기능 요구사항을 충분히 지원하지 못함.

- 특정 계산식이 특정 상황에서 올바르게 수행되지 못함.

- 루프(loop)제어 구조 코딩이 잘못됨.

- 고성능 거래 처리 시스템의 응답 시간이 적절하지 않음.

- 사용자 경험(UX) 피드백이 제품 기대치에 미치지 못함.

 

 

프로젝트 리스크 : 프로젝트 목적 달성 능력에 부정적인 영향을 줄 수 있는 상황

 

<프로젝트 리스크의 예>

 

 

 

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

 

리스크 기반 접근법 : 제품 리스크 수준을 조기에 낮추는 데 기여. 제품 리스크 식별과 리스크 발생 가능성과 영향을 평가하는 제품 리스크 분석을 포함함.

 

 

🟡5.6 결함 관리

 

<결함 보고서의 목적>

 

<결함 보고서의 내용>

 

 

 

 

 

 

 

Reference

ISTQB CTFL Syllabus 2018 V 3.1.1_한글_v1.0

 

위 책 내용을 챕터별 중요한 포인트 위주로 정리한 자료입니다.

스스로 공부하기 위한 요점정리 노트이므로 상업적인 사용 목적은 전혀 없음을 알려드립니다:)

 

이 시험에 대한 정보 및 각종 자료는 아래 사이트에서 확인하실 수 있습니다. ⬇⬇⬇

http://www.kstqb.org/sw/sw3.asp