상세 컨텐츠

본문 제목

Writing Effective Defect Reports by Kelly Whitmill

테스팅 번역 자료들

by techbard 2007. 5. 16. 22:00

본문

반응형

invalid-file

원문 PDF


"소프트웨어 테스터는 버그 리포트로 말을 한다."

는 얘기가 있다. 곧 버그 리포트는 직무 그 자체라고 해도 과언이 아니다. 적어도 외부에서 QA를 보는 사람의 입장에서는... 따라서, 효과적인 버그 리포트 쓰기가 매우 중요하다고 할 수 있겠다. 특히 개발자들이 글쓰기 공부를 다시 해야 한다는 주장들도 정말 심심치 않게 볼 수 있다. (글쓰기: 개발자 기본 소양, 개발자들의 글쓰기 능력, 프로그래머가알아야할것) 공통적으로 얘기하는 것은 글쓰기 능력!

그러면, 이런 글쓰기 능력이 요구되는 개발자들을 상대하는 QA들은? (오해없기 바란다. 개발자들의 자질을 문제 삼는 것이 절대 아니다.) 누구에게나 어필하고 이해시키기 위한 글쓰기 능력을 QA들이 가져야 함을 강조함이다.

결국, 얼마나 효과적으로 버그 리포트를 작성하느냐의 문제인 것이다. 이에 대해 여러 글들이 있지만 그중 하나를 번역해서 공개한다.

18년 동안의 경력이라... 켈리는 여자 이름인듯 한데, PDF 뒷부분에 오토바이 타고 있는 돼지 그림은 먼가?

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

저자 소개

Kelly Whitmill은 소프트웨어 테스팅 분야에서 18년 동안의 경력을 가지고 있습니다. 그 대부분의 시간 동안 그는 테스트에 필요한 효과적인 방법과 툴을 찾아내고 생산해 내는 책임이 있는 팀의 리더로 일해왔습니다. 특히 그는 제한적인 리소스를 가지고 있는 환경에 효율적인 실용적인 접근법에 관심이 있습니다. 그는 테스트 자동화에 매우 관심이 있습니다. 그는 작은 규모에서 큰 규모의 회사까지 모두 일해본 경력을 가지고 있습니다. 그는 PC 기반, 유닉스 기반, 메인 프레임 기반의 프로젝트에서 일한 경력을 가지고 있습니다. 그는 현재 콜로라도 주의 Boulder에 있는 IBM 프린트 시스템 사업부에서 일하고 있습니다.

효과적인 버그 리포트 작성하기

Kelly Whitmill

서문

버그 리포트(결점 보고서)는 테스트의 결과물 중에서 가장 중요합니다. 특히, 테스트 플랜만큼 중요하며 또 대부분의 다른 결과물 보다 더 제품의 품질에 영향을 미칩니다. 따라서, 어떻게 하면 버그 리포트를 잘 작성할 수 있는지 배우는 노력은 매우 가치가 있는 일입니다.

효과적인 버그 리포트는 다음과 같은 효과가 있습니다:

- 개발팀으로부터 발생하는 버그의 수를 감소시킵니다.
- 버그를 감소시키는 속도를 증가시킵니다.
- 테스트 과정의 신뢰성을 높입니다.
- 테스트 인원과 개발팀과의 팀워크를 강화시킵니다.

왜 어떤 테스터 들은 다른 사람보다 개발팀으로부터 훨씬 더 좋은 응답을 받게 됩니까?

대답은 버그 리포트에 있습니다. 아래의 간단한 법칙들을 따른다면 더 자연스럽게 업무의 효율이 좋아질 것입니다.

완벽한 버그 리포트를 작성하는 것이 최종 목적이 아니라 하더라도 효율적인 버그 리포트를 작성한다면 모든 사람에게 적당한 메시지를 전달하고 업무를 완료하게 하며, 업무 프로세스를 단순하게 만들어 줍니다.

이 문서는 버그 리포트의 두 가지 관점에 초점을 맞추고 있습니다.

