Содержание отчета об ошибках

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

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

Откуда берутся баги

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

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

Виды багов

🧨 Логические. Приводят к тому, что программа зависает, работает не так, как надо, или выдает неожиданные результаты — например, не записывает файл, а стирает.

🧨 Синтаксические. Это опечатки в названиях операторов, пропущенные запятые или кавычки.

🧨 Взаимодействия. Это ошибка в участке кода, который отвечает за взаимодействие с аппаратным или программным окружением. Такая ошибка возникает, например, если неправильно использовать веб-протоколы.

🧨 Компиляционные. Появляются, если что-то не так с компилятором или в коде есть синтаксические ошибки. Компилятор будто ругается: «Не понимаю, что тут написано. Не знаю, как обработать».

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

🧨 Арифметические. Бывает, в коде есть числовые переменные и математические формулы. Если где-то проблема — не указаны константы или округление сработало не так, возникает баг.

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

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

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

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

Как составить баг-репорт

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

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

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

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

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

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

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

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

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

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

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

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

Остальные элементы указывают, в зависимости от условий. Например, если софт на ставят на ПК, то нужна версия ОС. Если приложение браузерное, то указывают браузер.

Пример баг-репорта

Основные принципы: как не допускать ошибок в баг-репорте

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

Указывайте:

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

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

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

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

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

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

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

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

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

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

Жизненный цикл баг-репорта

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

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

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

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

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

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

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

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

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

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

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

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

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

• Jira.
• YouTrack.
• Redmine.

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

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

• GitHub.
• GitLab.
• Bitbucket.

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

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

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

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

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

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

Главное: что такое баг-репорт

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

Баг-репорт (bug report) — это технический документ, который подробно описывает ошибку в работе программы, приложения или другого ПО. Его составляет тестировщик, чтобы разработчикам было понятно, что работает неправильно, насколько дефект критичен и что нужно исправить.

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

Виды багов

• Функциональные. Возникают, когда фактический результат работы не соответствует ожиданиям: не получается опубликовать комментарий на сайте, добавить товар в корзину или открыть страницу.
• Визуальные. Это случаи, когда приложение выглядит иначе, чем задумано: кнопка накладывается на текст, не отображаются картинки или текст выходит за пределы окна.
• Логические. Баг, при котором что-то работает неправильно с точки зрения логики, — например, когда можно указать несуществующую дату (31 февраля) или поставить дату рождения из будущего (2077 год).
• Дефекты UX. Приложение или программа неудобны в использовании: при просмотре ленты новостей пользователя постоянно отбрасывает к началу, слишком близко расположены кнопки и вместо одной нажимается другая.
• Дефекты безопасности. Случаи, когда из-за ошибки в коде данные пользователей (почты, пароли, фото, информация о платежах) могут быть доступны третьим лицам.

Структура баг-репорта

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

Серьезность и приоритет багов

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

• S0 Trivial (Тривиальный) — баг не влияет на работу программы, поэтому для его исправления могут не выделить отдельную задачу, а исправить попутно при исправлении других, похожих ошибок. Например, при заполнении анкеты в поле «Дата рождения» по умолчанию отображается не актуальный год, а 1999-й.
• S1 Minor (Незначительный) — баг почти не нарушает логику процессов, поэтому с ним программа может нормально работать. Например, неудобная навигация в интерфейсе.
• S2 Major (Серьезный) — баг создает неудобства в использовании, но еще не нарушает функционал программы.
• S3 Critical (Критический) — баг мешает приложению выполнять основные функции: калькулятор расходов неправильно считает бюджет или в текстовом редакторе невозможно вводить текст.
• S4 Blocker (Блокирующий) — ситуация, когда программа не работает в принципе: сайт выдает «ошибку 404» или не запускается приложение.

Приоритет — это срочность выполнения задачи. Всего выделяется три уровня приоритетов:

• P1 Высокий — исправляется в первую очередь, так как баг ломает работу приложения.
• P2 Средний — обязательный к исправлению баг после критического.
• P3 Низкий — не требует немедленного решения.

Жизненный цикл бага

Статус бага в репорте определяется его «жизненным циклом», который состоит из четырех основных стадий:

