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

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

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

Что такое баг

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

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

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

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

Виды багов

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

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

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

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

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

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

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

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

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

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

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

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

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

Серьёзность бага
Как влияет на систему
S1 — Блокирующая (Blocker).
Приложение не запускается ни на одном устройстве или выдаёт ошибку при загрузке.

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

S2 — Критическая (Critical).
Часть функционала не работает, но это не блокирует процесс.

Пример: Скидка по купону не работает, но товар всё равно можно купить без скидки.

S3 — Значительная (Major).
Часть логики работает некорректно, но пользователь может решить проблему другим способом.

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

S4 — Незначительная (Minor).
Не нарушает логику приложения.

Пример: кнопка «Купить» уехала за экран и видна только наполовину.

S5 — Тривиальная (Trivial).
Не относится к логике приложения и не влияет на общее качество продукта.

Пример: малозаметная опечатка в меню.

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

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

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

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

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

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

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

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

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

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

Начните карьеру в IT с профессии тестировщика
Спустя 4 месяца обучения в вашем портфолио будет 6 протестированных приложений. Пройдите бесплатную вводную часть курса, чтобы попробовать себя в роли тестировщика.
Поделиться
Wed Jan 18 2023 17:35:09 GMT+0300 (Moscow Standard Time)