Жизненный цикл отчета об ошибке - ErrorsMaster.ru - большая энциклопедия ошибок и их решений

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

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

Виды багов

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

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

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

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

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

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

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) — баг был отсрочен или отклонен, но теперь исполнитель взял его в работу.

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

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

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

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

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

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

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

Источник

Программирование • 01 декабря 2022 • 5 мин чтения

Тот ещё жук: как начинающему тестировщику составить хороший баг‑репорт

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

Что такое баг
Виды багов
Приоритеты и жизненный цикл бага
Как выглядит жизненный цикл бага в теории и на примере дефекта в интернет-магазине
Что такое баг-репорт
Шаблон баг-репорта
Как правильно оформить баг-репорт
Совет эксперта

Что такое баг

Багом (от англ. bug) или дефектом часто называют ошибку в программном коде. Это не совсем ошибка, а скорее несоответствие фактического результата ожидаемому. То, как должна работать программа, описывают в требованиях к разработке. В идеальном мире она будет работать именно так, как её задумали заказчики. Но в реальности можно увидеть не то, что ожидалось.

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

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

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

Как таблица решений помогает провести все тест-кейсы и ничего не забыть

Виды багов

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

● Визуальный, относится к интерфейсу приложения. Кнопка «Купить» уехала за пределы экрана.

● Функциональный. Не сохраняются данные: пользователь нажимает кнопку «Купить», но ничего не происходит, или может применить одноразовый купон на скидку два раза.

● Дефект UX, влияет на удобство. Чтобы подтвердить мобильный телефон, пользователю приходится несколько раз покидать и возвращаться в мобильное приложение.

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

● Баг производительности. Приложение занимает в памяти смартфона слишком много места, работает медленно и быстро тратит заряд батареи.

● Баг требований, или логический баг. До начала разработки приложения или отдельной «фичи» в требованиях что-то не учли. Например, забыли добавить всплывающее оповещение, что при включённом VPN приложение может работать с ошибками. Программист запрограммировал так, как было в требованиях (или как он их понял). В итоге, приложение работает, как описано в требованиях, но не так, как нужно бизнесу.

Вид бага — это одна из ключевых его характеристик. Когда понятно, к чему относится дефект, с ним проще разобраться. На курсе «Инженер по тестированию» студенты учатся определять виды багов на примере реальных проектов.

Начните карьеру в IT с профессии тестировщика

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

Приоритеты и жизненный цикл бага

Чем отличается приоритет от серьёзности и как их используют

У бага есть два важных атрибута — приоритет и серьёзность.

Серьёзность показывает, насколько баг влияет на возможность работать в программе. Обычно выделяют 5 уровней серьёзности бага. Самый опасный — блокирующий баг. Например, мобильное приложение перестало загружаться, и пользователь видит пустой экран. Самый безвредный — тривиальный баг. Он не влияет на работу приложения, а многие пользователи его даже не заметят. Это может быть, например, опечатка в разделе меню, куда редко заходят.

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

● высокий — исправить в первую очередь;
● средний — исправить, когда разобрались с первой категорией багов;
● низкий — исправить, когда разобрались с багами других приоритетов.

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

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

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

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

Как выглядит жизненный цикл бага в теории и на примере дефекта в интернет-магазине

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

В результате локализации может быть два вывода:

● Это не баг, или проблема не на стороне разработчиков. Например, внутренний пользователь чего-то не знает по системе и его нужно обучить. Или у пользователя приложения застряли деньги, а проблема на стороне банка.

● Это баг программы, и его нужно завести в баг-трекинговой системе.

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

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

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

● Тестировщик описал, в чём проблема, и присвоил задаче статус — новый баг.

● Задачу в работу берёт аналитик, чтобы уточнить, какие условия закладывали в ТЗ для продукта. Баг получает новый статус — анализ. На проекте может не быть аналитика или задачу не нужно уточнять — тогда её сразу берёт в работу разработчик.

● Аналитик добавил уточнения по задаче и передал разработчику. Новый статус — в разработке.

● Разработчик отдаёт задачу аналитику, если хочет что-то уточнить, а если нет, то передает тестировщику.

● Тестировщик проводит ретест — проверяет, исправили баг или нет. Если проблему решили, он закрывает задачу, если нет — возвращает задачу разработчику. Она снова получит статус «В разработке».

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

● Готово. Теперь пользователь видит только актуальные товары.

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

Пример жизненного цикла бага на реальном проекте

Что такое баг‑репорт

В тестировании баг-репорт — это отчёт об ошибке, который заводится в баг-трекинговой системе.

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

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

Примеры метрик:

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

Опытные тестировщики советуют искать золотую середину:

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

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

● Если в Jira уже есть задача, внутри которой нашли баг — не оформлять его отдельно, а написать в комментарии к этой задаче. Допустим, в приложение интернет-магазина решили добавить новую функцию к Чёрной пятнице — купон на скидку. Когда пользователь его применит, все товары в корзине подешевеют на 20%. Купон должен работать только когда в корзине больше одного товара. Программисты закончили разработку и передали в тестирование. Тестировщик нашёл баг: если удалить из корзины все товары, кроме одного, скидка так и останется — 20%. Такой баг оформляют в виде комментария.

Шаблон баг‑репорта

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

Как правильно оформить баг‑репорт

Хороший баг-репорт приходит с опытом. Вот на что нужно обратить внимание джуну:

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

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

● Вложения. Если баг визуальный или UX (поехала вёрстка, не работает кнопка), то без скриншота или скринкаста не разобраться — важно показать, что видит пользователь.

● Шаги воспроизведения. Бывает, что джун начинает издалека: «Включить компьютер». Или пишет слишком абстрактно: «Заходишь на страницу, товар не отображается». Важно искать золотую середину: описывать те шаги, которые относятся к багу, и так, чтобы другим коллегам было понятно. Например: нажать кнопку «Начать», сканировать любой товар из задачи.

● Взгляд на проблему. Тестировщику важно хотя бы пытаться смотреть на проблему с точки зрения бизнеса. Например, текст не помещается в поле, а как этот баг влияет на бизнес? Ответ на вопрос поможет в будущем определять серьёзность и приоритет бага.

● Фактический и ожидаемый результат. То, как тестировщик заполнит эти поля, влияет на его коммуникацию по задаче с разработчиком. Если проблема описана непонятно, разработчик не сможет сразу за неё взяться, а будет уточнять детали у тестировщика. Например, придёт с вопросами, если увидит в документе, что фактический результат — кнопка не работает, а ожидаемый результат — кнопка работает.

Как не стоит писать баг-репорты. Опытный тестировщик в ответ на такой документ скажет, что баг-репорт описан непонятно: что значит «нельзя сканировать»? В результатах нужно описывать, что происходит, а не то, чего не происходит. Не хватает информации о том, какие материалы нужно приложить к такому багу, скриншоты или скринкасты

Вот как могли бы оформить этот баг более опытные джуны и продвинутые тестировщики.

Баг-репорт от опытного джуна или ленивого мидла

