티스토리 뷰

한 인도인이 버그 리포트에 기재되어야 할 내용에 대해서 잘 설명한 것을 번역한다. 추가 정보를 준비만 해두고 프로그래머가 요청한 경우에 제공하라고 하는데, 내 생각은 조금 다르다. 일단 저장할 공간만 충분하다면 관련이 있다고 생각되는 추가 정보들은 모두 버그 리포트에 별첨해 두는 것이 좋다는 생각이다. 요즘 저장 공간은 상대적으로 가격이 싸지만, 한 번 지나간 로그나 기록 파일들은 어디서 찾을 수 있단 말인가?

-----------------------------------------------------------------------------------------------------

버그를 리포트하는데 사용하는 툴과 상관없이, 버그 리포트는 다음의 상세 내용을 필수적으로 포함하고 있어야 한다.

- 버그 ID 번호
- 버그 제목과 유형(카테고리)
- 버그의 출처 (테스트 케이스 또는 다른 출처)
- 버그의 심각도
- 버그의 중요도
- 버그의 상태 (오픈, 수정된, 완료됨, 유저 에러, 디자인 등등)
- 가장 최근에 상태가 변경된 일자와 시간, 각각의 상태 변경의 누적 히스토리
- 버그를 재현해 내는데 필요한 단계를 포함한 상세 기술(description)
- 버그가 발견된 컴포넌트나 프로그램
- 스크린 프린트, 로그등 개발자가 버그의 원인을 파악하는데 도움이 되는 것
- 발생 단계 (stage of origination)
- 이 버그를 조사 또는 수정하기 위해 지정된 사람

버그 리포트의 첫번째 목적은 프로그래머에게 자신의 눈으로 버그를 볼수 있도록 하기 위함이다.
당신의 버그 리포트가 그들이 버그를 직접 확인할 수 있게 만들지 못한다면, 그들 스스로 버그를 만들어 낼 수 있도록 하기 위해서 상세한 설명을 해주어야 한다.

첫번째 목적이 달성되지 못한 경우, 프로그래머가 스스로 버그를 만들어내지 못할 것이다. 버그 리포트의 두번째 목적은 무엇이 잘못되었는지를 기술하는 것이다.
모든 것을 상세히 기술하라. 당신이 본 것을 기술하고, 당신이 기대한 것을 기술하라. 에러 메시지를 기술한다. 특히 숫자가 포함되어 있다면 더욱 그렇게 해야 한다.

당신의 컴퓨터에 기대하지 않은 프리즈(freeze)가 발생한 경우, 당신이 사태가 파악될 때까지 아무것도 하지 마라. 그리고, 더 위험한 상황이 될 것이라고 생각되는 어떤 것도 하지 마라.

가능한 한 모든 수단을 동원해서 당신이 생각할 수 있는 에러의 원인을 찾으려고 시도해 본다. 하지만, 그렇게 하더라도 당신은 나타난 증상만을 리포트해야 한다.

프로그래머가 필요하다고 한 경우 추가 정보를 제공할 준비를 해둔다. 그들이 필요하다고 하지 않은 경우, 그들은 요청하지 않을 것이다. 그들은 일부러 서툰 짓을 하지는 않을 것이다.
손쉽게 구별할 수 있는 버전 번호를 기록하라. 왜냐하면, 프로그래머들이 필요로 할 것이기 때문이다.

명백하게 작성하라. 당신이 의도하고 있는 것을 말하고, 잘못 이해한 것이 아님을 다시 한 번 확인하라. 결국, 정확해야 한다는 것이다.

댓글
댓글쓰기 폼
공지사항
Total
394,963
Today
7
Yesterday
27
«   2018/11   »
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
글 보관함