• Открыт (Open) — тестировщик выявил баг и добавил в репорт.
• В работе (In Progress) — о баге сообщили исполнителю, и он занимается исправлением.
• Исправлен (Ready for check) — исполнитель закончил работу по исправлению бага и передал проект на повторную проверку тестировщику.
• Закрыт (Closed) — баг устранен и больше не воспроизводится.

Кроме основных есть еще несколько статусов:

• Отклонен (Rejected) — исправлению бага помешала ошибка в репорте, например неверный алгоритм в пункте «Шаги к воспроизведению».
• Отсрочен (Deferred) — баг признан неприоритетным и исправление переносится.
• Переоткрыт (Reopened) — баг был отсрочен или отклонен, но теперь исполнитель взял его в работу.

Как правильно писать баг-репорт

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

На что стоит обратить внимание при описании дефекта?

Выявить причину возникновения. Например, если на сайте не получается восстановить пароль, то проблема может быть как в бэкенде, так и во фронтенде. Задача тестировщика — разобраться в ней, так как от этого зависит, кому из разработчиков отдавать баг на исправление.

Провести проверку на разных устройствах. Если проблема есть в десктоп-версии, то она может возникнуть и на мобильных устройствах, поэтому стоит проверить.

Провести проверку в разных версиях ПО. Баг может не воспроизводиться в старой версии ПО, но появится в новой.

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

Отчеты об ошибках Windows (WER) (кодовое название Watson) — это отчеты о сбоях технология введена Microsoft с Windows XP^[1] и включен в более поздние версии Windows и Windows Mobile 5.0 и 6.0. Не путать с Доктор Ватсон инструмент отладки, который оставил дамп памяти на локальном компьютере пользователя, Windows Error Reporting собирает и предлагает отправить сообщение об ошибке отлаживать информация (а дамп памяти ) используя Интернет для Microsoft когда приложение вылетает или перестает отвечать на рабочем столе пользователя. Никакие данные не отправляются без согласия пользователя.^[2] Когда аварийный дамп (или другая информация о сигнатуре ошибки) достигает сервера Microsoft, он анализируется, и информация о решении отправляется обратно пользователю, если таковая имеется. Решения обслуживаются с помощью отчетов об ошибках Windows. Отчет об ошибках Windows работает как Служба Windows. ^[3]

История

Windows XP

Microsoft впервые представил отчет об ошибках Windows с Windows XP.^[1]

Виндоус виста

Отчет об ошибках Windows был значительно улучшен в Виндоус виста, когда публично API были введены для сообщения о сбоях, отличных от сбоев и зависаний приложений.^[4] Используя новые API-интерфейсы, как описано в MSDN, разработчики могут создавать собственные отчеты и настраивать пользовательский интерфейс отчетов. Отчет об ошибках Windows также был переработан с упором на надежность и удобство для пользователей. Например, WER теперь может сообщать об ошибках даже из процессов в плохих состояниях, таких как стек исчерпания, повреждения PEB / TEB и куча повреждений, условия, которые в выпусках до Windows Vista привели к тихому завершению программы без сообщения об ошибке. Новый Панель управления Также был представлен апплет «Отчеты о проблемах и решения», в котором ведется учет ошибок и проблем системы и приложений, а также представлены возможные решения проблем.

Windows 7

Отчеты о проблемах и решения Панель управления апплет был заменен разделом обслуживания Центр поддержки Windows на Windows 7 и Сервер 2008 R2.

Новое приложение Problem Steps Recorder (PSR.exe) доступно во всех сборках Windows 7 и позволяет собирать действия, выполненные пользователем при возникновении сбоя, чтобы тестировщики и разработчики могли воспроизвести ситуацию для анализа и отладки.^[5]

Системный дизайн

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

Ошибки, собранные клиентами WER, отправляются в службу WER. В службе WER задействовано около 60 серверов, подключенных к сети хранения данных объемом 65 ТБ, в которой хранится база данных отчетов об ошибках, и к сети хранения данных объемом 120 ТБ, в которой хранятся необработанные файлы CAB за период до 6 месяцев. Услуга предназначена для получения и обработки более 100 миллионов отчетов об ошибках в день, что достаточно, чтобы пережить коррелированные глобальные события, такие как Интернет-черви.^[6]

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

Ведра

В системе отчетов об ошибках Microsoft Windows (WER) отчеты о сбоях организованы по «сегментам». Сегменты классифицируют проблемы по:^[7]

