Как писать баг-репорты, которые помогут всей команде
Всем привет!
Меня зовут Михаил, я специалист по тестированию в компании ITFB Group.
Работа тестировщика состоит из множества различных задач, но самые важные — это обнаружение и описание багов. Однако сам процесс выявления ошибки — лишь половина дела. Настоящая ценность для команды разработки заключается в грамотном документировании найденного бага, а именно — в создании баг-репорта.
Написание баг-репорта может показаться простой задачей, однако чтобы он действительно был полезным и помогал разработчикам быстро разобраться в проблеме, важно учесть множество нюансов. Хорошо составленный баг-репорт не только описывает саму ошибку, но и содержит всю необходимую информацию для её воспроизведения, анализа и последующего исправления. Этот навык требует определённых знаний, внимания к деталям и опыта.
Рассмотрим основные составляющие качественного баг-репорта.
Название бага Это первое, что видит команда, поэтому название должно быть кратким и ёмким. Пример: «Кнопка «Отправить» не работает на странице регистрации».
Краткое описание В нескольких предложениях нужно объяснить суть проблемы. Например: «При нажатии на кнопку «Отправить» на странице регистрации форма не отправляется, хотя все обязательные поля заполнены». Это помогает получить общее представление о баге, не тратя время на чтение подробных шагов воспроизведения.
Ссылка на требования (если есть) Эта информация помогает понять, какой ожидаемый функционал был нарушен. Важно ссылаться на документацию, чтобы разработчики знали, от чего отталкиваться при исправлении бага.
Предусловия Перед тем, как приступить к воспроизведению бага, важно указать, что должно быть подготовлено. Например: «Пользователь должен быть не авторизован на сайте». Это позволит избежать дополнительных вопросов и ошибок при проверке.
Шаги воспроизведения Один из важнейших пунктов — пошаговая инструкция для воспроизведения проблемы. Пример:
Откройте страницу регистрации (в идеале здесь еще нужно приложить прямую ссылку).
Заполните все обязательные поля.
Нажмите кнопку «Отправить». Четкие и структурированные шаги должны обеспечить воспроизведение проблемы любому человеку, даже тому, кто недавно присоединился к проекту.
Ожидаемый результат Здесь указываем, что должно было произойти. Пример: «Форма регистрации должна быть успешно отправлена, и пользователь должен получить сообщение о подтверждении».
Фактический результат Описание того, что произошло на самом деле. Пример: «Ничего не происходит, форма остаётся на той же странице, без сообщения об ошибке».
Вложения Если проблема имеет визуальные проявления или сложна для описания, стоит приложить скриншоты, видео или логи. Это ускоряет понимание бага.
Окружение воспроизведения бага Очень важно указывать окружение, в котором был выявлен баг: версия ОС, браузер, устройство и т.д. Пример: «Windows 10, Microsoft Edge версия 130.0.2849.80». Иногда баги проявляются только на определённых конфигурациях.
Автор бага Да, многие заводят баги в системах управления задачами вроде Jira, где автоматически указывается автор, однако лучше указать это дополнительно.
Исполнитель Здесь необходимо указать разработчика, аналитика или другого специалиста, который будет ответственным за исправление данного недочета.
Серьёзность и приоритет Это два параметра, которые помогают установить важность бага. • Серьёзность указывает на степень влияния на систему (например, критический, серьёзный, незначительный). • Приоритет помогает определить, насколько быстро нужно исправить баг (например, высокий, средний, низкий).
Бывает так, что на оформление полноценного баг-репорта не хватает времени. Если тестировщик понимает, что ответственный за устранение ошибки уже знает, где и что необходимо править, и уверен в том, что исправлением займутся в ближайшее время, можно составить сокращенный баг-репорт. Он может быть не таким подробным, но при этом включать в себя достаточно информации для понимания и воспроизведения ошибки:
Краткое, но ёмкое название.
Предусловие, в котором предельно кратко описана суть выявленной ошибки.
Ожидаемый и фактический результаты.
Скриншоты, видео, архивы запросов из devtools или логи ошибки. Может показаться, что вышеуказанной информации вполне достаточно для оформления баг-репорта, который поможет всей команде, однако не всё так просто. Недавно среди коллег (тестировщиков, разработчиков и аналитиков) я провёл опрос, чтобы узнать, с какой частотой они сталкиваются со сложностями при проверке баг-репорта. Результаты — на диаграмме.
Мы видим, что 86,2% специалистов испытывают различного рода проблемы при работе с чужими баг-репортами.
Чтобы понять, что должно содержаться в баг-репорта для облегчения его понимания и восприятия, я задал следующий вопрос.
Как можно видеть из результатов опроса, самыми важными аспектами баг-репортов разработчики, аналитики и тестировщики назвали:
шаги для воспроизведения — 86%;
ожидаемый и фактический результаты — по 76%;
описание проблемы — 73%.
Результаты опроса полностью соответствуют действительности: при оформлении именно этих этапов баг-репорта тестировщики чаще всего испытывают трудности. Расскажу о тех сложностях, которые многократно встречались в моей практике.Пропуск шагов воспроизведения
Имеется ввиду не тот случай, когда специалист просто забыл написать какой-либо шаг (иногда такое тоже периодически случается). Здесь речь о том, что авторы баг-репортов порой намеренно не пишут о каком-либо действии для воспроизведения бага. Это происходит из-за того, что тестировщик, будучи хорошо погруженным в проект, не думает о том, что получатель репорта может быть новичком или по каким-то другим причинам не знать подробностей и нюансов возникновения подобных ошибок. Конечно, описывать излишне подробно тоже не стоит (например: сначала как отдельный шаг написать «Наведите курсор мыши на кнопку «Добавить», а уже следующим шагом «Нажмите на кнопку «Добавить»), главное — сообщить достаточное количество информации.Неконкретное написание шагов воспроизведения
Иногда бывает так, что автор баг-репорта описывает шаг, но не включает в него разного рода важные нюансы. Так, например, во фразе «Введите необходимое значение» из контекста сразу непонятно –, а какое значение в данном случае является необходимым. Тут может быть два варианта решения проблемы. В первом случае нужно вместо слова «необходимое» использовать слово «валидное». Во втором — писать числовое значение, которое пользователь должен ввести (к примеру, «введите 10000»). Можно сказать, что некорректное написание шагов является следствием сложности, о которой говорилось в п.1 — когда автор не думает о том, что получатель отчета может не знать всей информации о проекте.Сложные формулировки
Иногда авторы при написании баг-репорта используют очень длинные предложения, которые часто бывают логически не связаны между собой. Оборванные фразы, неуточненные предложения, отсутствие конкретики и сложносоставные конструкции в тексте репорта сильно усложняют его прочтение и, как следствие, увеличивают сроки для воспроизведения бага и устранения ошибки.Непонятный заголовок.
Предположим, что мы участвуем в разработке корпоративного портала, где можно создавать различные заявки (отпуск, командировки, работа в выходные дни и т.д.), и у нас проблема в том, что не получается завести какую-то из них. В этом случае, если в заголовке просто написать «Не создается заявка», будет непонятно, какая именно заявка не создается и что конкретно нужно поправить\проверить.
Идеальное название баг-репорта должно отвечать на 3 главных вопроса: Что случилось? Где? И когда? (Например: «В личном кабинете сотрудника после нажатия на номер заявки не открывается карточка данной заявки»). Важно избегать абстрактных фраз, чтобы название сходу давало представление о проблеме.
Конечно, бывают и другие сложности и ошибки при составлении баг-репорта, я здесь выделил именно те, с которыми чаще сталкивался в своей практике.
Чтобы узнать, какие аспекты мои коллеги считают наиболее важными при изучении баг-репорта, я провел опрос:
По результатам опроса, именно шаги воспроизведения (80%), а также разница между ожидаемым и фактическим результатами (70%) являются самой важной информацией. Поэтому при написании баг-репортов обязательно стоит обращать внимание на данные этапы.
Советы для составления качественного баг-репорта
Эти рекомендации могут помочь при написании баг-репортов как начинающим тестировщикам, так и опытным специалистам, которым нужно написать данный текстовый артефакт.
Проверьте ранее заведенные баг-репорты
Перед тем, как начать заводить новый дефект, нужно убедиться, что его ранее никто не описывал. Это позволит не дублировать информацию и не создать путаницу в отчетах. Если обнаружилось, что этой ошибке уже посвящен какой-то из предыдущих отчетов, оставьте в найденном баг-репорте комментарий об актуальности данной ошибки или впишите в него другую информацию, которая может быть полезна для команды.Напишите отчет сразу после обнаружения ошибки
С момента обнаружения бага до написания соответствующего отчета должно пройти как можно меньше времени: по «свежим следам» можно наиболее информативно описать ошибку и не допустить при этом неточности. При задержке вы рискуете упустить контекст, забыть ключевые детали или воспроизвести баг в другом окружении, что может исказить его поведение. Если приступить к написанию баг-репорта сразу нет возможности, то в таком случае зафиксируйте себе где-то общие тезисы или важные нюансы, чтобы при написании дефекта не забыть о них.Подробно задокументируйте ошибку
Успешное исправление ошибки напрямую зависит от того, как её задокументировать. Поэтому уделите этому внимание, и всё распишите как можно детальнее. Ведь чем подробнее и точнее описана ошибка, тем меньше времени разработчик тратит на её воспроизведение, а значит — увеличивает вероятность исправления в срок.Напишите отчет как можно грамотнее и понятнее
Как уже было обговорено ранее, нужно писать баг-репорт так, чтобы читающему было всё понятно при прочтении и не приходилось дополнительно обращаться к кому-либо за пояснениями. Причем это относится не только к условному разработчику или аналитику, которые будут работать над исправлением данного дефекта: баг-репорт должен быть понятен любому участнику команды. Всегда есть вероятность того, что, например, исправление данного бага будет отложено в связи с низким приоритетом или же из-за того, что в данный момент исправить эту ошибку не представляется возможным. Потом проверкой исправления данного бага может заниматься другой тестировщик, который в случае скудного и неграмотного описания не будет понимать, что вообще нужно смотреть и как должен выглядеть ожидаемый результат и т.д. Поэтому при составлении баг-репорта попробуйте абстрагироваться от объема своих знаний по проекту и постарайтесь включить в отчет как можно больше достоверной структурированной информации.Укажите предусловия
Указание предусловий иногда упускается авторами дефектов, хотя это очень важный аспект, который может помочь не только воспроизвести найденный баг, но и найти саму проблему. Например, в личном кабинете пользователя не работает определенный функционал. Написать с каким именно пользователем возникает данная проблема не займет много времени, а в результате именно этот аспект может стать главным: вдруг на него или на его роль лежат какие-либо ограничения, о которых автор баг-репорта забыл или просто не знал.Правильно назначьте задачу
Правильный выбор исполнителя задачи может сильно повлиять на решение выявленной проблемы. Ведь можно не просто выбрать не того исполнителя из нужного отдела (может оказаться, что выбранный сотрудник вообще не ответственен за данный функционал), а неправильно для себя определить источник проблемы и назначить баг-репорт не на то подразделение (например, не на front-end, а на back-end). Хорошо, если конечный адресат обратит на это внимание и перенаправит на нужное подразделение, но так бывает не всегда. Вероятнее всего в таком случае, что задача окажется проигнорированной и останется висеть в системе (особенно, если у нее низкий приоритет). Поэтому, если у вас есть какие-то сомнения в конечном адресате, то обязательности уточните этот момент у тимлида или у других коллег.Правильно выберите приоритет
Этот пункт особенно важен, если отсутствует возможность связаться напрямую с тестировщиком или разработчиком\аналитиком, который будет заниматься устранением выявленной проблемы. Из-за неправильно установленного приоритета исправление очень важной ошибки может быть оставлено в последнюю очередь и, наоборот: дефект, который мало, на что влияет, и который можно было бы оставить напоследок, будет исправлен раньше наиболее важных. Если считаете необходимым, то можете также в описании или в комментарии к баг-репорту объяснить, почему вы в данном случае проставили именно такое приоритет.Добавьте фото и видео
Если есть подтверждающие баг доказательства, то стоит приложить их к баг-репорту. Во-первых, это поможет исполнителю задачи убедиться в существовании проблемы, если по каким-то причинам у него баг не будет воспроизводиться. А во-вторых, даст возможность разработчику\аналитику обратить внимание еще и на другие дефекты, на которые мог не обратить внимания сам автор тестового артефакта.
Старайтесь сделать так, чтобы на фото\видео было понятно, на каком окружении воспроизводится ошибка (например, ссылка в браузере). Также очень важно, чтобы качество файлов было приемлемого уровня: на фото должно быть всё было четко видно, а видео, как минимум, не должно не содержать никаких посторонних звуков.Используйте дополнительные инструменты
Если вы нашли баг — не останавливайтесь на этом, по возможности старайтесь пользоваться инструментами разработчика (DevTools), API (например, Postman) и др. для получения дополнительной информации. Например, у вас есть таблица, в которой после введения новых данных нужно нажать кнопку «Обновить», однако она не работает. Благодаря DevTools можно попытаться разобраться в чем же дело: это dev не реагирует на нажатие или же back не обрабатывает полученную информацию как надо. А если вы создаете какую-либо заявку, нажимаете кнопку «Отправить», а у вас появляется ошибка, попробуйте по возможности сделать такой же запрос по созданию заявки, но только через Postman. Это даст много дополнительной информации и для вас, и для ответственного за исправление выявленной ошибки.Закрывайте задачи вовремя
После того, как вы провели ретест ранее выявленной ошибки и убедились в том, что дефект устранен, сразу её закройте. Так она не будет висеть в системе и никого смущать: ни автора баг-репорта, ни остальных членов команды, которые учитывают при составлении плана работ все задачи с открытым статусом. В идеале также перед закрытием баг-репорта оставить в данной задаче соответствующий комментарий о том, что дефект устранен или другую полезную для команды информацию.Обращайтесь за советами к коллегам
Как бы это банально ни звучало, но не стесняйтесь просить помощи у своих коллег для написания баг-репортов — в любой адекватной команде на первом месте стоит улучшение качества продукта, а не критика коллег. К тому что, понимание того, что и как работает, помогает не только вам, но и всему проекту целом.
Также могу посоветовать в случае необходимости (например, при недостатке информации, обилии ошибок в описании проблемы и т.д.) корректировать и чужие баг-репорты. Это может повысить их качество и ускорить процесс исправления дефектов. Вот небольшая статистика из моего опроса:
Результаты говорят о том, что 80% специалистов вносят различные правки в чужие тестовые артефакты. Естественно, предварительно стоит обсудить этот момент с коллегами и выяснить, насколько корректировка, которую вы хотите ввести, действительно необходима и как вообще к подобного рода правкам относятся на вашем проекте.
Работа с чужими баг-репортами — это не только способ улучшить артефакты, но и возможность учиться друг у друга, что важно для роста всей команды.
Подводя итог, хотелось бы подчеркнуть две важные мысли.
Во-первых, прежде чем применять все приведённые советы, важно учесть специфику вашего проекта. В некоторых командах или системах баг-репорты требуют уникальных атрибутов, а где-то уже сложились свои правила и стандарты. Эти требования могут варьироваться в зависимости от специфики проектов, используемых инструментов и корпоративных подходов к управлению качеством. Соблюдение этих требований — это не только знак уважения к процессам команды, но и способ сделать ваши отчёты более полезными и эффективными.
Во-вторых, ошибки — это часть любого процесса, особенно, если вы только начинаете. Конечно, стоит стремиться к их минимизации, но не забывайте: с опытом приходит понимание тонкостей, и даже самые опытные специалисты допускают недочеты. Главное — учиться на них и продолжать двигаться вперёд. Как говорится, не ошибается только тот, кто ничего не делает.