Заголовок: [Инвентаризация] В начатой задаче при попытке сканирования товаров визуально ничего не происходит

Предусловия: Приложение Инвентаризация запущено и активно, открыта невыполненная задача для инвентаризации

Шаги:

1. Нажать кнопку «Начать».

2. Сканировать товар, присутствующий в задаче и еще не отсканированный.

Фактический результат: при попытке сканирования товара визуально ничего не происходит. В логах ошибка <Error…> (приложен лог с ошибкой).

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

Окружение: Apple iPod touch 32 Gb.

Приоритет: критичный.

Баг-репорт от мидла или сеньора

Заголовок: [Инвентаризация] В начатой задаче сканирование товара не записывается в задачу, в логах ошибка <Error…>.

Предусловия: Приложение Инвентаризация запущено и активно, открыта невыполненная задача для инвентаризации.

Шаги:

1. Нажать кнопку «Начать».

2. Сканировать любой товар из задачи.

Фактический результат: при попытке сканирования товара сканер пищит (как и должен), но в задачу сканирование не записывается. В системных логах приложения ошибка <Error…> (приложен кусок лога с ошибкой). В серверных логах ошибка <Error…> (приложен кусок лога с ошибкой).

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

Доп.информация: если отправить запрос о сканировании не с устройства, а через эмулятор, то ошибок не возникает, возвращается корректный ответ (приложены запрос и ответ и логи с эмулятора).
Окружение: Apple iPod touch 32 Gb, версия приложения 1.2.21.3, тестовый стенд INTG.

Приоритет: критичный.

В примерах нет ошибок, но видно, как можно подойти к задаче в зависимости от опыта.

Совет эксперта

Ольга Ермолаева

Самый полезный для тестировщика вопрос — «Что если?». На нём завязана вся локализация. Выдвигайте больше гипотез и проверяйте их с разных сторон.

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

Руководитель направления QA

Тестирование мобильных приложений: инструкция для начинающих

Кто такой инженер по тестированию и как им стать, чтобы начать IT-карьеру

Источник

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

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

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

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

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

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

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

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

Указывайте:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jira.
YouTrack.
Redmine.

Форма создания отчета об ошибке в системе управления проектами Jira

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

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

GitHub.
GitLab.
Bitbucket.

Форма создания отчета об ошибке в системе управления исходным кодом GitHub

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

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

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

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

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

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

Главное

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

Примечание: ниже перевод статьи «Reporting bugs — a how-to guide», в которой приводится ряд нехитрых действий, которые могут помочь как пользователю, так и разработчику справиться с ошибками на сайте или в веб-приложении. В свете постоянного появления в Рунете проектов со статусом «бета», статья может быть особенно полезна.

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

«Оно просто не работает»

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

Хороший отчет

Хороший отчет об ошибке должен сообщить разработчику три важные вещи:

какое поведение ожидалось;
что же на самом деле произошло;
что вы при этом сделали или делали.

Какое поведение ожидалось

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

Второй тип ошибок заключается в том, что приложение действует не так, как вы ожидаете. Это может происходит в том случае, если разработчик неверно воплотил часть технического задания, но, может быть, приложение просто не может работать так, как вам хочется. В таком случае разработчик полагает, то оно работает так, как задумывалось, и оно действительно «работает», хотя, может быть, действительно неправильно. Если в своем сообщении об ошибке вы скажите, что эта возможность не работает, разработчик может потратить массу времени, пытаясь обнаружить какую-либо ошибку в этой части приложения, хотя ему всего лишь нужно понять, что оно не работает так, как вы ожидаете. Если в своем сообщении вы напишите о том, что ожидаете от приложения, то разработчику будет проще понять: «Хмм, ему хочется, чтобы происходило «А», но на самом деле происходит «Б» — и правильное решение будет принято значительно быстрее.

Что же на самом деле произошло

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

«Форма не отправляется — я остаюсь на той же странице, где был».

Но, возможно, в результате отправки формы появляется пустая страница:

«После отправки формы загружается пустая страница».

Если на экране появилось сообщение об ошибке, включите его в ваше сообщение. Просто скопируйте и вставьте его.

Если вы используете Internet Explorer, тогда ваш браузер может не показывать сообщения об ошибках, которые выдает сервер, а просто общую страницу с ошибкой. Убедитесь, что IE показывает именно то сообщение об ошибке, которое пришло от сервера. Для этого зайдите в Tools > Internet Options > Advanced, затем прокрутите вниз и выключите опцию Show friendly http error messages. Для пользователей IE 7 нужно зайти в Сервис > Свойства Обозревателя > Дополнительно и включить опцию Выводить подробные сообщения об ошибках http.

Что вы при этом делали

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

Последовательность действий

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

Любые введенные данные

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

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

Браузер и операционная система

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

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

какое поведение ожидалось;
что же на самом деле произошло; и
что вы при этом сделали или делали.

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

Спасибо всем, кто читал и читает мои переводы. Буду признателен за любые комментарии и дополнения. Удачи в устранении ошибок!

Web Optimizator: проверка скорости загрузки сайтов

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

Баг-репорт

22 сентября 202130.2к.4 минОбновлено 17 января 2023

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

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

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

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) — баг был отсрочен или отклонен, но теперь исполнитель взял его в работу.

(рейтинг: 4.2, голосов: 5)

С одной стороны его задача — быть простым и понятным, а с другой стороны — быть эффективным.

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

Шаблон отчета о дефекте, который отвечает запросам тестировщика и программиста, выглядит следующим образом:
1. Заголовок ошибки
2. Описание ошибки
3. Начальные условия
4. Шаги воспроизведения
5. Ожидаемый результат
6. Фактический результат
7. Вложения

В зависимости от ситуации или компании, в которой вы работаете, шаблон может изменяться и отклоняться в разные стороны. Например, в некоторых случаях «Начальные условия» не пишут. Если дефект связан с графикой, то рекомендуется добавить скриншот. Также вводятся дополнительные атрибуты для указания Платформы или Барузера и т.д.

Теперь рассмотрим структуру шаблона подробно на конкретном примере. Допустим, мы тестируем сайт. На сайт есть раздел Контакты. В этом разделе находится Форма обратной связи.

^{Баг на сайте}

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

Данный баг мы и будем описывать по шаблону.

Заголовок ошибки (Title)

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

Наиболее эффективным описанием считается описание, которое отвечает на три вопроса:
— Что произошло?
— Где появилась ошибка?
— Когда или при каких условиях найден дефект?

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

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

Пример плохого заголовка: Ошибка, когда нажимаю «Отправить сообщение».
Пример хорошего заголовка: При нажатии на кнопку «Отправить сообщение» в форме обратной связи сообщение не отправляется.

Описание ошибки (Summary)

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

Правильное и качественное описание также позволяет сразу понять проблему и приступить к ее исправлению.

Пример плохого описания: Жму «Отправить сообщение», а в ответ тишина.
Пример хорошего описания: При нажатии на кнопку «Отправить сообщение» в заполненной форме обратной связи ничего не происходит. Аналогичное поведение, если форма не заполнена.

