예제와 함께 버그 보고서를 작성하는 방법
루카스 베넷
버그 리포트란 무엇입니까? 왜 좋은 버그 보고서가 필요한가요?
Bug Report는 테스트 팀에 다양한 이점을 제공하는 STLC의 중요한 문서입니다. 소프트웨어 테스트 중에 발견된 모든 결함, 여러 버그, 오류 및 기타 불일치를 추적하고 이를 보고합니다.
이 사후 테스트 문서의 목적은 테스트 프로세스 중에 발생한 버그 수준에 대한 정보를 관련 전문가 팀에 제공하는 것입니다.
너의 소프트웨어 개발 엔지니어 이러한 유형의 보고서를 사용하면 소프트웨어에 존재하는 모든 결함과 문제를 인식할 수 있습니다. 또한 버그의 문제점을 파악할 수 있으므로 최선의 방법을 사용하여 버그를 수정할 수 있습니다. 또한 버그와 문제를 파악하는 데 도움을 주어 시간과 비용을 절약하는 데도 도움이 됩니다.
왜 좋은 버그 설명에 관심을 가져야 합니까?
훌륭하고 상세한 소프트웨어 버그 보고서를 작성하기 위해 고려해야 할 사항은 다음과 같습니다.
- 이는 향후 릴리스에서 동일한 버그를 방지하는 데 도움이 되는 가이드 역할을 합니다.
- 의사소통(이메일, 전화)에 소요되는 시간을 절약하세요.
- Less 개발자를 위해 일하세요(그들은 당신이 원하는 것을 정확히 할 것입니다).
- 프로젝트의 병목 현상이 줄어듭니다. 버그는 더 빠르고 효율적인 방법으로 수정될 것입니다.
버그 보고서 작성 방법(버그 보고서 템플릿)
버그 추적 시스템에 따라 다르기 때문에 정확한 버그 보고서 템플릿은 없습니다. 템플릿은 다를 수 있습니다.
그러나 버그 보고서를 작성할 때는 항상 다음과 같은 일반적인 필드가 필요합니다.
- 버그 ID/제목.
- 심각도 및 우선순위.
- 기술설명
- 환경
- 재현 단계.
- 예상 결과.
- 실제 결과.
- 첨부 파일(스크린샷, 비디오, 텍스트)
이러한 모든 버그 추적 구성 요소를 하나씩 살펴보겠습니다.
1) 제목/버그 ID:
모든 버그에는 고유한 식별 번호가 부여되어야 합니다. 버그 보고 도구는 새로 제기된 버그에 대해 고유한 번호여야 하므로 버그를 쉽게 식별할 수 있습니다.
예 :
❌ 나쁨: “다시 보면 제품이 보이지 않아요. 그렇지 않아요.”
- 막연한
- 적극적인
- 너무 장황하다
해결책을 시행할 것을 요구합니다.
✅ 좋음: "CART - 표시되지 않는 장바구니에 새 항목이 추가되었습니다."
- 이러한 종류의 제목은 즉시 문제를 찾습니다(CART).
- 실제 기술적인 문제에 초점을 맞춥니다.
2) 버그 심각도:
버그 심각도는 버그 보고서에서 매우 중요한 요소입니다. 결함이 애플리케이션 성능에 미치는 영향을 설명합니다.
- 차단기: 이 오류로 인해 앱이 실패하게 됩니다.
- 전공 : 심각한 오류는 비즈니스 논리의 주요 변경을 나타냅니다.
- 마이너 : 애플리케이션의 기능에는 영향을 미치지 않지만 예상 결과에는 영향을 미치는 문제입니다.
- 하찮은: 앱의 기능이나 작동에는 영향을 미치지 않습니다. 오타일 수 있습니다.
3) 버그 우선순위:
버그 우선순위를 결정하는 일반적인 등급은 다음과 같습니다.
- 높음 : 흐름에 영향을 미치거나 앱 사용을 차단하는 모든 것을 다룹니다.
- 매체 : 이는 사용자 경험에 부정적인 영향을 미칩니다.
- 마이너 : 오타, 아이콘 누락, 레이아웃 문제 등과 같은 기타 모든 오류.
4) 환경:
버그는 특정 환경에서만 나타날 수 있으며 다른 환경에서는 나타나지 않습니다. 예를 들어, 때때로 웹사이트를 실행할 때 버그가 나타나는 경우가 있습니다. Firefox, 또는 앱이 실행될 때만 오작동하는 경우 Android 장치가 iPhone에서 잘 작동합니다.
이러한 버그 보고서는 브라우저 간 또는 장치 간 테스트를 통해서만 식별할 수 있습니다. 따라서 버그를 보고할 때 QA는 버그가 하나 이상의 특정 환경에서 관찰되어야 하는지 여부를 지정할 수 있어야 합니다.
5) 요약:
그러나 버그 보고서에 제목만 추가하는 것은 목적에 부합하지 않습니다. 따라서 제목이 충분하지 않은 경우 짧은 보고서 요약을 추가할 수 있습니다.
버그가 발생한 시기와 방법을 포함하여 가능한 한 짧은 단어로 요약합니다. 제목과 버그 설명도 검색에 사용되어야 하므로 중요한 키워드를 포함했는지 확인해야 합니다.
예:
- 나쁜: "테스트에 뭔가를 추가하려고 했는데, 그렇게 하거나 버튼을 클릭해도 아무것도 나타나지 않았습니다."
- 좋은 : "장바구니에 [PRODUCT]을(를) 추가하려고 했는데 특정 제품 개요 웹페이지에서 '추가' 버튼을 클릭해도 아무 일도 일어나지 않았습니다."
6) 재현 단계:
버그를 보고할 때 이를 재현하기 위한 단계를 지정하는 것이 중요합니다. 버그를 일으킬 수 있는 작업도 포함해야 합니다. 여기서는 일반적인 진술을 하지 마십시오.
따라야 할 단계를 구체적으로 설명하십시오.
다음은 잘 작성된 절차의 예입니다.
단계 :
- 제품 X1을 선택하세요.
- 장바구니에 추가를 클릭하세요.
- 장바구니에서 제품을 제거하려면 제거를 클릭하세요.
7) 예상 결과:
버그 보고서에서는 기술 작업, 테스트 사례 결과 설계 또는 테스터의 의견에 따라 예상되는 결과를 설명하는 것이 중요합니다. 이 모든 기능은 개발자가 필요한 정보를 빠르게 찾는 데 집중할 수 있도록 도와줍니다.
예 :
필수 항목은 "제출" 버튼을 클릭한 후 빨간색으로 강조 표시되어야 합니다.
8) 실제 결과:
이름에서 알 수 있듯이 이 필드는 버그의 실제 효과를 설명합니다. 실제 결과에 대한 명확한 설명을 작성하는 것이 매우 중요합니다.
예 :
필수 항목은 "제출" 버튼을 클릭하면 녹색으로 강조 표시됩니다.
9) 첨부파일(스크린샷 및 동영상):
버그 보고서에서는 정보를 시각적으로 표시해야 할 때 정보를 더 쉽게 인식할 수 있도록 버그 보고서에 파일을 첨부하는 것이 가장 좋습니다.
예 :
- 스크린 샷 : 스크린샷은 프로그램의 실수를 쉽게 설명할 수 있습니다. 특정 주석, 원 또는 화살표 이미지로 버그를 강조 표시하면 편리합니다.
- 동영상 : 때로는 버그를 말로 설명하기 어려울 수 있으므로 개발자가 프로그램의 결함을 수정할 수 있도록 동영상을 제작하는 것이 좋습니다.
10) 영향을 받는 버전:
버그가 보고된 영향을 받는 소프트웨어 버전입니다.
11) 수정 버전:
버그가 해결된 소프트웨어 버전입니다. 따라서 버그를 보고한 QA는 버그가 수정되었는지 확인할 때 올바른 소프트웨어 버전을 사용합니다.
12) Target 버전 :
버그를 수정하기 위해 대상으로 삼아야 하는 대상 버전입니다. 따라서 개발팀이 버그 수정 작업을 할 때 대부분 특정 애플리케이션 버전을 대상으로 합니다.
13) 휴무일:
소프트웨어 테스팅 팀이 버그를 종결한 날짜입니다. 버그를 닫는 것은 소프트웨어 테스팅의 필수적이고 필수적인 부분입니다.
14) 상태:
새로운 버그가 생성되면 상태는 공개여야 합니다. 그 후 진행 중, 수정됨, 실행 중, 다시 열기 등의 단계를 거칩니다.
버그 보고서 작성을 위한 팁
효과적인 버그 보고서를 작성하는 동안 기억해야 할 몇 가지 중요한 팁은 다음과 같습니다.
- 버그 보고서를 작성할 때는 구체적으로 작성하세요. 쓸모 없거나 관련성이 없는 사실을 포함하지 않도록 하세요.
- 버그가 발견되는 즉시 즉시 보고해야 합니다.
- 개발자가 사실과 정보를 사용하여 문제를 디버깅할 수 있도록 보고서를 자세히 준비하십시오.
- 검증을 위해 다른 유사한 모듈에서 동일한 버그 발생을 테스트해야 합니다.
- Rev버그 보고서를 제출하기 전에 적어도 한 번은 확인하세요.
- 버그 보고서에는 하나의 오류에 대한 설명만 포함되어 있는지 확인해야 합니다.
- 마지막으로, 어떤 것에 대해 불분명하다고 생각되면 프로젝트 관리자에게 도움을 요청하는 것을 두려워해서는 안 됩니다.
버그 보고 도구
수동으로 수행되었던 버그 보고 프로세스는 이제 시중에서 구할 수 있는 다양한 버그 보고 도구를 사용하여 수행되고 있습니다.
- 지라
- Zoho 버그 추적기
- 버그질라
자세한 리뷰를 확인하실 수 있습니다. 최고의 버그 보고 도구.
버그 보고서 작성 중 일반적인 문제 및 해결 방법:
버그 보고서를 작성하는 동안 발생하는 몇 가지 일반적인 문제와 해결 방법은 다음과 같습니다.
| 버그 신고 예시 | 문제 |
|---|---|
| 2에 3을 곱하면 답은 양수가 됩니다. | 예시가 아닌 패턴을 보고하세요. |
| 이를 방지하기 위해 새 항목을 추가할 때 목록은 알파벳순으로 정렬됩니다. | 무엇이 잘못되었는지 설명만 하지 마세요. |
| 예 : 그러기 위해서는 브라우저를 열고 사이트의 URL을 입력해야 합니다. 첫 번째 필드인 'username'의 철자가 잘못되었음을 알 수 있습니다. |
항상 요점을 직접 말하십시오(절대로 이야기를 하지 마십시오!). |
| 보고서에 있는 고객 이름의 철자가 잘못되었습니다. 우선순위: 높음, 심각도: 높음 | 우선순위와 심각도를 혼합하지 마십시오. |
| 세금 계산 공식이 정확하지 않습니다 !!?? | 대문자, 빨간색 글자, 빨간색 원, '!'를 사용하지 않습니다. |
| 홈페이지 Ul 디자인은 별로인 것 같아요. | 당신의 판단을 사용하지 마십시오. |
| 불분명한 설명의 예: 오늘 토론에 대해 이 페이지에 필요한 작업을 수행하십시오. | 모든 사람이 이해할 수 있도록 설명을 작성하세요. |
| 페이지 배경은 파란색, 주황색, 녹색이어야 하며 검정색이나 흰색으로 만들 수도 있습니다.
웹개발팀과 디자인팀에서 무엇이 필요한지 불분명해서 좋지 않습니다. |
옵션을 최소화하세요 |
| 세금 계산 공식이 예상대로 작동하지 않는 경우가 있습니다. | 황금률: '가끔'이라는 단어를 사용하지 마세요. |
버그 신고 예시
다음은 버그 보고서의 작은 예입니다.
[내 계정] 업데이트 버튼에 마우스오버 시 밑줄이 표시됩니다.
상품 설명 내 계정 섹션의 업데이트 버튼에 마우스 오버 시 밑줄을 제거해야 합니다.
링크 : http://test.com/mv-account/
브라우저/OS: 크롬 25. OSX 요세미티 10.10.2
재현 단계 :
1. www.test.com으로 이동합니다.
2. 로그인 자격 증명을 통해 로그인
3. 내 계정으로 이동
4. 업데이트 버튼에 마우스 오버
실제 결과: 밑줄이 있습니다.
예상 결과: 밑줄 없음.
로그인 데이터: test@test.com / mysecretpass12
버그 보고서 작성 시 실수를 피해야 합니다.
버그 보고서를 작성할 때 피해야 할 몇 가지 중요한 실수는 다음과 같습니다.
- 당신의 불만에 대해 글을 쓰지 말고, 당신의 개인적인 감정을 결코 포함하지 마십시오.
- 게시물에 이모티콘이 너무 많으면 작업에 집중하려는 사람들을 짜증나게 합니다.
- 게시물에 느낌표를 너무 많이 사용하지 마세요. 작업 속도가 빨라지지는 않습니다.
- 누구도 기분이 상하고 싶어하지 않습니다. 이는 동기를 파괴하고 문제 실현을 지연시킵니다.
