14. 테스트 실행 및 결함 보고

• 테스트 실행 : 주어진 테스트 절차 중 실행하고자 하는 테스트 절차 선정
• 결함 보고 : 테스트 실행 로그를 바탕으로 테스트 결과를 분석하여 결함을 식별

활동	산출물	설명
테스트 실행	테스트 실행 로그	테스트 실행 결과 테스트에 대한 전반적인 설명, 수행된 테스트 작업과 이벤트 나열
결함 보고	결함 보고서	검출된 각 결함에 대해 결함 컨텍스트, 설명, 심각도, 우선순위, 위험 분석, 상태 기술
	결함 추적 보고서	보고된 각 결함이 종결될 때까지 결함 검토 정보, 해결 정보, 해결 검증 정보 기술

 

---

테스트 실행

---

테스트 설계 및 구현 활동에서 개발된 테스트 절차를 실행

---

테스트 절차 선정

테스트 설계 활동에서 일반적으로 수많은 테스트 케이스 및 테스트 절차 개발

수많은 테스트 케이스들 중 어떤 것을 먼저 실행할지 결정하는 것 필요

 

우선순위 전략

• 피처 집합 우선순위 :
  각 피처 집합은 중요도에 따라 우선순위가 부여되어 있음
  우선순위가 높은 피처 집합의 테스트 절차를 낮은 피처 집합 테스트 절차보다 먼저 선택
• 테스트 케이스 우선순위 : 각 테스트 케이스도 중요도에 따라 우선순위가 부여되어 있음
• 테스트 절차 우선순위 : 각 테스트 절차도 중요도에 따라 우선순위가 부여되어 있음

테스트 완료 기준 전략

• 테스트 계획에서는 테스트 완료 여부를 판단하는 기준을 정의함
• 테스트가 종료되면 이 완료 기준에 따라 완료 여부를 평가하고 종료 보고서에 기록함
• 테스트 완료 기준 달성에 가장 큰 기여를 할 수 있는 테스트 절차를 먼저 실행하는 것이 바람직

---

테스트 절차 실행

테스트 실행 주체

테스트 레벨	개발자	테스터	사용자
컴포넌트 테스트	v	v
통합 테스트	v	v
시스템 테스트	v	v	v
인수 테스트		v	v

• 컴포넌트 테스트는 개별적인 모듈이 테스트 대상이라서 개발자가 테스트를 직접 실행시키는 것이 일반적
• 테스트 환경 구축 비용을 줄이고, 정확하고 신속하게 테스트 결과를 이해할 수 있음
• 역할이 매우 중요한 모듈은 테스터가 참여하여 컴포넌트 테스트를 수행하기도 함

 

• 통합 테스트는 개발자들이 직접 통합 테스트를 실행할 수도, 테스트가 진행할 수도 있음
• 테스터가 수행하는 경우 더 전문적인 기술을 이용해서 객관적인 관점에서 체계적으로 테스트 가능

---

테스트 결과 비교

• 테스트 절차를 구성하는 각 테스트 케이스에 대해 예상 결과와 테스트 대상의 실행 결과 비교
• 더 객관적이고 명확하게 수행하기 위해 예상 결과를 구체적으로 기술하는 것이 바람직
• 테스트 케이스에 따라 비교될 결과는 화면, 소리, 진동, 파일, 데이터 베이스 테이블, 네트워크 등

---

테스트 실행 기록

• 테스터는 테스트 절차를 실행 중 실제로 수행한 작업과 목격된 이벤트를 시간대별로 테스트 실행 로그 문서에 기록

설명

• 로그가 발생한 테스트 대상, 수행된 테스트 케이스, 적용된 테스트 절차 등을 간략하게 명시

테스트 작업과 이벤트

• 시간대별로 테스트가 수행한 세부작업을 기록
• 예상과 다른 결과가 관찰되거나 전혀 예상치 않은 이벤트가 발생하면 해당 이벤트를 구체적으로 기술
• 이 이벤트를 바탕으로 결함을 식별하고 결함 보고서를 작성하였다면 작성된 결함 보고서의 식별자를 기록

---

 

결함 보고

---

• 테스트 실행 활동에서 적절한 조치가 필요한 이슈를 발견하면 결함으로 보고
• 테스트 실행 결과물에 대한 분석을 바탕으로 검출된 결함은 결함보고서에 기록

---

테스트 결과 분석

• 테스터는 테스트 절차 실행을 통해 발견된 결함을 추가적으로 분석하여 결함 발생 상황을 더 명확하게 파악
• 결함이 유발된 상황의 테스트 데이터, 기대했던 값, 실제 관찰된 값과 테스트 절차 및 테스트 환경을 명확히 파악

결함의 구체화

• 개발자는 보고된 결함의 원인을 찾기 위해 결함을 재연해야 함
• 재연 가능할 정도로 결함 관련 테스트 데이터, 절차, 환경이 명확히 파악되어야 함
• 테스트 실행을 통해 예상치 않은 결함을 발견하면 여러 회 동일한 테스트 실행을 시도해서 상황을 구체적으로 파악

결함의 고립화

• 결함은 사용된 테스트 데이터, 적용된 테스트 절차, 구축된 테스트 환경 등에 따라 발생할 수 있음
• 결함의 발생에 직접적인 영향을 미치는 구체적인 상황이 효과적인 디버깅에 도움을 줄 수 있음
• 결함이 발견되면 사용된 테스트 데이터, 절차, 환경을 구성하는 요소에 대해
  어떤 요소가 결함 발생에 영향을 미치는지 구체적이고 자세하게 분석
• 구체적인 상황 파악을 위해 결함의 발생에 영향을 미치는 것으로 추정되는 중요 요소를 바꿔가며 테스트 수행

결함의 일반화