Начальные условия (Precondition)

В случае, если есть специфичные действия или шаги воспроизведения достаточно объемные, то указываются начальные условия. Например:
1. Быть авторизованным в системе.
2. Находиться на главной странице.

Пример плохих начальных условий: Находиться на сайте.
Пример хороших начальных условий:
1. Страница «Контакты»,
2. Платформа и устройство не имеют значения.

Шаги воспроизведения (Steps To Reproduce)

Шаги, при которых повторяется найденная ошибка. Например:
1. Нажать на кнопку “Войти”
2. Ввести “Имя пользователя” и “Пароль”
3. Нажать на кнопку “Ок”

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

Пример плохих шагов: 1. Зайти на сайт, 2. Зайти на страницу обратной связи, 3. Поставить курсор в поле Имя, 4. Ввести имя, 5. Поставить курсор в поле e-mail, 6. Ввести действующий e-mail, 7. Навести курсор на Отправить сообщение, 8. Щелкнуть по Отправить сообщение.
Пример хороших шагов:
1. Заполнить поля формы обратной связи,
2. Нажать на копку «Отправить сообщение»

Ожидаемый результат (Expected Result)

Результат, который должен быть при выполнении шагов. В идеале, его можно найти в ТЗ (техническом задании). На практике, ТЗ бывает не всегда и ожидаемый результат определяется либо здравым смыслом, либо по аналогии.

Пример плохого ожидаемого результата: Что-то должно произойти.
Пример хорошего ожидаемого результата: Сообщение отправляется либо система сообщает о невозможности его отправки.

Фактический результат (Actual Result)

Указывается результат, который получил тестировщик при выполнении описанных шагов. Также может отвечать на три вопроса “Что? Где? Когда?”.

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

Вложения (Attachments)

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

________________________________
При соблюдении правил оформления баг-репортов, ваша работа станет более эффективной.
________________________________

В следующей статье мы разберем такие атрибуты баг-репорта, как Приоритет и Серьезность дефекта.

На чтение 11 мин Просмотров 1.2к. Опубликовано 16.10.2021

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

Содержание

Что такое ошибка PHP?
Какие бывают типы ошибок в PHP?
Ошибки синтаксического анализа или синтаксиса
Фатальные ошибки
Предупреждение об ошибках
Уведомление об ошибках
Как включить отчеты об ошибках в PHP
Сколько уровней ошибок доступно в PHP?
Ошибки отображения PHP
Что такое предупреждение PHP?
Как помогают отчеты о сбоях
Завершение отчета об ошибках PHP

Что такое ошибка PHP?

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

die("something bad happened!");

Это завершит программу PHP и сообщит об ошибке. Когда программа завершается, это то, что мы называем фатальной ошибкой. Позже вы увидите, что мы можем контролировать, как именно обрабатывается ошибка, в случае, если нам нужно вызвать некоторую логику очистки или перенаправить сообщение об ошибке. Вы также можете смоделировать это с помощью trigger_error()функции:

<?php

trigger_error("something happened"); //error level is E_USER_NOTICE

//You can control error level
trigger_error("something bad happened", E_USER_ERROR);
?>

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

На самом деле в PHP есть две формы ошибок: стандартные обычные ошибки и исключения.

Исключения были введены в PHP 5. Они дают вам легче семантику, как try, throwи catch. Исключение легко создать. Это следует из большого успеха языков со статической типизацией, таких как C # и Java.

