http://www.ibm.com/developerworks/kr/library/dwclm/20090512/index.html

퇴고를 별루 못해서 그냥 막 이야기하듯 나열한거 같아 개인적으로는 아쉽습니다.

프로그래머라면 누구나 다른 사람이 작성한 ‘나쁜’ 버그 리포트를 받아보았을 것이다. 아무 내용도 없는 것, 예를 들면 그냥 "안 돼요" 같은 것이 이런 유형의 버그 리포트일 것이다. 이런 리포트는 이치에도 맞지 않을 뿐만 아니라 충분한 정보를 제공하지 않거나 아예 잘못된 정보를 제공하는 것이나 다름없다. 또는 다른 프로그램이나 네트워크 등의 오류처럼 사용자 과실로 밝혀지는 문제를 리포트하는 것도 이와 비슷한 부류일 것이다. 기술 지원 부서 일이 끔찍해 보이는 이유 중 하나는 바로 이러한 버그 리포트 덕분이다.
이 글에서는 ‘좋은’ 버그 리포트에는 어떤 내용이 필요한지에 대해 말해보고자 한다. 세상 모든 사람이 이 글을 읽어봤으면 좋겠지만, 적어도 내게 버그 리포트 보내는 사람은 꼭 읽어줬으면 좋겠다.

버그 리포트의 목적은 간단히 말해 프로그래머가 프로그램의 오류를 직접 보게 하기 위함이라고 할 수 있다. 직접 만나 보여줄 수도 있고, 오류 나는 과정을 자세하고 상세히 알려줄 수도 있을 것이다. 프로그래머에게도 마찬가지 오류가 나타나면 원인을 알 때까지 정보를 좀 더 모을 것이고, 같은 오류가 생기지 않으면 정보를 달라고 계속 요구할 것이다. 또 버그 리포트에서는 실제 발생하는 현상과 자신의 추측을 명확하게 구분해 밝혀야 한다. 추측은 생략해도 무방하지만 사실에 대해서는 절대로 생략해서는 안 된다.

프로그래머의 기본적인 지식을 믿어야 한다. 프로그램이 동작하지 않는다면 배포했을 리가 없다. 아니면 적어도 공지는 했을 것이다. 알려진 바가 없다면 프로그램은 잘 돌아가야만 한다. 그러므로 무언가 다른 점이 없는지, 특이한 설정이 없는지 확인해야 한다.

프로그래머는 프로그램에 대해서는 훤히 꿰고 있다. 어떤 부분이 확실하고 어떤 부분에서 문제가 생길 수 있는지도 잘 안다. 어디를 더 살펴봐야 하는지도 직관적으로 알고 있고, 전에 잘못되었던 부분을 이미 알고 있으므로 단서가 될만한 부분을 찾아낼 것이다.

지금은 인터넷 시대다. 프로그램에 이상이 생겼다고 해서 프로그래머를 내 컴퓨터 앞에 오게 할 수는 없다. 앞에서 얘기한 대로 직접 보여주는 것이 좋긴 하지만 그럴 수 없는 경우가 훨씬 더 많다. 그렇다면 프로그래머가 확인할 수 있도록 버그를 재현하는 것이 좋다. 정확히 어떠한 동작을 했는지에 대해 설명해야 한다.

이렇게 했는데도 프로그래머의 컴퓨터에서는 잘 동작한다면 아직도 정보가 충분하지 않다는 것인데, 아마도 모든 컴퓨터에서 문제가 발생하지는 않는다는 의미일 것이다. 무언가 다르게 동작한다는 것일 테고, 프로그램의 의도된 바를 정확히 모를 수도 있다. 틀렸다고 생각하는 것이 프로그래머가 알기엔 맞게 동작하는 것일지도 모른다.

프로그래머들이 쓰는 버그 리포트는 도움이 될 때가 많다. 동업자 정신을 발휘하여 프로그래머를 도우려고 자신의 지식을 이용하는 데 이것이 정확한 분석이라면 프로그래머로서는 문제를 절반은 해결한 거나 다름없다. 그러나 프로그래머라고 다른 프로그램에 대한 분석도 꼭 정확하리라는 보장이 없다. 그래서 더 혼란을 일으키는 경우도 있다.

"참 재미있어요. 좀 전에는 됐거든요"

버그 리포트의 가장 중요한 부분 중 하나가 ‘명확한 표현’이다. 모호하게 표현하면 누구든 오해하기 쉽다.

• 확실하고 구체적인 표현: 같은 내용을 여러 방법으로 표현할 수 있다. 예를 들면 "열기를 선택했어요"보다는 "파일 메뉴의 열기를 클릭했어요"나 "Alt-L을 눌렀어요"가 좀 더 구체적인 표현이다.


• 장황한 내용: 정보는 많을수록 유용하다. 많아도 프로그래머는 이 중에 필요한 것을 걸러 이용할 수 있다. 하지만 양이 적다면 유용한 정보를 얻을 때까지 계속 질문을 할 수밖에 없을 것이다.


• 정확한 대상: "FooBar 프로그램을 실행했더니 경고 창이 나왔어요. 닫으려고 했더니 죽어버렸죠"라고 하면 Foobar 프로그램을 닫았는지 경고 창을 닫았는지 모호하다. "경고 창의 확인 버튼을 눌러 경고 창을 닫으려 했더니 Foobar 프로그램이 죽었죠"라고 표현하는 게 좀 더 정확한 대상을 지칭하는 것이다. 또한 대명사도 자주 쓰면 정확한 대상이 되는 명사를 놓치기 쉽기 때문에 사용을 최소화하는 것이 좋다.


• 검토하기: 리포트를 보내기 전에 한 번 읽어보는 것이 좋다. 버그 재현을 위해 일련의 동작을 기술했다면, 동작들을 그대로 해보면서 다른 사람이 그대로 따라 한다고 가정하고 빠진 부분이 없는지 살펴본다.

• 프로그래머의 눈으로 확인할 수 있는 버그 리포트: 버그 리포트의 첫 번째 목적은 프로그래머가 자신의 눈으로 에러를 확인하게 하는 것이다. 앞에서 세워놓고 직접 보여줄 수 없다면, 프로그래머가 버그를 재현할 수 있도록 자세히 설명한다.


• 문제점을 파악할 수 있는 버그 리포트: 첫 번째 목적대로 프로그래머의 눈으로 확인하기가 어려울 수 있다. 무엇이 잘못된 것인지 프로그래머가 알도록 기술하는 것이 버그 리포트의 두 번째 목적이다. 본 것, 예상했던 것을 최대한 자세히 기술하고, 에러 메시지나 숫자 등이 나오면 잊지 말고 함께 기술한다.


• 입증할 수 있는 증거로서 버그 리포트: 있는 그대로 보이는 내용을 기술한다. 자기 나름대로의 분석도 유용할 수 있지만 사실적 증상을 대신할 수는 없다.


• 명확한 버그 리포트: 보고하려는 내용에 맞게 기술되어 있는지 다시 한 번 읽어보고 오해할 여지가 있는지 확인한다.

http://www.infoworld.com/tools/quiz/network-security/iq-test.php