сообщить о баге что это
Как правильно сообщать о багах, чтобы их быстро исправляли
2017-02-17 13:57:52 2021-09-17 14:03:09
В разгар сосредоточенной деятельности программистов отвлекают вопросы в скайпе. Иногда достаточно ответить, но бывает, выясняется, что на проекте возникла ошибка, требующая исправления, и мы начинаем уточнять детали, создаем задание в багтрекере, согласовываем сроки решения. А возвращаясь к прерванному делу, обнаруживаем, что прошло сорок минут. А потом менеджер спросит: «Вася, почему ты задачу оценил в 7 часов, а выполняешь второй день?»
Уважаемый заказчик! Когда на проекте обнаруживается неполадка, и вы хотите быстрее сообщить о ней в чат, помните следующее.
 | Если изложить суть непонятно или сумбурно, на выяснение деталей уйдёт дополнительное время, которое оплачиваете вы. При этом от текущих дел отрываются один, а то и несколько сотрудников. |
 | Может создаться иллюзия срочности. Например, разработчик попытается воспроизвести указанный дефект, не дождавшись ответов на уточняющие вопросы, и сразу попытается его исправить, что хорошо, если проблема критическая, плохо, если минорная (а есть более важные задания), и очень плохо, если вы вообще не планировали исправление. |
 | Возможна и обратная ситуация: обсуждаемая в скайпе неполадка может там и остаться. Многие сотрудники справедливо полагают, что решение вопроса начинается с заведения задачи в багтрекере. Скайп — лишь инструмент коммуникации, где можно оперативно обсудить текущий проект. В багтрекере же фиксируются задания, комментарии и принятые решения. Разбор спорных ситуаций производится тоже по багтрекеру. Иными словами, если вы собираетесь написать в скайпе что-то вроде «было бы неплохо сделать так. », а потом, спустя неделю, возмущаться, почему до сих пор «так» не реализовано, то, пожалуйста, не надо. |
 | Если вы не заведёте задачу в багтрекере, её заведём мы. Тогда следует проследить, что с ваших слов записано верно. |
Что надо сделать?
Время идёт, проект не готов, а бюджет не резиновый. Есть два варианта.
Первый. Наш сотрудник (тестировщик, специалист службы поддержки или менеджер проекта) воспроизведёт неполадку, уточнит её критичность, занесет информацию в багтрекер, мобилизует программистов и обозначит примерный срок завершения. Такая схема успешно применяется, если бюджет проекта позволяет оплатить участие дополнительного специалиста.
Второй. Вы можете завести задачу самостоятельно. Если хотите, чтобы проблема была решена быстро, она должна быть правильно понята. С этого момента подробнее.
Заголовок
Итак, возникла неполадка, о которой нужно заявить. Первое, что указываем при заведении задачи, — это заголовок, при первом взгляде на который должно быть понятно, что случилось. Заголовок должен отвечать на три вопроса.
«Что?» — что, собственно, произошло?
«Где?» — в каком месте интерфейса вы видите проблему?
«Когда?» — при каких обстоятельствах проявляется проблема?
Приведем примеры, когда заголовок не отвечает ни на один из вышеуказанных вопросов.
Примеры, когда заголовок отвечает только на часть вопросов.
Примеры хороших заголовков, отвечающих на вопросы «Что? Где? Когда?».
Описание
В большинстве случаев, при хорошо составленном заголовке описание проблемы может даже не потребоваться. С другой стороны, качественно заполненное поле «Description» может нивелировать недостатки заголовка, и даже указать на решение. Были случаи, когда ошибка, имеющая детальное описание, исправлялась в течение десяти минут, а без такового — несколько часов. В первом случае разработчик сразу понял, какую строчку кода ему править. Во втором — полдня отлаживал код, прежде чем выяснил причины сбоя.
Что нужно указать в описании задачи.
 | Подробности | Помогающие воспроизвести неполадку и навести разработчика на возможную причину ошибки. Например, когда вы по пунктам описываете, что делаете, и как это приводит к проблеме. Выполняя эти шаги, разработчик воспроизведёт ошибку под отладкой и сможет приступить к её исправлению. |
 | Фактический результат | Напишите, что конкретно происходит. |
 | Ожидаемый результат | Напишите, что должно происходить. Упуская этот пункт, вы вынудите программиста искать ответ в требованиях, что займет время. Если явных требований не задокументировано, изложите собственное мнение, иначе разработчик всё равно обратится к вам и будет ожидать ответа, что отложит решение проблемы. Или исправит, как сочтет нужным, а его видение может отличаться от вашего. |
 | Скриншот | В некоторых случаях заменяет тысячи слов, особенно если замечание касается интерфейса или дизайна. |
