[ISTQB] PART 05. 테스트 관리

1. 테스트 조직

1.1 테스트 조직과 독립성

테스트 조직의 독립성 수준

• 개발 조직, 본인이 작성한 코드를 직접 테스트
• 개발 팀 내부의 독립적 테스터
• 독립적 테스트 팀 또는 그룹, 개발팀의 상위 관리자에게 직접 보고
• 비지니스 조직 또는 사용자 커뮤니티 멤버들로 구성된 독립적인 테스트 그룹
• 사용성, 보안성, 인증과 같은 특정 영역의 전문 테스터들로 구성된 독립적인 테스트 그룹
• 아웃소싱 그룹 또는 조직 외부의 독립적 테스트 그룹

* 테스트 조직의 독립성 수준은 해당 조직의 테스트 요구사항과 테스트 대상 제품의 특성, 요구되는 품질 수준, 프로젝트 조직 구조 등을 고려하여 적절히 조정

 

독립성의 장점

• 결함을 보는 시각, 결함을 발견하는 방법이 개발자와 달라 상대적으로 객관적
• 개발단계에서 작성된 명세와 구현 산출물을 객관적으로 검증할 수 있음
• 테스트 전문가로서 결함을 효과적이고 효율적으로 찾아내는 전략적 접근이 가능
• 테스팅 프로세스 평가를 통해 테스팅을 개선

 

독립성의 단점

• 독립성 수준이 강하면 강할 수록 개발 및 제품관련 정보로부터 고립될 가능성이 높음
• 독립적 테스트를 마지막 체크포인트로 활용한다면, 프로젝트의 병목으로 작용할 수 있음
• 개발자가 품질에 대해 책임 지지 않으려고 할 수 있음

 

테스트 조직을 생성하거나 운영하기 위해 고려할 사항

• 개발 프로젝트와 조직의 목적에 부합하는 독립성 수준을 결정
• 개발팀과 테스트 팀 간의 의사소통 계획이 적절하게 수립되어야 함
• 독립성 수준을 정할 때 개발 산출물의 오픈 가능성을 고려
• 조직의 규모에 따라 여러 형태의 독립성 수준의 테스트 조직을 운영할 수 있음
• 개발팀과 테스트 팀 간의 갈등을 초례할 수 있는 부분을 고려하여 테스트 정책을 수립하고 배포

 

1.2 테스트 리더와 테스터의 임무

테스트 리더 : 테스트 활동과 업무를 계획하고 모니터링하고 제어하는 역할 수행

• 조직의 테스트 정책 및 테스트 전략을 작성하고 리뷰
• 테스트 전략과 테스트 계획을 작성하고 리뷰
• 테스트 전략과 계획을 프로젝트 관리자 및 이해관계자와 협의 및 조정
• 테스트 목적과 리스크에 대한 이해와 정황을 고려하여 테스트 계획을 수립
• 테스트 접근법을 결정
• 테스트에 소요 되는 시간, 노력, 비용을 추정하여 자원을 획득
• 수행 해야 할 테스트 레벨 및 테스트 사이클을 정의, 결함관리 계획 수립
• 테스트 결과와 진척을 모니터링 하여 계획 활동을 조정, 문제점을 보완하기 위해 추가 임무 수행
• 추적성 확보를 위한 테스터웨어의 형상관리 방안 구상
• 테스팅 및 제품의 품질을 평가, 테스트 진행상황을 모니터링 하기 위한 적절한 측정방법 제시
• 자동화 대상, 범위, 방법 등 결정
• 테스트 지원 도구 선정, 사용자 교육 및 훈련을 계획
• 테스트 환경 구축과 관련된 사항 결정
• 테스트 수행 과정에서 수집한 정보를 근거로 테스트 결과 보고서 작성

 

테스터 : 수립된 테스트 전략과 방향, 계획 및 테스트 리더의 지침에 따라 테스트 명세를 구현하고 테스트를 실행하는 역할 수행