throw new Exception("Yo, something exceptional happened);

Перехват и выдача исключений, как правило, более упрощены, чем более традиционная обработка ошибок PHP. Вы также можете иметь более локализованную обработку ошибок, а не только глобальную обработку ошибок с помощью set_error_handler (). Вы можете окружить конкретную логику блоками try / catch, которые заботятся только о конкретных исключениях:

<?php try {
    doSystemLogic();
} catch (SystemException $e) {
    echo 'Caught system exception ';
}

try {
    doUserLogic();
} catch (Exception $e) {
    echo 'Caught misc exception ';
}
?>

Какие бывают типы ошибок в PHP?

Ошибка PHP — это не одно и то же, но бывает четырех разных типов:

синтаксические или синтаксические ошибки
фатальные ошибки
предупреждения об ошибках
замечать ошибки

Ошибки синтаксического анализа или синтаксиса

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

<?php
$age = 25;

if ($age >= 18 {
    echo 'Of Age';
} else {
    echo 'Minor';
}
?>

Запустив приведенный выше сценарий, я получаю следующую ошибку:

Parse error: syntax error, unexpected '{' in <path> on line 4

С помощью сообщения об ошибке легко увидеть, что в операторе if отсутствует закрывающая скобка. Давайте исправим это:

<?php
    $age = 25;

    if ($age >= 18) {
        echo 'Of Age';
    } else {
        echo 'Minor';
    }
?>

Фатальные ошибки

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

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

Рассмотрим следующий сценарий:

<?php
    function add($a, $b)
    {
        return $a + $b;
    }

    echo '2 + 2 is ' . sum(2, 2);
?>

Как видите, сценарий определяет функцию с именем add, а затем пытается вызвать ее с неправильным именем. Эта ситуация приводит к фатальной ошибке:

Fatal error: Uncaught Error: Call to undefined function sum() in F:xampphtdocstest.php:7 Stack trace: #0 {main} thrown in <path> on line 7

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

echo '2 + 2 is ' . add(2, 2);

Предупреждение об ошибках

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

Взгляните на следующий код:

<?php
    $components = parse_url();
    var_dump($components);
?>

После выполнения приведенного выше кода мы получаем следующее предупреждение:

Warning: parse_url() expects at least 1 parameter, 0 given in <path> on line 2

Предупреждение вызывает тот факт, что мы не предоставили параметр функции parse_url. Давайте исправим это:

<?php
    $components = parse_url('https://example.com');
    var_dump($components);
?>

Это устраняет предупреждение:

array(2) { ["scheme"]=> string(5) "https" ["host"]=> string(11) "example.com" }

Уведомление об ошибках

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

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

<?php
    $numbers = "1,2,5,6";
    $parts = explode(",", $integers);

    echo 'The first number is ' . $parts[0];
?>

Как видите, сценарий определяет переменную $ numbers, а затем пытается передать переменную с именем $ inteers в функцию explode.

Неопределенные переменные действительно являются одной из основных причин уведомлений в PHP. Чтобы ошибка исчезла, достаточно изменить переменную $ inteers на $ numbers.

Как включить отчеты об ошибках в PHP

Включить отчеты об ошибках в PHP очень просто. Вы просто вызываете функцию в своем скрипте:

<?php
error_reporting(E_ALL);

//You can also report all errors by using -1
error_reporting(-1);

//If you are feeling old school
ini_set('error_reporting', E_ALL);
?>

Здесь сказано: «Пожалуйста, сообщайте об ошибках всех уровней». Мы рассмотрим, какие уровни есть позже, но считаем это категорией ошибок. По сути, он говорит: «Сообщайте обо всех категориях ошибок». Вы можете отключить отчет об ошибках, установив 0:

<?php
error_reporting(0);
?>

Параметр метода в error_reporting()действительности является битовой маской. Вы можете указать в нем различные комбинации уровней ошибок, используя эту маску, как видите:

<?php
error_reporting(E_ERROR | E_WARNING | E_PARSE);
?>

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

<?php
// Report all errors except E_NOTICE
error_reporting(E_ALL & ~E_NOTICE);
?>

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

Сколько уровней ошибок доступно в PHP?

В PHP 5 целых 16 уровней ошибок. Эти ошибки представляют категорию, а иногда и серьезность ошибки в PHP. Их много, но многочисленные категории позволяют легко определить, где отлаживать ошибку, исходя только из ее уровня. Итак, если вы хотите сделать что-то конкретное только для ошибок пользователя, например, проверку ввода, вы можете определить обработчик условий для всего, что начинается с E_USER. Если вы хотите убедиться, что вы закрыли ресурс, вы можете сделать это, указав на ошибки, оканчивающиеся на _ERROR.

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

Я хочу остановиться на нескольких популярных из них.

Во-первых, у нас есть общие ошибки:

E_ERROR (значение 1): это типичная фатальная ошибка. Если вы видите этого плохого парня, ваше приложение готово. Перезагрузите и попробуйте еще раз.
E_WARNING (2): это ошибки, которые не приводят к сбою вашего приложения. Похоже, что большинство ошибок находятся на этом уровне.

Далее у нас есть пользовательские ошибки:

E_USER_ERROR (256): созданная пользователем версия указанной выше фатальной ошибки. Это часто создается с помощью trigger_error ().
E_USER_NOTICE (1024): созданная пользователем версия информационного события. Обычно это не оказывает неблагоприятного воздействия на приложение, как и log.info ().

Последняя категория, на которую следует обратить внимание, — это ошибки жизненного цикла приложения, обычно с «core» или «compile» в названии:

EE_CORE_ERROR (16): Подобно фатальным ошибкам выше, эта ошибка может возникнуть только при запуске приложения PHP.
EE_COMPILE_WARNING (128): нефатальная ошибка, которая возникает только тогда, когда скрипт PHP не компилируется.

Есть еще несколько ошибок. Вы можете найти их полный список здесь.

Ошибки отображения PHP

Отображение сообщений об ошибках в PHP часто сбивает с толку. Просто погуглите «Отображение сообщения об ошибке PHP» и посмотрите. Почему так?

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

<?php
 ini_set('display_errors', 1);
 ini_set('display_startup_errors', 1);
?>

Их включение гарантирует, что они будут отображаться в теле веб-ответа пользователю. Обычно рекомендуется отключать их в среде, не связанной с разработкой. Целочисленный параметр метода также является битовой маской, как в error_reporting(). Здесь также применяются те же правила и параметры для этого параметра.

Что такое предупреждение PHP?

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

Вот пример:

<?php
 $x = 1;
 trigger_error("user warning!", E_USER_WARNING);
 $x = 3;
 echo "$x is  ${$x}";
?>

Вы все равно будете видеть, $x is 3несмотря на срабатывание предупреждения. Это может быть полезно, если вы хотите собрать список ошибок проверки. Я лично предпочитаю использовать исключения в наши дни, но ваш опыт может отличаться.

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

Как помогают отчеты о сбоях

PHP упрощает настройку внешних инструментов отчетов об ошибках, подобных тем, которые предлагает Raygun. Он предоставляет несколько различных ловушек для своей среды выполнения, чтобы обрабатывать ошибки и отправлять их по сети. См. Этот пример, взятый со страницы PHP Raygun :

namespace
{
    // paste your 'requires' statement

    $client = new Raygun4phpRaygunClient("apikey for your application");

    function error_handler($errno, $errstr, $errfile, $errline ) {
        global $client;
        $client->SendError($errno, $errstr, $errfile, $errline);
    }

    function exception_handler($exception)
    {
        global $client;
        $client->SendException($exception);
    }

    set_exception_handler('exception_handler');
    set_error_handler("error_handler");
}

Сначала мы объявляем клиента, используя ключ API для безопасности:

    $client = new Raygun4phpRaygunClient("apikey for your application");

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

 function error_handler($errno, $errstr, $errfile, $errline ) {
        global $client;
        $client->SendError($errno, $errstr, $errfile, $errline);
    }

    function exception_handler($exception)
    {
        global $client;
        $client->SendException($exception);
    }

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

Наконец, мы подключаем их к среде выполнения PHP, глобально обрабатывая как традиционные ошибки, так и новые исключения:

set_exception_handler('exception_handler');
set_error_handler("error_handler");

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

Завершение отчета об ошибках PHP

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

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

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

Баг-репорт включает обязательные и необязательные элементы.

Обязательные поля:

ID — идентификационный номер баг-репорта, должен быть уникальным. Помогает быстро найти нужный баг-репорт.
Заголовок — передает суть ошибки; помогает быстро понять, в чем дело.
Шаги воспроизведения — пошаговая инструкция о том, как воспроизвести ошибку.
Результаты — описание фактического результата и ожидаемого результата.
Окружение — операционная система, браузер, устройство (в случае мобильного приложения), версия приложения.
Приоритет — показывает степень критичность ошибки и срочность ее исправления.

Необязательные поля:

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

Пример правильно составленного баг-репорта:

Теперь давайте поговорим о каждом пункте немного детальнее.

Заголовок баг-репорта

Задача заголовка — в достаточной мере описать суть проблемы. Грамотно написанный заголовок помогает коллегами сразу понять суть, не тратя время на прочтение всего баг-репорта целиком. Заголовок должен отвечать на три вопроса: «Что? Где? Когда?», при этом не должен быть слишком длинным. Заголовок должен отражать реальный результат.

Примеры удачных заголовков:

Клик по слову «Регистрация» на странице подписки приводит к ошибке 400.
При переходе по ссылке «Заказ» на главной странице экрана открывается страница Контакты вместо страницы Мои заказы.

Шаги

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

Приоритет и серьезность

Приоритет (priority) отражает степень важности проблемы и срочность выполнения задачи, включает 3 уровня:

Высокий (high) — необходимо исправить в первую очередь, так как с данной ошибкой продукт не выполняет свой бизнес-задачи: например, не работает кнопка заказа в интернет-магазине.
Средний (medium) — ошибка менее критичная, пользователь может достигнуть цели, однако ПО работает не так, как от него ожидается. Например, в корзине интернет-магазина не отображается блок сопутствующих товаров.
Низкий (low) — не мешает пользователю достигнуть цели, можно починить после критических ошибок. Например, опечатки в тексте.

Серьезность (severity) показывает степень влияния на работу системы.

Блокирующий (blocker) — программа не работает. Например, сайт выдает ошибку 500.
Критический (critical) — не работает важная часть системы, приложение не выполняет своей функции. Например, невозможно добавить товар в корзину незарегистрированному пользователю.
Серьезный (major) — приложение работает, функциональность не пострадала, однако работает некорректно. Например, не позволяет пользователю выбрать марку авто в приложении по заказу такси.
Незначительный (minor) — приложение работает правильно, но вызывает какие-либо неудобства. Сюда можно отнести ошибки навигации и другие ошибки UX-характера.
Тривиальный (trivial) — ошибка, которая не оказывает никакого влияния на работу приложения. Например, опечатки в тексте.

Окружение

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

Вложения (вспомогательные материалы)

Помогают дополнить информацию о проблеме, визуализируют ошибку. К баг-репорту можно прикрепить:

Скриншоты и скринкасты
Логи, дампы
Переписки
Документацию

Пример скриншота ошибки с указанием конкретного места ошибки и поясняющим комментарием

Не забывайте давать вложениям понятные названия. Можно использовать маску {ID баг-репорта}_{суть ошибки}.

Чтобы прокачаться в тестировании и научиться находить самые каверзные баги, приходите учиться в OTUS.

Отчеты об ошибках (на англ. «Bug
Report»)– это основной
материальный продукт тестирования,
надежная техническая документация,
которая описывает вид ошибки в тестируемой
системе.

Для упрощения организации взаимодействия
групп и общего централизованного
хранения отчетов об ошибках следует
использовать системы отслеживания
ошибок (на англ. «bug tracking»).
Это позволяет иметь единое хранилище
ошибок, отслеживать их повторное
появление, контролировать скорость и
эффективность исправления ошибок,
видеть наиболее нестабильные компоненты
системы, а также поддерживать связь
между группой разработчиков и группой
тестирования (уведомления об изменениях
по почте и т.п.). Чем больше проект, тем
сильнее потребность в централизованном
хранилище дефектов.

Пример одной из свободных систем
отслеживания ошибок с веб-интерфейсом.
является Bugzilla (разработка
компании Mozilla). Данная
система очень проста и популярна в
использовании [10].

Подобная
система обеспечивает следующие функции:

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

Существуют основные виды продвижения
ошибки (на англ. «bug») по
системе (на англ. «Defect
flow»)(см. рисунок 6).

Рисунок 6 — Defect
flow

При поступление ошибки в систему, из
любого источника (заказчик, разработчик,
тестировщик), баг принимает статус new
(пер. с англ. «новый»). Затем рассматривается
программистом его описание и: или ошибка
решается (на англ. «resolve»)
или ей ставится статус duplicated
(пер. с англ. «дубль»), что означает, что
данная ошибка уже была и на данном этапе
решается, или же ей ставится статус
invalid (пер. с англ.
«необоснованный»)- неверное описание,
такой ошибки не существует. После всего
этого командой тестировщиков данная
ошибка перепроверяется и закрывается
(на англ. «verify») в случае,
если она больше не повторяется, или
переоткрывается (на англ. «reopen»), если
изменения все равно приводят к ошибке.

В отчете об ошибки необходимо соблюдать
некоторые правила:

1. В отчете должна быть с самого начала
понятна суть ошибки.

2.Должны быть четко понятны шаги
воспроизведения.

3.Должен быть известен альтернативный
правильный вариант поведения.

4. Указана версия и приоритет данной
ошибки.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

Автор: Ольга Рябова

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

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

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

Теперь надо записать свои действия. Записывать надо коротко, но ясно и понятно. Найти золотую середину. Если написать мемуары, то программист их не будет читать или подумает, что ошибка очень трудная и отложит на потом, а сверхкороткий отчёт никто не поймёт. Как следствие исправление ошибки (бага) повиснет в воздухе или отправят обратно вам с пометкой «не воспроизводится» или попросят уточнений, тем самым потратив попросту и Ваше и своё время. Также не стоит в один отчёт вписывать более одной ошибки. Мотив всё тот же.

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

Если возможно, попробуйте разные варианты чтобы выразить точно проблему.

Желательно также избегать жаргона или выражений которые могут быть трудны для понимания другими.

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

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

Описание ошибки

Теперь перейдём к описанию ошибки. В зависимости от того какая в компании багтрекинговая система (система учёта ошибок), будут и разные поля для ввода.

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

Приоритет (насколько серьёзная ошибка и какой скорости выполнения требует. Быстро надо исправить или можно подождать)

Назначить (кто будет заниматься ошибкой)

Класс (это какой вид ошибки- серьёзная, незначительная, опечатка…)

Заголовок ошибки

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

Описание проблемы

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

Пример: Открыл www.aaa.ru —> ввел в поле bbb слово ccc —>нажал кнопку ddd —> система выдала ошибку: ddd

Пример из жизни

Заголовок: Проблема с меню «забыли пароль»

Описание проблемы: Зайти на страницу авторизации —> нажать кнопку «Забыли пароль?» —> в поле «Лицевой счёт» вписать 2389 —> в поле «e-mail» вписать
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
—> система пишет: «Ошибка отправки сообщения. (#1)»

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

Приложения (Attachments)

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

ссылок
скриншотов
видео записи

Ссылка

Ну тут всё понятно. Выскочила ошибка — берётся ссылка на эту страницу и вставляется отчёт. Желательно ещё и со скриншотом. (при условии, что тестируется веб-приложение — прим. редактора)

Скриншоты

Очень полезная вещь для визуализации проблемы. Делаете скриншот проблемной зоны. (Самое простое — это на клавиатуре найти кнопку Print Screen, нажать её потом в открыть программку Paint (если мы находимся в операционной системе семейства Windows — прим. редактора), которая автоматически устанавливается в Windows и в ней нажать Ctrl-V, потом вырезать ненужное, сохранить (лучше в формате JPG))

Хотя, есть и более профессиональные программки, которые более приспособлены к такого рода действиям и имеют много очень полезных функций, например SnagIt, HyperSnap, HardCopy, RoboScreenCapture, FullShot 9, HyperSnap-DX 5, TNT 2. Скриншот нужно прикрепить к отчёту об ошибке.

Видео ролики

Если ошибку тяжело описать, то это самый подходящий метод. Программы: SnagIt, CamStudio

Источник

Схема
Cтатусы багов
Другие статусы (этапы цикла)
Действия в багтрекере
Указания
Ошибка, дефект, отказ
Инвалиды и дубликаты
Еще нюансы
Жизненный цикл дефекта в Bugzilla (схемы)

В процессе разработки всегда возникают дефекты (баги), которые тестировщики стараются найти, а разработчики пофиксить, то есть устранить. В баг-трекинговой системе фиксируется статус дефекта, и действия участников команды. Все происходит упорядоченно (поэтапно), нередко бывают повторные этапы. Баг проходит от «рождения» (Новый) до «смерти» (Закрыт). Этот процесс называется жизненным циклом дефекта.

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

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

Понятия баг и дефект, а также жизненный цикл дефекта и жизненный цикл бага в данной статье взаимозаменяемы.

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

Цикл обработки дефекта (бага), с присвоением ему различных статусов после выполнения различных действий — начиная с регистрации нового бага в системе и до закрытия после устранения.

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

Общая схема жизненного цикла дефекта (например, в Jira):

Жизненный цикл дефекта

Список статусов бага

Новый

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

Назначен

Когда новый дефект подтвержден и принят в обработку, получает статус Назначен (Assigned). Как правило назначается ответственный за устранение этого бага (поэтому статус еще может называться «Назначен НА кого-то»).

Открыт

Open-статус означает, что дефект приняли разработчики и начали процесс устранения.

На этом этапе возможен переход в статус «Отклонен» или «Отложен», то есть разработчик может «не принять» этот дефект — отклонить или отложить.

Устранен

Или Решен/Исправлен (Fixed, Resolved). Разработчики поработали с кодом, внесли нужные правки, пометили статусом «Исправлен», и возвращают тестировщикам для повторной проверки.

Ожидает повторного тестирования

В статусе Pending Retest дефект ожидает, когда тестировщики повторно проверят его, убедившись что все ОК, код теперь исправлен.

Повторно тестируется

Retest: тестировщик еще раз проверяет этот дефект, и убедившись что он устранен разработчиками, верифицирует это и закрывает дефект, а в противном случае переоткрывает.

Повторно открыт

Если повторное тестирование не смогло устранить баг, обнаруживается снова, ему присваивается статус Reopen. Баг открывается опять и еще раз проходит по циклу.

Проверен

Тестировщик еще раз проверяет (верифицирует) баг, повторно исправленный разработчиком, и если теперь он не проявляется, присваивается статус Verified.

Закрыт

Разработчики и тестировщики общими усилиями нашли и устранили дефект, он больше не появляется, и можно присвоить статус Closed.

Другие статусы в баг-трекерах

Отклонен

Разработчик отклонил этот дефект, присвоив статус Rejected, потому что дефект или является дубликатом (уже внесен в систему кем-то из коллег), дефект не воспроизводится, или вообще не считается дефектом.

Отложен

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

Дубликат

Этот дефект уже зарегистрирован другим тестировщиком, или суть дефекта та же, тогда присваивается статус Duplicate.

Не дефект

Баг может и есть, но ни на что не влияет, ни в чем не ухудшает функциональность и юзабельность — отмечается статусом Not a Defect.

Не воспроизводится

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

Невозможно устранить

Бывают ситуации, когда баг устранить невозможно по какой-то причине: недостатки технологии, стоимость, нехватка времени, недостаточная квалификация или просто лень. Он переводится в статус Can’t be fixed.

Требует уточнения

Статус Need more information по сути близок к «Не воспроизводится» выше, но с нюансами. Такой статус присваивается, когда разработчики не сумели воспроизвести баг по шагам, предоставленным тестировщиком, или если тестировщик составил не очень подробный репорт.

Подробнее о действиях в баг-трекере

В словесной форме (и в других баг-трекерах кроме Jira) это выглядит примерно так:

Дефект обнаруживается тестировщиком.
Тестировщик присваивает ему статус «Новый».
О новом дефекте тотчас узнает проджект-менеджер, который исследует ситуацию — является ли дефект действительно дефектом, стОит ли устранять сейчас и пр.
Если нет, дефекту присваивается статус «Отклонен».
Если дефект действительно существует, и стОит внимания сейчас, проджект-менеджер проверяет, является ли дефект дубликатом и если да, обозначается как дубликат.
Если не дубликат, дефект передается в работу разработчику, который начинает действия по устранению проблемы, с присвоением статуса «In Progress», и по завершению — «Исправлен».
Далее дефект возвращается в зону ответственности тестировщика под статусом «Повторно тестируется». Тестировщик снова запускает тест-кейсы, и если дефект опять проявляется, повторно открывает его и возвращает разработчику.
А если все хорошо, дефект закрывается, с присвоением соответствующего статуса «Закрыт».

Указания по эффективности жизненного цикла

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

Ошибка, дефект (баг) и отказ в контексте жизненного цикла дефекта

Ошибка (error) — например когда разработчик видит отличие между тем как приложение себя ведет и тем как должно себя вести, в процессе разработки
Дефект (баг) — случается когда тестировщик обнаруживает несоответствие между реальным и предполагаемым поведением приложения в процессе тестирования
Отказ (failure) — несоответствие реального и предполагаемого поведения обнаруживается уже в процессе пользования приложением конечным пользователем, клиентом, или тестировщиком на этапе приемочного тестирования.

Инвалиды и дубликаты

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

Что еще нужно помнить о жизненном цикле багов

Дефекты могут возникать на любом этапе разработки и тестирования
Чем раньше дефект обнаружен и устранен, тем лучше (выгоднее для компании)
В идеале — на том же этапе, когда дефект найден (тогда «стоимость дефекта» минимальная)
Статическое тестирование (анализ кода без выполнения), проводимое на раннем этапе разработки, выгоднее чем дебаг на позднем

Жизненный цикл дефекта в Bugzilla (в принципе релевантно для любого багтрекера)

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

Сложнее, но с объяснениями:

***

Источник

Раздел: Тестирование > Тестовые Артефакты > Баг Репорт > Жизненный цикл бага

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

Теперь переходим к описанию данной схемы.

Допустим вы нашли баг и зарегистрировали его в баг трекинг системе. Согласно нашей блок-схеме он получит статус “Новый”. Тестировщик, ответственный за валидацию новых баг репортов, или координатор проекта (в зависимости от распределения ролей в вашей команде) может перевести его в один из следующих статусов:

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

Рассмотрим теперь по порядку каждый из вариантов.

Отклонен. В этом случае вы можете либо поспорить о судьбе вашего багрепорта, изменив статус на “Переоткрыт” либо закрыть его — статус “Закрыт”
Отсрочен. Баг репорт в статусе “Отсрочен” можно перевести в статус “Открыт”, когда потребуется исправление либо в статус “Закрыт”, если уже не потребуется.
Открыт. Именно в таком состоянии разработчик получает баг репорт для исправления. Он может отклонить (дальнейшие действия смотрите в пункте 1) или исправить баг. Баг репорт в статусе “Исправлен” переводится на тестировщика для проверки. В случае если проблема все еще воспроизводится, выставляется статус “Переоткрыт” и баг репорт направляется назад на доработку к разработчику. Если же исправление было успешным, то баг репорт переводится в статус “Закрыт”.

* * *

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

Наверх

Отсканируйте QR код для того чтобы узнать ваш статус

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

Содержание

Баг-трекинговые системы

Немного терминологии. Инструмент управления дефектами (defect management tool), инструмент отслеживания дефектов (defect tracking tool), инструмент отслеживания помех (bug tracking tool): Инструмент, обеспечивающий фиксирование дефектов и изменений, а также поддержку их состояний.

Инструмент управления инцидентами (incident management tool): Инструмент, который обеспечивает запись и отслеживание статуса инцидентов.

Часто имеет процессно-ориентированные возможности для поддержки и контроля распределения, исправления и повторной проверки дефектов, а также возможности отчетности.

Теперь перейдем непосредственно к жизненному циклу бага.

Жизненный цикл бага: статусы

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

Обнаружен (submitted) или Open. Итак, тестировщик находит дефект и представляет его на рассмотрение в систему управления дефектами. С этого момента баг начинает свою официальную жизнь и о его существовании знают необходимые люди.
Назначен (assigned). Далее ведущий разработчик рассматривает дефект и назначает его исправление кому-то из команды разработчиков.
В работе (In Progress). Данный статус присваивается в случае, когда разработчик работает над исправлением данного бага.
Исправлен (fixed). Разработчик, которому было назначено исправление дефекта, исправляет его и сообщает о том, что задание выполнено.
Проверен (verified). Тестировщик, который обнаружил ошибку проверяет на новом билде (в котором исправление данной ошибки заявлено), исправлен ли дефект на самом деле. И только в том случае, если ошибка не проявится на новом билде, тестировщик меняет статус бага на Verified.
Открыт заново (reopened). Если баг проявляется на новом билде, тестировщик снова открывает этот дефект. Баг приобретает статус Reopened.
Отклонён (declined). Баг может быть отклонён. Во-первых, потому, что для заказчика какие-то ошибки перестают быть актуальными. Во-вторых, это может случится по вине тестировщика из-за плохого знания продукта, требований (дефекта на самом деле нет, не смогли понять, не смогли воспроизвести).
Отложен (deferred). Если исправление конкретного бага сейчас не очень важно или заказчик пока думает, или мы ждём какую-то информацию, от которой зависит исправление бага, тогда баг приобретает статус Deferred.
Закрытые (closed) баги. Закрытым считается баг в состояниях Проверен (verified) и Отклонён (declined).

Примечание: Открытые (open) баги. Открытыми являются баги в состояниях Обнаружен (submitted), Назначен (assigned), Открыт заново (reopened). Иногда к открытым относят и баги в состояниях Исправлен (fixed) и Отложен (deferred).

Резолюция (Resolution) – пояснение к статусу в жизненном цикле бага

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

Unresolved — присваивается тимлидом команды разработчиков или МП при открытии нового бага.
Fixed – данная резолюция присваивается после устранения дефекта разработчиком.
Won‘t Fix – резолюция применяется, если открытый баг не может быть исправлен, описанный дефект не является багом, данный баг, по разным причинам, нет необходимости устранять.
Duplicate – присваивается отчетам о дефектах, которые дублируют уже открытые.
Cannot Reproduce – такая резолюция присваивается если открытый баг не удалось воспроизвести.
Verified — по окончанию контроля устранения бага и в случае, когда баг действительно исправлен корректно, то присваивается данная резолюция

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

Помните, критичный баг, найденный тестировщиком в последний день, является багом в работе самого тестировщика! А так же не все баги должны быть исправлены.

В чем еще вам лгут российские политики

Это не война, это только спецоперация

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

Россия хочет только защитить ЛНР и ДНР

Российская армия обстреливает города во всех областях Украины, ракеты выпускали во Львов, Ивано-Франковск, Луцк и другие города на западе Украины.

На карте Украины вы увидите, что Львов, Ивано-Франковск и Луцк — это больше тысячи километров от ЛНР и ДНР. Это другой конец страны.

Это места попадания ракет 25 февраля. За полтора месяца их стало гораздо больше во всей Украине.

Центр Украины тоже пострадал — только первого апреля российские солдаты вышли из Киевской области. Мы не понимаем, как оккупация сел Киевской области и террор местных жителей могли помочь Донбасу.

Мирных жителей это не коснется

Это касается каждого жителя Украины каждый день.

Тысячам семей пришлось бросить родные города. Снаряды попадают в наши жилые дома.

Это был обычный жилой дом в Тростянце, в Сумской области. За сотни километров от так называемых ЛНР и ДНР.

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

Российская армия обстреливает пункты гуманитарной помощи и «зеленые коридоры».

Во время эвакуации мирного населения из Ирпеня семья попала под минометные обстрелы — все погибли.

Среди убитых много детей. Под обстрелы уже попадали детские садики и больницы.

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

Это груднички, которых вместо теплых кроваток приходится размещать в подвалах. С начала войны Украине родилось больше 15 000 детей. Все они еще ни разу в жизни не видели мирного неба.

В Украине — геноцид русскоязычного народа, а Россия его спасает

В нашей компании работают люди из всех частей Украины: больше всего сотрудников из Харькова, есть ребята из Киева, Днепра, Львова, Кропивницкого и других городов. 99% сотрудников до войны разговаривали только на русском языке. Нас никогда и никак не притесняли.

Но теперь именно русскоязычные города, Харьков, Мариуполь, Россия пытается стереть с лица земли.

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

Украинцы сами в себя стреляют

У каждого украинца сейчас есть брат, коллега, друг или сосед в ЗСУ и территориальной обороне. Мы знаем, что происходит на фронте, из первых уст — от своих родных и близких. Никто не станет стрелять в свой дом и свою семью.

Украина во власти нацистов, и их нужно уничтожить

Наш президент — русскоговорящий еврей. На свободных выборах в 2019 году за него проголосовало три четверти населения Украины.

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

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

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

Это месть за детей Донбасса

Российские СМИ любят рассказывать о кровожадных украинских детоубийцах. Но «распятый мальчик в трусиках» и «мальчик — мишень для ракет ВСУ» — это легенды, придуманные российскими пропагандистами. Нет ни единого доказательства подобным страшилкам, только истории с государственных российских телеканалов.

Однако допустим, что ваши солдаты верят в эти легенды. Тогда у нас все равно появляется вопрос: зачем, мстя за детей Донбасса, они убивают детей Донбасса?

8 апреля солдаты рф выпустили две ракеты в вокзал Краматорска, где четыре тысячи украинцев ждали эвакуационные поезда. Ракетным ударом российские солдаты убили 57 человек, из которых 5 — дети. Еще 16 детей были ранены. Это дети Донбасса.

На одной из ракет остались остатки надписи «за детей».

Сразу после удара российские СМИ сообщили о выполненном задании, но когда стало известно о количестве жертв — передумали и сказали, что у рф даже нет такого оружия.

Это тоже ложь, вот статья в российских СМИ про учения с комплексом Точка-У. Рядом скриншот из видео с военным парадом, на котором видна Точка-У.

Еще один фейк, который пытались распространить в СМИ: «выпущенная по Краматорску ракета принадлежала ВСУ, это подтверждает ее серийный номер». Прочитайте подробное опровержение этой лжи.

Посмотрите на последствия удара. Кому конкретно из этих людей мстили за детей Донбасса?

Если бы Россия не напала на Украину, Украина бы напала на Россию

Нет, не напала бы.

Посмотрите, в скольких войнах участвовала и сколько войн развязала Россия за 30 лет:

1992–1993 — Россия оккупировала Приднестровье
1992–1993 — Россия спровоцировала Абхазскую войну
1994–1996 — Первая русско-чеченская война
1999–2009 — Вторая русско-чеченская война
2008 — Российско-грузинская война
2015–2022 — Вторжение России в Сирию
2014–2022 — Российско-украинская война

Украина за 30 лет не начала ни одну войну. Мы защищали отобранные россией территории, но никогда не развязывали войны.

Украинцы сами хотят в Россию

Это неправда, мы не хотим быть частью России. Мы суверенная страна с большой историей. Мы хотим развиваться так, как это видим МЫ, а не диктатор из соседней страны.

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

Люди выходят на митинги против российских оккупантов, в них стреляют, бросают светошумовые гранаты. Но на следующий день люди выходят вновь.

Россия начала войну, чтобы не подпустить НАТО к своим границам

Четыре страны, которые входят в НАТО, уже граничат с Россией: Латвия, Литва, Эстония и Польша.

Украина не входит в НАТО. Более того, в середине февраля канцлер Германии подчеркнул, что в обозримом будущем нашу страну и не планируют принимать в НАТО.

На нашей территории нет баз НАТО и нет американских биолабораторий.

Путин использует НАТО как страшилку для россиян, но при этом в 2000 году он сам планировал присоединить Россию к альянсу.

Вновь, если вы не верите нам, украинской стороне, проверьте информацию в независимых международных СМИ:

Как Путин оправдывает вторжение в Украину. Фактчекинг DW (Deutsche Welle)

Зачем нужен хороший баг-репорт?

Если ваш отчет об ошибках (баг-репорт) составлен правильно, то шансы на быстрое исправление этих багов — выше. Таким образом, исправление ошибки зависит от того, насколько качественно вы о ней сообщите. Составление отчетов об ошибках — не что иное, как навык, и сейчас мы рассмотрим, как его сформировать.

«Смысл написания отчета о проблемах (баг-репорта) состоит в том, чтобы исправить эти проблемы» — Cem Kaner. Если тестировщик не сообщает об ошибке правильно, программист, скорее всего, отклонит эту ошибку, заявив, что она невоспроизводима.

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

Каковы качества хорошего баг-репорта в разработке программного обеспечения?

Любой может написать баг-репорт. Но не каждый может написать эффективный бар-репорт.

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

Характеристики и методы включают в себя:

1) Наличие четко определенного номера ошибки:

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

2) Воспроизводимость:

Если найденная вами ошибка не воспроизводима, то она никогда не будет исправлена.

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

3) Будьте конкретны:

Не пишите очерк о проблеме.

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

Эффективный баг-репортинг

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

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

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

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

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

Четко указывайте информацию об ошибке: «Как?» и «Где?». Отчет должен ясно показывать, как был выполнен тест и где именно произошел дефект. Читатель отчета должен легко воспроизвести ошибку и найти ее.

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

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

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

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

Как сообщить об ошибке?

Используйте следующий простой шаблон баг-репорта:

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

Составитель отчета: Ваше имя и адрес электронной почты.

Продукт: В каком продукте вы нашли эту ошибку.

Версия: Версия продукта с ошибкой, если таковая имеется.

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

Платформа:

Укажите аппаратную платформу, на которой вы обнаружили эту ошибку. Различные платформы, такие как «ПК», «MAC», «HP», «Sun» и т. д.

Операционная система:

Укажите все операционные системы, в которых вы обнаружили ошибку. Операционные системы, такие как Windows, Linux, Unix, SunOS, Mac OS. Упомяните разные версии ОС, такие как Windows NT, Windows 2000, Windows XP и т. д., если это применимо.

Приоритет:

Когда следует исправлять ошибку? Приоритет обычно устанавливается от P1 до P5. P1 следует понимать, как «исправить ошибку с наивысшим приоритетом» и P5 — «исправить, если позволяет время».

