티스토리 뷰
이미 다수의 프로젝트를 진행해 보신 테스터라면 다들 알고 계실 만한 내용입니다만,
경험이 미숙하거나 새로 테스터 업무를 시작하시는 분들에게는 도움이 될 만한
내용이라 올립니다. (원문은 현재 찾을 수가 없군요. ^_^;)
------------------------------------------------------------------------------
MS의 테스트 매니저 Roger Sherman이 Quality Week '99에서 발표한 내용입니다.
<좋은 버그 리포트 작성하기의 기술>
테스트 시간만 소모하고, 버그를 수정하지 하지 못하는(역자주: 찾지 못하는) 비생산적인 버그 리포트의
가장 큰 문제점은 다시 재연할 수 없다는 데에 있으며, 이는 상이한 상태의 테스트, 개발 환경 사이에서 일회적이고
단발적인 툴과 Configuration 때문에, 그리고 테스트 상에서 행해진 수행에 대한 정의가 명확하고 올바르지
못하기 때문에 야기된다고 말하고 있습니다.
좋은 리포트를 쓰기 위한 10가지 팁입니다.
1. 구성
꼼꼼하고 세심하게 테스트하고 기술하면 테스트 시 시스템이 어떻게 돌아가는지를 단번에 알 수 있습니다.
오류 발생 시, 최초의 오류 발생 시점을 알 수 있게 됩니다.
2. 재연
버그 리포트를 작성하기 전에 오류의 재연 개연성에 대해서 점검해야 합니다. 문제가 다시 발생하지 않아도
리포트를 계속 쓰되, 드문 드문 발생하는 문제의 속성에 대해 기술하면 됩니다.
경험상 리포트 작성 전 세 번 정도의 시도가 적당한 것 같습니다. 문제를 재연시키는 과정을 깔끔하게 문서화하면
재연 개연성을 바로 알 수 있습니다.
3. 격리
오류를 재연하고 나면 버그를 격리시키는 방법에 대해 계속하여 기술해야 합니다.
이는 특정 변수들을 바꾸는 것을 말하며, 오류 증상을 변경시킬 수 있는 시스템 Configuration 등이 해당됩니다.
개발자가 디버깅을 할 때 어떻게 시작하면 좋을지 알려주는 정보가 됩니다.
4. 일반화
버그를 격리시키고, 재연할 수 있으면 문제를 일반화하여야 합니다. 같은 오류가 다른 모듈 등에서도 발생하는지,
동일 오류로 인해 한 층 더 심각한 문제가 발생되는가 등이 해당합니다.
5. 비교
버그가 발견된 테스트 상태를 확인하면, 그 상태가 이전에 실행했을 때는 괜찮았었는지 앞의 결과들을
체크해야 합니다. 만일 그렇다면, 그 버그는 처음에는 문제가 없었으나 나중에는 오류가 나는 퇴행성 버그일
가능성이 높습니다.
이 단계가 한 테스트 내에서의 지난 수행만을 단순히 점검하는 것 이상의 것들을 포함할 수 있도록
두 번 이상 각각 테스트 하여 그 때마다 종종 일어나는 테스트 상태에 대해 기술하십시오.
Reference 플랫폼이 있으면, 거기서도 테스트를 반복하여 결과를 기록하도록 하십시오.
6. 개요
버그 리포트의 시작, 즉 오류의 요약은 가장 중요한 부분입니다.
따라서, 고객에게 그 오류가 어떤 영향을 끼칠 지에 대해 생각해야만 합니다.
보고서를 읽는 사람의 시선을 사로 잡고, 경영진에게 분명하게 말하기 위해서 뿐만 아니라,
버그 리포트의 우선 순위를 정하는 데도 도움이 되기 때문입니다.
7. 요약
불 필요한 단계나 표현들을 줄이는 데 중점을 두어 버그 리포트 초안을 다시 읽어 보아야 합니다.
난해한 기술, 관계 없는 내용이나 단계에 대한 언급은 불 필요 합니다.
8. 명확
군 더더기 표현을 삭제하는 것에 더해서 곡해되지 않도록 주의를 기울여야 합니다. 특정 표현이 모호하거나
잘못 이해할 소지가 있고, 주관적이라면 피하는 것이 좋습니다. 분명하고 확실한 사실만을 기술하는 것이
중요합니다.
9. 중립
좋지 못한 소식을 전하는 테스터는 더욱 세심한 주의를 기울여 치우지지 않은 공정한 자세로 버그 리포트를
작성해야 합니다.
개개의 개발자를 공격하거나, 오류를 비난하는 등의 행위는 개발자들로 하여금 나쁜 마음을 품고 제품의 질을
향상시키는 좀 더 큰 목적을 잊게 할 수도 있기 때문입니다. 사실에 근거한 표현을 골라 사용하는 등의
세심한 주의를 기울여야 합니다.
10. 리뷰
리포트가 잘 되었다고 느껴지면, 두 명 이상의 동료 테스터들에게 리뷰를 부탁하십시오.
리뷰를 하는 동료들은 제안을 하거나 구체적인 질문을 하거나, 적절한 상황 판단을 통해 보고서를 작성한
테스터에게 그것이 진짜로 버그 인지에 대해 이의를 제기할 수도 있을 것입니다.
항상 테스트 팀은 최상의 버그 리포트 만을 제출하여야 합니다. (역자주: 양치기 소년의 우화)
* 좋은 버그 리포트의 작성 지표는 다음과 같습니다.
1) 경영진에게 명확합니까? 특히 개요 부분이 중요합니다.
2. 개발 팀에게 유용합니까? 효과적으로 디버깅 하는데 필요한 정보를 제공해 주어야 합니다.
3) 버그 발생에서 종료까지의 기술이 간결해야 합니다. 부족한 정보 때문에 개발자를 고생시키고, 테스트를
다시 하는 수고를 줄이기 위해서.
- 끝 -
경험이 미숙하거나 새로 테스터 업무를 시작하시는 분들에게는 도움이 될 만한
내용이라 올립니다. (원문은 현재 찾을 수가 없군요. ^_^;)
------------------------------------------------------------------------------
MS의 테스트 매니저 Roger Sherman이 Quality Week '99에서 발표한 내용입니다.
<좋은 버그 리포트 작성하기의 기술>
테스트 시간만 소모하고, 버그를 수정하지 하지 못하는(역자주: 찾지 못하는) 비생산적인 버그 리포트의
가장 큰 문제점은 다시 재연할 수 없다는 데에 있으며, 이는 상이한 상태의 테스트, 개발 환경 사이에서 일회적이고
단발적인 툴과 Configuration 때문에, 그리고 테스트 상에서 행해진 수행에 대한 정의가 명확하고 올바르지
못하기 때문에 야기된다고 말하고 있습니다.
좋은 리포트를 쓰기 위한 10가지 팁입니다.
1. 구성
꼼꼼하고 세심하게 테스트하고 기술하면 테스트 시 시스템이 어떻게 돌아가는지를 단번에 알 수 있습니다.
오류 발생 시, 최초의 오류 발생 시점을 알 수 있게 됩니다.
2. 재연
버그 리포트를 작성하기 전에 오류의 재연 개연성에 대해서 점검해야 합니다. 문제가 다시 발생하지 않아도
리포트를 계속 쓰되, 드문 드문 발생하는 문제의 속성에 대해 기술하면 됩니다.
경험상 리포트 작성 전 세 번 정도의 시도가 적당한 것 같습니다. 문제를 재연시키는 과정을 깔끔하게 문서화하면
재연 개연성을 바로 알 수 있습니다.
3. 격리
오류를 재연하고 나면 버그를 격리시키는 방법에 대해 계속하여 기술해야 합니다.
이는 특정 변수들을 바꾸는 것을 말하며, 오류 증상을 변경시킬 수 있는 시스템 Configuration 등이 해당됩니다.
개발자가 디버깅을 할 때 어떻게 시작하면 좋을지 알려주는 정보가 됩니다.
4. 일반화
버그를 격리시키고, 재연할 수 있으면 문제를 일반화하여야 합니다. 같은 오류가 다른 모듈 등에서도 발생하는지,
동일 오류로 인해 한 층 더 심각한 문제가 발생되는가 등이 해당합니다.
5. 비교
버그가 발견된 테스트 상태를 확인하면, 그 상태가 이전에 실행했을 때는 괜찮았었는지 앞의 결과들을
체크해야 합니다. 만일 그렇다면, 그 버그는 처음에는 문제가 없었으나 나중에는 오류가 나는 퇴행성 버그일
가능성이 높습니다.
이 단계가 한 테스트 내에서의 지난 수행만을 단순히 점검하는 것 이상의 것들을 포함할 수 있도록
두 번 이상 각각 테스트 하여 그 때마다 종종 일어나는 테스트 상태에 대해 기술하십시오.
Reference 플랫폼이 있으면, 거기서도 테스트를 반복하여 결과를 기록하도록 하십시오.
6. 개요
버그 리포트의 시작, 즉 오류의 요약은 가장 중요한 부분입니다.
따라서, 고객에게 그 오류가 어떤 영향을 끼칠 지에 대해 생각해야만 합니다.
보고서를 읽는 사람의 시선을 사로 잡고, 경영진에게 분명하게 말하기 위해서 뿐만 아니라,
버그 리포트의 우선 순위를 정하는 데도 도움이 되기 때문입니다.
7. 요약
불 필요한 단계나 표현들을 줄이는 데 중점을 두어 버그 리포트 초안을 다시 읽어 보아야 합니다.
난해한 기술, 관계 없는 내용이나 단계에 대한 언급은 불 필요 합니다.
8. 명확
군 더더기 표현을 삭제하는 것에 더해서 곡해되지 않도록 주의를 기울여야 합니다. 특정 표현이 모호하거나
잘못 이해할 소지가 있고, 주관적이라면 피하는 것이 좋습니다. 분명하고 확실한 사실만을 기술하는 것이
중요합니다.
9. 중립
좋지 못한 소식을 전하는 테스터는 더욱 세심한 주의를 기울여 치우지지 않은 공정한 자세로 버그 리포트를
작성해야 합니다.
개개의 개발자를 공격하거나, 오류를 비난하는 등의 행위는 개발자들로 하여금 나쁜 마음을 품고 제품의 질을
향상시키는 좀 더 큰 목적을 잊게 할 수도 있기 때문입니다. 사실에 근거한 표현을 골라 사용하는 등의
세심한 주의를 기울여야 합니다.
10. 리뷰
리포트가 잘 되었다고 느껴지면, 두 명 이상의 동료 테스터들에게 리뷰를 부탁하십시오.
리뷰를 하는 동료들은 제안을 하거나 구체적인 질문을 하거나, 적절한 상황 판단을 통해 보고서를 작성한
테스터에게 그것이 진짜로 버그 인지에 대해 이의를 제기할 수도 있을 것입니다.
항상 테스트 팀은 최상의 버그 리포트 만을 제출하여야 합니다. (역자주: 양치기 소년의 우화)
* 좋은 버그 리포트의 작성 지표는 다음과 같습니다.
1) 경영진에게 명확합니까? 특히 개요 부분이 중요합니다.
2. 개발 팀에게 유용합니까? 효과적으로 디버깅 하는데 필요한 정보를 제공해 주어야 합니다.
3) 버그 발생에서 종료까지의 기술이 간결해야 합니다. 부족한 정보 때문에 개발자를 고생시키고, 테스트를
다시 하는 수고를 줄이기 위해서.
- 끝 -