Жизненный цикл отчета об ошибке - Не ошибается лишь тот, кто ничего не делает!

Программирование • 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

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

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

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

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

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

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

(рейтинг: 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

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

***

Источник

Как Вы думаете, какой навык тестировщика — самый важный?

Написание тест-кейсов?

Тест-анализ?

Может автоматизация тестирования?

Что-то из soft-skills?

Умение работать в команде?

Как насчет поиска багов?

Написание хороших баг репортов — это самый важный навык тестировщика!

Почему?)

Потому что хороший баг репорт это:

экономия времени и сохранение нервов разработчика (не нужно тратить время на “понимание” ошибки и раздражающие разговоры “это баг — нет, это не баг”)
радость для бизнеса (исправления делаются быстро, повышается качество продукта)
удовольствие для клиента (все мы хотим пользоваться качественными продуктами)

Ни один другой навык не приносит столько пользы, как этот)

Вы можете быть супер-аналитиком, находить по 100 багов за день, общаться и дружить со всеми разработчиками. Но, если Вы не умеете создавать баг репорты — баги не будут исправляться. А если баги не будут исправляться… Вы сами можете догадаться, что произойдет 🙂

Научиться писать качественные баг репорты — просто!

Каким образом и что для этого нужно?

Читайте в этой статье)

Что такое Баг / Дефект?

Перед тем, как начать разговор о баг репортах, стоит очень хорошо разобраться, что такое “баг”, ведь его мы и будем описывать 🙂

Слово “баг” — это технический жаргон [1] [2]. Оно используется в разговорах, статьях и приложениях (Jira, TestRail и т.п.)

Стандарты [3] и книги [4] используют другое название — “дефект”, оно более профессиональное.

Так как это не научная статья, мы будем использовать слово “баг”, как более распространенное и привычное 🙂

Существует несколько определений бага:

Баг — это изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [3]
Баг — это проблема, которая может приводить к отказу приложения или получению неправильных результатов, если ее не исправить. [ISO 24765, перевод]
Баг — это недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа [4]

Данные определения описывают баги в коде и их сложно применить к багам в требованиях, UI / UX и т.п.

На этапе проверки требований у нас нет компонента, системы (см. определение 1,3) или приложения (определение 2). У нас есть только текст, который их описывает, если он вообще существует 😂

Более универсальное и доступное определение приведено в книге [4]:

Баг — это отклонение фактического результата от ожидаемого результата.

Здесь:

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

Давайте рассмотрим несколько примеров багов.

Баг в функционале:

Существует функция, которая возвращает сумму чисел.
Передав ей значения sum(2, 2) мы должны получить 4 (ожидаемый результат)
Предположим, функция возвращает значение, отличное от 4, например 5 (фактический результат)
фактический результат ≠ ожидаемому результату (5 ≠ 4), значит это баг в логике функции

Баг в требованиях:

У нас есть требование, в котором указано, что дата регистрации клиента на сайте должна равняться 02.04.20 (фактический результат)
Здравый смысл подсказывает, что датой регистрации должна быть “текущая дата в момент регистрации” (ожидаемый результат)
Фактический результат ≠ ожидаемому результату, значит это баг в требованиях

Баг в UX:

Предположим, Вы открываете меню сайта на мобильном устройстве. Меню находится справа и занимает 70% ширины экрана. Слева появляется черный фон
Вы нажимаете на черный фон — ничего не происходит.
Опыт подсказывает, что после клика на фон меню должно закрываться (ожидаемый результат), но по факту — ничего не происходит (фактический результат)
Фактический результат ≠ ожидаемому результату, значит это баг в UX

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

Баги являются следствием ошибок.

В свою очередь, ошибка — это действие человека, которое приводит к неправильным результатам [4].

Причин возникновения ошибок множество [5]:

Стресс
Спешка
Усталость, болезнь
Непонимание задания
Отсутствие коммуникации
Невозможность сконцентрироваться
Некомпетентность
Чрезмерная сложность ПО
Отсутствие документации / информации
…

Ошибки делают все и делают их всегда.

Это неотъемлемая часть природы человека и ее невозможно изменить или обойти.