1) 소견과 기술
2) 요약

이제 효율적인 버그 리포트 작성을 위해 필요한 요소들을 살펴 봅시다.

버그에 대한 소견

아래에 당신의 다음 번 버그 리포트가 효율적이 되도록 해주는 중요한 포인트 들이 있습니다.

1. 간단히 - 간단하지만 분명하도록 언급하세요.
2. 정확성 - 버그인지 아니면 유저 에러인지, 기능을 잘못 이해 한 것인지 또는 그 밖에 다른 것인지?
3. 감정이입 배제 - 사실 만을 언급하세요. 리포트에 농담이나 감정이 섞여서는 안됩니다.
4. 구분 - 명확하게 문제가 무엇인지 언급하세요.
5. 단순화 - 버그를 분리하기 위해서 무엇이 수행되었습니까?
6. 일반화 - 문제가 얼마나 일반적인지 이해하기 위해 무엇이 수행되었습니까?
7. 재현 - 이 문제를 재현하거나 발생시키기 위해 필요한 것은 무엇입니까?(환경, 재현 순서, 조건 입니까?)
8. 영향력 - 고객에게 미칠 영향은 무엇입니까? 테스트에 미칠 영향은 무엇입니까?
9. 디버그 지원 - 디버그를 더 쉽게 하기 위한 개발은 무엇입니까? (트레이스, 덤프, 로그, 직접적인 접근 등...)
10. 증거물 - 에러가 존재한다는 증거가 될 수 있는 문서는 무엇입니까?

기술적으로 완전한 서술이 되었다고 해서 효율적인 버그 리포트가 되지는 않습니다.
그보다는 적절한 질문들에 대한 대답이 되었는지 확인하는 것이 더 중요합니다.
특히, 중요한 항목들이 포함되어 있는지 확인하는 것이 당신의 리포트를 보는 사람들에게는 더 유용할 것입니다.

효과적인 리포트를 위해 필수적인 항목들

간단히

간단하지만 분명하도록 언급하세요. 첫번째로, 불필요한 단어들을 제거합니다. 둘째로, 관계가 없는 정보는 추가하지 않습니다. 적절한 정보를 포함시키고, 정보가 적절한지 확인하는 일은 중요합니다.

문제를 재현해 내는 방법이 명확하지 않고 문제를 확실히 이해하고 있지 않은 상황이라면 어떤 경우에라도 먼저 더 많은 정보를 수집해야 합니다.

부적절한 정보는 정보가 부족한 경우처럼 잘못될 가능성이 있다는 것을 기억하세요.

요약의 예를 들어 봅시다.

피해야 하는 예(대부분이 도움이 되지 않는 많은 정보로 인해서 어려움이 있는 경우):

I was setting up a test whose real intent was to detect memory errors.
나는 메모리 에러를 발견해 내려는 명백한 의도를 가지고 테스트를 작성했다.

 In the process I noticed a new GUI field that I was not familiar with. I decided to exercise the new field. I tried many boundary and error conditions that worked just fine. Finally, I cleared the field of any data and attempted to advance to the next screen, then the program abended. Several retries revealed that anytime there is not any data for the "product description" field you cannot advance to the next screen or even exit or cancel without abending.

권장하는 예:

The "exit", "next", and "cancel" functions for the "Product Information" screen abends when the "product description" field is empty or blank.

정확성

당신이 보고하는 것이 정말로 버그인지 확인해야 합니다. 셋업의 문제, 유저 에러, 제품에 대한 이해도 부족으로 당신의 리포트에 문제가 있다는 평판을 얻게 된다면 매우 빨리 신뢰를 잃을 수 있습니다.

문제를 기술하기 전에 사전 준비가 되었는지 확인하십시오.

문제 기술전 고려 사항:

- 셋업 과정의 어떤 것이 이 문제를 유발시켰을 가능성이 있는가? 예를 들면, 올바른 버전이 인스톨 되었는가? 의존적인 조건들이 만족되었는가? 정확한 로그인 명, 보안 항목, 명령 또는 작업의 순서 등등...

