Что такое отчет об ошибке

Баг-репорт — это отчет об ошибке. В нём указывают, что нужно исправить в программном обеспечении или на сайте. Перечисляют причины и факты, почему поведение считают ошибочным.

Отчеты отличаются: содержание зависит от предметной области, типа программного обеспечения и даже части программы, где произошла ошибка. Но есть и общие, характерные для всех отчетов моменты.

Почему важно сообщать об ошибках и кто это делает

Никто не хочет работать с программным обеспечением, которое ведет себя не так, как ожидалось. Например, постоянно вылетает, выдает неправильный результат. Плохой пользовательский опыт делает программу бесполезной. Отчеты об ошибках помогают сделать так, чтобы ПО выполняло то, что нужно.

Во многих командах разработчиков есть тестировщики или даже службы обеспечения качества. Они ищут и готовят сообщения об ошибках, а разработчики устраняют проблемы.

Тестировщиком реально стать даже без опыта в IT. Для этого пройдите курс Skypro «Инженер по тестированию». Научитесь писать тестовую документацию и составлять отчеты, тестировать веб- и мобильные приложения и API, освоите нужные инструменты. Внутри — мастер-классы с реальными рабочими задачами, домашки и разборы от наставника. Создадите четыре проекта для портфолио и получите диплом гособразца.

Основные принципы

Правильные отчеты помогают программистам быстрее исправлять ошибки. Детали зависят от типа багов. Но есть несколько основных принципов — что и как включать в баг-репорт, чтобы заранее снять вопросы разработчиков.

Указывайте:

1️⃣ Только одну ошибку на отчет. Это золотое правило, потому что так гораздо проще исправлять баги. Легче отслеживать статус отдельных отчетов и выставлять приоритеты задач, распределять работу между несколькими разработчиками. Да и меньшее количество информации проще запомнить и проанализировать.

2️⃣ Место интерфейса программного обеспечения, в котором возникла ошибка. Опишите экран, на котором находитесь, состояние интерфейса. Включите URL-адрес страницы, если это веб-приложение.

3️⃣ Действия в программе. Пошагово опишите действия, которые выполняли перед тем, как столкнулись с ошибкой. Это важно: может оказаться, что некорректное поведение программы началось до того, как вы его заметили.

4️⃣ Ожидания. Поведение программы может быть некорректным с точки зрения общей логики или вашего личного опыта — указывайте не только очевидные отказы выполнения и неверные результаты вычислений. Программы создают, чтобы облегчить пользователям жизнь, а не заставлять их подстраиваться под готовый результат.

5️⃣ Скриншот или запись экрана с ошибкой. Есть риск ошибиться, когда пишешь отчет об ошибке. Это значительно усложнит работу команды разработки. Визуальные материалы — более точный способ указать на проблему, чем просто описать ее.

6️⃣ Техническую информацию. То есть вашу операционную систему, браузер, тип устройства — персональный компьютер, мобильный телефон или планшет. А еще тип устройства ввода — клавиатуру, мышь, сенсорный экран и прочее. Будут полезны и параметры монитора, чтобы исправить ошибки в отображении пользовательского интерфейса.

7️⃣ Все сообщения об ошибках и коды. Они помогут определить, что это за ошибка и как ее устранить. Показывайте и те сообщения, которые кажутся нерелевантными. Даже они могут помочь разобраться в проблеме.

8️⃣ Можете ли вы воспроизвести проблему. То есть происходит ли одно и то же каждый раз, когда вы пытаетесь выполнить задачу. Эта информация поможет разработчику найти причину ошибки.

9️⃣ Пробовали ли исправить проблему. Есть причина, по которой айтишник всегда спрашивает: «Вы пробовали выключить и снова включить?» или «Пытались ли обновить веб-страницу?». Перезагрузка может быть простым способом исправить проблему. Если она не исчезает — это дает много информации. Укажите, и это сэкономит время на последующее обсуждение проблемы.

