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

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

좋은 버그를 신고하는 것은 어렵지 않지만 약간의 노력이 필요합니다. 목표는 쉽게 손상된 부분을 찾고, 근본 원인에 도달하며, 무엇보다도 문제를 해결할 방법을 찾는 것입니다. 빠르게 진행되는 버그는 명확한 예상 동작으로 쉽게 재현되는 경향이 있습니다.

버그인지 확인

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

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

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

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

브라우저 간에 차이가 있는 동작은 일반적으로 상호 운용성 문제로 우선순위가 높습니다. 특히 버그가 포함된 브라우저가 특이한 경우 이에 해당합니다. BrowserStack과 같은 도구를 사용하여 최신 버전의 Chrome, Firefox, Safari, Edge를 테스트해 보세요.

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

최근 버전에서 문제가 발생했나요?

이전에는 예상대로 작동했지만 최신 브라우저 출시에서 중단되었나요? 이러한 '회귀'는 특히 제대로 작동한 버전 번호와 실패한 버전을 제공하는 경우 훨씬 빠르게 처리될 수 있습니다. BrowserStack과 같은 도구를 사용하면 이전 브라우저 버전을 쉽게 확인할 수 있으며 bisect-builds 도구(Chromium용)를 사용하면 변경사항을 매우 효율적으로 검색할 수 있습니다.

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

다른 사용자에게도 같은 문제가 표시되나요?

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

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

버그가 무엇인지 파악했다면 이제 브라우저 버그 데이터베이스를 검색하여 버그가 이미 신고되었는지 확인합니다.

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

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

버그 신고

이전에 버그가 신고된 적이 없다면 브라우저 공급업체에 알려야 합니다.

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

Mozilla에 최소화된 테스트 사례를 만드는 방법에 대한 유용한 도움말이 있습니다. 긴 이야기를 간단히 말하자면 문제 설명으로 시작하는 것도 좋지만 버그에 문제를 보여주는 링크 데모를 제공하는 것만큼 좋은 방법은 없습니다. 빠른 진행 가능성을 극대화하려면 예시에 문제를 설명하는 데 필요한 최소한의 코드가 포함되어야 합니다. 최소한의 코드 샘플은 버그가 수정될 가능성을 높이기 위해 할 수 있는 가장 중요한 작업입니다.

다음은 테스트 사례를 최소화하기 위한 몇 가지 팁입니다.

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

축소된 테스트 사례 호스팅

축소된 테스트 사례를 호스팅하기에 적합한 장소를 찾고 있다면 다음과 같은 방법을 이용할 수 있습니다.

이러한 사이트 중 일부는 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)에서만 재현할 수 있습니다. 사용한 테스트 환경의 세부정보를 포함해야 합니다.

버그 제출

마지막으로 버그를 제출합니다. 그런 다음 버그에 대한 응답이 있는지 이메일을 주의 깊게 살펴봐야 합니다. 일반적으로 조사 또는 버그 수정 시 엔지니어가 추가 질문을 하거나 문제를 재현하는 데 어려움이 있는 경우 문의할 수 있습니다.