6장 버그 관리와 TC 효과성

어떻게 버그를 관리할 것이며,
TC(=테스트케이스)의 효과성을 측정하는 방법에 대해 알아보자

※ TC → 테스트케이스

---

내용정리

1. 버그 관리

A. 최초의 버그

버그 어원 & 버그리포트에 들어갈 필수 구성 요소

• 최초 버그 리포트

15:25 Started MultAdder Test.
15:45 Relay # 79 F
(moth) in relau
First actual case of bug being found

< 1947년 오작동 분석 → 진공관 속 들어간 작은 벌레로 오류 >

• 버그 리포트 필수 구성 요소 (위 문서도 포함)
  • 테스트 절차 : 버그 재현 절차 명시
  • 근본원인 : 버그 유발한 근본 원인 명시
    
    
• 근본 원인 작성 이유
  • 동일한 버그를 가진 다른 제품(or 다른 버전)에서도 문제없이 버그만 수정하기 위함.
    
    

B. 버그는 작은 일이 아니다

버그 탐색의 중요성

• '버그'는 사소할지라도, 버그가 끼치는 영향은 사소하지 않다.
  ex) 우주 탐사선 화성 충돌, 방사능 기계 오작동, 주식매매
  

2. 결함 관리의 첫 단계는 이를 정의하는 것이다.

A. 결함 추적 시스템

결함 추적 시스템이란?

• 결함 관리 방법 : 결함들을 결함추적시스템 이용하여 보고부터 수정까지 관리
• 결함 추적 시스템 역할 : 사용자, 지원 부서, 개발자, QA 엔지니어 사이 정보 통로 역할
• 결함 추적 시스템 관리 : 중요한 정보는 지속적 유지 & 부정확 정보는 삭제
• 결함 추적 보고서 요소 : '누가, 무엇을, 언제, 어디서, 왜?' 포함

B. 누가 정의?

결함 보고서에 들어갈 명시할 책임자 목록 & 역할별 결함 추적 시스템 이용 목적 차이

• 결함 추적 보고서 책임자 기록
  1. 결함 최초 발견자
  2. 결함 수정자
  3. 수정한 결함 검증자
     
     
• 결함 추적 시스템 이용자별 목적
  • 개발자 : 결함에 대한 정확한 재현 방법
  • QA엔지니어 : 현재 테스트과 연관 여부 or 신규 테스트 추가 여부
  • 고객 : 현재 결함 있는지, 이전 결함 수정 여부
    
    
• 결함 심각도 보고
  • 보고하는 사람에 따라 심각도가 달라진다.
    (∵ 일부 서버 장애 → 해당서버 관리자한텐 심각)
    ⇒ 우선순위와 심각도는 해당 조직의 결함 정책에 따라 정의

C. 무엇을 정의?

결함 보고에 들어갈 필수 정보 요건

• 증상 : 결함에 대한 간단한 설명
• 재현 방법 : 누구라도 결함 재현 가능토록 재현 방법 기재
  • SW 버전, OS, HW 성능. 기타 사전 조건, 재현 절차
• 우선순위 : 우선으로 수정되어야 하는 정도 . 합의된 정책에 따라 표기 ( P1 > P5)
• 심각도 : 결함이 미치는 영향 의미. 우선순위와 상관 관계가 있으나 동일 X
  (∵ 우선순위 = 심각도 * 가능성)

D. 언제 정의?

제품 수명 주기 관련하여 결함 발견 시기 (초기, 테스팅, 베타, 출시, 관리, ...)

• 제품 수명 내내 항상 동일한 툴과 프로세스로 결함 추적할 것.
  (∵ 변경하면, 변경 이전 결함 추적이 어려워짐)
• 제품 수명 후반에 찾을수록 비용 ↑ ⇒ 개발 과정 중 발견 / 출시 이후 발견 구별하여 관리

E. 어디서 정의?

SW 어느 리버전에 결함 발견했는지 보고

• 정식 버전, 베타 버전, 별도 버전 등 결함 발생 버전 명시
  (∵ 버전에 따른 다른 버전도 동일 결함 발생 여부 & 수정 현황 목적)

F. 꼬리표(태그) 붙여야 하는 이유

결함 관리에 태그 사용법

• 목적 → 결함에 대한 근본 원인 조사 위함
• 역할 → 태그를 이용하여 관련 테스트를 찾고, 예상하는 근본 원인에 대해 검증 & 반증 가능

3. TC(테스트케이스) 효과성

효과적인 TC란?

• 효과적인 TC?
  • 수해한 TC 수가 많은가? X
  • 수행한 TC가 결함을 얼마나 찾아냈는가? O
    ⇒ TC는 단순히 돌리고 끝내는 방학 숙제가 아니다. TC는 결함을 찾아내는 것이 중요하다.

• TC의 효과성 측정 방법(TCE)

$TCE = \frac{N_t}{N_{tot}}$

- N_t : TC가 발견 버그 수
- N_tot : N_t + 테스트 이후 발견된 버그 수 

• 완벽하게 TC를 설계하여 진행했다면, TCE = 1.00

A. 버그 심각도 반영

TCE + 심각도에 따른 가중치 부여

• TCE가 동일하더라도, 사소하고 특수한 버그를 찾은 TC와 치명적이고 대중적 버그를 찾은 TC 효과성은 다르다.
• P1 ~ P5 에 따라 가중치 부여하여 TCE 계산 (P1 : 10, P2 : 8, P3 : 6, ...)

4. 테스트 이후 발견 버그 분석

테스트 이후 나중에서야 발견된 버그 관리법

• 테스트 이후 발견된 결함들은 다음과 같이 분류하여 관리한다.
  • 잘못 분류된 버그 → 정확한 카테고리로 이동 + 버그 분류 가이드라인 마련
  • 불완전한 TC → 해당하는 기능 영역 리뷰 + TC 보강하거나 재설계
  • TC 미존재 → 버그 유발한 기능을 기반한 TC 설계
  • 테스트 수행상의 문제 → 테스트 절차나 HW/SW 의존성 리뷰
  • 부정확한 TC → 테스트된 기능 리뷰. TC 설계 이후, 기능이 변경되었는지 확인
  • 부정확한 기능 명세 → 설계자 혹은 개발자에게 문의. 명세 리뷰 프로세스 조사.

---

정리

기억에 남는 문장

• 버그에 대한 근본 원인을 명시해야, 다른 제품에도 동일한수정 작업을 수행 가능하다.
• '버그'는 사소할지라도, 버그가 끼치는 영향은 사소하지 않다.
• 테스트 케이스를 많이 수행했다고 해서 시스템이 충분히 테스트됐다는 것을 의미하는 것이 아니다

배운 것

• QA 엔지니어는 단순히 결함을 탐색하는 것뿐만 아니라, 수정된 결함들도 관리해야 한다.
• 테스트 케이스는 수행하는 것에 목적이 있는 것이 아니라, 오류 찾는 것에 목적이 있다.
  물론 결함을 찾지 못한 테스트 케이스도 의미가 있지만, 결함을 찾은 테스트 케이스가 더욱 값지다.

참고도서

Adam Goucher, ⌜뷰티풀 테스팅⌟, 지앤선, 2011