- 이전 테스트 과정의 Manual Test 또는 테스트 결과, 완전히 초기화 되지 않은 환경 등이 남아 있어서 이 문제를 유발시킨 것은 아닌지?

- 이 문제가 네트워크 장비로 인해 발생한 것인지, 또는 다른 환경적인 요인에 기인한 것인지?

- 이 문제가 어떻게 발생하는지 진정으로 이해하고 있는가?

테스트 결과에 영향을 미칠 수 있는 다양한 요소들은 항상 존재합니다.

따라서, 당신의 리포트에서 버그라고 인식한 것의 역할을 고려해 보고 그것의 영향을 이해하고 있는지 확인해야 합니다.

이것은 초보 테스터와 숙련된 테스트를 금방 구별할 수 있는 하나의 방법입니다.

만약에 당신이 발견한 버그가 정말 버그인지 확신할 수 없다면 버그 리포트를 작성하기 전에 개발자나 숙련된 테스터에게 자문을 구하는 것이 현명한 판단입니다.

다음과 같은 격언을 기억하는 것이 도움이 됩니다. "리포트의 내용이 쓸데 없이 많은 것은 애교로 봐줄 수 있지만, 부실한 리포트 내용은 문제를 야기할 수 있다." 리포트를 쓰는 것을 두려워 하지 마십시오. 리포트 한 것이 문제가 맞다는 것을 증명하는데 최선을 다하십시오.

항상 잘못되었던 리포트로부터 무언가를 배우려고 노력하세요.

감정 이입 배제

객관적으로 문제를 서술하십시오. 리포트에 농담을 사용하거나 감정이 드러나는 표현을 사용하지 않는 것이 좋습니다. 당신이 리포트를 쓰는 당시에는 재미있었던 것이 야근과 개발 기간 준수에 스트레스를 받고 있는 개발자에게는 재미있지 않을 수도 있습니다.

감정적인 내용이 포함되어 있는 리포트는 문제를 해결하는 데에는 아무런 도움도 되지 않습니다.

감정적인 내용이 포함되어 있는 리포트는 의사 소통과 팀워크를 저해하는 장벽을 만들게 됩니다.

심지어 그것은 개발자가 당신을 불신하게 만들며 이전에 리포트 했던 문제들 까지도 당신에게 되돌려 보낼 수 있습니다. 그리고, 당신은 당신의 리포트가 옳고 개발자가 그르다는 것을 증명해야 할지도 모릅니다.

단순히, 문제점 만을 기술하고 개발자에게 도움이 될 수 있는 부가적인 정보를 추가하십시오.

이러한 방법이 장시간 동안 계속 유지된다면 당신은 직업적으로 존경 받으며 신뢰 받을 수 있게 됩니다.

버그 리포트를 보고하기 전에 전체 내용을 읽어 보고 다른 사람에 대해서 부정적으로 비쳐질 수 있는 부분을 빼거나 다시 기술하십시오.

감정 이입 배제의 예(다음은 어떤 값에서 문제가 발생하는지 개발자가 더 자세한 정보를 원한다고 요구한 반송 리포트에 대한 응답입니다.)

피해야 하는 예(맨 처음 구절은 개발자를 비난하는 것처럼 비쳐 질 수 있으며 유용한 정보가 포함되어 있지 않습니다.):

이전 리포트를 보고 조금만 더 확인해 보면 알 수 있듯이, ABC 기능은 음수가 입력되면 비정상 종료되어 버립니다.

권장하는 예:

ABC 기능은 어떤 음수 값에도 비정상 종료되어 버립니다. 예를 들면, -1, -36, -32767 등의 값으로 테스트 해보았습니다.

구분

당신의 리포트를 읽는 사람이 문제가 무엇인지 알기 위해 많은 시간을 고민해야 할 필요는 없습니다.

