5. 테스트 관리

5.1.1 독립적인 테스팅 (독립적 테스트의 장단점을 설명할 수 있다)

---

독립적인 테스팅 : 개발자가 아닌 전문 테스터가 하는 테스팅(조직에 따라 독립성 수준이 달라짐)

 

장점

• 독립적인 테스터는 다양한 관점으로 개발자와 다른 유형의 장애를 찾아낼 수 있다.
• 독립적인 테스터는 관계자가 제작한 명세와 가정에 대해 확인하고 의의를 제기하고 틀렸음을 입증할 수 있다.
• 벤더의 독립 테스터는 회사의 압박 없이 똑바로, 객관적으로 보고 가능하다.

단점

• 개발팀과의 고립으로 협업이 어려울 수 있고, 피드백 전달이 늦어지고, 적대적 관계 형성
• 개발자가 품질에 대한 책임감을 잃을 수 있다.
• 독립적인 테스터가 병목 현상의 장본인으로 비쳐질 수 있다.
• 독립적인 테스터는 중요한 정보를 전달받지 못할 수 있다.

 

5.1.2 테스트 관리자 및 테스터의 역할(테스트 관리자와 테스터의 역할을 식별할 수 있다.)

---

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

• 조직의 테스트 정책과 테스트 전략을 개발하고 리뷰
• 정황을 고려한 테스트 활동과 테스트 목적과 리스크 이해를 바탕으로 테스트 활동을 계획. 예를 들어, 테스트 접근법 선택, 테스트 추정(테스트 시간, 노력, 비용), 리소스 획득, 테스트 레벨과 테스트 주기 정의, 결함 관리 등이 계획에 포함될 수 있다.
• 테스트 계획서 작성과 업데이트
• 프로젝트 관리자, 제품 책임자, 기타 관계자와 테스트 계획 관련 협의
• 통합 계획 등과 같은 다른 프로젝트 활동과 테스팅 관점 공유
• 테스트 분석, 설계, 구현, 실행 활동을 개시하고, 테스트 진행과 결과를 모니터링하며 종료 조건(또는 종료 조건 정의)의 상태를 점검하고 테스트 완료 활동을 촉진
• 수집한 정보를 바탕으로 테스트 진행 상황 보고서와 테스트 요약 보고서 작성과 배포
• 테스트 결과와 진행 상황에 따라 계획을 조정하고 테스트 제어에 필요한 모든 조치를 취함
• 결함 관리 시스템과 테스트 웨어에 적합한 형상 관리 체제 구축 지원
• 테스트 진척 상황 측정과 테스팅 및 제품 품질 평가를 위한 적절한 메트릭 도입
• 테스트 프로세스 지원용 도구 선택과 구현 지원. 예를 들자면, 도구 선택 예산에 대한 권고, 파일럿 프로젝트에 시간과 노력 할당, 도구 사용에 대한 지속적인 지원 제공 등
• 테스트 환경 구축에 관한 결정
• 조직에 테스터, 테스트팀, 테스트 활동을 홍보하고 지지를 요청
• 테스터의 역량과 경력 개발 (예: 교육 계획, 성과 평가, 코칭 등)

테스터의 역할 : 테스트 계획을 리뷰하고 직접적인 테스팅을 수행

• 테스트 계획을 리뷰하고 계획 작성에 참여
• 요구사항, 사용자 스토리와 인수 조건, 명세, 모델(즉, 테스트 베이시스)의 테스트 용이성을 분석, 리뷰, 평가
• 테스트 컨디션 식별 및 기록, 테스트 케이스, 테스트 컨디션, 테스트 베이시스 간의 추적성 설정
• 테스트 환경을 설계, 구축, 검증하고 필요한 경우 시스템 관리자, 네트워크 관리자와 협업
• 테스트 케이스와 테스트 프로시저를 설계 및 구현
• 테스트 데이터를 준비하고 획득
• 상세 테스트 실행 일정 수립
• 테스트를 실행하고 결과를 평가해, 기대 결과와 차이 기록
• 테스트 프로세스에 적합한 도구 사용
• 필요한 경우 테스트 자동화 (개발자나 테스트 자동화 전문가의 도움을 받을 수 있음)
• 수행 효율성, 신뢰성, 사용성, 보안성, 호환성, 이식성과 같은 비기능 품질 특성 평가
• 테스트 산출물 리뷰

 

5.2.1 테스트 계획의 목적과 내용 (테스트 계획의 목적과 내용을 요약할 수 있다.)

---

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

 

테스트 계획의 활동

