노년코딩

5.3.1 테스트 경과 모니터링

▶테스트 모니터링 목적

 - 테스트 활동에 대한 피드백과 가시성을 제공하여 테스트 계획, 또는 조직 차원의 테스트 정책이나 전략을 준수하는지 관찰.

- 테스트 케이스 작성률 : 계획 대비 완료된 테스트 케이스의 비율
- 테스트 환경 구축률 : 완료된 테스트 환경 구축 작업 비율
- 테스트 케이스 실행 관련 메트릭 : 실행된 테스트 케이스의 비율
- 통과되거나 실패된 테스트 케이스 수 : 결함 밀도, 발견된 결함과 수정된 결함, 장애율, 재 테스트 결과
- 요구사항, 리스트, 코드의 테스트 커버리지
- 제품에 대한 테스터의 주관적 자신감
- 테스트 마일스톤
- 테스팅 비용 관련 메트릭 : 비용 들여 추가 진행에 대한 이득 비

5.3.2 테스트 리포팅

▶ 테스트 리포팅

 - 테스팅 동안의 노력 및 활동에 대한 정보 및 제품의 결함 정보를 요약하여, 이해관계자의 의사결정을 지원할 목적으로 보고서를 작성하고 보고하는 활동

 - 진행 보고서 : 주요 시점에 현재 상황을 보고

   >> 주간, 월간 보고서(제품 품질, 테스트 생산성, 리스크, 프로세스 품질 등)

 - 종료 보고서 : 특정 테스트 유형 및 레벨이 종료되는 시점 보고 

   >> 테스팅 기간 동안 처리했던 주요 업무

   >> 향후 업무에 대한 의사결정을 위해 의미 있게 분석된 정보와 메트릭

 - 테스트 계획 단계에서 미리 계획하고 설계 --> 완성도 올라감.

▶ 결함 관련 메트릭 (메트릭 : 수치로 표현할 수 있는 측정)

 - 평균 결함 건수

 - 심각도별 결함 건수

 - 결함유형별 분포 비율

 - 결함 조치율

 - 발견 단계별 분포 비율

▶ 결함 발생 이유

 - 표준 미준수, 테스트 부족, 마무리 부족, 팀 간 의사소통 부족, 코딩 실수 등.

▶ 결함 유형

 - 시스템 오작동

 - 시스템이 멈추거나 다운됨

 - 예상치 못한 시스템의 동작이나 반응

 - 시스템이 가지고 있어야 할 기능, 성능 특성의 누락이나 불완전한 경우

 - 문서화 결함

 - 사용용이성 저하

 - 선능 저하

 - 데이터 훼손 및 데이터 무결성 깨짐

 - 데이터 손실 

- 수집된 메트릭의 활용
>> 해당 테스트 레벨에 대한 테스트 목적의 적절성 평가
>> 사용된 테스트 접근법의 적절성 평가
>> 목적 대비 테스팅의 효과성 평가

▶테스트 진행 보고서

 - 테스트 진행 중 합의사항과 근시일 내에 진행할 테스트 활동에 대한 내용을 포함.

   >> 소프트웨어 품질, 테스트 생산성, 소프트웨어 제품 리스크, 테스트 프로세서 품질, 테스트 문제점 등.

▶ 테스트 종료 보고서

 - 레벨별 종료 보고서와 프로젝트 종료 보고서로 나뉨

 - 테스트 계획 대비 차이

 - 오픈되어 있는 제품 리스크와 예상되는 영향

 - 해결되지 않은 결함과 그로 인해 예상되는 영향

 - 시스템 파트의 현 상태와 커버된 리스크

 - 테스트 프로세서 품질

 - 테스트 프로젝트 수행 경험

 - 다음번 테스트에 대한 조언

▶ 테스트 보고서 활용

 - 어플리케이션 출시 여부

 - 결함의 심각도 및 유형 파악

 - 요구사항에 대한 테스트 커버리지 확인

 - 어플리케이션 품질 결정

 - 다음 단계의 테스트를 위한 테스트 주요 요소 파악