🔟 Насколько проблема влияет на работу. Обычно серьезность варьируется от очень высокой (полностью останавливает работу) до очень низкой (визуальные недочеты). Эта информация поможет командам разработчиков расставить приоритеты, определить порядок, в котором устранять ошибки.

Основные элементы

Отчет должен быть четким, действенным и простым. Иначе разработчикам будет сложно понять проблему и найти решение.

Обычно программисты и тестировщики договариваются, что и как указывать. Еще на это влияет система, в которой готовят отчет. Но есть общие компоненты баг-репорта:

👉 Резюме — краткое обозначение проблемы, причина и тип ошибки.

👉 Описание — подробности и любые сведения, которые помогут локализовать и исправить ошибку.

👉 Вложения — любые визуальные или другие материалы.

👉 Срок выполнения — если важно, чтобы ошибку исправили к определенной дате.

👉 Критичность — комментарий, насколько баг мешает нормальной работе приложения.

Часто выделяют следующие уровни критичности ошибок:

☝ Блокирующий (Blocker) — полностью блокирует нормальную работу программы, нужно исправить как можно быстрее.

☝ Критический (Critical) — сильно искажает логику приложения и значительно осложняет работу с ним.

☝ Значительный (Major) — затрагивает только отдельные элементы программы, существенно мешает работать.

☝ Незначительный (Minor) — либо не сильно влияет на работу программы, либо проявляется редко.

☝ Тривиальный (Trivial) — относится к визуальным недочетам в интерфейсе: опечатки, неудобные цвета и прочее.

Жизненный цикл

Порядок работы тоже зависит от соглашений в команде, системы управления. Но выделяют общие статусы отчета, которые встречаются практически везде:

💡 Новый — только создан, ждет проверки разработчиком.

💡 Принят — отчет проверили, проблему подтвердили.

💡 Отклонен — отчет проверили, но команда разработки отказалась работать по нему. Например, потому что ошибку не удалось повторить. Или то, что показалось ошибкой, — нормальное поведение программы. Или проблему уже устранили, когда работали над другим отчетом.

💡 Назначен — ошибку передали исполнителю.

💡 В работе — разработчик исправляет ошибку.

💡 Проверяется — исполнитель закончил работу, результат проверяет старший специалист.

💡 Закрыт — ошибку исправили, результат доступен пользователям.

Системы для отчетов об ошибках

Современные программы — это сложные, многоуровневые информационные системы. Большинство из них неидеальны, где-то постоянно появляются баги. Чтобы помочь командам разработчиков справиться с потоком отчетов об ошибках от пользователей или тестировщиков, создали специальные системы. Они позволяют автоматизировать работу с багами.

Такие программы называют баг-трекерами. Чаще всего они — часть более сложных систем: управления проектами или исходным кодом приложения.

Системы управления проектами созданы, чтобы помочь контролировать разработку программы. Акцент в них сделан на планировании, отчетности и аудите. Такие системы чаще используют менеджеры проектов, тестировщики, разработчики в коммерческих продуктах.

К наиболее распространенным системам управления проектами относят:

• Jira.
• YouTrack.
• Redmine.

Системы управления исходным кодом позволяют отслеживать изменения, контролировать версии кода и управлять отчетами об ошибках. Ими чаще пользуются именно разработчики. Не только в коммерческих, но и в свободно распространяемых программных продуктах, программах с открытым исходным кодом.

К основным системам управления исходным кодом относят:

• GitHub.
• GitLab.
• Bitbucket.

Интерфейсы и функции систем довольно сильно отличаются, но для работы с отчетами все предоставляют базовый набор функций:

✔️ форма создания отчета об ошибке с полями для ввода основных элементов;

✔️ управление состоянием и параметрами;

✔️ форма обсуждения, в которой команда задает вопросы и оставляет комментарии, указывает дополнительные детали;

✔️ уведомление об изменениях через имейл или другую систему обмена сообщениями.

У части баг-трекеров есть публичное голосование. Пользователи голосуют за или против бага: так повышают или понижают его приоритет.

Главное