• 테스팅의 범위 정의, 목적, 리스크 결정
• 전반적인 테스팅 접근법 정의
• 테스트 활동을 소프트웨어 수명주기 활동에 통합하고 조정
• 테스트 대상 다양한 테스트 활동에 필요한 인력과 기타 자원, 테스트 활동 수행 방법 결정
• 테스트 분석, 설계, 구현, 실행, 평가 활동의 일정 조정. 일정은 특정 날짜(예: 순차적 개발에서)나 반복주기 단위(예: 반복적 개발)로 편성할 수 있다.
• 테스트 모니터링과 제어에 사용할 메트릭 선정
• 테스트 활동 예산 결정
• 테스트 문서의 구조와 상세화 정도 정의 (ex 템플릿이나 예제 문서를 제공함으로써)

 

5.2.2 테스트 전략과 테스트 접근법(여러 테스트 전략을 구별할 수 있다.)

---

테스트 전략, 접근법 : 테스트 필요 요소(유형, 사람, 도구 등등)에 대한 접근 방법을 타당한 근거를 기반으로 결정하는 것을 의미

접근법	정의	내용
분석적	특정 요소에 대한 분석을 기반으로 한 테스트 전략	리스크를 분석해 집중적으로 테스팅 해야 할 곳을 결정하는 것 -> 리스크 기반 테스팅
모델기반	제품의 특성 특면에 대한 모델을 제작하여 실제 테스트 수행	제품의 특성 특면에 대한 모델을 제작하여 실제 테스트 수행
방법론적	사전에 정의한 테스트 셋이나 테스트 컨디션을 체계적으로 사용	체계적으로 장애, 경험, 체크리스트, SW 품질 기반 테스팅
프로세스 및 표준 준수	외부 규정이나 표준을 기반으로 테스트	외부 규정이나 표준을 기반으로 테스트를 분석, 설계, 구현
전문자의 조언 혹은 자문	외부 전문가의 조언, 가이드를 바탕으로 테스트 커버리지 등의 기준을 정하는 테스팅	외부 전문가의 조언, 가이드를 바탕으로 테스트 커버리지 등의 기준을 정하는 테스팅
리그레션-기피	기존 기능에 대한 리그레션 테스트를 기피를 목표	보유한 테스트 관련 자료, 리그레션 테스트 자동화 스크립트, 표준 테스트 수트 등의 재사용을 통한 테스팅
반응적	테스트 실행 중 발생하는 이벤트에 따라 반응적으로 수행하는 테스트.	이전 테스트 결과에서 얻은 지식을 바탕으로 테스트를 설계하고 구현하며 즉각 테스트를 실행 -> 경험 기반 테스팅

 

5.2.3 시작 조건과 종료 조건(시작 조건과 종료 조건에 대한 예제를 들 수 있다.)

---

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

• 테스트 가능한 요구사항, 사용자 스토리나 모델(예: 모델 기반 테스트 전략을 따르는 경우)의 가용 여부
• 이전 테스트 레벨의 종료 조건을 충족한 테스트 항목의 가용 여부
• 테스트 환경 가용 여부
• 필요한 테스트 도구 가용 여부
• 테스트 데이터와 기타 필요한 자원의 가용 여부

종료 조건 : 특정 테스트 활동을 종료하기 위해 정의한 조건

• 계획한 테스트 실행 완료
• 정의한 커버리지 수준 (요구사항, 사용자 스토리, 인수 조건, 리스크, 코드 등의 커버리지)의 도달
• 해결하지 못한 결함 수가 합의된 수보다 적음
• 추정 잔존 결함의 수가 충분히 적음
• 신뢰성, 수행 효율성, 사용성, 보안성 등 품질 특성의 수준이 원하는 수준에 도달

 

5.2.4 테스트 실행 일정(우선순위, 기술적 및 논리적 의존성 정보를 이용해 테스트 케이스 실행 일정을 수립할 수 있다.)

---

테스트 실행 일정 : 테스트 스위트를 어떤 순서(우선순위, 종속 관계, 확인 테스트, 리그레션 테스트)로 실행할지 정의

 

테스트 실행 순서 우선순위

• 종속성을 갖는 테스트 케이스 > 높은 우선순위를 기술적 종속성으로 갖는 테스트 케이스 = 높은 우선순위를 논리적 종속성으로 갖는 테스트 케이스 > 우선순위

 

5.2.5 테스트 노력에 영향을 미치는 요소(테스팅과 연관된 노력에 영향을 주는 요소를 식별할 수 있다)

---

제품특성

• 제품과 관련된 리스크
• 테스트 베이시스의 품질
• 제품의 크기
• 제품 도메인의 복잡도
• 품질 특성 요구사항 (예: 보안성, 신뢰성)
• 요구되는 테스트 문서의 상세화 정도
• 법적, 규제 준수 요구사항

