Как создать баг-репорт на практике. С примером шаблона.

• Герман, автор курса "Студио", проводит открытый урок.  

• Цель урока - объяснить, кто такой тестировщик, и дать практику.  

• Пример для объяснения - тема баг-репорта.  

• Баг-репорт - это отчет о найденной ошибке.  

• Герман обещает дать контакты для отправки баг-репортов и фидбек.  

• Начинается с объяснения, зачем нужен баг-репорт.  

• Баг-репорт рассматривается на пятой лекции курса.  

• Герман объясняет, что тестировщик тестирует сайты, мобильные приложения или бэкенд.  

• Сегодня фокус на тестировании сайтов.  

• Процесс начинается с описания продукта менеджером.  

• Менеджер описывает функции, цели и разделы продукта.  

• Формируется документация или требования.  

• Дизайнер создает дизайн продукта на основе документации.  

• Дизайн создается в программе Figma.  

• Figma содержит детальное описание продукта.  

• Разработчики создают продукт на основе документации и дизайна.  

• Тестировщик проверяет, что продукт соответствует требованиям и дизайну.  

• Тестировщик выявляет и фиксирует баги.  

• Тестировщик проверяет разницу между ожидаемым и фактическим поведением.  

• Ожидаемое поведение описано в документации и дизайне.  

• Фактическое поведение - это результат работы разработчика.  

• Тестировщик фиксирует разницу между ожидаемым и фактическим поведением.  

• В индустрии тестировщики заводят баг-репорты.  

• Вопрос о том, где заводить баг-репорты и как это делать.  

• Вики: набор знаний по проекту, аналог Википедии, но для конкретной компании.  

• ТМС: сервис для хранения тест-кейсов, используется для проверки функциональности и поиска дефектов.  

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

• Баг-репорт – это задача, которая заводится в таск-трекер.  

• В тестовых заданиях часто просят создать баг-репорт в свободной форме, используя Google Docs или Notion.  

• Важно правильно оформить баг-репорт, чтобы он выглядел профессионально.  

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

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

• Рекомендуется добавлять хэштеги для удобства поиска и классификации багов.  

• Хэштеги помогают классифицировать баги по проекту, окружению и другим параметрам.  

• В заголовке баг-репорта можно использовать до трех хэштегов.  

• Пример: бак веб прот указывает на проблему на сайте, в тестовой среде и на основной версии сайта.  

• Описание проблемы должно быть подробным и не ограничиваться длиной сообщения.  

• Пример: при попытке авторизации через Apple ID возникает ошибка 500.  

• Используйте глаголы в инфинитиве для описания шагов.  

• Пример: открыть сайт, попытаться авторизоваться через Apple ID.  

• Добавьте скриншот или видео для лучшего понимания проблемы.  

• Пример: скриншот ошибки при авторизации.  

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

• Пример: успешная авторизация.  

• Окружение: прод или тест.  

• Билд: номер сборки или версии сайта.  

• Пример: версия сайта 3.0.  

• Укажите, на какой платформе или в каком браузере воспроизводится проблема.  

• Пример: проблема в Chrome, но может быть и в других браузерах.  

• Опишите устройство, на котором найдена проблема.  

• Пример: MacBook Pro 2023 года.  

• Укажите метод тестирования, если проблема связана с бэкендом.  

• Пример: тестирование сайта.  

• Назначьте исполнителя для баг-репорта.  

• Пример: руководитель разработки.  

• Наблюдатели получают уведомления об изменениях в баг-репорте.  

• Пример: коллеги тестировщики, руководитель тестирования, менеджер.  

• Добавьте автора, статус и дату создания.  

• Пример: дата создания 16 ноября 2023 года.  

• Приоритет и серьезность важны для определения важности проблемы.  

• Пример: теория расходится с практикой.  

• Существует пять уровней влияния дефекта: блокер, критикал, нормал, майнер, триви.  

• Блокер полностью блокирует систему, например, сайт не открывается.  

• Критикал нарушает ключевую бизнес-логику, например, не работает перевод денег в банке.  

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

• Майнер не нарушает логику, но есть, например, визуальные ошибки.  

• Триви минимально влияет на систему, например, визуальные изменения.  

• Приоритет задачи влияет на очередность её выполнения.  

• Разработчик выбирает задачу с самым высоким приоритетом.  

• Тестировщик не может влиять на приоритет задачи, это делает менеджер.  

• Тестировщик фиксирует разницу между ожидаемым и фактическим поведением и передает менеджеру.  

• Влияние на систему может быть максимальным, но приоритет минимальным.  

• Пример: сайт не работает в Internet Explorer, но приоритет минимальный.  

• Опечатки могут иметь минимальную серьезность, но максимальный приоритет, влияя на репутацию.  

• В реальной практике редко встречаются оба поля серьезность и приоритет.  

• Обычно используется только поле приоритет, где указывается влияние на работоспособность.  

• На собеседованиях часто спрашивают разницу между серьезностью и приоритетом.  

• Баг-репорты должны быть качественными и не ленивыми.  

• Тестировщики должны писать подробные и структурированные баг-репорты.  

• Качественные баг-репорты производят впечатление и помогают в оценке работы тестировщика.  

• Добавление полей для улучшения баг-репорта.  

• Баг-репорт будет смотреть разработчик или менеджер.  

• Менеджеру нужна аналитика для расстановки приоритетов.  

• Баг может затрагивать только одну платформу или версию ОС.  

• Важно указать, сколько пользователей затронуто.  

• Пример: баг в Safari, который влияет на 2.4% пользователей.  

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

• Прикрепите статистику о количестве пользователей, затронутых проблемой.  

• Прикрепите документацию, чтобы разработчику было проще.  

• Логи помогают разработчикам понять причину ошибки.  

• Пример использования инструментов Kibana и Center.  

• Пример использования Kibana и Center для поиска ошибок.  

• Kibana ловит все логи, включая положительные и отрицательные.  

• Важно научиться искать логи и прикреплять их к баг-репорту.  

• Использование фильтров для поиска логов по времени и URL.  

• Пример фильтрации по времени за последние пять минут и по URL.  

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

• Добавление ссылки на тред в мессенджере для обсуждения проблемы.  

• Возможность спросить у коллег, если баг уже известен.  

• Сохранение обсуждения для будущих пользователей баг-репорта.  

• Добавление смешной гифки в конце баг-репорта для улучшения восприятия.  

• Использование сервисов типа Giphy для создания гифок.  

• Отправка баг-репорта через ссылку для удобства исправления ошибок.  

• Призыв к тестировщикам найти баги на тестовом сайте и отправить баг-репорты.  

• Обещание индивидуального фидбека и ответов на вопросы.  

• Подробности о том, как и куда отправлять баг-репорты, будут в описании ролика.