Лучшие спортсмены, ученые, инженеры, политики, актеры, музыканты — ошибаются. Бизнес-аналитики, разработчики, тестировщики, дизайнеры, администраторы, переводчики и т.п. — не исключение…

Заблуждение об отсутствии ошибок — это один из принципов тестирования.

Все ли баги нужно исправлять?

Нет, не все.

В идеальном мире — наверное да, но мы не знаем где он 🙂

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

Это может происходить потому что вы:

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

Ситуация, когда Вы создаете “ложный” баг репорт — называется false-fail result [3].

Такие “моменты” характеризуют качество документации, качество подготовки к тестированию, качество проведения тестирования и анализируются QA (Вы ведь уже знаете, что QA ≠ тестирование?)

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

Вряд ли кто-то будет заниматься ошибкой, исправление которой стоит $1000 в то время как она затрагивает всего 0.002% пользователей, не приносящих ценности компании.

Zero bug policy — отличный процесс работы с багами при использовании гибкой разработки

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

Каждый найденный баг всегда проходит через конкретные “этапы”, которые называются жизненный цикл бага.

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

Не путайте жизненный цикл бага и жизненный цикл ПО — это не связанные вещи!

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

Давайте рассмотрим каждый этап и переходы между ними подробнее.

Этапы жизненного цикла бага

1. Открыт (Open) — баг создан, оформлен и передан разработчику / команде разработки

2. В Работе (In Progress) — ведутся работы по исправлению

3. Исправлен (Ready for check) — баг исправлен и передан тестировщику на повторную проверку

4. Закрыт (Closed) — баг проверен и больше не воспроизводится

Переходы бага между этапами жизненного цикла

Переходы между этапами жизненного цикла пронумерованы в соответствии с нумерацией списка ниже.

1. Открыт — Закрыт. Если баг — это “не баг”, он может сразу быть закрыт, без промежуточных операций.

Иногда этот переход выносят в отдельный этап жизненного цикла, который называется Отклонен (Rejected). Он используется для анализа процесса тестирования или оценки работы тестировщиков / разработчиков.

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

Мы считаем, что это не верно, потому что мнение разработчика — субъективное. Теоретически, он может “отклонять” баг если:

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

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

2. Открыт — В Работе. Баг подтвержден и передан разработчикам, которые начали работу над исправлением.

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

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

Появление большого количества багов в статусе “Не Баг” говорит о проблемах в коммуникации и / или документации.

4. В Работе — Исправлен. Ошибку локализовали и исправили, она передана тестировщику.

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

Этот переход может существовать как отдельный этап жизненного цикла бага — Переоткрыт (Reopened).

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

6. Исправлен — Закрыт. Тестировщик проверил исправление, баг больше не воспроизводится.

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

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

Такой “операцией” Вы испортите аналитику и метрики + создадите путаницу в релизах и процессе работы и т.п.

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

Теперь, когда мы разобрались с багами, причинами их возникновения и жизненным циклом — мы можем переходить к рассмотрению баг репорта 🙂

Что такое баг репорт (bug report)?

Баг Репорт (Bug Report) — документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [IEEE 829]

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

Баг Репорт (Bug Report) — документ, содержащий информацию о найденном баге.

Другие названия этого документа:

баг-репорт
отчет о дефекте
defect report

Зачем нужны баг репорты?

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

Написание баг репортов — чрезвычайно полезный процесс, потому что:

1. Происходит фиксации факта существования бага

Есть репорт — есть прецедент для реакции.
Нет репорта — никто ничего не будет делать.

Именно поэтому не стоит писать баги в скайп / чат / говорить лично и т.п.

Есть вероятность, что о нем забудут (и вы, в том числе) и не исправят.

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

2. Баг репорт помогает разработчику

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

В докладе Егора Бугаенко Testing and Testers на TestCon 2020, именно об этом был 4-ый вопрос и объяснения, почему это важно. Рекомендую посмотреть 🙂

3. Появляется возможность приоритизации исправлений

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

4. Появляется возможность анализа ошибок

Имея информацию о найденных дефектах Вы можете определять первопричины их возникновения и вносить изменения в рабочие процессы, чтоб их предотвращать. (Привет QA)