개발 프로세스 특성

• 조직의 안정성과 성숙도
• 사용하는 개발 모델
• 테스트 접근법
• 사용하는 도구
• 테스트 프로세스
• 시간적 압박

인력 특성

• 관련된 인원의 역량과 경험, 특히 유사한 프로젝트나 제품 관련 (예: 도메인 지식)
• 팀 응집력과 리더십

테스트 결과

• 발견한 결함 수와 심각도
• 필요한 재작업 규모

 

5.2.6 테스트 추정 기법(메트릭 기반 추정 기법과 전문가 기반 추정 기법의 차이 설명)

---

종류

• 메트릭(측정에 쓰이는 척도와 방법) 기반 기법 : 기존 유사한 프로젝트에서 얻은 메트릭에 기반하거나 보편적인 값을 바탕으로 테스트 노력 예측
• 전문가 기반 기법 : 테스트 리더나 전문가의 경험을 기반으로 테스트 노력 예측

 

5.3.1 테스팅에서 사용하는 메트릭(테스팅에 사용하는 메트릭을 상기할 수 있다)

---

테스팅 활동이나 종료 시점에 아래와 같은 사항을 평가하기 위해 메트릭을 수집할 수 있다

• 계획한 일정과 예산 대비 진행 상황
• 테스트 대상의 현재 품질
• 테스트 접근법의 타당성
• 목적 대비 테스트 활동의 효과

일반적인 테스트 메트릭

• 계획 대비 테스트 케이스 준비 작업 완료율 (또는 계획 대비 테스트 케이스 작성률)
• 계획 대비 테스트 환경 준비 작업 완료율
• 실행된 테스트 케이스의 비율
• 결함 정보 (예: 결함 밀도, 발견한 결함, 수정한 결함, 실패율, 확인 테스트 결과)
• 요구사항 커버리지, 사용자 스토리 커버리지, 인수 기준 커버리지, 리스크 커버리지, 코드 커버리지
• 작업 완료, 자원 할당과 사용, 노력
• 다음 결함을 발견하면 얻는 이익 대비 비용이나 테스트를 계속 실행해 얻게 되는 이익 대비 비용 등을 포함하는 테스팅 비용

 

5.3.2 테스트 보고의 목적, 내용, 독자(테스트 보고서의 목적, 내용, 독자를 요약할 수 있다)

---

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

 

테스트 상황 보고서에 포함해야 할 내용

• 테스트 계획 대비 테스트 활동과 진행 상황
• 진행을 방해하는 요소
• 다음 보고 기간에 진행하기로 계획한 테스팅
• 테스트 대상의 품질

테스트 요약 보고서에 포함되는 내용

• 테스팅 수행 내용 요약
• 테스트 기간 도중에 발생한 상황 정보
• 계획 대비 편차 (예: 일정, 기간, 테스팅 활동 노력)
• 종료 조건 및 완료의 정의에 대한 테스팅 현황과 제품 품질
• 진행을 방해했거나 계속해서 방해하고 있는 요소
• 메트릭
• 잔존 리스크 (5.5 절 참조)
• 재사용 가능한(만들어 낸) 테스트 작업 산출물

 

5.4.1 형상 관리(형상 관리가 테스팅을 어떻게 지원하는지 요약할 수 있다.)

---

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

 

확인 내용

• 모든 테스트 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경 이력을 기록한다. 형상 관리에서 테스트 항목은 서로 연관돼 있다.
• 모든 테스트웨어 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경사항을 추적하고, 서로 연결해 테스트 항목 버전과도 연결되도록 해서 테스트 프로세스 전반에 걸쳐 추적성을 유지할 수 있게 한다.
• 식별한 모든 문서와 소프트웨어 아이템은 테스트 문서 내에서 명확하게 상호 참조되도록 한다.

 

5.5.1 리스크의 정의(장애 발생 가능성과 영향도를 이용해 리스크 수준을 정의할 수 있다)

---

리스크 : 미래에 부정적 결과를 가져오는 이벤트의 발생 가능성이다. 리스크 수준은 이벤트 발생 가능성과 이벤트로 인한 영향도(피해)로 결정

 

리스크 수준은 원치 않는 일이 일어날 가능성과 그 영향도의 조합으로 결정한다.

 

단순 계산으로는 알아낼 수 없다.(합산, 곱셈 등으로 계산 불가능)

 

 

5.5.2 제품 및 프로젝트 리스크

---

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

제품에 대한 근본적인 문제 – 기대하는 기능 지원 X, 구조의 잘못, 수행 불가능 등

예

