좋은 브라우저 버그를 신고하는 방법

브라우저에서 발견한 문제를 브라우저 공급업체에 알리는 것은 웹 플랫폼을 개선하는 데 필수적인 부분입니다.

Pete LePage
Robert Nyman

좋은 버그를 신고하지만 약간의 작업이 필요합니다. 브라우저 엔지니어가 손상된 부분을 찾고 근본 원인을 파악하고 가장 중요한 것은 문제를 해결하는 방법을 최대한 쉽게 찾을 수 있도록 하는 것이 목표입니다. 빠르게 진행되는 버그는 명확한 예상 동작으로 빠르게 재현되는 경향이 있습니다.

버그인지 확인

첫 번째 단계는 '올바른' 동작이 무엇인지 파악하는 것입니다.

올바른 동작은 무엇인가요?

MDN에서 관련 API 문서를 확인하거나 관련 사양을 찾아보세요. 이 정보를 통해 실제로 손상된 API, 손상된 위치, 예상되는 동작을 결정할 수 있습니다.

다른 브라우저에서는 작동하나요?

브라우저 간에 다른 동작은 일반적으로 상호 운용성 문제로 더 높은 우선순위가 부여됩니다. 특히 버그가 있는 브라우저가 예외인 경우 더욱 그렇습니다. BrowserStack과 같은 도구를 사용하여 최신 버전의 Chrome, Firefox, Safari, Edge에서 테스트해 보세요.

가능하면 사용자 에이전트 스니핑으로 인해 페이지가 의도적으로 다르게 동작하지 않는지 확인합니다. Chrome DevTools에서 User-Agent 문자열을 다른 브라우저로 설정해 봅니다.

최근 출시에서 문제가 발생했나요?

이전에는 예상대로 작동했지만 최근 브라우저 출시에서 작동하지 않나요? 특히 작동한 버전 번호와 실패한 버전 번호를 제공하는 경우 이러한 회귀에 훨씬 더 빠르게 조치를 취할 수 있습니다. BrowserStack과 같은 도구를 사용하여 이전 브라우저 버전을 확인할 수 있습니다. bisect-builds 도구(Chromium용)와 같은 도구를 사용하여 변경사항을 검색합니다.

문제가 회귀이고 재현할 수 있는 경우 일반적으로 근본 원인을 빠르게 찾아 해결할 수 있습니다.

다른 사용자에게도 동일한 문제가 발생하나요?

문제가 발생한 경우 다른 개발자에게도 동일한 문제가 발생했을 가능성이 큽니다. 먼저 Stack Overflow에서 버그를 검색해 보세요. 이렇게 하면 추상적인 문제를 특정 손상된 API로 변환하는 데 도움이 될 수 있으며 버그가 수정될 때까지 단기적인 해결 방법을 찾는 데 도움이 될 수 있습니다.

이전에 신고된 적이 있나요?

버그에 대한 개념을 파악했다면 브라우저 버그 데이터베이스를 검색하여 버그가 이미 신고되었는지 확인해야 합니다.

문제를 설명하는 기존 버그를 발견하면 버그에 별표표시, 즐겨찾기 또는 댓글을 달아 지원을 추가합니다. 또한 많은 사이트에서 참조 목록에 추가하고 버그가 변경될 때 업데이트를 받을 수 있습니다.

버그에 관한 의견을 작성하는 경우 버그가 웹사이트에 미치는 영향에 관한 정보를 포함하세요. 버그 추적기는 일반적으로 모든 댓글에 대해 이메일을 보내므로 '+1' 스타일의 댓글을 추가하지 마세요.

버그 신고

이전에 버그가 신고되지 않은 경우 브라우저 공급업체에 버그를 알립니다.

최소화된 테스트 사례 만들기

Mozilla에는 최소화된 테스트 사례를 만드는 방법에 관한 유용한 도움말이 있습니다. 간단히 말하자면 문제에 대한 설명은 좋은 시작이지만 문제를 보여주는 연결된 데모를 버그에 제공하는 것만큼 좋은 방법은 없습니다. 신속하게 진행할 수 있도록 하려면 예시에는 문제를 보여주는 데 필요한 최소한의 코드만 포함해야 합니다. 버그가 수정될 가능성을 높이려면 최소 코드 샘플을 사용하는 것이 가장 중요합니다.