• Баг-репорт — специальный вид отчета о неисправности в программном обеспечении или веб-сайте. Баг-репорт готовят тестировщики или специалисты из команды по контролю качества.
• Оформление баг-репорта сильно влияет на скорость, с которой исправят ошибки, на итоговый результат. Указывайте причину и тип ошибки, подробности, срок выполнения, критичность. Прикладывайте скриншоты или запись экрана.
• Прописывайте, пробовали ли исправить проблему, насколько она влияет на работу. Указывайте операционную систему, браузер, тип устройства, параметры монитора.
• Есть системы, с которыми проще создавать баг-репорты и управлять ими. Основные: Jira, YouTrack, Redmine, GitHub, GitLab, Bitbucket.

Введение

В программировании отчёт об ошибке (англ. error report или crash report) — это файл, содержащий техническую информацию об исключительной ситуации (исключении), произошедшем в программе на компьютере пользователя. В терминологии программирования критическая ошибка, которая приводит к аварийному завершению программы, также называется крэшем (англ. crash).

Отчеты об ошибках часто включают в себя такую информацию, как: тип креша, образ стека, версия программы, тип центрального процессора, версия операционной системы, а также лог программы.

Создание отчета об ошибке

Отчет об ошибке обычно создается специальной программой (англ. crash reporter). Целью такой программы является сбор данных о произошедшем креше и отправка этих данных по сети Интернет некой третьей стороне, обычно этой третьей стороной является производитель программного обеспечения. Отчет об ошибке призван помочь разработчикам программного обеспечения выяснить причину креша и исправить ее в последующих релизах программного продукта.

Mac OS X

В Mac OS X cуществует стандартная программа — сборщик отчетов об ошибке: /System/Library/CoreServices/Crash Reporter.app. Crash Reporter.app отправляет креш-логи, стандартные для ОС Unix, в компанию Apple Computer, где эти логи анализируют их инженеры. В верхнем поле окна отчета об ошибке содержится креш лог, а в нижнем пользователь может ввести свои комментарии, например, рассказать что он делал в момент, когда произошел креш. Пользователи также могут скопировать лог и отправить его разработчику ПО для анализа. Crash Reporter.app работает в трех основных режимах в случае ошибки: ничего не делать, вывести сообщение «Application has crashed» или вывести окно отчета об ошибке.

Windows

Microsoft Windows XP включает в себя службу отправки отчетов об ошибке, называемую Windows Error Reporting (неформально называемую Dr. Watson), которая позволяет оправить отчет об ошибке в компанию Microsoft для онлайн-анализа. Информация отправляется в централизованную базу данных, управляемую Microsoft. Отчет содержит необходимую информацию, которая позволяет разработчику диагностировать причину ошибки и исправить ее.

Windows вероятно имеет наиболее сложную систему анализа ошибок на сегодняшний день, в которой централизованная база данных может быть настроена для сбора дополнительной информации от пользователей, испытывающих определенный тип проблемы. Система охватывает все части процесса отладки и выпуска ПО таким образом, что исправления могут быть применены к ПО на компьютере пользователя автоматически через службу Windows Update.

GNOME

На платформе GNOME для сбора и отправки отчетов об ошибке используется утилита Bug Buddy. Когда приложение, использующее библиотеки GNOME аварийно завершается, Bug Buddy генерирует снимок стека, используя отладчик gdb и предлагает пользователю отправить отчет в систему GNOME bugzilla. Пользователь может добавить свой комментарий и посмотреть, что содержится в отчете.

KDE

Утилита для отправки отчетов об ошибках в KDE называется Dr. Konqi.

Mozilla

Talkback

(также известный как Quality Feedback Agent) являлся утилитой для отправки сообщений об ошибках в программном обеспечении Mozilla вплоть до версии 1.8.1 для отправки отчетов об ошибках на централизованный сервер.^[1] Talkback является проприетарным ПО, на которое Mozilla Corporation получила лицензию у компании SupportSoft. Когда продукты Mozilla (например Mozilla Firefox, Mozilla Thunderbird) аварийно завершали свою работу, агент Talkback предлагал пользователю ввести описание ошибки. Talkback не заменит собой встроенной в операционную систему программы для отправки отчетов об ошибке, которая, запускается наряду с агентом Talkback. Talkback был заменен на программу Breakpad в браузере Firefox начиная с версии 3.