• Имя приложения,
• Версия приложения,
• Дата сборки приложения,
• Название модуля,
• Версия модуля,
• Дата сборки модуля,
• Код исключения ОС^[8][9]/ Код системной ошибки,^[10][11]
• и смещение кода модуля.

В идеале каждая корзина содержит отчеты о сбоях, вызванных одной и только одной основной причиной. Однако есть случаи, когда это идеальное взаимно-однозначное сопоставление не выполняется. Во-первых, эвристика, согласно которой сбои группируются, может привести к тому, что один сбой будет отнесен к нескольким сегментам; например, каждый раз, когда приложение с ошибкой перекомпилируется, приложение будет иметь новую дату сборки модуля, и результирующие сбои затем будут отображаться в несколько сегментов. Во-вторых, поскольку в алгоритм сегментирования учитывается только определенная информация о состоянии отказа, несколько различных ошибок могут быть сопоставлены с одним сегментом; например, если приложение вызывает одну функцию, например Strlen со строками, поврежденными по-разному из-за различных дефектов базового кода, сбои могут быть сопоставлены с одним и тем же сегментом, потому что они кажутся сбоями в одной и той же функции из того же приложения и т. д. Это происходит потому, что сегмент создается на клиенте ОС Windows без выполнение любого анализа символов в дампе памяти: модуль, выбранный клиентом Windows Error Reporting, является модулем наверху стека. Изучение многих отчетов приводит к неисправному модулю, который отличается от исходного определения корзины.^[12]

Стороннее ПО

Производители программного и аппаратного обеспечения могут получать доступ к своим отчетам об ошибках с помощью Microsoft Центр разработки для Windows Панель оборудования и рабочего стола (ранее Winqual ) программа.^[13] Чтобы данные отчетов об ошибках передавались только инженерам, ответственным за продукт, Microsoft требует, чтобы заинтересованные поставщики получили VeriSign Цифровой идентификатор класса 3 или DigiCert сертификат.^[14] Цифровые сертификаты, предоставляемые более дешевыми поставщиками (например, Thawte, Комодо, GlobalSign, GeoTrust, Cybertrust, Доверить, GoDaddy, QuoVadis, Trustwave, SecureTrust, Уэлс Фарго ) не принимаются.^{[15][16][17][18][19]}

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

Влияние на программное обеспечение будущего

Microsoft сообщила, что данные, собранные с помощью отчетов об ошибках Windows, существенно повлияли на внутреннюю разработку программного обеспечения. Например, в 2002 г. Стив Баллмер отметил, что отчеты об ошибках позволили команде Windows исправить 29% всех ошибок Windows XP с помощью Windows XP SP1. Более половины всех Microsoft Office Ошибки XP были исправлены в Office XP SP2.^[20] Успех частично основан на Правило 80/20. Данные отчетов об ошибках показывают, что существует небольшой набор ошибок, который отвечает за подавляющее большинство проблем, с которыми сталкиваются пользователи. Исправление 20% дефектов кода может устранить 80% и более проблем, с которыми сталкиваются пользователи. Статья в Нью-Йорк Таймс подтвердил, что данные отчетов об ошибках сыграли важную роль в устранении проблем, замеченных в бета-версиях Windows Vista и Microsoft Office 2007.^[21]

Проблемы конфиденциальности и использование АНБ

Хотя Microsoft сделала гарантии конфиденциальности, они признают, что личная информация могут содержаться в памяти и данных приложения, скомпилированных в «минидампах» размером 100-200 КБ, которые Windows Error Reporting компилирует и отправляет обратно в Microsoft. Они настаивают на том, что в случае отправки личных данных в Microsoft, они не будут использоваться для идентификации пользователей, согласно заявлению Microsoft. политика конфиденциальности.^[22][23] Но сообщая о проблемах в Microsoft, пользователи также должны доверять партнерам Microsoft. Около 450 партнеров получили доступ к базе данных отчетов об ошибках для просмотра записей, связанных с их драйверы устройств и приложения.^[24]

Старые версии WER отправляют данные без шифрования; только WER из Windows 8 использует шифрование TLS.^[25] В марте 2014 года Microsoft выпустила обновление (KB2929733) для Windows Vista, 7 и Server 2008, которое шифрует первый этап WER.^[26]

