메뉴

좋은 버그 보고서를 작성하는 방법? 팁과 요령

how write good bug report

문제를 제거하기 위해 도구를 사용해보십시오

왜 좋은 버그 리포트인가?

버그 보고서가 효과적이라면 수정 될 가능성이 더 높습니다. 따라서 버그 수정은 얼마나 효과적으로보고 하느냐에 달려 있습니다. 버그보고는 기술에 지나지 않으며이 기술을 달성하는 방법을 설명하겠습니다.

“문제 보고서 (버그 보고서) 작성의 요점은 버그를 수정하는 것입니다.”– Cem Kaner 작성. 테스터가 버그를 올바르게보고하지 않으면 프로그래머는이 버그를 재현 할 수 없다고 표시하여 거부 할 가능성이 높습니다.

좋은 버그 보고서를 작성하는 방법

이것은 테스터의 도덕적, 때로는 자아도 해칠 수 있습니다. (자존심을 유지하지 말 것을 제안합니다. 자존심은 '버그를 올바르게보고했습니다', '나는 그것을 재현 할 수 있습니다', '그 / 그녀가 버그를 거부 한 이유는 무엇입니까?', '내 잘못이 아닙니다'등입니다. ,).

학습 내용 :

블랙 박스와 화이트 박스 테스트의 차이점

좋은 소프트웨어 버그 보고서의 특성은 무엇입니까?

누구나 버그 보고서를 작성할 수 있습니다. 그러나 모든 사람이 효과적인 버그 보고서를 작성할 수있는 것은 아닙니다.

평균 버그 보고서와 좋은 버그 보고서를 구분할 수 있어야합니다. 좋은 버그 보고서와 나쁜 버그 보고서를 구별하는 방법은 무엇입니까? 매우 간단합니다. 다음 특성과 기술을 적용하여 버그를보고합니다.

특성 및 기술에는 다음이 포함됩니다.

# 1) 명확하게 지정된 버그 번호 : 항상 각 버그 보고서에 고유 번호를 할당하십시오. 그러면 버그 레코드를 식별하는 데 도움이됩니다. 자동화 된 버그보고 도구를 사용하는 경우 버그를보고 할 때마다이 고유 번호가 자동으로 생성됩니다.

보고 한 각 버그의 번호와 간략한 설명을 기록해 둡니다.

# 2) 재현 가능 : 버그를 재현 할 수없는 경우 수정되지 않습니다.

버그 재현 단계를 명확하게 언급해야합니다. 재현 단계를 가정하거나 건너 뛰지 마십시오. 단계별로 설명 된 버그는 쉽게 재현하고 수정할 수 있습니다.

# 3) 구체적이어야합니다. 문제에 대한 에세이를 쓰지 마십시오.

구체적이고 요점을 파악하십시오. 최소한의 단어로 문제를 효과적으로 요약하십시오. 유사 해 보이더라도 여러 문제를 결합하지 마십시오. 각 문제에 대해 서로 다른 보고서를 작성하십시오.

효과적인 버그보고

버그보고는 소프트웨어 테스팅의 중요한 측면입니다. 효과적인 버그 보고서는 개발 팀과 잘 소통하고 혼동이나 잘못된 소통을 방지합니다.

좋은 버그 보고서는 명확하고 간결한 누락 된 핵심 사항없이. 명확성이 부족하면 오해로 이어지고 개발 프로세스도 느려집니다. 결함 작성 및보고는 테스트 수명주기에서 가장 중요하지만 무시되는 영역 중 하나입니다.

버그를 제출하려면 좋은 글을 쓰는 것이 매우 중요합니다. 테스터가 명심해야 할 가장 중요한 점은 명령적인 어조를 사용하지 않는다 보고서에서. 이것은 사기를 깨고 건강에 해로운 업무 관계를 만듭니다. 외설적 인 어조를 사용하십시오.

가정하지 마십시오 개발자가 실수를 했으므로 거친 단어를 사용할 수 있습니다. 보고하기 전에 동일한 버그가보고되었는지 여부를 확인하는 것도 똑같이 중요합니다.