다음은 테스트 사례를 최소화하는 데 도움이 되는 몇 가지 팁입니다.

  • 웹페이지를 다운로드하고 <base href="https://original.url">를 추가한 다음 로컬에 버그가 있는지 확인합니다. URL이 HTTPS를 사용하는 경우 실시간 HTTPS 서버가 필요할 수 있습니다.
  • 최대한 많은 브라우저의 최신 빌드에서 로컬 파일을 테스트합니다.
  • 모든 내용을 하나의 파일로 압축해 보세요.
  • 버그가 사라질 때까지 코드를 삭제합니다 (불필요하다고 알고 있는 것부터 시작).
  • 버전 제어를 사용하면 작업을 저장하고 잘못된 작업을 실행취소할 수 있습니다.

축소된 테스트 사례 호스팅

축소된 테스트 사례를 호스팅할 좋은 장소를 찾고 있다면 다음과 같은 몇 가지 장소를 사용할 수 있습니다.

이러한 사이트 중 일부는 콘텐츠를 iframe에 표시하므로 기능이나 버그가 다르게 작동할 수 있습니다.

문제 신고

최소화된 테스트 사례를 확보했다면 버그를 신고할 준비가 된 것입니다. 적절한 버그 추적 사이트로 이동하여 새 문제를 만듭니다.

명확한 설명과 재현 단계를 추가합니다.

먼저 엔지니어가 문제를 빠르게 파악하고 분류하는 데 도움이 되는 명확한 설명을 제공합니다.

When installing a PWA using the `beforeinstallprompt.prompt()`, the
`appinstalled` event fires before the call to `prompt()` resolves.

다음으로 문제를 재현하는 데 필요한 세부 단계를 제공합니다. 여기에서 축소된 테스트 사례가 사용됩니다.

What steps will reproduce the problem?
1. Go to https://basic-pwa.glitch.me/, open DevTools and look at the
   console tab.
2. Click the Install button in the page, you might need to interact with
   the page a bit before it becomes enabled.
3. Click Install on the browser modal install confirmation.

마지막으로 예상 결과와 실제 결과를 설명합니다.

What is the expected result? In the console:
0. INSTALL: Available (logged when `beforeinstallprompt` event fired)
1. INSTALL_PROMPT_RESPONSE: {outcome: "accepted", platform: "web"}
   (logged when beforeinstallprompt.prompt()` resolves)
2. INSTALL: Success (logged when `appinstalled` event fired)

What is the actual result? In the console:
0. INSTALL: Available (logged when `beforeinstallprompt` event fired)
1. INSTALL: Success (logged when `appinstalled` event fired)
2. INSTALL_PROMPT_RESPONSE: {outcome: "accepted", platform: "web"}
   (logged when beforeinstallprompt.prompt()` resolves)

자세한 내용은 MDN의 버그 신고 작성 가이드라인을 참고하세요.

보너스: 문제의 스크린샷 또는 스크린캐스트 추가

필수는 아니지만 문제의 스크린샷이나 스크린캐스트를 추가하면 도움이 되는 경우가 많습니다. 이는 여러 단계 또는 비정상적인 활동 후에 버그가 발생할 때 특히 유용합니다. 브라우저 엔지니어에게 무슨 일이 일어났는지 더 잘 보여주는 방법은 스크린캐스트와 스크린샷입니다.

환경 세부정보 포함

일부 버그는 특정 운영체제에서만 재현되거나 특정 유형의 디스플레이 (예: 낮은 DPI 또는 높은 DPI)에서만 재현됩니다. 사용한 테스트 환경의 세부정보를 포함해야 합니다.

버그 제출

마지막으로 버그를 제출합니다. 버그에 대한 응답은 이메일로 전송됩니다. 일반적으로 조사 중에 엔지니어가 추가 질문을 할 수 있습니다. 문제를 재현하는 데 어려움이 있으면 문의할 수 있습니다.