5. Тестировщик содействует устранению бага

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

6. Появляется возможность контроля этапа исправления бага

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

Наличие отчета о дефекте с изменяющимся статусом позволяет легко и быстро определять точное “положение” бага и контролировать его исправление.

7. Появляется возможность оценки качества продукта в текущий момент времени

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

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

Именно поэтому навык написания хороших отчетов критически важен для любого профессионала-тестировщика и его нужно освоить в совершенстве 😉

Атрибуты баг репорта

Баг репорт — это технический документ.

У него есть некий набор атрибутов (полей, параметров) для структуризации информации.

Атрибуты баг репорта можно разделить на 2 группы:

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

Основные поля

ID — уникальный идентификатор бага
Заголовок / Краткое описание / Тема / Summary / Title — четко и кратко описывает суть бага. Оформляется в виде одного предложения, состоящего из трех частей отвечающих на вопросы “Что? Где? Когда?”. Редко бывает, что ответ на вопрос “Где?” или “Когда?” может опускаться, если он не дает полезной информации. (примеры заголовков можно найти в разделе Серьезность)
Шаги к воспроизведению — четкое, последовательное описание шагов / действий, которые необходимо совершить, чтоб воспроизвести баг со всей необходимой информацией
Фактический результат — результат, который мы видим
Ожидаемый результат — результат, который мы хотели / ожидали увидеть
Серьезность — показывает, насколько серьезные последствия от дефекта с точки зрения влияния на систему (см. раздел Серьезность)

Дополнительные поля

Скриншот / видео — изображение / видео, которое четко и наглядно демонстрирует баг. Если видео или скриншот сделан качественно, его может быть достаточно для понимания сути ошибки и ее исправления
Требование — ссылка на требование, которое не соблюдено. Наличие этой информации в 99% случаев предотвращает разговор “баг — не баг” и испорченное настроение 🙂
Тип бага — для анализа “слабых” мест в ПО, баги могут разделять на типы (см. Тип бага)
Приоритет — очередь, в которой баг будет исправляться (Высокий -> Средний -> Низкий)
Дополнительные файлы — файлы, которые нужны для воспроизведения бага (файлы определенного размера, типа, логи и т.п.)
Окружение — информация об окружении, на котором воспроизводится баг (версия браузера, операционная система, размер экрана, тестовый сервер и т.п.)
Статус — текущий статус бага в его жизненном цикле (Открыт, В работе…)
Автор — человек, который создал баг (нужен для уточнения информации, если потребуется)
Исполнитель — человек, которые работает над багом в данный момент времени
Комментарии — обсуждение исправления ошибки
Версия — версия ПО, в которой был обнаружен баг
Версия исправления — версия ПО, в которую будет добавлено исправление бага

Серьезность бага (Bug Severity)

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

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

S4 | Blocker

Блокирующий — баг описывает ситуации, когда ПО не работает в принципе.

Примеры:

Не открываются страницы сайта (показывается белый фон / 404 / 50Х ошибка)
Не запускается мобильное приложение после нажатия на иконку на рабочем столе
Зависает интерфейс приложения после нажатия на кнопку «купить» (кнопки перестают нажиматься, приложение невозможно свернуть и т.п.)

S3 | Critical

Критический — баг влияет на критический функционал или критические данные.

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

Примеры критических функций в разных приложениях:

Баннера на сайте Х (приведение новых клиентов на сайт Y с использованием баннеров — основная функция сайта Х)
Форма логина на сайте Y (без логина — клиент не может попасть на форму заказа и оформить его, а это одна из основных функция сайта Y)
Форма оплаты на сайте Y (без формы оплаты — клиент не сможет оплатить свой заказ — самый критический функционал сайта Y)

Помимо критического функционала, к критическим багам относятся:

“Дыры” в безопасности системы
Полная / частичная потеря работоспособности системы на ощутимый промежуток времени, вызванная падением сервера
Проблема, которую пользователь не сможет обойти своими силами
1. например, если открытое модальное окно можно закрыть только нажатием на крестик, и нажатие не срабатывает на iOS

Примеры:

Указана неправильная ссылка на баннере в сайдбаре на странице Х
Отсутствует ограничение максимальной длины вводимых в поле Name данных на странице Donate
Показывается сообщение о серверной ошибке (503) на странице /signin после попытки логина
Показывается сообщение NGINX 404 error на главной странице блога Y
Не закрывается меню сайта после нажатия на крестик / черный фон

S2 | Major

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

К этому уровню относятся баги, связанные с:

Некритическим функциональными требованиями
Некритическим нефункциональными требованиями
Серьезными визуальными отклонениями в дизайне

Примеры:

Не отображается плашка New на странице /order-details
Не отображаются OG / Twitter microdata на странице X
Неправильный порядок блоков “What we do?” и “How about now” на странице Х

S1 | Minor

Незначительный — баг не влияет на бизнес логику приложения.

Чаще всего к этому уровню относятся баги в реализации UI (верстке), отсутствие переводов и т.п.

Примеры:

Не отображается ссылка /free-page в блоке “Free Products” в футере
Не переносится на новую строку / Не обрезается текст ссылки “Our TOP 20 projects” в блоке «How it works?» на странице Х
Не соответствует макету цвет текста в блоке Contact в футере

S0 | Trivial

Тривиальный — баг никак не влияет на качество продукта.

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

Примеры:

Отсутствует точка в конце предложения “This is whatever“ на странице Х
Отображается не актуальный год в футере сайта Х

Типы багов

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

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

Приведенные ниже типы багов относятся к WEB сайтам.

UI (ошибка в верстке)

Баг в верстке — следствие ошибки в разметке (HTML) или стилизации (CSS) элемента страницы в специфическом окружении.

Примеры:

Не отображается блок Х на странице Y (в дизайне блок есть, на странице — нет)
Неправильное расположение блока на странице X (в дизайне блок слева, на странице — справа)
Не переносится на новую строку / Не обрезается текст ссылки “Our TOP 20 projects” в блоке «How it works?» на странице Х

UX (ошибка в удобстве)

Баг в удобстве — неудобство / нелогичность работы с элементами / функционалом страницы.

Примеры:

Не получается с первого раза нажать на кнопку Х в футере на мобильном (очень маленькая зона клика, кнопку нужно сделать больше)
Удаляется заказ после нажатия на кнопку Х в модальном окне на странице Б (ожидаешь закрытия окна, а фактически удаляется заказ — UX путает)

Functional (ошибка в функционале)

Баг в функционале — несоответствие логики работы компонента заявленным функциональным требованиям.

Примеры:

Отображается неправильное количество ссылок в блоке Related Papers в sidebar
1. требование: выводить 5 ссылок
2. фактически: выводится 10 ссылок
Не происходит прокрутка страницы вверх после нажатия на кнопку To Top
1. требование: происходит прокрутка страницы вверх после нажатия на кнопку To Top
2. фактически: ничего не происходит
Не показалось сообщение об ошибке при вводе числа в поле Name
1. требование: допустимые символы для поля Name = буквы (обязательны) + пробелы (не обязательны). При вводе других символов — показываем сообщение об ошибке.
2. фактически: сообщение об ошибке не отображается
Не отображается модальное окно А после нажатия на кнопку Х
1. требование: после нажатия на кнопку X показывается окно А
2. фактически: после нажатия на кнопку X показывается окно С
Не отображается текст “Нет заказов” на профиле райтера, если количество заказов, назначенных райтеру = 0
1. требование: отображается текст “Нет заказов“, если количество заказов на профиле райтера = 0
2. фактически: не отображается текст “Нет заказов“, если количество заказов на профиле райтера = 0

SEO (ошибка в seo)

Баг в seo — ошибка, которая влияет на SEO (нарушение нефункциональных требований, касающихся seo).

Примеры:

Отображается неправильная структура заголовков блоков на странице Х
Найдены 4 ошибки на странице Х после проверки в w3c валидаторе
Указан неправильный title на странице Х
Закрыта для индексации страница Х
Отсутствует атрибут ALT на изображении Z на странице Х

Алгоритм создания баг репорта

Предположим, Вы нашли баг и приступаете к написанию баг репорта.

С чего начать?

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