중복 버그 테스트주기에 부담이됩니다. 알려진 버그의 전체 목록을 확인하십시오. 때때로 개발자는 문제를 알고 향후 릴리스에서 무시할 수 있습니다. 중복 버그를 자동으로 검색하는 Bugzilla와 같은 도구도 사용할 수 있습니다. 그러나 중복 버그를 수동으로 검색하는 것이 가장 좋습니다.

버그 보고서가 전달해야하는 가져 오기 정보는 다음과 같습니다. '어떻게?' 그리고 '어디?' 보고서는 테스트가 수행 된 방법과 결함이 정확히 어디에서 발생했는지 명확하게 대답해야합니다. 독자는 버그를 쉽게 재현하고 버그가있는 위치를 찾아야합니다.

명심하십시오 버그 보고서 작성 목적 개발자가 문제를 시각화 할 수 있도록하는 것입니다. 그는 버그 보고서에서 결함을 명확하게 이해해야합니다. 개발자가 찾고있는 모든 관련 정보를 제공해야합니다.

또한 버그 보고서는 향후 사용을 위해 보존되며 필요한 정보와 함께 잘 작성되어야합니다. 의미있는 문장과 간단한 단어 사용 버그를 설명합니다. 검토 자의 시간을 낭비하는 혼란스러운 말을 사용하지 마세요.

각 버그를 별도의 문제로보고하십시오. 단일 버그 보고서에 여러 문제가있는 경우 모든 문제가 해결되지 않으면 닫을 수 없습니다.

따라서 문제를 별도의 버그로 분할 . 이렇게하면 각 버그를 개별적으로 처리 할 수 ​​있습니다. 잘 작성된 버그 보고서는 개발자가 터미널에서 버그를 재현하는 데 도움이됩니다. 이렇게하면 문제를 진단하는데도 도움이됩니다.

버그를보고하는 방법?

다음과 같은 간단한 버그 보고서 템플릿을 사용하십시오.

이것은 간단한 버그 보고서 형식입니다. 사용중인 버그 신고 도구에 따라 다를 수 있습니다. 수동으로 버그 보고서를 작성하는 경우 수동으로 할당해야하는 버그 번호와 같이 일부 필드를 구체적으로 언급해야합니다.

보고자: 귀하의 이름과 이메일 주소.

생성물: 이 버그를 발견 한 제품입니다.

버전: 제품 버전 (있는 경우)입니다.

구성 요소: 이들은 제품의 주요 하위 모듈입니다.

최고의 Windows 운영 체제는 무엇입니까

플랫폼: 이 버그를 발견 한 하드웨어 플랫폼을 언급하십시오. ‘PC’,‘MAC’,‘HP’,‘Sun’등 다양한 플랫폼

운영 체제 : 버그를 발견 한 모든 운영 체제를 언급하십시오. Windows, Linux, Unix, SunOS, Mac OS와 같은 운영 체제. 해당되는 경우 Windows NT, Windows 2000, Windows XP 등과 같은 다양한 OS 버전을 언급합니다.

우선 순위: 버그는 언제 수정해야합니까? 우선 순위는 일반적으로 P1에서 P5로 설정됩니다. P1은 '가장 높은 우선 순위로 버그 수정'으로, P5는 '시간이 허용되면 수정'으로 표시됩니다.

심각성: 이것은 버그의 영향을 설명합니다.
심각도 유형 :

  • 차단기 : 더 이상 테스트 작업을 수행 할 수 없습니다.
  • 위독한: 응용 프로그램 충돌, 데이터 손실.
  • 주요한: 주요 기능 상실.
  • 미성년자: 경미한 기능 손실.
  • 하찮은: 일부 UI 개선.
  • 상승: 새로운 기능 또는 기존 기능의 일부 개선 사항을 요청하십시오.

상태: 버그 추적 시스템에 버그를 기록 할 때 기본적으로 버그 상태는 '신규'가됩니다.
나중에 버그는 Fixed, Verified, Reopen, Wo n’t Fix 등과 같은 다양한 단계를 거칩니다.

=> 여기를 클릭하세요 자세한 버그 수명주기에 대해 자세히 알아보십시오.