맨 첫 부분에 당신이 버그라고 인식한 내용을 간결하게 기술하십시오. 어떤 구절은 동작과 결과를 연속적으로 열거하기도 합니다. 예를 들면, 엔터 키를 눌렀고 A 동작이 발생했습니다. 그리고, 백 애로우 키를 눌렀고 B 동작이 발생했습니다. 그리고 나서, xyz 명령어를 입력했더니 C 동작이 발생했습니다.

위의 리포트 내용을 보는 사람은 당신이 수행한 모든 동작이 다 잘못된 것인지, 그 중 하나만 잘못인지, 잘된 동작인지 등 당신의 의도를 잘 파악하지 못할 수도 있습니다.

서술 자체가 매우 긴 경우를 빼고는 모든 경우에 있어 맨 첫 부분에 문제를 요약해서 기술할 필요가 있습니다.

다른 모든 이에게 보여 질 수 있는 당신의 리포트의 각기 다른 부분마다 요약된 내용을 기술하지 마십시오.

다른 이들이 당신이 수행했던 대로 모두 수행할 수 있을 것이라고 가정하지 마십시오.

당신의 주 목적은 이해 할 수 있는 내용을 기술하는 것이지 오해할 수 있는 내용을 기술하는 것은 아닙니다.

이해가 쉽도록 하기 위해서는 발생했던 것을 그대로 적는 것보다 분명하게 요약해서 문제를 기술해야 합니다.

요약의 예

피해야 하는 예(다음의 예에서 1) twinax 포트의 타이밍이 문제가 있거나 2) 프린터가 준비 대기 신호를 보내지 않거나 3) OP 패널의 디스플레이에 문제가 있는지 기술하는 것은 어려운 일입니다.):

Issuing a cancel print when job is in PRT state (job is already in the printer and AS/400 is waiting to receive print complete from printer) causes the Twinax port to not time out. The printer never returns to a READY state and indefinitely displays "PRINTING IPDS FROM TRAY1" in the op-panel.

권장하는 예(전체적인 기술을 하기 전에 당신이 생각하는 문제를 짧고, 명확하게 요약해서 배치하는 것이 좋습니다.)

프린팅 중간에 취소 작업 명령을 내리면 프린터가 행(Hang) 상태가 되어 버립니다. Issuing a cancel print when job is in PRT state (job is already in the printer and AS/400 is waiting to receive print complete from printer) causes the Twinax port to not time out. The printer never returns to a READY state and indefinitely displays "PRINTING IPDS FROM TRAY1" in the op-panel.

단순화

각 조직들은 문제를 단순화 하는데 얼마나 많은 수의 테스터가 필요한 지에 대해서 나름대로의 철학과 추정치를 가지고 있습니다. 하지만, 얼마나 필요하건 간에 테스터 자신은 문제를 단순화하기 위한 적절한 노력을 기울여야 합니다.

문제를 단순화할 때 아래의 내용을 고려해 봅시다.

- 문제를 재현해내는데 필요한 가장 짧고, 단순한 스텝을 찾도록 노력합니다.
-  어떤 외부적인 요인에 의해서 문제가 발생한 것은 아닌지 검토합니다. 예를 들면, 행 상태나 시스템 느려짐을 경험했다면 네트워크와 관련한 문제와 연관이 있지는 않은지? 당신이 모든 부분을 테스트 하고 있는 도중이라면 문제가 발생한 직후에 실행되고 있던 모듈이 무엇인지 알고 있는지? 어떤 모듈에서 문제가 발생했는지 범위를 좁히기 위해 도움이 될 수 있는 어떤 정보를 가지고 있는지?
- 당신이 여러 조건을 입력하는 테스트 중이라면, 문제가 발생하게 하는 조건이 되는 값을 찾을 때까지 여러 가지로 값을 변경해 입력해 봅니다.