• 소프트웨어가 명세에서 의도한 기능을 수행하지 못함
• 소프트웨어가 사용자, 고객이나 이해관계자가 요구하는 기능을 수행하지 못함
• 시스템 아키텍처가 일부 비기능 요구사항을 충분히 지원하지 못함
• 특정 계산식이 특정 상황에서 올바르게 수행되지 못함
• 루프(loop) 제어 구조 코딩이 잘못됨
• 고성능 거래 처리 시스템의 응답 시간이 적절하지 않음
• 사용자 경험(UX, User eXperience) 피드백이 제품 기대치에 미치지 못함

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

프로젝트 역량에 관한 내용의 문제가 발생한다. - 인력 부족, 갈등, 지연, 미흡, 문제 발생 등

예

• 프로젝트 이슈
• 배포, 작업 완료, 종료 조건이나 완료의 정의를 만족하지 못하고 지연
• 예산 문제
• 후반 변경으로 인한 재작업
• 조직 이슈
• 역량, 교육, 인력의 부족
• 개인적인 문제로 인한 갈등
• 전문가들의 비즈니스 우선순위 마찰로 인한 참여 미흡
• 정치적 이슈
• 테스터가 필요하지만 테스트 결과를 제대로 전달 받지 못한 경우
• 발견한 문제에 대한 후속 조치를 못한 상황
• 테스팅에 대한 잘못된 태도나 기대
• 기술적 이슈
• 요구사항이 잘 정의되지 않은 경우
• 시존 제약 사항으로 인한 요구사항 불만족
• 테스트 환경이 필요하나 준비 미흡
• 도구 지원이 필요하나 제공되지 않는 경우
• 개발 프로세스의 약점으로 인해 프로젝트 작업 산출물의 품질이나 일관성에 영향
• 결함 관리가 부실하고 기타 유사한 문제 때문에 축적된 결함, 기술적 부채 발생
• 공급자 이슈
• 외부 공급자가 필요한 제품이나 서비스를 공급하지 못하거나 파산
• 계약 관련 이슈로 프로젝트에 문제 발생

 

5.5.3 리스크 기반 테스팅과 제품 품질(제품 리스크 분석이 테스팅의 범위와 테스팅의 충분함에 어떻게 영향을 미치는지 예를 들어 설명할 수 있다)

---

리스크 기반 테스팅 : 리스크를 테스팅 노력을 집중하는데 사용. 부정적인 이벤트의 발생 가능성을 줄이거나 부정적인 이벤트의 영향을 줄이기 위해 사용.

 

특징

• 발견한 리스크에 힘을 쏟아 넣음
• 제품 리스크 분석 결과의 쓰임
• 사용할 테스트 기법 결정
• 수행할 테스트 레벨과 유형 확정(보안성, 가용성 테스팅)
• 테스트 수행 범위 결정
• 가능한 조기에 심각한 결함을 발견하기 위해 테스트 우선순위 결정
• 테스팅 활동 외 리스크 완화를 위한 다른 활동의 식별(경험 부족 설계자에게 교육 제공)
• 리스크 관리 활동의 절차
• 리스크를 분석 그리고 정기적으로 재분석
• 처리해야 할 중요한 리스크가 무엇인지 판단
• 해당 리스크 완화를 위한 행동 구현
• 리스크의 실제 발생을 대비한 대책 수립

 

5.6.1 결함 관리

---

결함 관리 : 테스팅의 목적 중 하나가 결함을 찾는 것이기 때문에 테스팅 중 발견한 결함은 반드시 기록해야 한다. 테스팅에 따라 중요도는 달라짐

 

일반적인 결함 관리 보고서의 목적

• 발생한 부정적인 이벤트를 제공해 구체적인 영향을 식별, 재현 테스트로 문제를 격리, 잠재 결함 수정, 문제 해결을 위한 다른 방법을 찾을 수 있도록 한다.
• 테스트 관리자에게 작업 산출물의 품질과 테스팅 영향을 추적할 방법 제공
• 개발과 테스트 프로세스 개선에 대한 아이디어를 제공

동적 테스팅에서 작성하는 결함 보고서의 내용

• 식별번호
• 제목, 결함에 대한 요약
• 결함 보고 날짜, 보고 주체 조직 및 작성자
• 테스트 항목 식별자와 환경
• 결함을 발견한 개발 생명주기 단계
• 로그, 데이터베이스 덤프, 스크린샷, 녹화 기록 등의 결함 재현과 해결을 위한 설명
• 기대 및 실계 결과
• 관계자의 관점에서의 심각도의 범위와 정도
• 수정 우선순위
• 결함 보고서의 상태
• 결론, 의견, 승인 여부
• 글로벌 이슈
• 변경 이력
• 참조