할당 대상 : 버그가 발생한 특정 모듈을 담당하는 개발자를 알고있는 경우 해당 개발자의 이메일 주소를 지정할 수 있습니다. 그렇지 않으면 관리자가 개발자에게 버그를 할당하지 않을 경우 모듈 소유자에게 버그를 할당하므로 공백으로 유지하십시오. 참조 목록에 관리자의 이메일 주소를 추가 할 수 있습니다.

URL : 버그가 발생한 페이지 URL입니다.

요약: 대부분 60 단어 이하의 버그에 대한 간략한 요약입니다. 요약이 문제가 무엇이며 어디에 있는지를 반영하는지 확인하십시오.

기술: 버그에 대한 자세한 설명입니다.

설명 필드에 다음 필드를 사용하십시오.

  • 단계 재현 : 분명히 버그를 재현하는 단계를 언급합니다.
  • 예상 결과: 위에서 언급 한 단계에서 애플리케이션이 작동하는 방식.
  • 실제 결과: 위의 단계, 즉 버그 동작을 실행 한 실제 결과는 무엇입니까?

버그 보고서의 중요한 단계입니다. 버그 유형을 설명하는 하나 이상의 필드로 '보고서 유형'을 추가 할 수도 있습니다.

보고서 유형은 다음과 같습니다.

1) 코딩 오류
2) 설계 오류
3) 새로운 제안
4) 문서 문제
5) 하드웨어 문제

버그 보고서의 중요한 기능

다음은 버그 보고서의 중요한 기능입니다.

# 1) 버그 번호 / ID

버그 번호 또는 식별 번호 (예 : swb001)를 사용하면 버그보고와 버그 참조가 훨씬 쉬워집니다. 개발자는 특정 버그가 수정되었는지 쉽게 확인할 수 있습니다. 전체 테스트 및 재 테스트 프로세스를 더 부드럽고 쉽게 만듭니다.

# 2) 버그 제목

버그 제목은 버그 보고서의 다른 부분보다 더 자주 읽 힙니다. 버그에 포함 된 모든 내용을 설명해야합니다.

버그 제목은 독자가 이해할 수 있도록 충분히 암시 적이어야합니다. 명확한 버그 제목은 이해하기 쉽고 독자는 버그가 이전에보고되었는지 또는 수정되었는지 알 수 있습니다.

# 3) 우선 순위

버그의 심각도에 따라 우선 순위를 설정할 수 있습니다. 버그는 Blocker, Critical, Major, Minor, Trivial 또는 제안 일 수 있습니다. 중요한 것들을 먼저 볼 수 있도록 P1에서 P5까지의 버그 우선 순위를 지정할 수 있습니다.

# 4) 플랫폼 / 환경

명확한 버그보고를 위해서는 OS 및 브라우저 구성이 필요합니다. 버그를 재현 할 수있는 방법을 전달하는 가장 좋은 방법입니다.

정확한 플랫폼이나 환경이 없으면 애플리케이션이 다르게 동작 할 수 있으며 테스터 쪽의 버그가 개발자 쪽에서 복제되지 않을 수 있습니다. 따라서 버그가 발견 된 환경을 명확하게 언급하는 것이 가장 좋습니다.

# 5) 설명

버그 설명은 개발자가 버그를 이해하는 데 도움이됩니다. 발생한 문제를 설명합니다. 잘못된 설명은 혼란을 야기하고 개발자와 테스터의 시간을 낭비하게됩니다.

설명의 효과에 대해 명확하게 전달할 필요가 있습니다. 완전한 문장을 사용하는 것이 항상 도움이됩니다. 각 문제를 모두 무너 뜨리는 대신 개별적으로 설명하는 것이 좋습니다. '나는 생각한다'또는 '나는 믿는다'와 같은 용어를 사용하지 마십시오.

# 6) 재현 단계

좋은 버그 보고서는 재현 단계를 명확하게 언급해야합니다. 단계에는 버그를 유발하는 작업이 포함되어야합니다. 일반적인 진술을하지 마십시오. 따라야 할 단계를 구체적으로 작성하십시오.

잘 작성된 절차의 좋은 예가 아래에 나와 있습니다.