• 결함의 발생에 영향을 주는 요소를 최대한 일반적으로 기술하는 것이 바람직

---

결함 기록

• 테스트 결과 분석을 바탕으로 식별된 결함은 결함 보고서에 기록
• 결함 보고서는 버그 보고서, 테스트 사건 보고서, 문제 보고서 등으로 불림

결함 컨텍스트

어떤 상황에서 해당 결함이 식별되었는지 기술

테스트 및 개발자가 결함을 정확히 이해하고 재연 가능하게 기술

결함 제거를 도울 수 있는 충분한 정보 기술

• 개별 테스트 : 결함을 검출한 개별 테스트 명시, 어떤 테스트 레벨에서 발견한 결함인지 기술
• 테스트 대상 : 결함이 검출된 테스트 대상을 고유하게 지칭
• 테스트 환경 : 결함을 발생시킨 테스트 환경을 구체적으로 기록
• 테스트 절차 및 테스트 케이스 :
  결함을 발생시킨 테스트 실행 절차 및 테스트 케이스 기술, 결함을 발생시킨 구체적인 테스트 데이터 명시

 

결함 설명

목격된 결함이 재연되고 해결될 수 있도록 상세하게 기술

• 실제 결과 : 실제로 관찰된 결괏값을 기록(결함의 고립화, 일반화)
• 이상 상황 : 실제 결과와 예상 결과의 차이점에 대한 분석 내용 및 예상치 않게 발견된 오동작 상황 기록

 

심각도 

발견자 관점에서 볼 때 기술적인 측면과 비즈니스적인 측면을 모두 고려하여 검출된 결함이 미칠 수 있는 영향의 범위와 크기를 바탕으로 심각도 기술

 

우선순위

검출된 결함 해결의 긴급성을 기술, 대부분의 조직은 3단계에서 5단계 정도로 우선순위 부여

 

위험 분석

검출된 결함과 관련된 새로운 위험에 대한 분석 결과 기록

기존 위험의 갱신 상태(발생 가능성, 영향도)에 따른 위험도의 변경이 있다면 이점도 기술

 

결함 상태

검출된 결함에 대한 조치 상태를 기록 (결함 추적)

---

결함 추적

• 테스트 절차를 실행하여 발견한 결함은 결함 보고서로 기록
• 발견된 결함은 적절한 개발자를 선정하여 수정을 요청

 

• 개발자는 소프트웨어를 작성한 후 테스터에게 전달
• 테스터는 계획된 테스트 전략에 따라 테스트 케이스 및 절차를 생성하고 테스트 수행
• 개발자는 요청된 결함을 수정하고 테스터에게 전달
• 테스터는 해결이 됐는지, 새로운 결함이 발생하지 않았는지 점검하기 위해 테스트 실행

결함 생명 주기

결함의 상태는 open, review, assigned, resolved, verified, closed, reopen, deferred 등이 있음

• open : 테스터가 테스트 절차를 실행하여 발견한 결함을 분석 후 구체화, 고립화, 일반화로 보고한 상황
• review : open 된 결함의 처리 방안을 검토하는 상태
• deferred : open 된 결함을 곧바로 수정하지 않고 다음 릴리스에서 해결하기로 연기된 상태
• assigned : 결함을 해결하기로 결정된 상태에서 수정할 개발자가 결정되고 그 개발자에게 해결이 요구된 상태
• resolved : 개발자가 자신에게 할당된 수정 해결을 처리한 상태
  fixed, duplicate, won't fix, invalid
  개발자가 요청된 결함을 수정(fixed)한 경우, 요청된 결함이 기존의 다른 결함과 중복되는 경우가 있음(duplicate)
  긴급한 것이 아니라 수정하지 않는 경우(won't fix), 결함 보고(테스트 케이스, 절차)에 문제가 있는 경우(invalid)
• verified : 개발자의 결함 처리가 합당한지 정확한지 검증이 된 상태
• reopen :  결함이 정확하게 수정되지 않은 경우

 

결함 처리 시나리오

경미한 결함의 무시 시나리오

 

차후에 결함을 처리하는 경우

 

이번 릴리스에서 결함을 처리하는 경우

 

 

결함 추적 보고서

• 테스터가 검출한 결함은 개발자를 할당하여 결함을 해결하거나, 다음 버전으로 미루거나, 무시
• 담당자 할당, 처리 연기, 결함 무시를 기록
• 결함 추적 보고서는 결함을 발견한 테스터, 해결을 할당받은 개발자, 수정을 검증하는 테스터 등 공유
• 테스트 자동화 도구의 일종으로 결함 추적 지원 도구는 결함의 기록과 결함 처리 및 검증 기록 그리고 결함의 처리 상황을 다양한 기준으로 분석하여 보고서를 작성하는 기능 제공

---

산출물 요약

---

테스트 실행 산출물

테스트 실행 로그

• 테스트 대상, 테스트 환경
• 시간대별로 실제 수행된 테스트 작업과 그 결과
• 결함이 식별된 경우 해당 결함에 대한 식별자 기술

---

결함 보고 산출물

결함 보고서

• 결함 식별자, 결함을 발견한 테스터와 발견 일시 기록
• 결함 발견 시 구체적인 개별 테스트, 테스트 대상, 테스트 환경, 테스트 케이스 및 절차 등 결함 컨텍스트에 기록
• 결함의 심각도, 우선순위, 관련 위험 분석 결과와 현재 결함의 상태 기술

결함 추적 보고서

• 추적 대상이 되는 결함의 식별자가 먼저 작성
• 결함에 대한 검토 정보, 결함 해결 정보, 결함 해결 검증 정보를 기술
• assigned(fixed, duplicate, won't fix, invalid), deferred, closed의 검토 결과를 기술