▶좋은 리포팅 요건

5.3.3. 테스트 제어

▶ 테스트 제어

 - 테스트 진행 보고서나 수집된 메트릭을 근거로 테스트가 계획대로 수행되도록 가이드 하거나 정정하는 활동

 - 테스트 제어 활동의 예

   >> 테스트 모니터링으로부터 얻은 정보를 기반으로 의사 결정

   >> 프로젝트 리스크가 실제 발생 하였을 때 테스트의 우선순위를 조정

   >> 테스트 환경의 가용성 이슈가 있을 경우 테스트 일정 변경

   >> 테스트 시작 조건 조정

   >> 수정사항 빌드에 반영하기 전에, 해당 수정사항을 개발자가 재 테스트하도록 요구

5.3.4 테스트 완료

▶ 테스트 완료

 - 특정 레벨 또는 유형의 테스팅에서 테스트 계획서에서 계획했던 모든 항목들이 완료되면 시작하는 활동

 - 목적 : 테스트 자산 및 환경을 보존, 테스트 활동에서의 교훈을 찾아내어 이해관계자와 공유

 - 테스트 완료 보고서에는 테스트 계획대비 실적, 결함 상태, 리스크 등과 함께 테스트 자산의 보존 상황 및 교훈을 기록하고 이를 이해 관계자에게 보고함.

5.4 형상 관리

▶ 형상 관리의 목적

 - 프로젝트나 제품의 전체 수명 주기에 걸쳐 시스템이나 소프트웨어(컴포넌트, 데이터, 문서)의 상태를 그대로 보존, 보호하고 유지하기 위함

>> 테스트웨어 식별, 버전 관리, 변경 추적, 상호 연관성, 개발 아이템(테스트 대상)과의 연계 관리 등을 통해 테스트 프로세스 전반에 걸친 추적성 확보.
>> 테스트 문서에서 참조하고 있는 모든 관련 문서 또는 소프트웨어 아이템을 모호하지 않게 관리.

 - 테스터는 형상 관리를 통해 테스트된 품목, 테스트 문서, 케이스와 테스트 하네스(테스트환경셋팅) 등을 혼선 없이 관리하고 효율적 재사용.

 - 형상 관리 절차는 테스트 계획 단계에서 결정하고 문서화

5.5 리스크와 테스팅

▶ 리스크

 - 이벤트, 위험 요소, 위협 혹은 상황의 발생 가능성과 발생했을 경우의 바람직하지 못한 결과 즉, 잠재적 문제

5.5.1 프로젝트 리스크

5.5.2 제품 리스크

▶제품 리스크

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

   >> 개발 팀에서 전달받은 장애 가능성이 높은 소프트웨어

   >> SW 및 HW가 개인이나 회사에 손실을 끼칠 가능성

   >> 취약한 소프트웨어 특성(기능성, 신뢰성, 사용성, 성능)

   >> 의도된 기능을 수행하지 못하는 SW

 - 제품 품질에 대한 리스크

 - 리스크 vs. 테스트

   >> 리스크 : 테스트를 시작하는 시점을 결정하고 더 강력하고 깊이 있게 테스트할 부분을 결정하기 위해 사용.

   >> 테스트 : 의도하지 않은 결과를 야기시키는 리스크를 줄이거나, 의도하지 않은 결과로 야기되는 영향과 손실을 줄이기 위해 사용.  

리스크 관리 : 리스크 식별 --> 리스크 분석 --> 리스크 계획 --> 리스크 추적
 - 리스크 식별 : 무엇이 리스크이고 어디에 리스크가 있는지 확인
 - 리스크 분석 : 중요하고, 복잡하고, 잠재적으로 결함이 많은 부분을 분석(리스크 우선 순위 결정.)
                         *리스크 = 장애 발생 빈도 x 장애로 인한 영향
 - 리스크 계획 : 리스크 정보를 근거로 대처 방안 수립 (리스크 줄이는 "테스트" 생성)
 - 리스크 추적 : 리스크 및 리스크에 대한 대응을 모니터링