Серьезность ошибки:

Описывает влияние ошибки.

Типы Серьезности ошибки:

Блокировщик (Blocker): дальнейшая работа по тестированию невозможна.
Критическая (Critical): сбой приложения, потеря данных.
Major: серьезная потеря функциональности.
Minor: незначительная потеря функциональности.
Незначительная (Trivial): некоторые улучшения пользовательского интерфейса.
Улучшение (Enhancement): запрос новой функции или некоторого улучшения существующей.

Статус ошибки:

Когда вы регистрируете ошибку в любой системе отслеживания ошибок, то по умолчанию статус ошибки будет «Новый».

Позднее ошибка проходит через различные этапы, такие как «Исправлено», «Проверено», «Повторно открыто», «Не исправлено» и т. д.

Назначить разработчику:

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

URL:

URL страницы, на которой произошла ошибка.

Краткое резюме:

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

Описание:

Подробное описание ошибки.

Используйте следующие поля для поля описания:

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

Это важные шаги в отчете об ошибках. Вы также можете добавить «Тип отчета» как еще одно поле, которое будет описывать тип ошибки.

Видео курсы по схожей тематике:

Типы отчетов включают в себя:

1) Ошибка в коде
2) Ошибка проектирования
3) Новое предложение
4) Проблема с документацией
5) Аппаратная проблема