문제를 기술함에 있어 가능한 한 문제를 발견했던 입력 조건을 그대로 적는 것이 좋습니다. 예를 들어, 어떤 특정한 PostScript 문서를 출력하면서 문제가 있다는 것을 발견했다면, 다른 PostScript 문서에서도 동일한 문제가 발생할 것이라는 생각이 들어도 문제가 발생했던 바로 그 문서를 문제로 리포트 하는 것이 좋습니다.

당신의 조직에서 문제를 단순화 하는 당신의 능력이 테스터로서의 당신의 가치를 더 높여줄 것입니다.

문제를 효과적으로 단순화하는 능력은 모든 이들의 작업 시간을 대단히 줄여 줄 수 있으며, 또한 당신이 문제가 수정되었는지 확인할 때도 많은 시간을 절약할 수 있습니다.

일반화

때때로, 개발자들은 문제의 원인이 좀더 포괄적인 것에 있기 때문에 좀 더 다른 식의 수정이 요구되는 데도, 당신이 리포트 한 바로 그 문제만 수정하려고 합니다.

예를 들어, 내가 "myfile"을 저장하려고 했을 때 "Save file" 기능이 실패하고 워드 프로세스가 비정상 종료되었다고 가정하면 간단히 원인 파악을 해보았을 때는 0 바이트의 파일을 저장하려고 했을 때 문제가 발생한다는 것을 파악할 수 있습니다.

아마도, 이 버전에서는 Remote Disk나 Read Only Disk 등의 저장하려고 하면 역시 동일하게 문제가 발생할 수도 있을 겁니다.

당신이 리포트 하기 전에 이러한 사실을 알았다면 개발자는 시간을 절약할 수도 있었을 것이고, 좀 더 나은 방법으로 문제를 수정할 수도 있었을 것입니다.

문제를 발견했을 때 명확히 한 곳의 문제라고 단정할 수 있는지 또는 그와 연관된 다른 문제가 있을 가능성이 있는지 확인할 수 있는 과정을 거치도록 하십시오.

일반화의 예

피해야 하는 예:

"File Not Found"에러 메시지 박스의 파일 이름에 쓰레기 문자가 들어 있습니다.

권장하는 예:

"File Not Found"에러 메시지 박스의 파일 이름에 쓰레기 문자가 들어 있습니다. 메시지에 또 다른 글자가 추가되는 경우에는 반드시 이와 같은 에러가 발생했습니다. 기존 메시지에 상황에 따라 추가되는 글자가 없는 기본 메시지 박스는 문제가 발생하지 않았습니다.

재현

어떤 버그는 쉽게 재현되는 반면, 어떤 것을 그렇지 않습니다.

당신이 버그를 재현할 수 있다면, 재현하는데 필요한 것을 정확하게 설명해야 합니다. 설명에는 전체 스텝, 정확한 구문, 파일 이름, 일련의 순서 등 문제를 재현하는데 사용된 모든 것이 될 수 있습니다.
만약에 문제가 어떤 스텝, 어떤 조건에서도 발생한다는 확신이 들더라도 가급적이면 문제를 재현할 수 있는 명백한 예를 기술해야 합니다. 당신이 버그가 다시 재현 가능한지 확인한다면 간단하고 명백한 재현 방법을 찾을 수 있을 것이고 그 방법을 버그 리포트에 기술할 수 있을 것입니다.

만약에 당신이 문제를 재현할 수 없고 재현할 가능성도 전혀 없어 보이는 상황이라면 문제를 찾거나 수정하기 위해 작업을 하는 사람을 위해서 모든 적절한 정보를 기술하십시오.

이런 적절한 정보는 당신이 문제가 발견된 시스템에서 또 다른 정보를 캡쳐해야 하는지, 문제가 발견된 시스템을 개발팀이 조사할 필요가 있는지 개발팀에게 물어 보아야 하는지 생각해 보는 시간이 될 수도 있습니다.

재현이 반드시 가능한지 확인하지 않은 상태에서 이후에 다시 재현이 될 것이라고 생각하지 않는 것이 좋습니다.

만일에 문제를 재현할 수 없거나 재현해 보지 않았다면 버그 리포트에 그 내용을 기록해두는 것은 매우 중요합니다.