Breakpad

Breakpad (ранее также известный как Airbag) — это замена Talkback. Он является ПО с открытым исходным кодом. Breakpad разрабатывается совместно Google и Mozilla, и используется в текущих продуктах, основанных на движке Mozilla, таких как Firefox или Thunderbird.^[2][3] Этот продукт имеет большое значение, так как это первая мультиплатформенная утилита с открытым исходным кодом, предназначенная для отправки отчетов об ошибках.

Начиная с 27 мая 2007, Breakpad включен в стволовые сборки (trunk builds) Firefox 3 для Windows NT и Mac OS X, а также, несколько недель спустя, в Linux.^[4]

Ubuntu

Вместе с релизом Ubuntu 6.10, Ubuntu включает утилиту Apport^[5].

Apport перехватывает процессы, в которых произошло исключение и которые готовы создать дамп ядра (core dump), и записывает отчеты об ошибках в определенное место. Затем специальный демон, предлагает пользователю отправить отчеты в Ubuntu для их анализа.^[6]

World of Warcraft

World of Warcraft — еще одна программа, использующая свое собственное средство доставки отчетов об ошибке, называемое «Error Reporter». Однако данная утилита не всегда перехватывает исключения; иногда вместо него вызывается стандартная утилита-креш репортер, встроенная в ОС. Известно, что Error Reporter иногда сам завершается аварийно в процессе отправки отчета об ошибке.

CrashRpt

Еще одной библиотекой для доставки отчетов об ошибке в операционной системе Windows является CrashRpt^[7][8]. Библиотека CrashRpt позволяет отлавливать исключения в программах, созданных в Microsoft Visual C++ и работающих в Windows. Библиотека распространяется по «новой» лицензии BSD.

CrashRpt перехватывает необработанные исключения, создает файл-минидамп, строит описатель ошибки в формате XML, предоставляет интерфейс с пользователем, и, наконец, сжимает отчет и отправляет его группе поддержки приложения.

Cмотрите также

• Core dump
• Баг
• Обработка исключений

Ссылки

1. ↑ Mozilla Talkback server. Архивировано из первоисточника 5 апреля 2012. Проверено 21 сентября 2006.
2. ↑ Deploying the Airbag. BSBlog (Mozilla developer Benjamin Smedberg’s weblog).
3. ↑ Using Breakpad with Gran Paradiso (1.9a3). BSBlog (Mozilla developer Benjamin Smedberg’s weblog).
4. ↑ Bug 381099 — Turn on crash reporting by default (Win+Mac), mozilla.org bug tracker]
5. ↑ EdgyReleaseNotes. Проверено 14 февраля 2007.
6. ↑ Apport. Ubuntu Wiki. Проверено 14 февраля 2007.
7. ↑ CrashRpt Project Page. Архивировано из первоисточника 3 февраля 2012.
8. ↑ Использование библиотеки CrashRpt. Архивировано из первоисточника 5 апреля 2012.

Эта статья — об автоматически создаваемых отчётах об аварийном завершении. О сообщениях о любых багах, создаваемых вручную («багрепортах») см. система отслеживания ошибок.

В программировании отчёт об ошибке (англ. error report или crash report) — это файл, содержащий техническую информацию об исключительной ситуации (исключении), произошедшей в программе на компьютере пользователя. В терминологии программирования критическая ошибка, которая приводит к аварийному завершению программы («падению»), также называется крэшем или «крашем» (от англ. crash).

Отчёты об ошибках часто включают в себя такую информацию, как: тип крэша, образ стека, версия программы, тип центрального процессора, версия операционной системы, а также лог программы.

Создание отчёта об ошибке