Приоритет
Создавая задачу, вы можете определить степень серьёзности, исполняя роль руководителя проекта (ведь вы, по факту, им и являетесь). Градации серьёзности следующие.
Вот основное, что следует знать о заведении отчётов о дефектах в багтрекерах, и чаще всего этого достаточно для эффективного взаимодействия с разработчиками. Ну а если что-то действительно важное, всегда можно сообщить в скайпе: «Ребят, я там баг завёл срочный, вот ссылка на него. Когда исправите?».
Apple объяснила, как правильно сообщать о багах и проблемах с iPhone и iOS
Apple выпустила инструкцию, в которой рассказывается, как правильно сообщать компании о различных проблемах с айфонами и прошивками.
Всякий раз, когда вы регистрируете новый отчет об ошибке, будьте понятны и показывайте все наглядно. Предоставляете ли вы конкретные отзывы об ошибке, с которой сталкиваетесь, или общие отзывы — опишите вашу проблему подробно.
1. Все начинается с четкого заголовка. Он должен содержать емкое описание проблемы. Например, «события календаря в macOS 10.15.4 отсутствуют после создания быстрого события».
Плохо: «Отсутствуют события в календаре».
2. Если вы разрабатываете приложение, то укажите в описании и заголовке его название и версию сборки.
3. При описании своей проблемы тщательно расписывайте каждый шаг. Часто бывает полезно сделать вид, что тот, кто его читает, никогда не видел приложение или систему, о которой вы сообщаете.
Например, если вы напишете «Когда я создаю событие в Календаре, оно исчезает через мгновение», на экране недостаточно подробностей, чтобы воспроизвести проблему. Вы создаете событие календаря с помощью кнопки «Быстрое событие» или перетаскиваете, чтобы добавить новое событие? Как долго длится момент? Событие исчезло после выхода из многозадачности или вы остались в программе?
Вместо этого подумайте, как можно подробно описать свою проблему. Например:
• Нажмите кнопку «Быстрое событие» в приложении «Календарь».
• Заполните событие с любым названием.
• Нажмите «Создать событие».
Фактический результат: событие появляется в нужном месте календаре, но затем исчезает.
Ожидаемый результат: событие календаря должно появиться и остаться в моем календаре.
После заполнения ваших шагов воспроизведения и ожидаемого результата также стоит рассмотреть дополнительные факторы, которые могут повлиять на проблему.
• Вы вошли в iCloud?
• У вас есть какие-либо настройки специальных возможностей?
• Воспроизводится ли проблема подобным образом в других местах ОС?
4. Воспроизведите проблему и сделайте скриншоты или видеозапись экрана. Последнее особенно полезно, чтобы разработчики могли посмотреть все тщательно и, возможно, обнаружить ошибку, которую вы не заметили.
5. Укажите в баг-репорте логи ошибок. Для этого в сервисе создания отчетов есть специальная клавиша.
10 правил хорошего тона при описании багов
Здравствуйте, меня зовут Наталья, я инженер по тестированию компании Docsvision.
Иногда, когда я просматриваю ошибки, записанные новенькими (а иногда и старенькими) тестировщиками, рука машинально тянется к лицу. В голове возникает только одна мысль:
«Что? Что я сейчас прочитала?»
В интернете много информации о том, ЧТО обязательно должно присутствовать в баг-репорте. А я решила поделиться с вами своими мыслями о том, КАК нужно писать баг-репорт, чтобы было понятно, о чём вы пишете.
В первую очередь, я писала это для инженеров по тестированию и инженеров технической поддержки, которые передают нам баги, присланные заказчиками. Также моя статья может помочь сформировать описание возникшей проблемы при обращении пользователя в техподдержку: корректное описание позволяет без дополнительных вопросов быстрее обработать инцидент.
Вообще её может быть полезно почитать всем членам команды разработки ПО, которые фиксируют своё общение в багтрекинговой системе.
Приведу пример, чтобы стало понятно, от чего моя рука летит к лицу со скоростью света:
«В контроле файлов при наличии достаточного числа файлов, имена некоторых не отображаются полностью.
Создаём любой документ УД. На вкладке Регистрация в поле Добавьте файл, правым кликом мышь, и выбираем несколько файлов. Второй вариант, перетащить несколько файлов в данное поле. В резутате, если несколько файлов, названия не помещаются полностью. Только если развернуть карточку на весь экран можно увидеть всё полностью. Строка с файлом должна переноситься на следующую строку в контроле, но этого не происходит.»
(Орфография и пунктуация сохранены).
Какой-то невероятный кусок текста, состоящий из сплошного потока сознания.
Коллеги! Вы же пишете для других людей, у которых совсем другая голова и совсем другой образ мыслей. Вы должны писать понятно!
Вот ТОП-10 правил хорошего тона, которых я придерживаюсь сама и которые рекомендую коллегам:
1) Сначала глагол.
2) Принцип «Что-Где-Когда».
3) Обезличенность.
4) Простые конструкции.
5) Без лишних слов.
6) Сократить очевидное.
7) Упростить описание сложного действия.
8) По пунктам.
9) Однозначность.
10) Перечитать.
1. Сначала глагол
Магистр Йода из «Звёздных войн» говорил так, что его было непросто понять с первого раза. Его речь строилась по принципу «объект-глагол-субъект».
«Когда и тебе 900 лет исполнится, тоже не молодо будешь выглядеть ты».
В нашей речи глагол стоит в начале (если он есть).
Пример:
Плохо – «Скопированную карточку открыть на редактирование».
Хорошо – «Открыть на редактирование скопированную карточку».
2. Принцип «Что-Где-Когда»
Этот принцип общеизвестный – сначала надо написать «что», а уже потом «в каком месте» и «при каких условиях». Лучше всего работает при составлении краткого описания ошибки.
Что происходит? – «Не создаётся карточка», «Выдаётся необработанное исключение», «Не создаётся база данных».
Где происходит? – «В виртуальной папке», «На вкладке История», «В контекстном меню».
Когда происходит? – «По нажатию кнопки», «После смены состояния карточки», «При сохранении изменений».
Пример:
Плохо – «В отчёте при добавлении файла комментария текстовый комментарий стирается».
Хорошо – «Стирается текстовый комментарий в отчёте при добавлении файла комментария».
3. Обезличенность
Описание ошибки – это не летопись ваших действий, а руководство для другого человека. Уберите себя из описания.
Пример:
Плохо – «Нажимаем кнопку», «Открываю страницу».
Хорошо – «Нажать кнопку», «Открыть страницу».
4. Простые конструкции
Сложносочинённые и сложноподчинённые предложения, причастные и деепричастные обороты осложняют восприятие текста. Чем проще будет построено предложение, тем лучше.
Пример:
Плохо – «На панели инструментов есть кнопка с шестерёнкой, открывающая меню из двух пунктов, при наведении на которую не появляется всплывающая подсказка».
Хорошо – «Навести мышку на кнопку с шестерёнкой на панели инструментов – не появилась всплывающая подсказка».
5. Без лишних слов
Когда я смотрю советские фильмы, в которых каждая вторая фраза стала крылатой, я восхищаюсь тем, как тщательно проработана речь персонажей. Ни одного лишнего словечка. Каждое слово на вес золота. Так же нужно составлять и описание ошибок – каждое слово должно что-то значить.
Привычная речь богата эпитетами, местоимениями, предлогами, которые дополнительного смысла не привносят. Если справиться с собственным мозгом очень сложно, запишите весь поток сознания как есть, а потом удалите из текста те слова, которые не несут смысловой нагрузки.
Пример:
Плохо – «По какой-то причине смена значений в поле работает довольно странно – по сути обновление поля происходит через какой-то промежуток времени».
Убрать слова «По какой-то причине», «довольно», «странно», «по сути». Они не содержат ценной информации и могут быть удалены из описания без потери смысла. Словосочетание «какой-то промежуток времени» может быть заменено на более короткий синоним.
Хорошо – «Обновление значений в поле происходит с задержкой».
6. Сократить очевидное
Некоторые действия не являются специфичными для тестируемой системы. Например, сохранение некоторого объекта, закрытие окна, вызов контекстного меню, двойной клик, запуск приложения. Эти действия обычно интуитивно понятны, поэтому при описании ошибки не стоит заострять на них внимание.
Пример:
Плохо – «Найти ярлык приложения на рабочем столе, кликнуть по нему 2 раза левой кнопкой мыши».
Хорошо – «Открыть приложение по ярлыку».
7. Упростить описание сложного действия
Допустим, в тестируемой системе есть некоторая специфичная операция. Новенькие тестировщики или разработчики, которые плохо ориентируются в интерфейсе, могут не знать, как выполнить такую операцию. Поэтому описать выполнение этой задачи можно через описание простых действий, которые помогут её выполнить.
Пример:
Плохо – «Согласовать документ», «Выполнить синхронизацию свойств».
Хорошо – «Нажать кнопку «Согласовано» на панели инструментов карточки документа», «Выбрать команду «Синхронизировать свойства» в контекстном меню объекта».
Да, это увеличивает объём описания. Зато уменьшает время воспроизведения за счёт сокращения количества вопросов типа «А как это сделать?» к автору ошибки.
Важно! То, что очевидно для вас, не всегда очевидно для другого человека.
Лично я использую 2 приёма оценки очевидности своего описания:
1) Представить, что видишь интерфейс впервые;
2) Спрогнозировать вопросы, которые могут появиться у читателя.
8. По пунктам
Хорошая практика – разбить шаги воспроизведения на пункты. Это даёт 2 главных преимущества:
1) Упрощается прохождение шагов воспроизведения.
2) Появляется возможность сослаться на некоторый пункт.
Пример:
1) Открыть справочник категорий.
2) Добавить новую категорию. Сохранить, закрыть справочник.
3) Повторить пункты 1 и 2.
Или
1) Создать карточку документа.
2) Создать карточку документа другого вида.
3) Открыть карточку, созданную на шаге 1.
Сколько действий должен содержать один пункт? Вопрос, на который все тестировщики отвечают по-разному.
Я считаю, что общее количество пунктов должно быть не более 5-6, последующие пункты уже воспринимаются сложнее, первое преимущество теряется.
Один пункт должен содержать набор действий, позволяющий достичь некоторой точки. Такой точкой может быть возникновение системного сообщения, создание некоторого артефакта в системе – всё, на чём можно приостановить воспроизведение.
9. Однозначность
Речь наша богата синонимичными словами и словосочетаниями, одни из них уместны и понятны всем, другие – не очень. Я придерживаюсь следующих трёх принципов.
Первый принцип – избегать жаргонных слов и слов с размытым смыслом.
Пример:
Плохо – «система ругается», «клацнуть в молоко», «окно уезжает за экран», «кансельнуть».
Хорошо – «выдаётся необработанное исключение», «кликнуть в пустое место окна», «окно перемещается за пределы экрана», «отменить».
Второй – использовать принятые в вашей команде слова. Второй принцип иногда может исключать первый. Например, если все поголовно в компании говорят «задизейблено» вместо «неактивно», значит, употребление этого слова будет более понятно остальным членам команды. Никто же не ходит в магазин за гальваническим элементом, все ходят за батарейками.
Важно! Если разные коллеги говорят по-разному (кто-то «хинт», кто-то «подсказка»), для эффективности дальнейшего поиска такой ошибки лучше при описании употребить и то, и другое слово.
Третий – одно из правил, провозглашённых в фильме «Посвященный», — «Правильно употребляй слова». Например, иногда словом «символ» заменяют слово «буква», но это разные входные данные, не следует их путать.
10. Перечитать
После того, как вы написали и откорректировали описание ошибки, обязательно перечитайте от начала и до конца. Возможно, вы найдёте опечатку, нечаянный повтор слова, лишний символ или что-то в этом духе. Поскольку взгляд замыливается от чтения собственного текста, я использую метод переключения внимания – увожу взгляд буквально на пару секунд на растение в горшке или соседа слева, а потом возвращаюсь к тексту.
Дополнительно я советую почитать книжку Ли Лефевера «Искусство объяснять. Как сделать так, чтобы вас понимали с полуслова».
Учитесь доносить свои мысли грамотно и понятно, чтобы вас было легко и приятно читать. И да пребудет с вами сила!
P.S.: Убийца – дворецкий, а тот «невероятный кусок текста» из начала статьи должен был выглядеть вот так:
«Не помещаются полностью названия файлов в файловом контроле документа при наличии нескольких файлов.
1) Создать любой документ УД. Оставить в режиме окна, не переходить в полноэкранный.
2) Добавить более 1 файла на вкладке Регистрация в файловый контроль (командой контекстного меню или перетаскиванием).
Результат: Названия файлов видны не полностью. Недостаточно места для отображения названий файлов при размере окна по умолчанию.
Ожидаемый результат: Названия файлов должны отображаться полностью.»
Баг и баг репорт
Как Вы думаете, какой навык тестировщика — самый важный?
Может автоматизация тестирования?
Что-то из soft-skills?
Умение работать в команде?
Как насчет поиска багов?
Написание хороших баг репортов — это самый важный навык тестировщика!
Потому что хороший баг репорт это:
Ни один другой навык не приносит столько пользы, как этот)
Вы можете быть супер-аналитиком, находить по 100 багов за день, общаться и дружить со всеми разработчиками. Но, если Вы не умеете создавать баг репорты — баги не будут исправляться. А если баги не будут исправляться… Вы сами можете догадаться, что произойдет 🙂
Научиться писать качественные баг репорты — просто!
Каким образом и что для этого нужно?
Читайте в этой статье)
Что такое Баг / Дефект?
Перед тем, как начать разговор о баг репортах, стоит очень хорошо разобраться, что такое “баг”, ведь его мы и будем описывать 🙂
Слово “баг” — это технический жаргон [1] [2]. Оно используется в разговорах, статьях и приложениях (Jira, TestRail и т.п.)
Стандарты [3] и книги [4] используют другое название — “дефект”, оно более профессиональное.
Так как это не научная статья, мы будем использовать слово “баг”, как более распространенное и привычное 🙂
Существует несколько определений бага:
Данные определения описывают баги в коде и их сложно применить к багам в требованиях, UI / UX и т.п.
На этапе проверки требований у нас нет компонента, системы (см. определение 1,3) или приложения (определение 2). У нас есть только текст, который их описывает, если он вообще существует 😂
Более универсальное и доступное определение приведено в книге [4]:
Баг — это отклонение фактического результата от ожидаемого результата.
Давайте рассмотрим несколько примеров багов.
Откуда берутся баги?
Баги являются следствием ошибок.
В свою очередь, ошибка — это действие человека, которое приводит к неправильным результатам [4].
Причин возникновения ошибок множество [5]:
Ошибки делают все и делают их всегда.
Это неотъемлемая часть природы человека и ее невозможно изменить или обойти.
Лучшие спортсмены, ученые, инженеры, политики, актеры, музыканты — ошибаются. Бизнес-аналитики, разработчики, тестировщики, дизайнеры, администраторы, переводчики и т.п. — не исключение…
Все ли баги нужно исправлять?
Нет, не все.
В идеальном мире — наверное да, но мы не знаем где он 🙂
Что мы знаем, так это то, что все люди ошибаются. Тестировщики тоже. Иногда Вы можете замечать вещи, которые багами не являются.
Это может происходить потому что вы:
Ситуация, когда Вы создаете “ложный” баг репорт — называется false-fail result [3].
Такие “моменты” характеризуют качество документации, качество подготовки к тестированию, качество проведения тестирования и анализируются QA (Вы ведь уже знаете, что QA ≠ тестирование?)
Если баг на самом деле существует, то перед исправлением всегда нужно оценивать его критичность, срочность и сложность исправления.
Zero bug policy — отличный процесс работы с багами при использовании гибкой разработки
Жизненный цикл бага
Каждый найденный баг всегда проходит через конкретные “этапы”, которые называются жизненный цикл бага.
Цикл, его этапы и переходы между ними сильно зависят от процесса тестирования и разработки, используемого в компании. Поэтому здесь приводится базовый процесс, этапы которого существуют в 99% случаев. Он прост для понимания, но помните, в реальном мире все немного сложнее 🙂
Не путайте жизненный цикл бага и жизненный цикл ПО — это не связанные вещи!
Давайте рассмотрим каждый этап и переходы между ними подробнее.
Этапы жизненного цикла бага
1. Открыт (Open) — баг создан, оформлен и передан разработчику / команде разработки
2. В Работе (In Progress) — ведутся работы по исправлению
3. Исправлен (Ready for check) — баг исправлен и передан тестировщику на повторную проверку
4. Закрыт (Closed) — баг проверен и больше не воспроизводится
Переходы бага между этапами жизненного цикла
Переходы между этапами жизненного цикла пронумерованы в соответствии с нумерацией списка ниже.
1. Открыт — Закрыт. Если баг — это “не баг”, он может сразу быть закрыт, без промежуточных операций.
Иногда этот переход выносят в отдельный этап жизненного цикла, который называется Отклонен (Rejected). Он используется для анализа процесса тестирования или оценки работы тестировщиков / разработчиков.
На некоторых сайтах можно прочитать, что “баг отклоняется разработчиком, если он считает, что дефект не важен”.
Мы считаем, что это не верно, потому что мнение разработчика — субъективное. Теоретически, он может “отклонять” баг если:
Если происходит отклонение бага, разработчик должен аргументированно описать, почему он не считает найденную неточность багом, а решение про исправление или закрытие должен принимать человек, который отвечает за качество (QA, PO, PM).
2. Открыт — В Работе. Баг подтвержден и передан разработчикам, которые начали работу над исправлением.
3. В Работе — Закрыт. Бывает, что в ходе исправления ошибки разработчик понимает, что это не ошибка, а что-то другое. (фича / неточность в требованиях, которую обсудили без тестировщиков и т.п.) В этом случае разработчик описывает, почему это не баг, и закрывает задачу.
Иногда этот переход выносят в отдельный этап жизненного цикла, Не Баг (Not A Bug). В таком случае задача возвращается тестировщикам, они ее пересматривают и либо закрывают, соглашаясь с разработчиком, либо исправляют описание и заново открывают.
Появление большого количества багов в статусе “Не Баг” говорит о проблемах в коммуникации и / или документации.
4. В Работе — Исправлен. Ошибку локализовали и исправили, она передана тестировщику.
5. Исправлен — Открыт. Тестировщик проверил исправление, баг все еще воспроизводится, то есть не исправлен. Он возвращается разработчику (возможно с указанием каких-то дополнительных деталей)
Этот переход может существовать как отдельный этап жизненного цикла бага — Переоткрыт (Reopened).
Появление большого количества багов в статусе “Переоткрыт” может говорить о проблемах в оформлении багов и использоваться для анализа качества работы тестировщиков.
6. Исправлен — Закрыт. Тестировщик проверил исправление, баг больше не воспроизводится.
7. Закрыт — Открыт. Если баг случайно закрыли, должна быть возможность его переоткрыть.
Не стоит переоткрывать закрытые баги, если они уже были исправлены, проверены и закрыты. Ситуация может возникать в ходе регрессионного тестирования.
Такой “операцией” Вы испортите аналитику и метрики + создадите путаницу в релизах и процессе работы и т.п.
Лучше создавать новый баг, скопировав закрытый и связав их между собой. Тогда путаницы не будет, а разработчику не придется искать ошибку, которую он уже исправлял 🙂
Теперь, когда мы разобрались с багами, причинами их возникновения и жизненным циклом — мы можем переходить к рассмотрению баг репорта 🙂
Что такое баг репорт (bug report)?
Баг Репорт (Bug Report) — документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [IEEE 829]
Мы уже знаем, что такое баг, поэтому определение можно упростить.
Баг Репорт (Bug Report) — документ, содержащий информацию о найденном баге.
Другие названия этого документа:
Зачем нужны баг репорты?
Почему баги нельзя исправлять сразу, зачем писать отчеты? Лишняя работа, только время тратить… — типичный менеджер, который не слышал о качестве
Написание баг репортов — чрезвычайно полезный процесс, потому что:
1. Происходит фиксации факта существования бага
Есть репорт — есть прецедент для реакции.
Нет репорта — никто ничего не будет делать.
Именно поэтому не стоит писать баги в скайп / чат / говорить лично и т.п.
Есть вероятность, что о нем забудут (и вы, в том числе) и не исправят.
Потом баг найдет либо заказчик в ходе приемочного тестирования, либо клиент — и вряд ли они будут этому рады… Вы тоже не будете рады, когда разработчик скажет, что он впервые это видит.
2. Баг репорт помогает разработчику
Для воспроизведения и последующего исправления бага разработчикам нужна информация. Она должна быть максимально точной, полной и понятной. Без нее разработчику придется тратить время на поиск и анализ ошибки, и вряд ли он будет этому рад. Да и менеджмент не будет рад, так как разработчик будет заниматься не разработкой, а чем-то другим…
В докладе Егора Бугаенко Testing and Testers на TestCon 2020, именно об этом был 4-ый вопрос и объяснения, почему это важно. Рекомендую посмотреть 🙂
3. Появляется возможность приоритизации исправлений
Если у вас есть несколько багов — вам всегда придется выбирать, какой из них исправлять в первую очередь, потому что все сразу исправить не получится.
4. Появляется возможность анализа ошибок
Имея информацию о найденных дефектах Вы можете определять первопричины их возникновения и вносить изменения в рабочие процессы, чтоб их предотвращать. (Привет QA)
5. Тестировщик содействует устранению бага
Хорошо созданный баг репорт — это огромная помощь разработчику, так как из полученной информации он быстро сможет определить, где находится ошибка и исправить ее.
6. Появляется возможность контроля этапа исправления бага
Вы уже знаете, что до момента исправления, каждый баг проходит через определенные стадии жизненного цикла.
Наличие отчета о дефекте с изменяющимся статусом позволяет легко и быстро определять точное “положение” бага и контролировать его исправление.
7. Появляется возможность оценки качества продукта в текущий момент времени
Если в ходе тестирования было найдено 50 багов и все они были оформлены как баг репорты — вы, как менеджер, сможете оценивать готовность продукта, оценивать объем требуемых доработок, принимать решения о релизе и т.п.
Отчеты о дефектах дают командам очень полезную и важную информацию, которая необходима для контроля качества продукта.
Именно поэтому навык написания хороших отчетов критически важен для любого профессионала-тестировщика и его нужно освоить в совершенстве 😉
Атрибуты баг репорта
Баг репорт — это технический документ.
У него есть некий набор атрибутов (полей, параметров) для структуризации информации.
Атрибуты баг репорта можно разделить на 2 группы:
Основные поля
Дополнительные поля
Серьезность бага (Bug Severity)
Серьезность характеризует уровень влияния бага на работоспособность приложения / компонента и необходима для дальнейшего проставления приоритета.
Приведенные ниже уровни — не стандартизированы и могут отличаться в разных компаниях.
S4 | Blocker
Блокирующий — баг описывает ситуации, когда ПО не работает в принципе.
S3 | Critical
Критический — баг влияет на критический функционал или критические данные.
К критическому функционалу относятся функции приложения, без которого само приложение станет бессмысленным, либо перестанет выполнять свои основные функции.
Примеры критических функций в разных приложениях:
Помимо критического функционала, к критическим багам относятся:
S2 | Major
Серьезный — баг не влияет на критический функционал, но создает неудобства при использовании приложения / системы.
К этому уровню относятся баги, связанные с:
S1 | Minor
Незначительный — баг не влияет на бизнес логику приложения.
Чаще всего к этому уровню относятся баги в реализации UI (верстке), отсутствие переводов и т.п.
S0 | Trivial
Тривиальный — баг никак не влияет на качество продукта.
Из-за того, что такие баги не влияют на качество продукта, преднамеренно их не исправляют (они не “окупаются”). Обычно, правку делают в ходе реализации смежной задачи.
Типы багов
Дополнительный атрибут “Тип бага” необходим для обнаружения слабых мест в процессе разработки и тестирования, а также для их последующей корректировки.
Используемые типы багов определяются в зависимости от направления, размера и сложности проекта.
Приведенные ниже типы багов относятся к WEB сайтам.
UI (ошибка в верстке)
Баг в верстке — следствие ошибки в разметке (HTML) или стилизации (CSS) элемента страницы в специфическом окружении.
UX (ошибка в удобстве)
Баг в удобстве — неудобство / нелогичность работы с элементами / функционалом страницы.
Functional (ошибка в функционале)
Баг в функционале — несоответствие логики работы компонента заявленным функциональным требованиям.
SEO (ошибка в seo)
Баг в seo — ошибка, которая влияет на SEO (нарушение нефункциональных требований, касающихся seo).
Алгоритм создания баг репорта
Предположим, Вы нашли баг и приступаете к написанию баг репорта.
Ниже приведен алгоритм, следуя которому Вы точно ничего не упустите и снизите вероятность создания дубликатов или некачественных отчетов.
🔥 Если Вы хотите потренировать свой навык создания отчетов о дефекте и получить оценку с рекомендациями, Вы можете оставить заявку на получение практического задания по созданию баг-репортов.
Пример хорошего баг репорта (bug report example)
Предположим, в ходе исследовательского тестирования Вы заметили следующее:
И Вы хотите создать отчет о найденном баге (нет перевода текстов ошибок).
Итоговый вариант может выглядеть так:
Заголовок / Краткое описание / Тема / Summary / Title
Не переведены на украинский язык тексты ошибок (что?) на форме “Зворотний зв’язок” на странице https://itawards.ua/ua (где?) в UA версии сайта (когда?)
Скриншот / видео
Скриншот / ссылка на скриншот
Шаги к воспроизведению
Фактический результат
Отображаются ошибки на английском языке
Ожидаемый результат
Отображаются ошибки на украинском языке
Серьезность
Кто внимательно рассмотрел изображение с багом (или решил сам протестировать форму) — мог заметить еще несколько “странностей”.
Например, некоторые тексты ошибок содержат грамматические ошибки, атрибуты полей содержат свойство autocomplete, которое не работает в большинстве браузеров, а анимация на форме зависает при наведении на любой из прямоугольников.
Может показаться, что это мелочи, и так оно и есть. Но если таких мелочей будет слишком много — продукт не будет вызывать доверия у клиента и его не будут считать качественным.
The Devil is in details.
🔥 Если Вы хотите потренировать свой навык создания отчетов о дефекте и получить оценку с рекомендациями, Вы можете оставить заявку на получение практического задания по созданию баг-репортов.
Пример баг репорта в Jira
Jira является одной из самых распространённых систем управления проектами в мире и очень часто используется в ИТ.
Так может выглядеть описанный выше баг репорт в Jira:
Пример баг репорта в Jira
Основные поля являются обязательными для заполнения при создании бага, без них задача просто не сохраниться 🙂
Ошибки при создании баг репорта
Создание хороших баг репортов требует определенных знаний, навыков и опыта.
Начинающим тестировщикам (и не только, как бы это ни было странно) иногда тяжело справляться с этой задачей, и они часто делают следующие ошибки:
Знание типичных ошибок помогает проверять самого себя (можно создать чек-лист) и позволяет создавать более качественные отчеты без возвратов на доработку!
Резюме
В статье мы рассмотрели все, что нужно знать начинающему тестировщику о багах, баг репортах и их жизненном цикле.
Мы поняли, что баг репорты — это чрезвычайно важные документы, потому что именно они описывают найденные в процессе тестирования дефекты, исправление которых и повышает качество продукта.
И именно правильное и качественное оформление баг репортов является ключевым навыком тестировщика.
🔥 Если Вы хотите потренировать свой навык создания отчетов о дефекте и получить оценку с рекомендациями, Вы можете оставить заявку на получение практического задания по созданию баг-репортов.
Если у вас есть вопросы или предложения — пишите нам в Телеграм!
Если вам интересно тестирования и Вы хотите получать актуальную информацию по этой теме — подписывайтесь на наш Tелеграм канал. У нас очень интересно: статьи, видео, тесты, опросы, нет спама 😉
Источники
Что такое баг?
Баг — это отклонение фактического результата от ожидаемого результата.
Здесь:
— фактический результат — это то, что мы “видим” или то, что произошло после проделанных действий
— ожидаемый результат — это ожидания наблюдателя, которые он получил из требований, спецификаций, любой другой документации, личного опыта и здравого смысла
Откуда берутся баги?
Баги являются следствием ошибок.
В свою очередь, ошибка — это действие человека, которое приводит к неправильным результатам.
Что такое баг репорт (bug report)?
Баг Репорт (Bug Report) — документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [IEEE 829]
Баг Репорт (Bug Report) — документ, содержащий информацию о найденном баге.
Что такое Серьезность бага (Bug Severity)?
Серьезность характеризует уровень влияния бага на работоспособность приложения / компонента и необходима для дальнейшего проставления приоритета.