• 테스트 계획 및 테스트 전략을 리뷰
• 테스트 용이성 평가를 위해 요구사항, 명세, 모델을 리뷰
• 테스트 명세 작성(설계)
• 테스트 환경 구축
• 테스트 데이터 준비 및 획득
• 테스트 구현, 실행, 로그 기록 및 테스트 실행 결과 평가, 결함 보고의 임무 수행
• 테스트 운영 및 관리 도구, 테스트 모니터링 도구를 사용
• 테스트 자동화 구현 및 자동화 요구사항을 구체화
• 컴포넌트나 시스템의 성능 측정
• 테스트 명세서 리뷰

 

2. 테스트 계획과 추정

2.1 테스트 계획

• 테스팅 목적, 테스트 범위, 필요한 자원 그리고 일정을 결정하는 등의 업무 수행
• 조직 차원의 테스트 정책 및 전략, 테스트 범위, 목적, 제품의 리스크, 프로젝트 리스크, 제약사항, 심각성, 테스트 용이성, 자원의 가용성에 영향을 받음
• 프로젝트 또는 대상에 대한 정보가 상세화 될 수록 테스트 계획 역시 상세화
• 테스트 수명주기 전반에 관여하는 지속적인 작업
• 테스트 수행동안 변화하는 프로젝트 환경, 요구사항들에 의해 새롭게 도출되거나 변경되는 리스크를 감지, 테스트 대상의 품질 상황과 정보를 획득하여 지속적으로 테스트 계획을 조정하고 제어해야 함

 

2.2 테스트 계획 활동 내용

• 테스트 범위와 리스크 결정, 테스팅의 목적 식별
• 테스트의 총체적인 접근법(테스트 전략) 정의
• 테스트 레벨과 각 테스트 레벨 별 시작과 종료 조건 정의
• 테스팅 활동과 소프트웨어의 획득, 공급, 개발, 운영, 유지보수 단계의 수명주기 활동을 통합하고 조정
• 무엇을 테스트 하고, 누가 테스트 활동을 수행하고, 어떻게 수행하고, 테스트 결과는 어떻게 평가 할지 결정
• 테스트 분석과 설계 일정 계획
• 테스트 구현, 실행 및 평가의 일정을 계획
• 정의된 다양한 테스트 활동에 자원을 할당
• 테스트 문서의 분량, 상세함의 정도, 구조와 템플릿을 정의
• 테스트 준비와 실행, 결함과 리스크 이슈를 모니터링, 제어하기 위한 측정기준 선정
• 충분한 정보를 제공하여 테스트 준비와 실행을 재현 가능하도록 테스트 프로시저의 상세 수준 결정

 

2.3 완료 조건

• 하나의 테스트 레벨 또는 특정 목적의 테스팅이 언제 종료할지를 정의

 

2.4 테스트 추정

• 테스트 프로세스에 관여하는 모든 작업들에 대한 비용, 노력, 기간을 결정
• 테스트 추정 방법
  • 메트릭 기반 접근법 : 과거 프로젝트나 유사 프로젝트의 메트릭을 근거로 또는 전형적인 가치를 근거로 테스트 노력 또는 업무량 예측
  • 전문가 기반 접근법 : 전문가나 업무 수행 주체에 의한 예측
• WBS(Work Breakdown Structure) : 테스트 업무를 세분화하여 각 업무에 적절한 재원을 배분, 수렴
• 기능점수 : 개발의 어려움 정도를 반영
• TPA(Test Point Analysis) : 테스팅의 어려움을 분석하여 테스트의 노력을 체계적으로 산정

 

2.5 테스트 접근법, 전략

• 테스트 레벨, 유형, 사람, 도구, 절차, 방법, 자원 등과 같은 테스트 필요 요소들에 대한 접근 방법을 타당한 근거를 기반으로 결정하는 것
• 테스트 접근법
  • 예방적 접근법 : 가능한 프로젝트 초반에 즉, 개발이 완료되기 전에 테스트를 설계
  • 사후(행동)적 접근법 : 소프트웨어 또는 시스템이 개발된 이후에 테스트를 설계 

 