Важные фичи в вашем отчете об ошибках

Рассмотрим несколько составляющих отчета о найденном баге

Ниже приведены важные элементы баг-репорта:

1) Номер ошибки/идентификатор:

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

2) Наименование ошибки:

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

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

3) Приоритет:

В зависимости от серьезности ошибки, для нее может быть установлен приоритет. Ошибка может быть Blocker, Critical, Major, Minor, Trivial или предложением по улучшению функционала. Приоритет ошибки от P1 до P5 может быть задан так, чтобы важные из них просматривались первыми.

4) Платформа / Среда:

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

5) Описание:

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

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

6) Шаги для воспроизведения ошибки:

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

Хороший пример правильно написанной пошаговой процедуры приведен ниже:

Последовательность шагов:

Выберите продукт wer05.
Нажмите на «Добавить в корзину».
Нажмите «Удалить», чтобы удалить продукт из корзины.

7) Ожидаемый и фактический результат:

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

Скриншот:

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

Некоторые дополнительные советы, для написания хорошего баг-репорта

Ниже приведены некоторые дополнительные советы, чтобы написать хороший отчет об ошибке:

1) Немедленно сообщите о проблеме:

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

2) Воспроизведите ошибку три раза перед написанием баг-репорта:

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

3) Протестируйте эту же ошибку на других похожих модулях:

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

4) Составьте хорошее резюме ошибки:

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

5) Прочитайте несколько раз отчет об ошибке, прежде чем нажать кнопку «Отправить»:

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

Бесплатные вебинары по схожей тематике:

6) Не используйте оскорбительные выражения:

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

Заключение.

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

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

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

С нашей стороны для качественной подготовки тестировщиков, предлагаем вам ознакомиться с курсом подготовки специалиста-тестировщика на ITVDN — Quality Assurance

По материалам статьи

Источник