В декабре 2013 года независимая лаборатория обнаружила, что WER автоматически отправляет информацию в Microsoft, когда к компьютеру подключается новое USB-устройство.^[25]

Согласно с Der Spiegel, отчет о сбоях Microsoft использовался АНБ ТАО блок для взлома компьютеров Секретариат общественной безопасности Мексики. Согласно тому же источнику, отчеты о сбоях Microsoft автоматически собираются в АНБ. XKeyscore база данных, чтобы облегчить такие операции.^[27]

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

• Winqual
• Доктор Ватсон (отладчик)

Рекомендации

Профессия тестировщика ПО очень многогранна, ведь она требует внимания к деталям, креативности, коммуникативных навыков и усидчивости. Последнее качество особенно пригодится для такой части работы QA-инженера, как составление тестовой документации.

Один из примеров ― баг-репорт (от англ. bug report ― отчёт об ошибке), который содержит описание всех найденных дефектов в работе приложения. Не имеет значения, тестируете ли вы компьютерную игру, приложение для банка или сайт онлайн-магазина ― составление правильного отчёта является залогом продуктивного QA-процесса.

Баг-репорт содержит ответы на следующие вопросы:

• что идёт не так;
• где проявляется дефект;
• когда ошибка воспроизводится.

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

Разберёмся, как добиться этого сочетания.

Как выявляют баги?

Вы, как инженер по обеспечению качества, можете узнать о наличии дефектов в программном обеспечении несколькими способами:

1. во время проведения тестирования ПО;
2. при обращении заказчика с описанием ошибки;
3. из сообщений пользователей, которые столкнулись с проблемами во время использования программного продукта.

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

Какой инструмент используют для документирования дефектов?

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

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

Некоторые компании отдают предпочтение и менее известным инструментам, например, Redmine или Mantis.

Каких правил придерживаться при написании баг-репорта?

Правило №1: следуйте принципу «1 дефект = 1 баг-репорт». Это позволит сохранить прозрачность процессов на проекте и детально следить за исправлением недочётов.

Правило №2: пишите баг-репорт простым и лаконичным языком, ведь от того, насколько быстро разработчик поймёт суть проблемы зависит скорость внесения правок в код.

Правило №3: описывайте дефект кратко, но с сохранением максимума полезной информации.

Правило №4: удостоверьтесь в воспроизводимости ошибки до заведения баг-репорта, повторите свой алгоритм действий и по возможности сократите число шагов.

Правило №5: проверьте, нет ли идентичного дефекта, который уже был зафиксирован.

Если всё в порядке, можно переходить к описанию.

Из каких элементов состоит баг-репорт?

Форма заполнения баг-репорта включает несколько полей (атрибутов). Туда тестировщик вносит характеристики дефекта. Число атрибутов может варьироваться в зависимости от баг-трекинговой системы и особенностей проекта, но с некоторыми тестировщики работают постоянно. Рассмотрим их:

Summary (заголовок)

Первый элемент баг-репорта — это краткое описание сути проблемы. В этом поле мы должны коротко и ясно описать выявленный дефект. Уже на этом этапе вы можете придерживаться правила «Где? Что? Когда или в каких условиях?». Не лишним будет добавить и данные о тестовом окружении, под которым выявлен дефект. Формулируйте этот атрибут в виде связного предложения, так будет проще вникнуть в суть проблемы.

Давайте рассмотрим конкретный пример. Представьте, что вы тестируете площадку объявлений menyaemsya.com. Согласно требованиям, поле с описанием товара должно содержать максимум 350 символов. Но вы видите, что система пропускает описание, которое превышает данный лимит. Для этого дефекта вам нужно составить баг-репорт. Воспользуемся подсказкой «Что? Где? Когда?», чтобы составить заголовок. Получается:

«Ограничение на ввод символов в поле с описанием товара отсутствует на всех страницах».

При тестировании мобильных приложений важно внести и название платформы, iOS или Android.

Заголовок готов. Можем двигаться дальше.

Description (описание)

Содержание этого поля отличается в зависимости от баг-трекинговой системы. Например, JIRA или Redmine предполагают описание шагов воспроизведения ошибки. Пользователи Mantis тут могут более подробно описать суть проблемы, а для описания пути воспользоваться атрибутом «Steps to reproduce» (в пер. с англ. «действия по воспроизведению»). Выглядеть это описание может следующим образом:

1. переход на сайт menyaemsya.com;
2. вход или регистрация;
3. нажатие кнопки «Добавить объявление»;
4. ввод символов в поле «Описание».

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

«Пользователь авторизован на сайте menyaemsya.com и перешёл в корзину».

Actual/expected result (фактический/ожидаемый результат)

Нам предстоит ещё раз указать на суть дефекта и добавить информацию о том, как элемент ПО должен работать корректно.

Пример заполнения данного раздела:

«При внесении информации в поле “Описание” количество вводимых пользователем знаков не лимитируется. Ожидается, что после внесения 350 символов система не будет выводить на экран знаки и предложит пользователю сократить текст».

Attachments (вложения)

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

Priority (приоритет)

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

Системы определения важности могут отличаться, но скорее всего вы встретитесь с подобной градацией:

• P1 High (высокий приоритет);
• P2 Medium (средний приоритет);
• P3 Low (низкий приоритет);

Высокий приоритет имеют критические дефекты, которые необходимо исправить в кратчайшие сроки. Категория P3 включает те баги, которые не влияют на работу системы и могут быть устранены в последнюю очередь.

Severity (серьёзность)

Ошибки имеют и другую характеристику ― степень серьёзности влияния на систему.

• Blocker — это статус для проблем, которые прерывают работу приложения.
• Critical — такой баг значительно влияет на работоспособность, но не приводит к блокировке.
• Major — ошибка, которая не способствует фундаментальным изменениям, но может привести к незначительным искажениям отображения информации или выполнения некоторых функций.
• Minor — не влияет на работу системы. К этой категории можно отнести ошибки в текстовых блоках или визуальных решениях.

Status (статус)

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

• New – новый баг;
• Feedback – требуется обратная связь;
• Acknowledged – с содержанием документа ознакомились;
• Accepted – ошибка воспроизвелась и была подтверждена;
• Assigned – исправление ошибки назначено;
• Resolved – изменения были внесены;
• Closed – дефект больше не воспроизводится.

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

• Environment/platform – среда, платформа или операционная система;
• Fix version – этап разработки ПО на момент выявления бага;
• Assignee – пользователь, которому предстоит утвердить или исправить дефект;
• Lable – категория ошибки (текст, визуальные элементы и прочее).

Резюмируем

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

• убедиться в воспроизводимости ошибки;
• оценить поведение системы на разных платформах (при необходимости);
• проверить дефект на уникальность в баг-трекинговой системе.

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

Умение составлять подобные репорты является важным для тестировщика навыком, который вы можете развить, ежедневно тренируясь. А освоить азы вам помогут наши замечательные преподаватели, сотрудники международной ИТ-компании, на курсе «Основы тестирования ПО». Присоединяйтесь!

Жрец

28 октября 2010 в 15:16

Введение в отчеты об ошибках

• Чулан *

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

Сколько раз Вы писали своим пользователям: «сделайте пожалуйста скриншот сообщения об ошибке и пришлите его мне»? И ведь периодически оказывается, что ошибка возникает очень редко и вызвать ее повторное появление пользователь не в силах. Автоматическая отправка отчетов об ошибках – великолепное решение этой проблемы.

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

Как это работает

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

Как правило, для передачи отчета используется протокол HTTP (возникает меньше проблем с межсетевыми экранами), а из отправляемых сведений наибольшую ценность представляют сведения о типе ошибки, состоянии стека вызовов, дате и времени возникновения, версии программы, значениях некоторых переменных, объеме свободной памяти, версии операционной системы и используемых библиотек, иногда подробные сведения об аппаратном обеспечении.

Пример реализации на C#

Рассмотрим умышленно простой пример, на сервере будем исользовать веб-сервис на WCF, получающий сообщение об ошибке и сохраняющий его в файл, на клиентской стороне займемся отправкой сообщений при возникновении необработанных исключений (будем без лишних вопросов передавать время и текст исключения на сервер).

Для начала – серверная сторона.
Интерфейс веб-сервиса

{
public interface IErrorReporting
{
string PostErrorInfo(string info);
}
}

Реализация этого интерфейса

Namespace ErrorReportingService
{
public class ErrorReporting: IErrorReporting
{
public string PostErrorInfo(string info)
{
System.IO.File.AppendAllText(System.Web.Hosting.HostingEnvironment.ApplicationPhysicalPath + «\App_Data\reports.txt»,
«nn»+info);
return «ok»;
}
}
}