영향력

이 버그가 고객에게 발생했을 때 어떠한 영향(반응)이 있을 것인가? 어떤 버그들의 영향은 볼 것도 없습니다. 예를 들어, "엔터 키를 눌렀더니 시스템이 죽어 버림" 같은 것들입니다.

어떤 버그들은 판단하기에 쉽지 않은 경우도 있습니다. 예를 들면, 윈도우에 오자가 있는 경우 등입니다. 특히, 이것이 그렇게 심각한 이슈가 아니어서 당신이 지적하지 않는다면 이 제품을 사용하는 사용자들의 첫인상을 좋지 않게 만들어서 제품에 대한 나쁜 인상을 가지게 만들 수 있습니다. 이런 경우에는, 오자가 제품의 전체의 인상을 좋지 않게 만들 수 있기 때문에 출시 전에 반드시 수정되어야 합니다.

여러 가지가 고려된 가장 현명한 판단을 해야 합니다. 만약에 버그가 잠재적으로 고객에게 영향을 미칠 수 있는 경우에는 제품 출시를 해서는 안되며 버그 리포트를 읽는 사람에게 고객에게 영향을 미칠 수 있는 버그라는 이해가 가능하도록 버그 리포트를 작성해야 합니다.

디버그 지원

개발자가 이 버그 리포트를 보고 디버그를 하기 위해 어떤 것이 필요할까요? 버그 리포트에서 Trace나 Dump, Log 같은 것들을 제공하고 있습니까? 버그 리포트에는 이러한 디버그 정보에 어떻게 접근할 수 있는지? 또는 어떤 디버그 정보가 수집 되었는지 명시하는 것이 좋습니다.

증거물

이 리포트가 버그라는 것을 어떻게 증명해야 할까요? 리포트에서 예상 작동 결과와 실제 작동 결과를 제공하고 있습니까? 당신이 예상 결과라고 기술한 것을 뒷받침할 만한 어떤 것이 기술되어 있나요?

당신이 리포트 한 이후에도 버그가 맞다는 당신의 생각이 명확해야 합니다.

또한, 당신이 다른 이에게 리포트 한 내용이 버그가 맞다는 확신을 주기위한 어떤 것이 제공되어야 합니다.

증거물들은 유저 가이드, 스펙 문서, 요구 사항 문서, 디자인 문서 등이 될 수 있으며 고객의 의견이나 경쟁 제품들이 모두 갖추고 있는 사실상의 표준 동작 또는 이 제품의 이전 버전의 동작 결과 등도 해당됩니다.

다른 이들이 당신이 발견했던 그대로 발견할 수 있을 것이라고 추측해서는 안됩니다. 사람들이 버그 리포트에서 당신이 의도했던 결론을 찾아낼 수 있을 것이라고 기대해서도 안됩니다. 당신이 3주가 지난 이후에도 이 리포트가 버그 였다는 것을 기억할 수 있을 것이라고 추측해서도 안됩니다. 당신이 리포트에서 버그 였다고 확신했던 근거가 무엇인지 생각해 보세요.

다른 이들에게 버그로 쉽게 받아 들여 지지 않을 것 같은 경우에는 조금 더 많은 근거를 확보해야 합니다.

점검표의 활용

당신이 버그 리포트를 작성할 때마다 이 문서의 내용을 읽고 기억해 내기는 쉽지 않습니다. 따라서, 자신만이 쉽게 사용할 수 있는 점검 항목을 만들어 리포트를 쓸 때마다 적용해 보는 것이 좋습니다.

Inspection은 가장 적은 노력과 최상의 효율로 소프트웨어의 품질을 향상시킬 수 있는 방법으로 알려져 있습니다. 또한, 적은 노력을 들어 효과적인 리포트를 작성하는 방법이기도 합니다.

이러한 점검표를 쉽게 기억하기 위해 다양한 방법을 동원하는 것이 좋습니다.