3. 모니터링과 제어

3.1 테스트 경과 모니터링

• 목적 : 테스트 활동에 대한 피드백과 가시성을 제공하여 테스트 계획, 또는 조직차원의 테스트 정책이나 전략을 준수하여 테스팅이 수행되는 지를 관찰하는 것
• 테스트 진행 보고서 검토 및 수집된 테스트 메트릭 분석, 이해관계자와 내용 공유 미팅 수행
• 새로운 리스크 출현과 이미 알려진 리스크의 변화를 감지하고 테스팅에 영향을 줄 수 있는지에 대해 이해관계자와 협의하도록 유도
• 모니터링 동안 수집된 정보 또는 메트릭은 제품의 품질 평가, 테스트 진척도 파악, 테스트 완료 조건 달성 평가에도 사용할 수 있음

 

3.2 테스트 리포팅

• 테스팅 동안의 노력 및 활동에 대한 정보 및 제품의 결함 정보 요약
• 이해관계자의 의사결정을 지원할 목적으로 보고서를 작성하고 보고하는 활동
• 테스트 보고서
  • 테스트 진행 보고서 : 테스트 진행 중 합의 사항과 근시일 내에 진행할 테스트 활동에 대한 내용
  • 테스트 종료 보고서 : 특정 테스트 유형 또는 테스트 레벨의 종료 시점에 작성하는 보고서, 전체 프로젝트 종료 시점에 작성되는 최종 보고서

 

3.3 테스트 제어

• 테스트 진행 보고서나 수집된 메트릭을 근거로 테스트가 계획대로 수행 되도록 가이드 하거나 정정하는 활동
• 테스팅 전 영역을 범위로 하며 소프트웨어 생명주기 활동이나 업무에도 영향을 줄 수 있음

 

3.4 테스트 완료

• 특정 레벨 또는 유형의 테스팅에서 테스트 계획서에서 계획했던 모든 항목들이 완료 되면 시작하는 활동
• 목적 : 테스트 자산 및 테스트 환경을 보존하고, 테스팅 활동에서의 교훈을 찾아내어 이해관계자와 공유하기 위함

 

4. 형상 관리

• 목적 : 프로젝트나 제품의 전체 수명주기에 걸쳐 시스템이나 소프트웨어의 상태를 그대로 보전, 보호하고 유지하기 위함
• 테스트웨어 식별, 버전 관리, 변경 추적, 상호 연관성, 개발 아이템과의 연계 관리 등을 통해 테스트 프로세스 전반에 걸친 추적성 확보
• 테스트 문서에 참조하고 있는 모든 관련 문서 또는 소프트웨어 아이템이 모호하지 않게 관리됨
• 형상 관리를 통해 테스트된 품목, 테스트 문서, 테스트와 테스트 하네스 등을 혼선 없이 관리하고 효율적으로 재사용 할 수 있음
• 형상 관리는 테스트 계획 단계에서 결정하고 문서화되어, 구현되어야 함

 

5. 리스크와 테스팅

• 리스크 : 이벤트, 위험 요소, 위협 혹은 상황의 발생 가능성과, 발생 했을 경우의 바람직한 못한 결과 즉, 잠재적인 문제
• 리스크 수준 : 의도하지 않은 이벤트가 발생될 가능성과 그 영향에 의해 결정됨
• 리스크 = 장애 가능성 x 손실
• 리스크  = 사용 빈도 x 결함 가능성 x 손실
• 리스크가 높다 -> 사용 빈도가 높으며 결함 가능성도 놓고 발생된 결함 또는 장애로 인한 손실이 크다는 것

 

5.1 프로젝트 리스크

프로젝트 목적을 달성하기 위한 프로젝트의 역량 전반에 걸쳐 관련되어 있음

 

조직적인 요소

• 테스팅 전문 스킬과 인력 부족
• 개인적 이슈와 교육훈련 관련 이슈
• 정치적인 이슈
• 테스팅에 대한 비현실적 태도나 기대치

 

기술적 이슈

