Программирование • 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» — расскажем, с чего начать свой путь к новой профессии.
Уровень сложности
Простой
Время на прочтение
3 мин
Количество просмотров 3.1K
Чтобы написать bug report(отчет об ошибке) в Jira необходимо выполнить несколько действий, которые ты узнаешь на примере «боевой» жиры. Уверен, что общую концепцию поймешь.
Далее ты узнаешь:
-
Что такое Jira?
-
Шаги для составления баг репорта
Что такое Jira?
Jira — это система управления проектами и отслеживания задач, которая используется командами разработки программного обеспечения.
Она позволяет создавать, отслеживать и управлять задачами разработки, контролировать прогресс выполнения, планировать версии и релизы, обеспечивать коммуникацию и сотрудничество в команде, а также предоставляет отчетность и аналитику для анализа производительности проекта.
Jira помогает командам разработки эффективно управлять проектами и обеспечивать успешную доставку программного обеспечения.
Шаги для составления баг репорта:
1). Перейдите в Jira и нажмите кнопку «Создать».
2). Выберите тип проблемы «Ошибка» из списка вариантов.
3). Заполните поле сводки кратким описанием проблемы(summary), например такой шаблон: «путь до бага» — «какая проблема?», «когда?», «где?». Заголовок можно по разному строить.
4). В поле описания предоставьте подробное объяснение проблемы, и любые отображаемые сообщения об ошибках, например добавить логи и/или веб сокеты. Также можно прикрепить видео, скрины и другие файлы с необходимой информацией. Тут же можно указать окружение, где воспроизвелось или в ином специальном поле.
5). Напишите шаги для воспроизведения в специальное поле. Рекомендую в виде пронумерованного списка.
6). Прикрепите к проблеме любые соответствующие файлы, например снимки экрана и/или файлы журнала(логи, иные файлы), возможно еще какие либо ярлыки, компоненты.
7). Установите уровень приоритета проблемы в зависимости от серьезности ошибки и срочности ее исправления.
8.) По серьезности (Severity) бага в большинстве случаев, на практике, остаются пустым, по моему опыту, потому что тут разрабу виднее и то даже они часто оставляют это поле пустым.
9.) Назначьте проблему на разработчика или на другого члена команды, ответственному за дальнейшую судьбу ошибки (поле Assignee) на определенном этапе её решения.
Данный пункт, также зависит от договоренности внутри команды, потому что бывает данное поле остается пустым или назначается аналитик, PM, или сразу разработчик. В моем опыте было так, что я мог сразу бывает так, что несколько пр в сборку попало разработчика или аналитика(было, что человек был лицом совмещающий PM, PO и должность аналитика), а было назначаешь только менеджера или вообще пусто.
Заполните поле сводки кратким описанием проблемы.
10). Добавить информацию о спринте, также ниже версию приложения, где был найден баг и в какой версии будет исправляться он, если это известно. Чаще всего этот вопрос решает аналитик, поэтому у него можно уточнить.
Указывать номер билда и/или commit hash — НЕ обязательно. Тут не особо принципиально, потому что если в девелопе, то следующие билды тоже будут с багой. По хэшу коммита, а если их несколько в таске? Вряд ли угадаешь в каком косяк. Еще бывает так, что несколько PR в сборку попало. Данное требование может возникнуть в редких случаях, например удаленно надо подебажить разрабу. Но так не всегда. Тут скорее зависит от разработчика, потому что кому-то реально проще подебажить и найти по коммиту место, где поломалось.
11.) Можно установить связь с другой задачей, если такова имеется и присутствует необходимость, например можно установить связь с таской, которую тестировали и в ней нашли баг.
12). Нажмите кнопку «Создать», чтобы отправить отчет об ошибке.
Это основные шаги для работы с баг репортом, но шагов может быть больше. Главное, как по мне, это логи и шаги воспроизведения.
Важно предоставить, как можно больше подробностей в отчете об ошибке, чтобы помочь разработчику понять и воспроизвести проблему. Если вы знаете фронт или бэк, а именно умеете или хотя б немного понимаете в разработке, то можете добавить свое предложение по решению проблемы или например загуглить проблему и дать ссылку на решение.
Также необходимо быть как можно более конкретными при описании шагов по воспроизведению ошибки, так как это поможет разработчику определить основную причину проблемы и быстрее ее исправить. Если что-то в багах не понимаете, то уточняйте у разрабов/аналитиков.
С одной стороны его задача — быть простым и понятным, а с другой стороны — быть эффективным.
Важно, чтобы программист при изучении данного отчета мог с легкостью воспроизвести описанный баг и понять ход мыслей тестировщика.
Шаблон отчета о дефекте, который отвечает запросам тестировщика и программиста, выглядит следующим образом:
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)
При необходимости тестировщики прикладывают скриншоты или видео воспроизведения ошибки. Также могут прикладывать логи выполнения программы.
________________________________
При соблюдении правил оформления баг-репортов, ваша работа станет более эффективной.
________________________________
В следующей статье мы разберем такие атрибуты баг-репорта, как Приоритет и Серьезность дефекта.
Профессия тестировщика ПО очень многогранна, ведь она требует внимания к деталям, креативности, коммуникативных навыков и усидчивости. Последнее качество особенно пригодится для такой части работы QA-инженера, как составление тестовой документации.
Один из примеров ― баг-репорт (от англ. bug report ― отчёт об ошибке), который содержит описание всех найденных дефектов в работе приложения. Не имеет значения, тестируете ли вы компьютерную игру, приложение для банка или сайт онлайн-магазина ― составление правильного отчёта является залогом продуктивного QA-процесса.
Баг-репорт содержит ответы на следующие вопросы:
- что идёт не так;
- где проявляется дефект;
- когда ошибка воспроизводится.
С этим техническим документом предстоит ознакомиться разработчикам, которые внесут изменения в программный код и исправят ошибки. Именно поэтому баг-репорт должен быть лаконичным, понятным и содержать максимум полезной информации.
Разберёмся, как добиться этого сочетания.
Как выявляют баги?
Вы, как инженер по обеспечению качества, можете узнать о наличии дефектов в программном обеспечении несколькими способами:
- во время проведения тестирования ПО;
- при обращении заказчика с описанием ошибки;
- из сообщений пользователей, которые столкнулись с проблемами во время использования программного продукта.
Идеальный сценарий ― первый, когда дефекты выявляются до релиза специалистами по обеспечению качества. Но иногда до начала составления баг-репорта тестировщику приходится изучать чужой опыт взаимодействия с ПО при появлении ошибки.
Какой инструмент используют для документирования дефектов?
Самой распространённой системой для отслеживания дефектов является JIRA. Данный ресурс позволяет фиксировать ошибки и следить за их жизненным циклом. Но эта программа не такая простая, особенно для новичков в ИТ. Поэтому важно ознакомиться с её функционалом.
Наши студенты уже на базовом курсе получают необходимый багаж знаний для эффективной работы с JIRA, а в этой статье мы подробно рассказали, как прокачать своё мастерство поиска в этой баг-трекинговой системе.
Некоторые компании отдают предпочтение и менее известным инструментам, например, Redmine или Mantis.
Каких правил придерживаться при написании баг-репорта?
Правило №1: следуйте принципу «1 дефект = 1 баг-репорт». Это позволит сохранить прозрачность процессов на проекте и детально следить за исправлением недочётов.
Правило №2: пишите баг-репорт простым и лаконичным языком, ведь от того, насколько быстро разработчик поймёт суть проблемы зависит скорость внесения правок в код.
Правило №3: описывайте дефект кратко, но с сохранением максимума полезной информации.
Правило №4: удостоверьтесь в воспроизводимости ошибки до заведения баг-репорта, повторите свой алгоритм действий и по возможности сократите число шагов.
Правило №5: проверьте, нет ли идентичного дефекта, который уже был зафиксирован.
Если всё в порядке, можно переходить к описанию.
Из каких элементов состоит баг-репорт?
Форма заполнения баг-репорта включает несколько полей (атрибутов). Туда тестировщик вносит характеристики дефекта. Число атрибутов может варьироваться в зависимости от баг-трекинговой системы и особенностей проекта, но с некоторыми тестировщики работают постоянно. Рассмотрим их:
Summary (заголовок)
Первый элемент баг-репорта — это краткое описание сути проблемы. В этом поле мы должны коротко и ясно описать выявленный дефект. Уже на этом этапе вы можете придерживаться правила «Где? Что? Когда или в каких условиях?». Не лишним будет добавить и данные о тестовом окружении, под которым выявлен дефект. Формулируйте этот атрибут в виде связного предложения, так будет проще вникнуть в суть проблемы.
Давайте рассмотрим конкретный пример. Представьте, что вы тестируете площадку объявлений menyaemsya.com. Согласно требованиям, поле с описанием товара должно содержать максимум 350 символов. Но вы видите, что система пропускает описание, которое превышает данный лимит. Для этого дефекта вам нужно составить баг-репорт. Воспользуемся подсказкой «Что? Где? Когда?», чтобы составить заголовок. Получается:
«Ограничение на ввод символов в поле с описанием товара отсутствует на всех страницах».
При тестировании мобильных приложений важно внести и название платформы, iOS или Android.
Заголовок готов. Можем двигаться дальше.
Description (описание)
Содержание этого поля отличается в зависимости от баг-трекинговой системы. Например, JIRA или Redmine предполагают описание шагов воспроизведения ошибки. Пользователи Mantis тут могут более подробно описать суть проблемы, а для описания пути воспользоваться атрибутом «Steps to reproduce» (в пер. с англ. «действия по воспроизведению»). Выглядеть это описание может следующим образом:
- переход на сайт menyaemsya.com;
- вход или регистрация;
- нажатие кнопки «Добавить объявление»;
- ввод символов в поле «Описание».
Если же предстоит выполнить слишком большую последовательность действий, то вы можете начать с описания условий.
«Пользователь авторизован на сайте menyaemsya.com и перешёл в корзину».
Actual/expected result (фактический/ожидаемый результат)
Нам предстоит ещё раз указать на суть дефекта и добавить информацию о том, как элемент ПО должен работать корректно.
Пример заполнения данного раздела:
«При внесении информации в поле “Описание” количество вводимых пользователем знаков не лимитируется. Ожидается, что после внесения 350 символов система не будет выводить на экран знаки и предложит пользователю сократить текст».
Attachments (вложения)
Этот элемент репорта позволяет проиллюстрировать суть бага и поделиться дополнительными данными. Вы можете прикрепить скриншоты, фото, видеозапись или иные файлы. Это упростит понимание сути проблемы и поможет быстрее сориентироваться.
Priority (приоритет)
Это важное поле, которое содержит информацию о срочности исправления дефекта. Данные этого атрибута помогают менеджеру планировать работу на проекте, ведь чем выше приоритет, тем скорее необходимо внести изменения.
Системы определения важности могут отличаться, но скорее всего вы встретитесь с подобной градацией:
- P1 High (высокий приоритет);
- P2 Medium (средний приоритет);
- P3 Low (низкий приоритет);
Высокий приоритет имеют критические дефекты, которые необходимо исправить в кратчайшие сроки. Категория P3 включает те баги, которые не влияют на работу системы и могут быть устранены в последнюю очередь.
Severity (серьёзность)
Ошибки имеют и другую характеристику ― степень серьёзности влияния на систему.
- Blocker — это статус для проблем, которые прерывают работу приложения.
- Critical — такой баг значительно влияет на работоспособность, но не приводит к блокировке.
- Major — ошибка, которая не способствует фундаментальным изменениям, но может привести к незначительным искажениям отображения информации или выполнения некоторых функций.
- Minor — не влияет на работу системы. К этой категории можно отнести ошибки в текстовых блоках или визуальных решениях.
Status (статус)
В этом поле находится актуальная информация о том, в каком состоянии текущая задача. Содержание этого атрибута может варьироваться в зависимости от баг-трекинговой системы. Вы можете столкнуться со следующими обозначениями:
- New – новый баг;
- Feedback – требуется обратная связь;
- Acknowledged – с содержанием документа ознакомились;
- Accepted – ошибка воспроизвелась и была подтверждена;
- Assigned – исправление ошибки назначено;
- Resolved – изменения были внесены;
- Closed – дефект больше не воспроизводится.
Такими являются основные элементы баг-репорта, с которыми приходится встречаться чаще всего. Но в отчёте могут содержаться и дополнительные поля:
- Environment/platform – среда, платформа или операционная система;
- Fix version – этап разработки ПО на момент выявления бага;
- Assignee – пользователь, которому предстоит утвердить или исправить дефект;
- Lable – категория ошибки (текст, визуальные элементы и прочее).
Резюмируем
Написание баг-репорта ― важный элемент QA-процесса, который позволяет ускорить устранение дефекта и подготовить качественное ПО к выходу на рынок. До начала написания документа важно:
- убедиться в воспроизводимости ошибки;
- оценить поведение системы на разных платформах (при необходимости);
- проверить дефект на уникальность в баг-трекинговой системе.
Хороший отчёт об ошибке написан простым и понятным языком, содержит максимум полезной информации. Ключевыми атрибутами баг-репорта являются заголовок, описание, приоритет и статус ошибки. Стоит придерживаться порядка написания отчёта и заполнять все поля в зависимости от особенностей трекинговой платформы и требований проекта.
Умение составлять подобные репорты является важным для тестировщика навыком, который вы можете развить, ежедневно тренируясь. А освоить азы вам помогут наши замечательные преподаватели, сотрудники международной ИТ-компании, на курсе «Основы тестирования ПО». Присоединяйтесь!
- Зачем нужен хороший баг-репорт?
- Каковы качества хорошего баг-репорта в разработке программного обеспечения?
- Характеристики и методы для сообщения о баге
- Эффективный баг-репортинг
- Простой шаблон баг-репорта
- Важные фичи в отчете об ошибках
- Номер ошибки/идентификатор
- Наименование ошибки
- Приоритет
- Платформа/среда
- Описание
- Шаги для воспроизведения ошибки
- Ожидаемый и фактический результат
- Скриншот
- Дополнительные советы для написания хорошего баг-репорта
- Заключение
Зачем нужен хороший баг-репорт?
Баг репорт это отчет об ошибках. И если он составлен правильно, то шансы на быстрое исправление этих багов выше. Таким образом, исправление ошибки зависит от того, насколько качественно вы о ней сообщите. Составление отчетов об ошибках — не что иное, как навык, и сейчас мы рассмотрим, как его сформировать.
«Смысл написания отчета о проблемах (баг-репорта) состоит в том, чтобы исправить эти проблемы» — Cem Kaner. Если тестировщик не сообщает об ошибке правильно, программист, скорее всего, отклонит эту ошибку, заявив, что она невоспроизводима.
Это может повредить рабочему настрою тестировщиков, затронуть их профессиональную гордость, их эго.
Каковы качества хорошего баг-репорта в разработке программного обеспечения?
Любой может составить пример баг репорта. Но не каждый может написать эффективный баг-репорт.
Вы должны уметь хорошо различать баг-репорт среднего качества и хороший баг-репорт. Как отличить хороший и плохой баг-репорты? Это очень просто, примените следующие характеристики и методы, чтобы качественно сообщить об ошибке.
Характеристики и методы включают в себя:
1) Наличие четко определенного номера ошибки:
Всегда присваивайте уникальный номер каждому сообщению об ошибке. Это, в свою очередь, поможет вам четко идентифицировать запись об ошибке. Если вы используете какой-либо инструмент автоматического формирования баг-репортов, то этот уникальный номер будет генерироваться автоматически каждый раз, когда вы делаете отчет.
Запишите номер и краткое описание каждой ошибки, о которой вы сообщили.
2) Воспроизводимость:
Если найденная вами ошибка не воспроизводима, то она никогда не будет исправлена.
Вы должны четко указать шаги для воспроизведения ошибки. Не принимайте и не пропускайте ни одного шага воспроизведения. Ошибку, которая описана шаг за шагом, легко воспроизвести и исправить.
3) Будьте конкретны:
Не пишите очерк о проблеме.
Пишите конкретно и по существу. Попытайтесь описать обнаруженную проблему минимальным количеством слов и максимально эффективным способом. Не объединяйте описания нескольких багов в одном отчете, даже если они кажутся похожими. Напишите разные отчеты для каждой проблемы.
Эффективный баг-репортинг
Отчеты об ошибках являются важным аспектом тестирования программного обеспечения. Эффективный баг-репорт хорошо понимается командой разработчиков и позволяет избежать путаницы или недопонимания.
Хороший отчет об ошибке должен быть четким и кратким, без каких-либо пропущенных ключевых моментов. Любое отсутствие ясности ведет к недопониманию и замедляет процесс разработки. Описание дефектов и составление отчетов — одна из самых важных, но часто игнорируемых областей в жизненном цикле тестирования.
Правильно составленный текст отчета про найденный баг очень важен для регистрации ошибки. Один из важных моментов, которые должен иметь в виду тестер, — это не использовать командный тон в отчете. Такой тон нарушает моральное состояние коллектива и создает нездоровые рабочие отношения. Используйте нейтральный тон.
Не думайте, что если разработчик допустил ошибку, то вы можете использовать грубые слова. Прежде чем сообщать, не менее важно проверить, был ли уже баг-репорт по этой ошибке ранее или нет.
Дубликаты ошибок — это постоянная проблема в цикле тестирования. Проверяйте весь список обнаруженных багов. Иногда разработчики могут знать о наличествующей проблеме и игнорировать ее в будущем выпуске. Используйте специальные инструменты, такие как Bugzilla, который автоматически ищет дубликаты ошибок. Тем не менее, лучше всего дополнительно вручную искать дубликаты ошибок.
Четко указывайте информацию об ошибке: «Как?» и «Где?». Отчет должен ясно показывать, как был выполнен тест и где именно произошел дефект. Читатель отчета должен легко воспроизвести ошибку и найти ее.
Имейте в виду, что цель написания баг-репорта — дать разработчику возможность визуализировать проблему. Он/она должен четко понимать суть дефекта, прочитав отчет об ошибке. Не забудьте предоставить всю необходимую информацию, которую ищет разработчик.
Кроме того, имейте в виду, что отчет об ошибках будет сохранен для будущего использования и должен быть хорошо написан и содержать необходимую информацию. Используйте содержательные предложения и простые слова, чтобы описать найденные ошибки. Не используйте запутанные утверждения, которые тратят время читателя.
Сообщайте о каждой ошибке как о отдельной проблеме. В случае описания нескольких багов в одном отчете, вы не сможете закрыть его, пока все проблемы не будут решены.
Следовательно, лучше всего разбить большие проблемы на отдельные баги. Это гарантирует, что каждая ошибка может быть обработана отдельно. Хорошо написанный баг-репорт помогает разработчику воспроизвести ошибку на своем терминале. Это помогает им также правильно диагностировать проблему.
Как сообщить об ошибке?
Используйте следующий простой баг репорт шаблон:
Это простая форма баг-репорта. Его содержание может варьироваться в зависимости от используемого вами инструмента отчетов об ошибках. Если вы пишете баг-репорт вручную, то необходимо упомянуть некоторые поля, например номер ошибки, который должен быть назначен вручную.
Составитель отчета: Ваше имя и адрес электронной почты.
Продукт: В каком продукте вы нашли эту ошибку.
Версия: Версия продукта с ошибкой, если таковая имеется.
Компонент: Основные подмодули продукта.
Платформа:
Укажите аппаратную платформу, на которой вы обнаружили эту ошибку. Различные платформы, такие как «ПК», «MAC», «HP», «Sun» и т. д.
Операционная система:
Укажите все операционные системы, в которых вы обнаружили ошибку. Операционные системы, такие как Windows, Linux, Unix, SunOS, Mac OS. Упомяните разные версии ОС, такие как Windows NT, Windows 2000, Windows XP и т. д., если это применимо.
Приоритет:
Когда следует исправлять ошибку? Приоритет обычно устанавливается от P1 до P5. P1 следует понимать, как «исправить ошибку с наивысшим приоритетом» и P5 — «исправить, если позволяет время».
Серьезность ошибки:
Описывает влияние ошибки.
Типы Серьезности ошибки:
- Блокировщик (Blocker): дальнейшая работа по тестированию невозможна.
- Критическая (Critical): сбой приложения, потеря данных.
- Major: серьезная потеря функциональности.
- Minor: незначительная потеря функциональности.
- Незначительная (Trivial): некоторые улучшения пользовательского интерфейса.
- Улучшение (Enhancement): запрос новой функции или некоторого улучшения существующей.
Статус ошибки:
Когда вы регистрируете ошибку в любой системе отслеживания ошибок, то по умолчанию статус ошибки будет «Новый».
Позднее ошибка проходит через различные этапы, такие как «Исправлено», «Проверено», «Повторно открыто», «Не исправлено» и т. д.
Назначить разработчику:
Если вы знаете, какой разработчик отвечает за тот конкретный модуль, в котором произошла ошибка, вы можете указать адрес электронной почты этого разработчика. В противном случае оставьте это поле пустым, так как это присвоит полю авторства ошибки значение владельца модуля, если менеджер не назначит ошибку разработчику.
URL:
URL страницы, на которой произошла ошибка.
Краткое резюме:
Добавьте краткое описание ошибки. Ориентируйтесь на 60 слов или меньше. Убедитесь, что составленное резюме отражает проблему и место, где она находится.
Описание:
Подробное описание ошибки.
Используйте следующие поля для поля описания:
- Воспроизводимые шаги: ясно упомяните шаги для воспроизведения ошибки.
- Ожидаемый результат: как приложение должно вести себя на вышеуказанных этапах.
- Фактический результат: каков фактический результат выполнения вышеупомянутых шагов, то есть поведение ошибки.
Видео курсы по схожей тематике:
Это важные шаги в отчете об ошибках. Вы также можете добавить «Тип отчета» как еще одно поле, которое будет описывать тип ошибки.
Типы отчетов включают в себя:
1) Ошибка в коде
2) Ошибка проектирования
3) Новое предложение
4) Проблема с документацией
5) Аппаратная проблема
Важные фичи в вашем отчете об ошибках
Рассмотрим несколько составляющих отчета о найденном баге
Ниже приведены важные элементы баг-репорта:
1) Номер ошибки/идентификатор:
Номер ошибки или идентификационный номер (например, xyz007) значительно упрощает составление баг-репорта и поиск места ошибки. Разработчик может легко проверить, исправлена ли конкретная ошибка или нет. Это делает весь процесс тестирования и повторного тестирования более плавным и легким.
2) Наименование ошибки:
Заголовок ошибки читается чаще, чем любая другая часть баг-репорта. Стоит указать в нем всё о том, что входит в баг.
Название ошибки должно быть достаточно осмысленным, чтобы читатель мог его понять. Четкий заголовок ошибки облегчает понимание, и читатель легко сможет проверить, было ли сообщение об ошибке ранее и была ли она исправлена.
3) Приоритет:
В зависимости от серьезности ошибки, для нее может быть установлен приоритет. Ошибка может быть Blocker, Critical, Major, Minor, Trivial или предложением по улучшению функционала. Приоритет ошибки от P1 до P5 может быть задан так, чтобы важные из них просматривались первыми.
4) Платформа / Среда:
Указание конфигурации ОС и браузера необходимо для большей точности в баг-репорте. Это лучший способ сообщить о том, как можно воспроизвести ошибку.
Без точной платформы или среды приложение может вести себя по-другому, и ошибка на стороне тестировщика может не повторяться на стороне разработчика. Поэтому лучше четко указать среду, в которой была обнаружена ошибка.
5) Описание:
Правильное описание ошибки помогает разработчику понять ошибку. Оно описывает возникшую проблему. Плохое описание создаст путаницу и потратит время разработчиков и тестеров.
Необходимо четко сообщить об эффекте в описании. Всегда полезно использовать полные предложения. Рекомендуется описывать каждую проблему отдельно, а не разрушать их полностью. Не используйте такие термины, как «я думаю» или «я считаю».
6) Шаги для воспроизведения ошибки:
Хороший отчет об ошибке должен четко указывать шаги для воспроизведения. Шаги должны включать действия, которые вызывают ошибку. Не делайте общих заявлений. Будьте конкретны в следующих шагах.
Хороший пример правильно написанной пошаговой процедуры приведен ниже:
Последовательность шагов:
- Выберите продукт wer05.
- Нажмите на «Добавить в корзину».
- Нажмите «Удалить», чтобы удалить продукт из корзины.
7) Ожидаемый и фактический результат:
Описание ошибки будет неполным без указания ожидаемых и фактических результатов. Необходимо обрисовать в общих чертах, каков результат теста и что ожидал бы пользователь в случае корректной работы программы. Читатель отчета должен знать, какой результат теста будет корректным. Ясно упомяните, что произошло во время теста и каков был результат.
Скриншот:
Одна картинка стоит тысячи слов. Сделайте скриншот с примером сбоя с соответствующими выделениями, чтобы указать дефект. Выделите неожиданные сообщения об ошибках светло-красным цветом. Это привлекает внимание к необходимой области.
Некоторые дополнительные советы для написания хорошего баг-репорта
Ниже приведены некоторые дополнительные советы, чтобы написать хороший отчет об ошибке:
1) Немедленно сообщите о проблеме:
Если вы обнаружите какую-либо ошибку во время тестирования, не нужно ждать, чтобы написать подробный отчет об ошибке позже. Вместо этого напишите отчет об ошибке немедленно. Это обеспечит хорошее качество отчета и воспроизводимость шагов получения ошибках. Если вы решите написать отчет об ошибке позже, есть большие шансы пропустить важные детали в баг-репорте.
2) Воспроизведите ошибку три раза перед написанием баг-репорта:
Ваш баг должен быть воспроизводимым. Убедитесь, что ваши шаги достаточно четкие, чтобы воспроизвести ошибку без какой-либо двусмысленности. Если ваша ошибка не воспроизводима каждый раз, вы все равно можете подать ошибку, указав периодическую природу бага.
3) Протестируйте эту же ошибку на других похожих модулях:
Иногда разработчик использует один и тот же код для разных похожих модулей. Таким образом, вероятность того, что ошибка в одном модуле возникнет и в других подобных модулях, выше. Вы даже можете попытаться найти более серьезную версию найденной ошибки.
4) Составьте хорошее резюме ошибки:
Краткое описание ошибки поможет разработчикам быстро проанализировать природу ошибки. Низкое качество отчета излишне увеличит время разработки и тестирования. Правильно взаимодействуйте с вашим баг-репортом. Имейте в виду, что сводка об ошибках используется в качестве справочной информации для поиска ошибки в инвентаре ошибок.
5) Прочитайте несколько раз отчет об ошибке, прежде чем нажать кнопку «Отправить»:
Прочитайте все предложения, формулировки и шаги, которые используются в баг-репорте. Посмотрите, не создает ли какое-либо предложение двусмысленность, которая может привести к неправильной интерпретации. Следует избегать вводящих в заблуждение слов или предложений, чтобы составить четкое сообщение об ошибке.
Бесплатные вебинары по схожей тематике:
6) Не используйте оскорбительные выражения:
Приятно, что вы проделали хорошую работу и обнаружили ошибку, но не используете это для критики разработчика или нападок на какого-либо человека.
Заключение
Что такое баги? Это несовершенства ПО, с которыми необходимо бороться, и один из главных помощников в этом – репорты об ошибках.
Мы рассмотрели некоторые особенности составления отчета про найденный баг. Нет сомнений, что ваш баг-репорт должен быть качественным документом.
Сосредоточьтесь на написании хороших отчетов об ошибках и потратьте некоторое время на выполнение этой задачи, потому что именно качественный баг-репорт является основной точкой связи между тестером, разработчиком и менеджером. Менеджеры со своей стороны должны объяснить своей команде, что составление хорошего отчета об ошибках является основной обязанностью любого тестировщика.
Ваши усилия по написанию хорошего отчета об ошибках не только сохранят ресурсы компании, но и создадут хорошие отношения между вами и разработчиками.
Для лучшей производительности команды стремитесь написать лучший отчет об ошибках.
С нашей стороны для качественной подготовки тестировщиков, предлагаем вам ознакомиться с курсом подготовки специалиста-тестировщика на ITVDN — Quality Assurance
По материалам статьи