많은 경우에 좋지 못한 버그 리포트가 발생하는 이유는 좋은 리포트를 쓰는 능력의 부족 때문만은 아닙니다.

보통 우리는 적절한 질문에 대답해 보는 것에 대해서 생각하지 못합니다.

이 점검표는 적절한 질문에 대답할 수 있는 손쉬운 방법을 마련해 줄 것입니다. 또한, 기억하기에 쉬운 기억 방법을 찾을 수 있을 겁니다.

각 점검 항목의 첫 글자를 연결해 보면 다음과 같은 글자가 만들어 집니다. CAN PIG RIDE

내용이 충분히 독특해져서 기억하기가 쉬워 졌을 겁니다.

한 20-30분 정도 이 글자를 들여다보고 그 의미를 생각해 봅시다. 그러면, 리포트를 작성할 때 채워야 하는 내용에 대해서 어느 정도 기억하기 쉬울 겁니다.

만약 10개의 항목을 모두 기억하는 것이 힘들 다면 PIG만이라도 반드시 외워 둡시다. 대개 Precise(구분), Isolate(단순화, Generalize(일반화) 이 세가지만 리포트에 존재해도 효과적인 리포트가 될 수 있습니다.

Template

리포트에 칸을 채워야 하는 정해진 양식이 있다면 적절한 질문에 답할 수도 있고 정확한 정보를 전달할 수 있습니다. 어떤 버그 리포트 시스템은 당신이 리포트를 입력하면 자동적으로 양식이 보여 지는 기능을 가지고 있기도 합니다. 그렇지 않다면, 당신의 리포트 입력란에 양식을 잘라 붙이기 할 수도 있습니다.

간단한 양식의 예가 아래에 있습니다.

Product Details:

 Product Name and Number: (     )
 Version, Revision, build and disk number: (     )

System Details:
 Computer Type: PC model, mainframe type, OS Level, etc. (     )
 Memory: (     )
 Disk Space: (     )
 Peripherals attached and used: (     )
 Network connectivity: (     )
 Configuration Details: (     )

Problem Summary: (     )

Problem Description: (include expected and actual results)
(                                                              )

Is this reproducible?(     )

Steps and conditions to reproduce:
(                                                              )

Has this problem been isolated? (     )
Has this problem been generalized? (     )
Additional Debug Information: (How to access logs, dumps, etc.)
(                                                              )

많은 경우에 효과적인 리포트는 당신이 올바르게 대답을 했는지 보다 올바른 질문에 대답을 했는지가 중요하며 그 항목은 아래와 같이 정리할 수 있습니다.

- Condense
- Accurate
- Neutralize
- Precise
- Isolate
- Generalize
- Re-create
- Impact
- Debug
- Evidence

당신의 버그 리포트에서 위와 같은 항목에 해당하는 내용을 제공할 수 있다면 회사 전체에 대단한 도움이 될 것입니다.

버그 요약

심각한 버그와 한 줄의 잘 요약된 버그 리포트는 대단히 강력한 의사 전달 표시가 됩니다. 가끔 의사 결정 권한을 가진 사람들은 요약된 내용만을 보기도 합니다.

요약은 전체 내용이 아닌 리포트에 포함되어 있는 것입니다. 요약은 project managers, screeners, team leads, other managers가 제품과 연관된 버그를 이해하려고 할 때 참고하는 것입니다.

요약은 간결하고 기술적이어야 하며 또 정확한 메시지를 전달할 수 있어야 합니다. 대개 요약은 길이에 제한이 있으므로 문법에 연연해 하지 않고 생략법을 사용하는 것이 좋습니다.

그러므로, 요약하기 위해 많이 생각해 보고 가장 효과적인 중요한 단어들을 선정해 사용하는 것이 반드시 필요합니다.

비정상 종료, 행, 오자 등의 단어는 사용하기에 효과적인 단어입니다.

더 서술할 수 있는 공간이 허락된다면 환경, 이 버그가 미치는 영향력, who, what, when, where, why questions 등 어느 것이라도 적절히 사용하는 것이 좋습니다.

몇몇의 버그 리포팅 시스템은 자동적으로 버그 리포트의 내용 중에 맨 첫 부분을 요약으로 간주해 출력해 주고 있습니다.

절대로 기본으로 내장되어 있는 요약 간추리기 기능을 사용하지 말고, 가능하다면 직접 요약 내용을 기술하는 것이 바람직합니다.

예를 들어, 아래의 요약 문은 사실이긴 하지만 의미하는 바가 정확하지는 않습니다.

요약 : 데이터 들을 저장하고 불러오기 하는 중에 문제가 발견됨

아마도 좀 더 명확히 기술한다면 다음과 같이 될 것입니다.

요약 : xyz 기능으로 데이터를 Save/Restore 하는 중에 WinNT 시스템에 문제가 발생하고 데이터가 깨짐.

당신이 원하는 모든 내용을 요약할 수는 없겠지만 아래의 방법을 사용한다면 좀 더 효과적일 것입니다.

요약할 때 고려 사항

필수 고려 사항:

1. 무엇이 문제인지 간결하고 명확히 기술하세요.(문제가 있다는 것만 기술하면 안됩니다.)

권장되는 고려 사항(공간이 허락한다면):

1. 의미심장한 단어를 사용합니다.
2. 버그가 재현된 환경과 고객에게 미칠 영향력을 함께 기술합니다.
3. 5W1H(who, what, when, where, why, and how)에 근거해 기술하세요.
4. 생략법을 적절히 사용하세요.
5. 문법에 맞는 문구 보다는 메시지를 잘 전달하는 문구가 중요합니다.
6. 리포트 시스템의 기본 값을 사용하지 않는 것이 좋습니다.

마치면서

테스터 들은 소프트웨어의 문제를 찾아 내기 위해서 엄청난 시간을 소비합니다.

하나의 버그 라도 찾게 되면, 리포트 작성과 버그를 수정하는데 드는 시간을 줄여 주어서 대단히 생산성을 높일 수 있게 됩니다.

리포팅 기술보다는 정확한 정보를 전달하는 것이 중요하다는 것을 기억하세요.

이 문서에서 기술한 10가지 주제인

- Condense
- Accurate
- Neutralize
- Precise
- Isolate
- Generalize
- Re-create
- Impact
- Debug
- Evidence

는 버그 리포트를 통해 효과적인 정보를 전달할 수 있게 도와줍니다.

모든 사람이 버그 리포트의 내용을 전부 보지는 않습니다. 많은 의사 결정권자 들은 그들이 판단을 내릴 때 잘 요약된 한 줄의 리포트를 참고합니다. 따라서, 잘 정리되고 정확한 내용을 담고 있는 리포트의 요약 부분은 매우 중요합니다.

적절한 시기에 제공되는 효과적인 버그 리포트는 실제로 문제를 수정할 수 있게 하며 적시에 수정할 수 있도록 합니다.

효과적인 버그 리포트는 당신을 신뢰할 수 있게 하며 가치를 높여 주며, 개발자, 매니저, 또는 다른 동료 테스트 들이 그들의 업무를 좀 더 잘 수행 할 수 있게 만들어 줍니다.

부록 A

Condense  (say it clearly but briefly)

Accurate  (Is it really a defect? Could it be user error, setup problem etc.?)

Neutralize  (Just the facts, no zingers, no humor, no emotion)


Precise   (Explicitly what is the problem?)

Isolate   (What has been done to isolate the problem?)

Generalize  (What has been done to understand how general the problem is?)


Re-create  (What are the essentials in creating/triggering this problem?)

Impact   (What is the impact if the bug were to surface in customer env.?)

Debug   (What does the developer need to debug this?)

Evidence  (What will prove the existence of the error? documentation?)

참고 문헌:

Rex Black, The Fine Art of Writing a Good Bug Report, http://www.rexblack.consulting.com

반응형

관련글 더보기

댓글 영역