Отчёт об ошибке обычно создаётся специальной программой (англ. crash reporter). Целью такой программы является сбор данных о произошедшем крэше и отправка этих данных по сети Интернет некой третьей стороне, обычно этой третьей стороной является производитель программного обеспечения. Отчёт об ошибке призван помочь разработчикам программного обеспечения выяснить причину крэша и исправить её в последующих релизах программного продукта.

Mac OS X

В Mac OS X существует стандартная программа — сборщик отчётов об ошибке: /System/Library/CoreServices/Crash Reporter.app. Crash Reporter.app отправляет крэш-логи, стандартные для ОС Unix, в компанию Apple Computer, где эти логи анализируют их инженеры. В верхнем поле окна отчёта об ошибке содержится крэш лог, а в нижнем пользователь может ввести свои комментарии, например, рассказать что он делал в момент, когда произошёл крэш. Пользователи также могут скопировать лог и отправить его разработчику ПО для анализа. Crash Reporter.app работает в трёх основных режимах в случае ошибки: ничего не делать, вывести сообщение «Application has crashed» или вывести окно отчёта об ошибке.

Windows

Microsoft Windows XP включает в себя службу отправки отчётов об ошибке, называемую Windows Error Reporting (не путать с Dr. Watson), которая позволяет отправить отчёт об ошибке в компанию Microsoft для онлайн-анализа. Информация отправляется в централизованную базу данных, управляемую Microsoft. Отчёт содержит необходимую информацию, которая позволяет разработчику диагностировать причину ошибки и исправить её.

Windows вероятно имеет наиболее сложную систему анализа ошибок на сегодняшний день, в которой централизованная база данных может быть настроена для сбора дополнительной информации от пользователей, испытывающих определённый тип проблемы. Система охватывает все части процесса отладки и выпуска ПО таким образом, что исправления могут быть применены к ПО на компьютере пользователя автоматически через службу Windows Update.

GNOME

На платформе GNOME для сбора и отправки отчётов об ошибке используется утилита Bug Buddy. Когда приложение, использующее библиотеки GNOME аварийно завершается, Bug Buddy генерирует снимок стека, используя отладчик gdb и предлагает пользователю отправить отчёт в систему GNOME bugzilla. Пользователь может добавить свой комментарий и посмотреть, что содержится в отчёте.

KDE

Утилита для отправки отчётов об ошибках в KDE называется Dr. Konqi.

Mozilla

Talkback

(также известный как Quality Feedback Agent) являлся утилитой для отправки сообщений об ошибках в программном обеспечении Mozilla вплоть до версии 1.8.1 для отправки отчётов об ошибках на централизованный сервер.^[1] Talkback является проприетарным ПО, на которое Mozilla Corporation получила лицензию у компании SupportSoft. Когда продукты Mozilla (например Mozilla Firefox, Mozilla Thunderbird) аварийно завершали свою работу, агент Talkback предлагал пользователю ввести описание ошибки. Talkback не заменит собой встроенной в операционную систему программы для отправки отчётов об ошибке, которая, запускается наряду с агентом Talkback.
Talkback был заменён на программу Breakpad в браузере Firefox начиная с версии 3.

Breakpad

Breakpad (ранее также известный как Airbag) — это замена Talkback. Он является ПО с открытым исходным кодом. Breakpad разрабатывается совместно Google и Mozilla, и используется в текущих продуктах, основанных на движке Mozilla, таких как Firefox или Thunderbird.^[2][3] Этот продукт имеет большое значение, так как это первая мультиплатформенная утилита с открытым исходным кодом, предназначенная для отправки отчётов об ошибках.

Начиная с 27 мая 2007, Breakpad включён в стволовые сборки (trunk builds) Firefox 3 для Windows NT и Mac OS X, а также, несколько недель спустя, в Linux.^[4]

Ubuntu

Вместе с релизом Ubuntu 6.10, Ubuntu включает утилиту Apport^[5].

Apport перехватывает процессы, в которых произошло исключение и которые готовы создать дамп ядра (core dump), и записывает отчёты об ошибках в определённое место. Затем специальный демон, предлагает пользователю отправить отчёты в Ubuntu для их анализа.^[6]

