Что такое баги? Если вы уже работаете в сфере технологий, то наверняка знаете ответ на вопрос. Для тех, кто только начинает свой путь в IT:
Баг – это ошибка или изъян в приложении, из-за которого оно ведет себя непредусмотренным образом или выдает неверные результаты.
Если вы нашли баг, о нем следует сообщить разработчикам, которые его устранят. Тестировщики делают это с помощью баг-репортов (отчетов о багах), а конечные пользователи – с помощью сообщений об ошибках. Независимо от того, идет речь о баг-репорте или простом сообщении, нужно постараться собрать как можно больше информации о баге и изложить ее в структурированном виде.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Что такое атрибуты бага?
Как описать баг?
Баг в программе имеет ряд характеристик – атрибутов. QA-специалисту важно уметь определять атрибуты бага и оформлять их в баг-репорт. Давайте рассмотрим самые распространенные атрибуты.
Серьезность (Severity)
Серьезность бага определяется влиянием, которое он оказывает на систему. Описывая баг, мы указываем уровень его серьезности. Классификация может быть разной, но часто выделяют такие уровни, как blocker, critical, major, minor, trivial.
Критичный (Critical) уровень серьезности бага
Такие ошибки оказывают серьезное влияние на систему. Они могут спровоцировать падение системы, аварийное выключение, повреждение данных (изменение или утечку информации) или критические сбои. Багам с таким уровнем серьезности присваивается наивысший приоритет при рассмотрении и устранении.
Пример. Пользователь после корректного ввода своих учетных данных попадает в чужой аккаунт, хозяин которого об этом и не подозревает.
Эта ошибка – большая проблема. Ее необходимо устранить как можно скорее, чтобы предотвратить нежелательные взломы и защитить конфиденциальность пользователей.
Приоритет (Priority)
Приоритет бага определяет то, насколько быстро его нужно устранить. Выделяют высокий, средний и низкий приоритеты, хотя возможны и другие градации.
Высокий (High) приоритет бага
Главное отличие багов с высоким приоритетом от багов с критичным уровнем серьезности в степени влияния на бизнес.
Пример. Когда покупатель добавляет товары в корзину и переходит к оформлению заказа, система не может применить скидки. Такой баг может не иметь высокого уровня серьезности, ведь из-за него система не падает. Но он точно будет иметь высокий приоритет, потому что невозможность воспользоваться скидкой может огорчить клиентов и они просто уйдут.
Примечание редакции: подробнее о серьезности и приоритетах багов и разнице между этими атрибутами читайте в статье “Серьезность и приоритет дефекта: в чем разница?”.
Воспроизводимость
Этот атрибут бага означает возможность воспроизвести проблему при соблюдении определенных условий.
Разработчикам проще исправить ошибку, если она воспроизводима. При этом для ее воспроизведения может потребоваться соблюдение нескольких условий в комплексе. Количество таких условий может зависеть от размера приложения.
Важно предоставить разработчику подробную информацию об условиях, в которых проявился баг:
- Версия программного обеспечения
- Логи приложения, API или устройства, где запущено приложение
- Конкретная конфигурация, при которой возникла ошибка
- Платформа, на которой работает программное обеспечение. Это может быть десктопное, мобильное, веб-приложение.
Благодаря полученной информации проектные менеджеры могут решить, действительно ли это баг (это может быть и результат каких-то причуд в требованиях). А разработчик может использовать информацию в баг-репорте, чтобы быстро локализовать и устранить баг и вернуться к кофе-брейку!
Описание
Четкое и подробное описание бага позволяет разработчикам понять, как и когда этот баг проявляется и каковы возможные причины его возникновения.
В описание включают шаги по воспроизведению бага, ожидаемые и фактические результаты, входные данные, а также любые соответствующие сообщения об ошибках или логи.
Считайте, что описание бага – это колонка сплетен в мире программного обеспечения. Описание всех деталей дефекта представляет собой баг-репорт.
Частота
Речь идет о том, как часто баг возникает и сколько людей затрагивает.
Частота возникновения может влиять на приоритет бага. Баги, которые часто возникают или затрагивают большое количество пользователей, обычно приоритетнее тех, которые возникают нерегулярно или затрагивают лишь небольшую часть пользователей.
Чтобы лучше понять это, рассмотрим баг в веб-приложении, когда нажатие на определенную кнопку периодически приводит к падению приложения.
Влияние частоты возникновения бага на его приоритет:
- Приложение аварийно завершает работу при каждом нажатии на кнопку. Если эта кнопка является частью важной функции в ПО, баг следует отнести к высокоприоритетным.
- Приложение падает только тогда, когда несколько пользователей одновременно нажимают на кнопку. Такой баг имеет меньшую частоту, но все равно является значительной проблемой. Учитывая, что у приложения несколько сотен пользователей, такому багу можно назначить средний приоритет.
- Приложение падает только тогда, когда много людей одновременно нажимают на кнопку. Это все равно проблема, но не такая срочная. Представьте, что вы на вечеринке и все одновременно пытаются войти в одну и ту же дверь – это беспорядок, но не катастрофа. В этом случае багу тоже может быть присвоен средний приоритет, поскольку проблема затрагивает достаточно большое количество пользователей.
- Приложение падает только тогда, когда на кнопку нажимает пользователь, использующий определенную версию браузера. Сюда же можно отнести случаи, когда кнопка является редко используемой частью приложения. Это как в ситуации, когда ваша игрушка ломается, только если играть с ней определенным образом или крайне редко – в большинстве случаев это не проблема. Такой тип дефекта можно пометить как низкоприоритетный.
Существуют и другие атрибуты:
- окружение (среда, в которой работает ПО)
- прилагаемые файлы (скриншоты или записи экрана)
- сотрудник или команда, кому сообщается об ошибке
- текущий статус бага (в работе, исправлен)
- комментарии (замечания о возможных обходных путях, предположения о причинах возникновения)
Когда QA-специалист собрал всю эту информацию, составляется баг-репорт.
Баг-репорт
Итак, тестировщик обнаружил баг, разобрался с тем, что он собой представляет, и нашел побольше деталей, касающихся этого бага, чтобы помочь коллегам устранить его. Он собирает эти атрибуты бага воедино и составляет документ под названием баг-репорт.
Баг-репорты создаются только тогда, когда мы убедились, что найденное нами – это баг.
Примечание. Оформляйте баг-репорт только если вы уверены в наличии дефекта. В противном случае сперва обсудите этот вопрос с продакт-менеджером.
“Смысл написания баг-репорта в том, чтобы добиться исправления багов”, – Джем Канер.
Давайте рассмотрим пример баг-репорта.
Описание бага:
Проблема: Дублирующиеся уведомления.
Сценарий. Студент колледжа полагается на приложение для составления расписания, чтобы своевременно получать уведомления о предстоящих занятиях и сроках сдачи заданий. Однако он заметил, что получает повторные уведомления об одном и том же событии, что может сбить его с толку и насторожить.
Шаги для воспроизведения:
- Добавьте новый урок или задание в расписание.
- Установите напоминание/уведомление для добавленного события.
- Дождитесь назначенного времени, чтобы получить уведомление.
Ожидаемый результат. Пользователь должен получить одно уведомление о запланированном событии.
Фактический результат. Пользователь получает несколько уведомлений об одном и том же событии, что приводит к путанице и потенциальному раздражению.
Дополнительная информация. Этот баг может быть результатом ошибки программирования в системе уведомлений, когда приложение запускает несколько уведомлений для одного запланированного события. Это может быть связано с тем, как приложение обрабатывает и управляет запланированными событиями и напоминаниями.
Возможное влияние на пользователя. Пользователь может пропустить важные уведомления из-за потока дублирующихся оповещений, что может привести к таким проблемам, как пропуск занятий или дедлайнов.
Возможное решение. Разработчики должны исследовать и устранить проблему в системе уведомлений, чтобы каждое запланированное событие вызывало только одно уведомление в указанное время.
Для успешного создания баг-репортов важно иметь четкое представление о жизненном цикле бага. Он охватывает обнаружение бага, подтверждение его существования, сообщение о нем и обеспечение того, чтобы это сообщение было получено соответствующей командой или специалистом.
Однако окончательное решение о том, действительно ли баг имеет значение, зависит от различных факторов. Например, от стандартов отрасли (баг-репорты в сфере аппаратного обеспечения отличаются от баг-репортов в сфере программного обеспечения), ожиданий клиентов и уровня допустимого риска.
Советы тестировщикам
Чтобы выловить как можно больше багов, можно:
- тестировать в паре
- выполнять тесты более одного раза
- снимать тестирование на видео, чтобы можно было воспроизвести его
- не тестировать, когда вы устали
- иметь в виду, что если не перепроверить подозрительное поведение продукта, можно легко пропустить важные ошибки.
Применяйте полученные знания и развивайтесь профессионально. Успешного тестирования 🙂
Перевод статьи «Everything About Bugs a QA should know».