▶  리스크 식별

   >> 기능적/ 기술적 아이템 모두 도출

   >> 요구사항에 따른 상위 레벨 테스트 관련 항목

   >> 아키텍처에 따른 하위 레벨 테스트 관련 항목

   >> 브레인스토밍을 통해 도출 가능

   >> 한 번에 분석해야 할 리스크 아이템 수를 적당히 제어할 필요 있음.

▶ 리스크 분석

▶ 경험적 리스크 요소

- 프로젝트 상황에 맞게 변형시킬 수 있으며, 가중치 적용 가능

▶리스크 계획 활동

 - 리스크 분석 결과를 근거로 대처 방안 수립

 - 리스크를 줄이는 테스트를 생성

 - 리스크 메트릭스 작성

   >> 리스크 분석 단계에서 합의/ 결정된 리스크 아이템별로 리스크 요소의 점수 이용하여 작성

   >> 장애 발생 가능성 리스크 요소 총점과 장애로 인한 영향 리스크 요소 총점을 구분하여 좌표에 표시

 - 테스트 레벨 별로 차별화된 리스크 기반 테스팅 전략 준비 

▶리스크 추적

 - 리스크 상황을 모니터링 해 잔존 리스크를 줄여나가는 활동

 - 리스크를 효과적으로 추적하기 위해 다양한 지표 개발 필요

5.6 인시던트 관리 ( == 결함관리)

▶ 인시던트 관리 목적

 -  테스트에서 발견한 이슈에 대해 추가적으로 수행해야 할 일에 대해 보고하고 이를 추적하기 위함

 -  인시던트 보고서 : 실제 결과와 기대 결과 사이의 불일치를 작성

 - 기 발생된 결함에 대한 재 테스트인 경우 인시던트 보고서 상태 변경

 - 인시던트 혹은 결함은 프로그램 개발, 리뷰, 테스팅 혹은 소프트웨어 제품 사용 중에 발견되거나 발생.

▶ 인시던트 혹은 결함 보고서

 목적 :
   >> 개발자와 다른 프로젝트 이해관계자가 문제점을 식별하고, 격리하고, 필요하면 정정하도록 피드백 제공.
   >> 테스트 대상 시스템의 품질과 테스팅 진척도를 추적하는 수단을 테스트 리더에게 제공.
   >> 테스트 프로세스 개선에 대한 아이디어 제공.

 - 인시던트 및 결함은 발견 및 분류에서 수정 및 확인까지 추적

 - 인시던트와 결함을 처리할 수 있는 적절한 조치에 대한 정의

 - 모든 인시던트 완료까지 관리하기 위해 조직은 인시던트 관리 프로세스 및 분류 규칙을 설정 --> 결함 생명 주기

5.7 테스트 프로세스 평가

▶  테스트 프로세스

 - 조직을 셋업하고 운영하는 관점에서의 조직 테스트 프로세스

   >> 테스트 정책과 테스트 전략을 수립하고 적용하며 개선하는 프로세스

 - 프로젝트 전체 또는 특정 레벨 및 유형의 테스트를 위한 테스트 매니지먼트 프로세스

   >> 총괄적으로 수행할 테스팅을 레벨 또는 유형 별로 수행되도록 관리, 통제.

 - 테스트 수행 관점에서 동적 테스팅과 정적 테스팅을 구분하여 각각의 프로세스 

▶ 테스트 프로세스 개선 활동(점진적, 효과적, 지속적)

 - 기대효과 

   >> 정렬되고 조직화되며 반복적

   >> 전문적이고 공학적인 활동으로 인식

   >> 개발 활동과는 독립적으로 수행

   >> 결함 발견 활동에서 결함 예방 활동으로 변화

   >> 정량적으로 측정되고, 관련 데이터가 축적되며, 테스트 프로세스의 문제점을 파악

   >> 지속적으로 개선되고 향상

   >> 테스트 비용을 절감시키고 조직 구성원의 만족감을 고취시킴