World of Warcraft

World of Warcraft — ещё одна программа, использующая своё собственное средство доставки отчётов об ошибке, называемое «Error Reporter». Однако данная утилита не всегда перехватывает исключения; иногда вместо него вызывается стандартная утилита-крэш репортёр, встроенная в ОС. Известно, что Error Reporter иногда сам завершается аварийно в процессе отправки отчёта об ошибке.

CrashRpt

Ещё одной библиотекой для доставки отчётов об ошибке в операционной системе Windows является CrashRpt^[7][8]. Библиотека CrashRpt позволяет отлавливать исключения в программах, созданных в Microsoft Visual C++ и работающих в Windows. Библиотека распространяется по «новой» лицензии BSD.

CrashRpt перехватывает необработанные исключения, создаёт файл-минидамп, строит описатель ошибки в формате XML, предоставляет интерфейс с пользователем, и, наконец, сжимает отчёт и отправляет его группе поддержки приложения.

См. также

• Core dump
• Баг
• Обработка исключений

Примечания

Любая компания по разработке программного обеспечения стремится к тому, чтобы продукт, который она создаёт, был высочайшего качества. Для того, чтобы этого добиться, QA специалисты должны обнаружить все недостатки и недочёты приложения ещё на ранних стадиях жизненного цикла разработки программного обеспечения. А когда ошибка обнаружена, её нужно описать так, чтобы разработчики могли легко понять, в чём заключается проблема, воспроизвести её и оперативно исправить. Именно для этого пишутся баг-репорты.  

В этой статье мы обсудим основные компоненты отчёта об ошибке, разберём, на какие моменты стоит обращать внимание при их составлении, а также рассмотрим, какие существуют инструменты для отслеживания багов. 
‍

Что такое баг-репорт?

Баг-репорт — это отчёт, который информирует разработчиков об ошибке (баге) в работе приложения. Этот документ должен быть хорошо структурированным и содержать достаточно деталей, чтобы читатель мог легко найти ответы на главные вопросы: 

• Где возникла проблема?
• Что именно работает не так, как ожидалось?
• Какие действия нужно выполнить, чтобы воспроизвести ошибку?

Не стоит также забывать о том, что у разработчиков нет времени читать слишком длинные, с множеством несущественных подробностей описания багов. Поэтому отчёты должны быть как можно более краткими. 

Как правило, репорт попадает в категорию плохо составленных по одной из двух причин: слишком много ненужных деталей или слишком мало полезной информации. Навык не включать в отчёт ничего лишнего приходит с опытом. А для того, чтобы не пропустить ничего важного, достаточно помнить об основных элементах баг-репорта. 
‍

Основные компоненты баг-репорта.

Давайте рассмотрим каждый раздел отчёта об ошибке и поговорим о том, на что стоит обращать внимание при написании. 
‍

Заголовок.

Заголовок — это та часть репорта, которую разработчики видят первой. Он должен представлять собой краткое описание бага. Общие заголовки вроде «Поиск не работает» не очень полезны. Что именно не работает? Система выдаёт результаты, не соответствующие запросу? Поиск длится слишком долго? Вариант «При нажатии на кнопку поиска функция не срабатывает» более информативен. Хорошие заголовки снижают вероятность появления дублирующихся репортов, а также позволяют разработчику быстрее найти нужный ему отчёт.   
‍

Описание бага.

Раздел с описанием ошибки должен содержать подробную информацию о том, что привело к возникновению проблемы, какой результат ожидали получить тестировщики, а что произошло на самом деле. Он может иметь такую структуру: 

• Шаги для воспроизведения бага. 

Очень важно предоставить разработчикам чёткие инструкции, как они могут воспроизвести ошибку. В идеале это должен быть пронумерованный список понятных действий:

1. Перейти на страницу входа в систему.
2. Ввести правильное имя пользователя.
3. Ввести неправильный пароль.

Чтобы сделать список короче, можно заранее оговорить некие условия. Например, если что-то не работает на странице редактирования профиля, не обязательно подробно описывать все шаги для входа в систему. Вместо этого можно внести информацию: предварительные условия — зарегистрированный пользователь вошёл в систему. 

