# Отчет об ошибках (баг-репорт)
Если возникает ошибка (а они, безусловно, возникают), то человек, обнаруживший ее, должен иметь возможность сообщить о ней (задокументировать и отправить) тем, кто отвечает за исправление этой ошибки или сбоя.
В идеале, баг-репорт должен объяснять, как именно сломан продукт.
Во время тестирования тестировщик записывает свои наблюдения, найденные баги и другую полезную информацию, полезную разработчикам и менеджменту. Вся эта информация — баг-репорт (или тест-репорт)
Детальный баг-репорт — важный итог, полученный в результате тестирования. Он содержит следующую информацию:
* баги тестируемого продукта
* способы воспроизведения багов
* окружение и специальные условия, в которых воспроизводятся баги
* резолюция (отчет о проверке), в случае, если разработчики исправили какие-то из ранее найденных багов.
Вот еще немного информации о том, что должен содержать хороший баг-репорт:
| Поле | Описание |
| --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Title (название)** | Краткий заголовок, описывающий проблему в общем. Не должен быть слишком длинным, но должен быть понятным и точным. |
| **Description (описание)** | Описание должно покрывать то, что не описано в названии. Содержит подробное описание бага, его влияние на продукт, шаги для воспроизведения, ожидаемый результат. |
| **Version (версия)** | Production-версия продукта, в которой был найден баг. Можно потратить много времени, пытаясь воспроизвести ошибку на других версиях (в которых, возможно, ее просто нет) |
| **Status (статус)** | В каждый момент времени баг может быть в одном из состояний: «Active» (активный), «Ready for Testing» (готов к тестированию), Closed (закрыт). Баг становится «активным», когда он найден; готов к тестированию — когда разработчик его исправляет. Тестировщик может перевести его в состояние «Closed» после исправления и повторного тестирования. |
| **Steps to reproduce (шаги воспроизведения)** | Описание шагов, которые нужно сделать, чтобы воспроизвести проблему. |
| **Assigned to (назначен на…)** | Имя разработчика или тестировщика, на которого назначен баг. |
| **Resulution (резолюция)** | Когда разработчик исправляет баг, желательно описать причину его появления и способ исправления. Это может быть полезно, если в будущем будет найдено что-то похожее. |
### Как лучше всего составить баг-репорт
#### Четко определите проблему
Для начала необходимо четко и правильно сформулировать проблему, которую вы хотите донести до разработчиков. Звучит просто, не правда ли?
Однако многие люди так не считают. Большинство людей пишут отчеты об ошибках, в которых вообще ничего не упоминается о проблеме.
Лучше было бы написать подробное описание того, что именно происходит вследствие ошибки, как она появилась и что именно вы сделали, чтобы ее обнаружить. Пока вы этого не сделаете, это будет просто отчет, и уж точно не об ошибке.
#### Составляйте отдельные отчеты о каждой ошибке
Рассмотрение различных неполадок в одном баг-репорте может легко привести к путанице и непониманию. Создавайте отдельные отчеты об ошибках для каждой проблемы. Так каждый баг-репорт будет содержать больше деталей. Это будет полезно для разработчиков, которым предстоит решать эти проблемы.
#### Укажите, как воспроизвести ошибку
Пока проблема не воспроизведена, она не является ошибкой. Она должна возникать снова и снова, а если этого не происходит, то это может быть и не ошибка вовсе. Когда вы знаете, как она возникла, вы можете качественнее сообщить о ней, а разработчики смогут лучше ее устранить.
#### Отправив баг-репорт, оставайтесь на связи
Как бы хорошо ни был составлен баг-репорт, если человек, отправивший его, недоступен, то он, скорее всего, бесполезен. Разработчики часто хотят получить дополнительную информацию от того, кто отправил отчет об ошибке, поэтому убедитесь, что вы доступны для того, чтобы разъяснить всю информацию, содержащуюся в нем.
#### Добавьте соответствующие коды
Код ошибки – это еще одна важная информация, которую необходимо предоставить. Разработчики могут использовать как отчет об ошибке, так и ее код для поиска и понимания проблемы.
Благодаря этому разработчики будут знать, какие именно действия необходимо воспроизвести и какие меры предпринять для быстрого устранения проблемы.
#### Соберите визуальные подтверждения
Хотя письменные сведения полезны, добавление визуальной информации в баг-репорт может помочь в процессе тестирования и исправления ошибок. Вы можете сделать запись экрана при помощи специальных программ (или сделать запись с помощью камеры смартфона) и отправить результат вместе с отчетом. Скриншоты также будут полезны.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://qabook.gitbook.io/start/teoriya-testirovaniya/bagi-defekty/otchet-ob-oshibkakh-bag-report.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.