소프트웨어 테스팅 노트

출처: 책 Software Testing by Ron Patton, 2001년, 294~297페이지

버그 추적 시스템

테스팅에서 발견한 버그를 기록하고 버그 생명 주기 전반에 걸쳐 모니터링할 수 있는 일종의 시스템이 필요한데, 버그 추적 시스템이 바로 그런 역할을 한다.

표준: 테스트 사건 보고서(The Test Incident Report)

ANSI/IEEE 829 표준에 ”테스팅 프로세스 중에 발생하는 조사가 필요한 모든 이벤트를 문서화"하는 것이 목적인 테스트 사고 보고서(Test Incident Report)라는 것이 정의되어 있다. 간단히 말해서 버그를 기록하는 문서이다. 이 보고서가 아래와 같은 내용을 담는다.

1. 식별자(Identifier): 버그 보고서를 찾고 참조하는 데 사용할 수 있는 고유 ID를 지정한다.

 2. 요약(Summary): 버그를 짧고 간결한 사실 진술로 요약한다. 테스트 중인 소프트웨어와 그 버전, 관련 테스트 절차, 테스트 케이스 및 테스트 사양에 대한 참조도 포함되어야 한다.

 3. 사건 설명(Incident Description): 다음 정보와 함께 버그에 대한 자세한 설명을 제공한다.

• 날짜 및 시간
• 테스터 이름
• 사용된 하드웨어 및 소프트웨어 구성
• 입력 값
• 절차 단계
• 예상되는 결과
• 실제 결과
• 재현 시도 및 시도된 내용에 대한 설명
• 프로그래머가 버그를 찾는 데 도움이 될 수 있는 기타 관찰 또는 정보

 4. 영향(Impact): 심각도와 우선순위는 물론 테스트 계획, 테스트 사양, 테스트 절차 및 테스트 케이스에 미치는 영향을 나타낸다.

수동 버그 보고 및 추적

ANSI/IEEE 829 표준은 버그 보고서가 취해야 하는 포맷을 정의하지는 않지만 간단한 문서 예를 제공한다. 그림 18.5는 이러한 종이 버그 보고서의 모습을 보여준다.

자동화된 버그 보고 및 추적

버그 추적을 위한 정보인 그림 18.5 양식에 입력된 데이터는 스프레드시트나 데이터베이스 애플리케이션으로 자동화될 수 있다. 그림 18.6은 업무 현장에서 마주칠 수 있는 자동화된 버그 보고 및 추적 시스템을 보여준다.

그림 18.6은 3,263개의 버그가 포함된 버그 데이터베이스의 최상위 뷰를 보여준다. 개별 버그의 ID, 제목, 상태, 우선순위, 심각도 및 해결 정보가 화면 상단 3분의 1에 간단한 목록으로 표시된다. 선택한 버그 항목에 대한 추가 정보가 화면 하단에 표시된다. 누가 버그를 열었는지, 누가 해결했는지, 누가 닫았는지 한눈에 알 수 있다. 버그가 생명 주기를 거치는 동안 버그에 대해 입력된 세부 정보를 스크롤할 수도 있다.

화면 상단에는 새 버그를 생성(열기)하거나 기존 버그를 편집, 해결, 닫기 또는 재활성화(다시 열기)하기 위해 클릭할 수 있는 일련의 버튼이 있다.