Теперь напишем обработчики исключений для вставки в тело Вашей программы и подключение их при запуске программы — класс Program может выглядеть вот так:

Static class Program
{
public static void SendDataAndShowMessage(System.Exception ex)
{
string text = DateTime.Now.ToShortDateString()+» «+
DateTime.Now.ToLongTimeString()+»n»+
ex.ToString();// тут хорошо бы его отформатировать, скажем, в XML, добавить данные о времени, дате, железе и софте…
try
{
(new ErrorReportingService.ErrorReportingClient()).PostErrorInfo(text);
MessageBox.Show(«Произошла ошибка. Информация об ошибке отправлена разработчику.nn» + text, «Ошибка программы», MessageBoxButtons.OK, MessageBoxIcon.Error);
}
catch (System.Exception ex2)
{
MessageBox.Show(«Произошла ошибка. Информацию об ошибке отправить разработчику не удалось.nn» + text, «Ошибка программы», MessageBoxButtons.OK, MessageBoxIcon.Error);
}
}
public static void AppDomain_CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
SendDataAndShowMessage((Exception)e.ExceptionObject);
Application.Exit();
}
public static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
{
SendDataAndShowMessage(e.Exception);
//на этом месте можно предложить «попытать продолжить работу» (ну-ну) или закрыть приложение
Application.Exit();
}
static void Main()
{
//Установка обработчика
AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(Program.AppDomain_CurrentDomain_UnhandledException);
Application.ThreadException +=
new System.Threading.ThreadExceptionEventHandler(Program.Application_ThreadException);

Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
}

Вот и весь код.

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

Морально-этическая сторона вопроса

С одной стороны, многих беспокоит, что в отчет об ошибке попадут их персональные данные, в связи с чем, правилом хорошего тона является демонстрация пользователю полного текста отчета об ошибке до его отправки, вывод запроса «можно ли отправить сообщение об ошибке?» и тому подобное. Увы, подавляющее большинство моих знакомых утверждают, что ни разу в жизни не нажали кнопку «да, отправить» при появлении соответствующего запроса.

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

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

Теги:
программирование, ошибки, исключения, отладка, тестирование, c#

Введение

В программировании отчёт об ошибке
(англ. 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

GNOME

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

KDE

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

Mozilla

Talkback

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

Breakpad

Ubuntu

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

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

World of Warcraft

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

Обновлено — 2017-01-25

Как отключить оповещение об ошибках? Часто во время работы на компьютере выскакивают окошки с оповещение об ошибках. Особенно это касается работы с текстовыми редакторами Microsoft Word. Они постоянно просят отправить отчет об ошибках. Толку от этих отчетов никакого, о вот такие уведомления иной раз просто выводят из себя. мы уже отключили. Теперь давайте отключим оповещение об ошибках.

В Windows XP и Windows 7 отключение оповещения об ошибках делается по разному. Но суть от этого не меняется.

В Windows XP это делается довольно таки просто

• Щелкните правой кнопкой мышки по значку Мой компьютер
  
  , и выберите в выпадающем меню пункт Свойства
  .
  

• Или откройте окно Свойства системы
  
  через Панель управления
  
  (—Пуск – Настройка – панель управления – Система
  
  );

• В открывшемся окне Свойства системы
  
  перейдите на вкладку Дополнительно
  
  и в самом низу нажмите кнопку Отчет об ошибках
  
  ;

• Во вновь открывшемся окошке установите переключатель на Отключить отчет об ошибках
  
  и сохраните настройки кнопкой ОК
  
  .

В Windows 7 отключить оповещение об ошибках можно таким образом:

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

Вот, на примере отключения оповещения об ошибках и посмотрите как это делается.

• Откройте
  Пуск — Панель управления
  
  . Наберите в поиске панели управления «Центр поддержки». Перейдите по ссылке Центр поддержки.
  

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

• Выберите Не проверять на наличие новых решений
  
  (не рекомендуется) и нажмите кнопку ОК
  
  .
  

Вот мы и отключили оповещение об ошибках.

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

Меня последнее время просто достали надоедливые , а у дочки компьютер постоянно вылетает на игре или при просмотре видео в самом интересном месте.

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

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