• Фактические и ожидаемые результаты. 

Здесь вы объясняете разницу между ожидаемым и фактическим поведением приложения. 

Ожидаемый результат: Не удаётся войти в учётную запись. Появляется сообщение об ошибке «Неверное имя пользователя или пароль».

Фактический результат: Не удаётся войти в учётную запись. Появляется сообщение об ошибке «Неверное имя пользователя”.

При написании каждого из этих подразделов не забывайте о том, что добавить всю полезную информации и исключить все ненужные детали одинаково важно. 
‍

Приложения 

Скриншоты или видеозапись экрана помогут разработчикам быстрее разобраться в сути проблемы и найти оптимальное решение. Однако это не означает, что можно добавить к отчёту видео и не утруждать себя описанием ошибки. Приложения лишь дополняют, но ни в коем случае не заменяют текстовую информацию. 
‍

Критичность и приоритет (Severity, Priority)

Эти разделы подсказывают, насколько серьёзные последствия может вызвать обнаруженная ошибка и как срочно её нужно устранить. Обычно багам присваивается один из 6 уровней критичности: блокирующий, критический, серьёзный, незначительный, тривиальный, предлагаемое улучшение. В зависимости от критичности проблемы ей назначается высокий, средний или низкий уровень приоритета. 
‍

Программно-аппаратное окружение (Environment) 

На разных устройствах приложения могут вести себя по-разному. Поэтому качественный отчёт об ошибке должен также содержать информацию об операционной системе, версии приложения, браузерах и девайсах, использованных в процессе тестирования.   

Подход к составлению отчётов об ошибках может немного отличаться от компании к компании. Это зависит от используемых технологий, типа проекта, принятых рабочих процессов и тестируемых продуктов. Однако понимание основных компонентов баг-репорта и требований к ним поможет вам составлять хорошие отчёты независимо от этих факторов.
‍

Инструменты для отслеживания ошибок или баг-трекеры. 

Баг-трекеры — это инструменты, которые позволяют командам эффективнее фиксировать и отслеживать дефекты в приложениях. В их функционал обычно входит следующее:

• Создавать баг-репорты. 
• Присваивать ошибкам приоритет.
• Менять статус бага на разных этапах его жизненного цикла (например, новый, открыт, отклонён, исправлен и т.д.).    
• Назначать ответственных за выполнение той или иной задачи. 
• Искать, фильтровать и сортировать ошибки по различным параметрам: по названию, критичности, идентификационному номеру и т.д.

Вот краткий обзор десяти популярных инструментов для отслеживания ошибок. 
‍

JIRA

JIRA — это баг-трекер и инструмент для управления Agile-проектами, который используют многие компании. Её легко подстроить под нужды конкретной команды и интегрировать практически с любым другим инструментом разработки.

Bugzilla

Bugzilla — это популярный баг-трекер с открытым исходным кодом. Он прост в использовании, имеет все необходимые функции и предоставляет расширенные возможности поиска.  

Trello

Trello — популярная система управления проектами. Она невероятно гибкая и позволяет наладить эффективный рабочий процесс по отслеживанию ошибок для команд любого размера.

Asana

Asana — ещё один инструмент управления проектами, который широко используется для отслеживания ошибок. В ней даже есть готовый шаблон для таких целей, который можно легко изменить или дополнить, в зависимости от потребностей компании. 

Redmine

Redmine — баг-трекер с открытым исходным кодом. Он популярен среди небольших команд, которым нужно простое и гибкое решение для управления различными проектами. 

FogBugz

FogBugz — веб-система управления проектами с функциями для отслеживания ошибок, управления задачами и учёта рабочего времени. 

YouTrack

YouTrack — это веб-система для отслеживания ошибок и управления проектами, разработанная компанией JetBrains. Она позволяет фиксировать дефекты, планировать спринты, управлять задачами и составлять отчёты о проделанной работе. 

Backlog 