Понять “суть” проблемы, а не ее проявление (если получится, но это требует технических знаний)
Воспроизвести дефект один-два раза (удостовериться, что он повторяется)
Проверить наличие найденного вами дефекта в системе управления дефектами (возможно, баг уже создали)
Написать заголовок (отвечает на вопросы “что? где? когда?”)
Написать основные поля отчета
Заполнить дополнительные поля отчета
Внимательно прочитать отчет. Убрать лишнее, добавить нужное!
Еще раз перечитать отчет! (самый важный пункт)
Сохранить отчет
Переназначить отчет либо проверяющему (если такой есть) либо разработчику (который будет исправлять ошибку)

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

Пример хорошего баг репорта (bug report example)

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

Пример UI дефекта (скриншот из баг репорта)

И Вы хотите создать отчет о найденном баге (нет перевода текстов ошибок).

Итоговый вариант может выглядеть так:

Заголовок / Краткое описание / Тема / Summary / Title

Не переведены на украинский язык тексты ошибок (что?) на форме “Зворотний зв’язок” на странице https://itawards.ua/ua (где?) в UA версии сайта (когда?)

Скриншот / видео

Скриншот / ссылка на скриншот

Шаги к воспроизведению

Открыть страницу https://itawards.ua/ua
Проскролить к форме “Зворотний зв’язок”
Нажать на кнопку “Надіслати”
Обратить внимание на язык ошибок, которые появились под полями формы

Фактический результат

Отображаются ошибки на английском языке

Ожидаемый результат

Отображаются ошибки на украинском языке

Серьезность

S1 (minor)

Кто внимательно рассмотрел изображение с багом (или решил сам протестировать форму) — мог заметить еще несколько “странностей”.

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

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

The Devil is in details.

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

Jira является одной из самых распространённых систем управления проектами в мире и очень часто используется в ИТ.

Так может выглядеть описанный выше баг репорт в Jira:

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

Открыть полное изображение в новой вкладке

Здесь:

красным отмечены основные поля
синими отмечены дополнительные поля

Основные поля являются обязательными для заполнения при создании бага, без них задача просто не сохраниться 🙂

Ошибки при создании баг репорта

Создание хороших баг репортов требует определенных знаний, навыков и опыта.

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

Заголовок не отвечает на вопросы “Что? Где? Когда?”
Заголовок содержит лишнюю информацию (версии, окружения, учетные данные пользователей и т.п.)
Отсутствуют шаги для воспроизведения
Шаги для воспроизведения излишне детализированы
Отсутствует фактический и / или ожидаемый результат
Отсутствует ссылка на требование, которое проверялось (если такое есть)
Отсутствие скриншота / видеозаписи для UI/UX багов (сюда можно также добавить отсутствие выделения ошибки на скриншоте)
Грамматические ошибки / Техническая безграмотность / Использование “жаргона”

Знание типичных ошибок помогает проверять самого себя (можно создать чек-лист) и позволяет создавать более качественные отчеты без возвратов на доработку!

Резюме

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

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

И именно правильное и качественное оформление баг репортов является ключевым навыком тестировщика.

Если у вас есть вопросы или предложения — пишите нам в Телеграм!

Если вам интересно тестирования и Вы хотите получать актуальную информацию по этой теме — подписывайтесь на наш Tелеграм канал. У нас очень интересно: статьи, видео, тесты, опросы, нет спама 😉

Источники

