How to write a bug report -for Testwork-

How to write a bug report

Below is a short summary of what to include for each component of a full bug report.

Clear Title

• A moderator should be able to understand what the bug report is about from the title alone.

One bug per report

• Report one bug in a single report. If you put in more than one many bug it may be overlooked, and will not be eligible for payment.

Actual results

• This section should expand on the title by stating the behaviour observed when the issue occurs.

Expected results

• The Expected Results section should state on how the app should behave according to the expected behaviour. 

E.g: The authorisation phase completes successfully, the user is logged into the newly created account and redirected to the home page of the app.

 Steps to reproduce:

• The Steps to Reproduce section should list each step required to reproduce the bug in chronological order.

Severity of the bug

• We use 5 categories to identify the severity of the bug.
  • Critical -  The bug prevents critical functionality within the app from working. This includes crashing, freezing for which no workaround is possible and a fix is required immediately.
  • High - The bug affects major functionality within the app from working. However, high priority bugs can be avoided with a workaround.
  • Medium - The bug does not cause a failure and does not interfere with the fluent work of the system and programs. It has an easy workaround.
  • Low - The bug does not affect functionality or data, or require a workaround.  It is a result of non-conformance to a standard that does not impact productivity - typing errors/ aesthetic inconsistencies.
  • Usability - A suggestion that would improve how an app is understood, learnt and used efficiently.  

Device and Operating System

• Each bug report must include details of the specific device and operating system you used during the test to  identify the bug.

Other Notes/Error Messages

• Include necessary and relevant evidence to show the problem your are describing. Evidence includes: screenshots, videos, crash or console logs (for crashes).
• Crashes and freezes should always include a video and console/crash logs. 
• Bugs with more than one step to reproduce usually require a video. 

---

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

다음은 전체 버그 보고서의 각 구성 요소에 대해 포함 할 내용에 대한 간략한 요약입니다.

제목 지우기

• 중재자는 제목만으로 버그 보고서가 무엇인지 이해할 수 있어야합니다.

보고서 당 하나의 버그

• 하나의 버그를 하나의 보고서에보고하십시오. 하나 이상의 버그를 여러 개 넣으면 간과 될 수 있으며 지불 자격이 없습니다.

실제 결과

• 이 섹션에서는 문제가 발생할 때 관찰 된 동작을 설명하여 제목을 확장해야합니다.

예상 결과

• 예상 결과 섹션에는 예상되는 동작에 따라 앱이 어떻게 동작해야하는지에 대해 설명해야합니다. 

예 : 인증 단계가 완료되면 사용자가 새로 생성 된 계정에 로그인하여 앱의 홈페이지로 리디렉션됩니다.

 재현 단계 :

• 재현 단계 섹션에는 버그를 시간순으로 재현하는 데 필요한 각 단계가 나열되어 있어야합니다.

버그의 심각도

• 우리는 5 가지 카테고리를 사용하여 버그의 심각도를 확인합니다.
  • 치명적 - 버그로 인해 앱 내의 중요한 기능이 작동하지 않습니다. 여기에는 일시적 중단, 일시 중지가 가능하며 즉시 해결해야하는 수정 작업이 포함됩니다.
  • 높음 -이 버그는 앱의 주요 기능이 작동하는 데 영향을줍니다. 그러나 우선 순위가 높은 버그는 피할 수 있습니다.
  • 보통 - 버그로 인해 오류가 발생하지 않으며 시스템 및 프로그램의 유창한 작업을 방해하지 않습니다. 쉬운 해결 방법이 있습니다.
  • 낮음 - 버그가 기능 또는 데이터에 영향을 미치지 않거나 해결 방법이 필요합니다. 이는 생산성에 영향을 미치지 않는 표준 오류 / 미적 불일치에 대한 부적합의 결과입니다.
  • 유용성 - 앱이 어떻게 이해되고, 학습되고, 효율적으로 사용되는지 개선 할 수있는 제안.  

장치 및 운영 체제

• 각 버그 보고서에는 버그를 식별하기 위해 테스트 중에 사용한 특정 장치 및 운영 체제에 대한 세부 정보가 포함되어야합니다.

기타 메모 / 오류 메시지

• 설명하는 문제를 보여줄 필요하고 관련있는 증거를 포함 시키십시오. 증거에는 스크린 샷, 비디오, 충돌 또는 콘솔 로그 (충돌)가 포함됩니다.
• 충돌 및 정지에는 항상 비디오 및 콘솔 / 크래시 로그가 포함되어야합니다. 
• 재현 할 단계가 둘 이상인 버그에는 일반적으로 비디오가 필요합니다.