Backlog — простая, но мощная платформа. Расширенные возможности поиска, полная история обновлений и изменений статусов, вики, иерархия задач, диаграммы Ганта и множество других полезных функций позволяют без труда наладить эффективный процесс отслеживания ошибок. 

Zoho Bug Tracking

Zoho Bug Tracking — это онлайн-платформа, с помощью которой можно создавать проекты, отслеживать ошибки, генерировать отчёты или обмениваться документами.

BugHerd

BugHerd — инструмент, который позволяет собирать отчёты о работе сайта прямо на его страницах. 

Безусловно, использование подходящих инструментов может облегчить работу по отслеживанию багов. Однако, чтобы наладить действительно эффективный процесс, одних инструментов мало. Нужно ещё, чтобы все члены команды придерживались основных правил по написанию качественных баг-репортов. 
‍

О чём стоит помнить при составлении баг-репортов? 

Вот несколько принципов, которых стоит придерживаться:

• Один отчет — одна ошибка. Даже если вы обнаружили проблемы в одном и том же месте, создавайте отдельные репорты для каждого бага. Если описывать несколько в одном отчёте, это только запутает читателя и он может упустить какой-то из дефектов. Кроме того, статус такого репорта невозможно будет изменить, пока разработчики не исправят все перечисленные в нём ошибки. И разобраться, как продвигается работа, будет сложнее.
• Избегайте дубликатов. Прежде чем создавать новый баг-репорт, проверьте, если проблема уже не была описана ранее.  
• Воспроизведите ошибку несколько раз, чтобы убедиться, что вы не пропустили ни одного важного шага в инструкциях для разработчиков. Если у вас не получается повторить проблему каждый раз, упомяните об этом и укажите коэффициент воспроизводимости (например: 7/10 раз баг воспроизводится).
• Придерживайтесь фактов и не стройте предположений о том, что могло стать причиной дефекта. Это может задать разработчикам неверное направление мысли и отсрочить устранение ошибки.  
• Всегда будьте вежливы, не обвиняйте и не критикуйте коллег. Ваша работа как тестировщика заключается в обеспечении высокого качества продукта, а не в оценке чьей-то работы. 
• И наконец, перечитайте свой отчёт, прежде чем отправить его. Он должен быть кратким, понятным и содержать всю необходимую информацию. 

Создание качественных баг-репортов — ценный навык для любого специалиста по обеспечению качества. Теперь, когда вы получили достаточно теоретической информации, пришло время применить свои знания на практике. Тренируйтесь — и совсем скоро вы будете писать отчёты, которые точно понравятся вашим разработчикам!

Полезные ссылки

https://www.atlassian.com/software/jira

https://www.bugzilla.org/ 

https://trello.com/en

https://asana.com/

https://www.redmine.org/ 

https://fogbugz.com/ 

https://www.jetbrains.com/youtrack/ 

https://backlog.com/ 

https://www.zoho.com/bugtracker/ 

https://bugherd.com/

Запись на курс Manual QA

This article is in the Product Showcase section for our sponsors at CodeProject. These articles are intended to provide you with information on products and services that we consider useful and of value to developers.

License

Redgate makes ingeniously simple software used by 804,745 IT professionals and counting, and is the leading Microsoft SQL Server tools vendor. Our philosophy is to design highly usable, reliable tools which elegantly solve the problems developers and DBAs face every day, and help them adopt database DevOps. As a result, more than 100,000 companies use products in the Redgate SQL Toolbelt, including 91% of those in the Fortune 100.

This article is in the Product Showcase section for our sponsors at CodeProject. These articles are intended to provide you with information on products and services that we consider useful and of value to developers.

License

Redgate makes ingeniously simple software used by 804,745 IT professionals and counting, and is the leading Microsoft SQL Server tools vendor. Our philosophy is to design highly usable, reliable tools which elegantly solve the problems developers and DBAs face every day, and help them adopt database DevOps. As a result, more than 100,000 companies use products in the Redgate SQL Toolbelt, including 91% of those in the Fortune 100.

Перейти к содержанию