C ++ 문자를 int로

단계 :

  • 제품 Abc01을 선택하십시오.
  • 장바구니에 추가를 클릭하십시오.
  • 카트에서 제품을 제거하려면 제거를 클릭하십시오.

# 7) 예상 및 실제 결과

예상 및 실제 결과없이 버그 설명이 불완전합니다. 테스트의 결과와 사용자가 기대해야하는 사항을 설명해야합니다. 독자는 테스트의 올바른 결과가 무엇인지 알아야합니다. 명확하게 테스트 중에 발생한 일과 결과를 언급하십시오.

# 8) 스크린 샷

사진은 천 단어의 가치가 있습니다. 결함을 강조하기 위해 적절한 캡션과 함께 실패 인스턴스의 스크린 샷을 찍습니다. 연한 빨간색으로 예기치 않은 오류 메시지를 강조 표시합니다. 이것은 필요한 영역에주의를 환기시킵니다.

좋은 버그 보고서를 작성하기위한 몇 가지 보너스 팁

다음은 좋은 버그 보고서를 작성하기위한 몇 가지 추가 팁입니다.

# 1) 즉시 문제보고

테스트 중에 버그를 발견하면 나중에 세부 버그 보고서를 작성하기 위해 기다릴 필요가 없습니다. 대신 즉시 버그 보고서를 작성하십시오. 이것은 좋고 재현 가능한 버그 보고서를 보장합니다. 나중에 버그 보고서를 작성하기로 결정하면 보고서의 중요한 단계를 놓칠 가능성이 높습니다.

# 2) 버그 리포트 작성 전 버그를 3 ​​회 재현

버그는 재현 가능해야합니다. 단계가 모호함없이 버그를 재현 할 수있을만큼 견고해야합니다. 매번 버그를 재현 할 수없는 경우 버그의 주기적 특성을 언급하는 버그를 제출할 수 있습니다.

# 3) 다른 유사한 모듈에서 동일한 버그 발생 테스트

때때로 개발자는 서로 다른 유사한 모듈에 대해 동일한 코드를 사용합니다. 따라서 한 모듈의 버그가 다른 유사한 모듈에서도 발생할 가능성이 더 높습니다. 발견 한 버그의 더 심각한 버전을 찾을 수도 있습니다.

# 4) 좋은 버그 요약 작성

버그 요약은 개발자가 버그 특성을 빠르게 분석하는 데 도움이됩니다. 보고서 품질이 좋지 않으면 개발 및 테스트 시간이 불필요하게 늘어납니다. 버그 보고서 요약과 잘 전달하십시오. 버그 요약은 버그 인벤토리에서 버그를 검색하기위한 참조로 사용됩니다.

# 5) 제출 버튼을 누르기 전에 버그 보고서를 읽으십시오.

버그 보고서에 사용 된 모든 문장, 문구 및 단계를 읽으십시오. 잘못된 해석으로 이어질 수있는 모호한 문장이 있는지 확인하십시오. 명확한 버그보고를 위해 오해의 소지가있는 단어 나 문장은 피해야합니다.

# 6) 욕설을 사용하지 마십시오

좋은 일을했고 버그를 발견 한 것은 좋지만이 크레딧을 개발자를 비판하거나 개인을 공격하는 데 사용하지 마세요.

결론

버그 보고서는 고품질 문서 여야합니다.

좋은 버그 보고서를 작성하는 데 집중하고이 작업에 시간을 투자하십시오. 이것이 테스터, 개발자 및 관리자 간의 주요 커뮤니케이션 지점이기 때문입니다. 관리자는 좋은 버그 보고서를 작성하는 것이 모든 테스터의 주요 책임이라는 것을 팀에 인식시켜야합니다.

좋은 버그 보고서를 작성하려는 귀하의 노력은 회사의 자원을 절약 할뿐만 아니라 귀하와 개발자 간의 좋은 관계를 형성 할 것입니다.

더 나은 생산성을 위해 더 나은 버그 보고서를 작성하십시오.

버그 보고서 작성의 전문가입니까? 아래 댓글 섹션에서 의견을 자유롭게 공유하십시오.

추천 도서

^