Баг (значения) // ru.wikipedia.org URL: https://ru.wikipedia.org/wiki/Баг_(значения) (дата обращения: 28.10.2020).
Программная ошибка // ru.wikipedia.org URL: https://ru.wikipedia.org/wiki/Программная_ошибка (дата обращения: 28.10.2020).
ISTQB Глоссарий Терминов Тестирования 2.3 [https://www.rstqb.org/ru/istqb-downloads.html?file=files/content/rstqb/downloads/ISTQB%20Downloads/ISTQB%20%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B8%CC%86%20%D0%A2%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D0%BE%D0%B2%20%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%202.3.pdf]
Куликов С. Тестирование программного обеспечения Базовый курс. — 3 изд. 2020. — 298 с.
Программа подготовки ISTQB Базового уровня 2018
[https://www.rstqb.org/ru/istqb-downloads.html?file=files/content/rstqb/downloads/ISTQB%20Downloads/ISTQB_CTFL_Syllabus_2018-RU.pdf]

FAQ

Что такое баг?

Баг — это отклонение фактического результата от ожидаемого результата.

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

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

Баги являются следствием ошибок.

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

Что такое баг репорт (bug report)?

Баг Репорт (Bug Report) — документ, содержащий информацию о найденном баге.

Что такое Серьезность бага (Bug Severity)?

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

Источник

Время на прочтение: 4 минут(ы) Рассказываем, как искать «баги», а не жуков, и правильно их описывать.

Время на прочтение: 4 минут(ы)

Что такое Баг-репорт

Это отчет/документ, в котором подробно излагаются проблемы с программным обеспечением, устройством или процессом. По-другому его называют отчет об ошибке.

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

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

Зачем составлять отчеты, если была найдена ошибка? Давайте представим реальную жизнь, если разработчики решали бы задачи и устраняли проблемы в общем чате (например, в телеграм). Поступившая проблема легко могла бы потеряться в этом чате, а специалисты не взялись бы за ее решение, так как упустили бы или подумали на другого. Чтобы этого избежать, существует баг-репорт, где понятно прописывается проблема и назначается ответственный, кто будет ее решать.

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

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

Заголовок репорта следует писать четко и кратко. “Как корабль назовешь, так он и поплывет”. Здесь примерно такая же история. Постарайтесь сформулировать проблему в одном или двух предложениях, чтобы тестировщик могу ее сразу понять.
Предоставьте пошаговое объяснение бага: подробно опишите проблему: что нужно сделать, чтобы прийти к ней, и приложите все значимые снимки экрана. Но не нужно указывать все возможные промежуточные действия, как например, “нажмите кнопку включения компьютера”.
Визуализируйте. Из предыдущего пункта вытекает еще правило: лучше всего прикладывать вложения (картинки, скриншоты) проблемы, особенно если это касается дизайна. Скриншоты должны показывать, где именно возникли ошибки, чтобы читатели могли легко воспроизвести их без предварительного доступа.
Определите обходные пути. Если возможно, предложите другие способы решения проблемы, которые сработали бы для вас.
Опишите свою среду: включите информацию об используемом устройстве, версии ПО или браузере.
Объясните ожидаемые и фактические результаты: что должно произойти и что произошло на самом деле.
Укажите серьезность. Отметьте, насколько дефект влияет на процессы и работу.

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

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

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

Заголовок	Четкий и краткий. Желательно уложиться в одно предложение
Описание*	Информация та же, что и в заголовке, но здесь следует привести немного больше деталей
Шаги для воспроизведения	Что нужно сделать, чтобы прийти к ошибке
Фактический результат	Что видно сейчас при воспроизведении всех шагов
Ожидаемый результат	Что вы хотите получить после решения проблемы и повторного прохождения всех шагов
Среда	Все технические характеристики: ПО, браузер
Вложения*	Картинки и скриншоты
Исполнитель*	Кто будет исправлять баг
Статус*	На каком этапе исправления находится проблема
Дополнительная информация*	Здесь можно указать обходные пути, по вашему мнению, или уже принятые действия для преодоления проблемы

Итого у вас должен получиться такой пример репорта (представим, что этот отчет написал начинающий джун):

Название:

Ошибка во времени загрузки страницы

Описание:

При попытке загрузить N сайт страница загружается необычно долго (более 10 секунд)

Действия по воспроизведению:

1. Откройте браузер N

2. Перейдите на сайт N

3. Обратите внимание на долгое время загрузки страницы

Ожидаемый результат:

Страница должна загрузиться в течение нескольких секунд

Фактический результат:

Страница загружается более 10 секунд

Информация об ОС/браузере/устройстве:

Chrome версии 67 в Windows 10

Курс

Инженер по тестированию

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

Записаться

Виды багов

Все ошибки можно разделить на разные типы:

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

Тип бага – это полезная информация в баг-репорте. Проще разбираться в проблеме, если ты знаешь, о чем она.

Приоритеты багов

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

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

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

Выделяют 5 уровней серьезности:

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

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

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

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

Источник