• 완성도 높은 요구사항을 정의하는데 있어서의 문제
• 기 제약조건 하에서 요구사항이 수용되는 정도
• 설계, 코드, 테스트의 품질

 

공급자 이슈

• 공급자인 제 3자 협력업체가 역할 수행에 실패
• 계약상의 이슈

 

5.2 제품 리스크

소프트웨어나 시스템에서 의도하지 않은 향후 이벤트나 위험 요소가 존재하는 잠재적인 장애 영역

 

잠재적 장애 영역

• 개발팀에서 전달 받은 장애 가능성 높은 소프트웨어
• 소프트웨어 및 하드웨어가 개인이나 회사에 손실을 끼칠 가능성
• 취약한 소프트웨어 특성(기능성, 신뢰성, 사용성, 성능)
• 의도된 기능을 수행하지 못하는 소프트웨어

 

리스크 기반 테스팅

• 프로젝트 초기 단계부터 리스크에 미리 대처할 수 있게 하여 제품의 리스크 수준을 줄여줌
• 제품 리스크를 식별해 주고, 해당 리스크를 이용해 테스트 계획 및 제어, 테스트 설계 및 명세화, 테스트 준비 및 실행을 가이드
• 프로젝트 이해관계자의 통찰과 공동의 총체적인 지식을 이끌어내어 리스크를 결정하고, 해당 리스크를 처리하는데 필요한 테스팅 수준을 결정

 

리스크 관리 방법

• 리스크 식별 : 테스트 대상을 리스크 분석 단위인 아이템으로 분류하고 식별
• 리스크 분석 : 중요하고, 복잡하고, 잠재적으로 결함이 많은 부분을 분석
• 결국, 장애 발생 빈도와 장애로 인한 영향을 식별
• 리스크의 우선순위를 결정
• 리스크 계획 활동 : 리스크 정보를 근거로 대처 방안 수립(테스트 전략 수립)
• 리스크 추적 : 리스크 완화 활동(테스팅)에 대한 모니터링 및 제어

 

6. 인시던트 관리

• 목적 : 테스트에서 발견한 이슈에 대해 추가적으로 수행해야 할 일에 대해 보고 및 추적 위함
• 인시던트는 발견되고 분류되는 시점부터 수정되고 확인 될 때까지 추적 되어야 할 대상

 

7. 테스트 프로세스 평가

ISO/IEC 29119 - 테스트 프로세스

• 조직차원의 테스트 프로세스 : 조직이 테스팅을 하는 이유 및 목적을 기술하는 테스트 정책과 테스팅 접근에 대한 조직 차원의 테스트 전략을 수립하고 적용하며 개선하도록 하는 프로세스
• 테스트 매니지먼트 프로세스 : 소프트웨어 개발 프로젝트에서 총괄적으로 수행해야 할 테스팅을 레벨 별로 또는 유형 별로 수행되도록 관리하고 통제 하는 프로세스
• 정적, 동적 테스트 프로세스 : 소프트웨어 개발 수명주기 전 반에 걸친 정적 테스트를 위한 준비 단계, 리뷰/분석 단계, 후속 처리 과정에 대한 프로세스와 각 테스트 레벨 또는 특정 테스트 유형에서 수행해야 할 분석 및 설계, 구현 및 실행, 환경 구성 및 유지보수 활동 등의 동적 테스트 프로세스를 의미

 

테스트 프로세스 성숙도가 높아진다면 테스팅 활동이

• 정렬되고 조직화되며 반복적이 됨
• 전문적이고 공학적인 활동으로 인식 됨
• 개발 활동과는 독립적으로 수행
• 결함 발견 활동에서 결함 예방 활동으로 변화
• 정량적으로 측정되고, 관련 데이터가 축적되며, 테스트 프로세스의 문제점을 파악하게 됨
• 지속적으로 개선되고 향상
• 테스트 비용을 절감, 조직 구성원의 만족감을 고취시킴

 

 

---

📚 참고 문헌 : 개발자도 알아야할 소프트웨어 테스팅 실무