Как оформить баг репорт в excel
Правила оформления записей в баг-трекере в каждой компании свои — это зависит как от политики компании, технологии разработки, используемного баг-трекера, типа проекта и много чего еще. Но в любом случае хороший баг-репорт обладает определенными характеристиками.
Если кратко, то хороший баг-репорт позволяет:
1. воспроизвести проблему (это не всегда возможно, но надо стремиться).
2. понять, в чем проблема и какова ее важность.
Как написать хороший баг-репорт?
Для начала надо подготовиться. Если вы обнаружили баг, не стоит моментально бежать в баг-трекер и писать «ничего не работает!». Воспроизведите ошибку. Воспроизвелась? Отлично. Не воспроизвелась? Значит, что-то вы не учли. Вспоминайте, что делали.
Снова воспроизвелась? Ура! А теперь минимизируйте количество шагов для воспроизведения, удостоверьтесь, что нет ничего лишнего.
Если используются какие-то входные данные, удостоверьтесь, что и они не содержат лишнего (действительно ли весь этот здоровенный кусок текста роняет редактор, а не один символ из него?).
Когда вы поняли, какие именно данные и какие ваши действия приводят к проблеме, кратко сформулируйте ее суть — придумайте заголовок баг-репорта. Опишите проблему настолько подробно и конкретно, насколько позволяет заголовок, при этом не увлекаясь его длиной :)
Пример плохого заголовка: «Все виснет, когда я вставляю текст из буфера обмена»
Пример «более хорошего» заголовка: «Редактор зависает при вставке текста, содержащего символ N, из буфера обмена по Ctrl+V»
Allenary: Можно еще упомянуть принцип «Что? Где? Когда?». В большинстве случаев это помогает написать удачный заголовок/подробное описание, Например,
Что: неправильный расчет данных
Где: на странице NNN
Когда: после ввода а поле Y отрицательного значения.
Старайтесь не писать фразы типа «я кликаю на ссылку», «я нажимаю кнопку» и им подобные. И заголовок, и описания шагов — это руководство к действию для тех, кто будет исправлять проблему, поэтому лучше формулировать как «кликнуть на ссылку», «нажать на кнопку».
Теперь откройте баг-трекер, начните заполнять форму баг-репорта.
Запишите заголовок.
В каких-то баг-трекерах поля «Подробное описание» и «Шаги для воспроизведения» различаются, в каких-то — нет.
Если поле «Подробное описание» есть, опишите в нем проблему более подробно — уточните те детали, которые пришлось опустить в заголовке. Если вы понимаете, в чем причина проблемы (используется устаревшая формула для расчетов, не учитывается какое-то значение и т.д.) — тоже пишите все здесь. Если не знаете — лучше не гадайте.
Если в форме записи об ошибке нет отдельного поля Affect version (версия продукта, в котором проявляется проблема), то укажите версию здесь.
«Шаги для воспроизведения» — основное поле для заполнения в баг-репорте.
Запишите шаги, которые вы определили. Как уже было сказано, шагов должно быть необходимо и достаточно для воспроизведения проблемы. Лишние не пишите. Необходимых тоже не пропускайте :)
После описания шагов обязательно напишите результат — что получилось.
Далее здесь же опишите ожидаемый результат, если это необходимо. Конечно, не стоит писать «Редактор не падает», но если, например, результаты расчетов не соответствуют ожидаемым, то это надо указывать.
Таким образом, описание шагов для воспроизведения должно выглядеть как-то так:
Шаги для воспроизведения:
1. Открыть…
2. Кликнуть…
3. Ввести в поле… значение N1
4. Ввести в поле… значение N2
4. Кликнуть кнопку Calculate
Результат:
В поле Result отображается V1.
Ожидаемый результат:
В поле Result отображается V2.
Если требуются исходные файлы, данные, дампы и пр. — сразу приаттачьте. Само собой, файлы должны содержать только информацию, необходимую для воспроизведения ошибки. Подчистите все лишнее.
Если проблема с визуальным отображением, то скриншот обязателен — можно будет понять ошибку и без воспроизведения шагов. Khizhnyak: На скриншотах лучше указывать место с ошибкой. Стрелочкой или просто полосой контрастного цвета. Здорово ускоряет «чтение» скриншота.
Но вставлять скриншоты в каждый баг-репорт совершенно не обязательно: пожалуйста, не плодите лишних сущностей. Если он ничем не поможет в воспроизведении проблемы — не тратьте время на его изготовление.
Кстати, про видео воспроизведения ошибки: оно может помочь разве что для подтверждения, что проблема действительно есть, просто воспроизвести ее сложно. Но часто ли вы делаете запись экрана заранее? :)
По остальным полям.
Severity, Priority.
Наличие этих полей и значения в этих полях отличаются от багтрекера к багтрекеру.
Severity — это критичность бага с точки зрения тестировщика: фича, опечатка в тексте, мелкая проблема, значительная проблема, падение продукта, блокирующая проблема и пр.
Priority — приоритет, с которым проблема должна быть исправлена.
Если есть оба поля, то тестировщик, как правило, выставляет только Severity, а Priority — старший тестировщик/старший программист/менеджер или любой другой ответственный за это дело человек.
Если есть только одно поле, то выставляем его.
«Какой приоритет ставить багу?» На этот вопрос нет однозначного ответа, все зависит от каждого конкретного случая. Но старайтесь не увлекаться и не ставить всем багам подряд высокий или критичный приоритет, реально оценивайте их критичность для проекта.
Можно выделить несколько принципов написания хороших баг репортов:
- Тщательно объясните, как воспроизвести ошибку. Сообщите всю необходимую для этого информацию, а также свои размышления о возможных причинах возникновения ошибки.
- Описывайте всё максимально подробно. Особенно это относится к ожидаемому и фактическому результатам, а также шагам воспроизведения.
- Пишите отчёт понятно. Используйте общеупотребимую лексику, точные названия элементов ПС, аккуратно оформляйте написанное.
- Давайте ссылку на требование. Если это возможно, обязательно давайте ссылку на соответствующее требование, к нарушению которого приводит фактический результат выполнения ПО.
- Чётко указывайте окружение. Здесь имеется в виду ОС, браузер, настройки и т.п., под которым произошла ошибка.
- Помните, что в баг-репорте нет места эмоциям. Помните, что баг-репорт – это технический документ и мы пишем роботу .
- В одном отчёте описывайте ровно одну проблему. Если вы видите две ошибки – пишите два отчёта.
- Если вам хватает знаний, проведите начальный анализ возможных причин возникновения ошибки и опишите его результаты в разделе «Комментарии».
- Попытайтесь найти наиболее серьёзные последствия ошибки. Возможно, то, что казалось незначительны вначале, на самом деле может привести к очень серьёзным неприятностям.
- После написаний отчёта ещё раз внимательно его перечитайте. Убедитесь, что все необходимые поля заполнены, и всё написано верно.
- Помните, что вам же самим потом придётся верифицировать баг по своему же баг-репорту.
- Пишите отчёт об ошибке сразу же, как только вы обнаружили ошибку. Откладывание записи «на потом» приводит к тому, что вы или вообще забудете об этой ошибке, или забудете о каких-то важных деталях. Также несвоевременное написание отчёта об ошибке не позволяет проектной команде реагировать на её обнаружение в реальном времени.
Шаблоны баг репортов для скачивания
[wpdm_category cols=»1″ toolbar=0 item_per_page=10 template=»link-template-calltoaction3.php»]
Что пишут в блогах
Конференции
Heisenbug 2022 Spring
Большая техническая конференция по тестированию
Online — с 30 мая по 1 июня. Offline-день — 21 июня
Профессиональная конференция по автоматизации в тестировании и рядом
27 и 28 июня, Москва, Radisson Slavyanskaya.
Что пишут в блогах (EN)
Разделы портала
Онлайн-тренинги
Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова
Баги, баги, баги! Нельзя обсуждать разработку ПО, не затрагивая тему багов. Поначалу термин "баг" может казаться странным жаргоном для "дефекта". По коду и машинам что, бегают жучки и паучки? Как правило, нет, но иногда таки да! В 1947 году Грейс Хоппер нашла мертвого мотылька, застрявшего в реле гарвардского компьютера Mark II, и в отчете о "жучке" шутила, что нашла настоящего жука за компьютерным дефектом. Несмотря на то, что изобретатели вроде Томаса Эдисона использовали термин "баг" для описания технологических глюков задолго до 1947 года, именно этот мотылек зафиксировал терминологию для компьютеров и ПО.
Баги случаются. Почему? Потому что никто не идеален, и поэтому не существует идеального ПО. Создание высококачественного ПО требует хорошего дизайна для устойчивости к багам, хорошего внедрения, дабы избежать багов, и хорошей обратной связи, чтобы сообщить о багах, когда они неизбежно возникнут. В статье я собрал лучшие практики для создания хороших баг-репортов.
Что такое баг-репорт?
Баг – это всего-навсего дефект. Термин относится исключительно к проблемам в ПО. Однако баг-репорт (или тикет) – это письменное описание, детализирующее дефект. Как правило, баг-репорты пишутся в инструменте управления проектом вроде Jira. Баг и отчет о нем – это две разные вещи. Естественно, что не обнаруженные баги могут отлично существовать в продукте, когда отчетов о них еще не существует.
Когда надо писать баг-репорт?
Баг-репорт надо писать, когда обнаружена новая проблема, которая выглядит как дефект. Проблемы обнаруживаются в ходе такой тест-деятельности, как прогон автотестов или ручное исследовательское тестирование. Их также находят при разработке новых фич. В худшем случае их найдут пользователи и начнут жаловаться!
Заметьте, я использую термин "проблема", а не "дефект". Всем проблемам нужны решения, но не все проблемы – это действительно дефекты. Иногда сообщивший о проблеме пользователь не знает, как должна работать фича. Иногда дело в неправильно сконфигурированном окружении. Член команды, выявивший проблему или получивший жалобу от клиента, должен провести небольшое расследование, чтобы убедиться, что проблема действительно выглядит как дефект ПО. Первоначальное расследование нужно проводить немедленно, пока еще жив контекст.
Если проблема выглядит реальным дефектом, а не недопониманием и не плохой настройкой конфигурации, детектив должен поискать эту проблему среди существующих баг-репортов. На нее или что-то похожее мог недавно наткнуться кто-то еще. Баги также могут появиться вновь даже после "исправления". Добавление информации в существующие репорты – куда лучшая практика по сравнению с созданием дубликатов.
Что, если проблема неясна? Если я не уверен, баг это или другой тип проблемы, я спрашиваю коллег. Я пытаюсь задавать вопросы вроде "Выглядит ли это правильным? Что может вызывать такое поведение? Может, я что-то сделал не так?" Слепо плодить баг-репорты для каждой проблемы – вести себя как мальчик из сказки, который кричал "Волки": команда будет менее чувствительной к предупреждением о реальных, важных багах. Небольшое расследование демонстрирует ваши хорошие намерения и во множестве случаев избавляет команду от лишней работы позднее. Несмотря на это, в случае сомнений создать репорт лучше, чем не создать. Небольшое количество ложноположительных результатов лучше риска реальных проблем.
Зачем нужны баг-репорты?
При обнаружении реального бага команда должна написать о нем репорт. Просто поговорить о баге проще и быстрее, особенно в небольших командах, но фиксировать это письменно важно для целостности процесса разработки ПО. Письменный отчет – это артефакт, который требует решения.
- Репорт создает петлю обратной связи для разработчиков.
- Репорт содержит всю информацию о баге в одном месте.
- Репорт можно отслеживать в инструменте управления проектами.
- Репорт можно соразмерять и приоритезировать относительно других задач разработки.
- Репорт хранит рабочую историю бага.
Баг-репорты помогают сделать исправление багов частью процесса разработки. Они привлекают к багам внимание, и их непросто игнорировать или проморгать.
Что входит в баг-репорт?
Вне зависимости от инструмента или процесса, хорошие баг-репорты содержат следующую информацию:
- Краткое описание проблемы
- Краткое, однострочное описание дефекта
- Которое ясно сообщает, что не так
- И используется в заголовке репорта.
- Идентификатор репорта
- Уникальный идентификатор баг-репорта.
- Как правило, генерируется автоматически инструментом управления вроде Jira
- Полное описание
- Подробное описание проблемы
- Разъясняет всю релевантную информацию
- Четкое и внятное
- Шаги воспроизведения
- Внятная процедура ручного воспроизведения проблемы
- Могут быть шагами упавшего тест-кейса
- Включают фактические и ожидаемые результаты
- Случаи, когда дефект воспроизводится и НЕ воспроизводится
- Версия продукта, ветка кода, название окружения, конфигурация системы, и так далее.
- Воспроизводится ли дефект постоянно или "плавает"?
- Артефакты
- Приложите логи, скриншоты, файлы, ссылки, и т. п.
- Влияние
- Как влияет дефект на пользователя?
- Блокирует ли он деятельность разработки?
- Какие кейсы упадут из-за этого дефекта?
- Анализ первопричин
- Если это известно, объясните, чем вызван дефект
- Если это неизвестно, предложите возможные причины
- Внимание: явно отделяйте доказательства от спекуляций!
- Приоритезация
- Если это возможно, назначьте задаче хозяина
- Назначьте ей серьезность или приоритет на основании гайдлайнов и здравого смысла
- Если это применимо, назначьте дедлайн
- И все остальное, что может понадобиться вашей команде.
- Воспроизводимость
Я всегда использую этот список в качестве шаблона, создавая баг-репорты. К примеру, в баг-репорте в Jira я делаю каждый пункт списка заголовком в поле "Описание". Иногда я пропускаю разделы, если мне недостаточно информации, но, как правило, не открываю баг-репорт, не имея на руках большей части этих сведений.
Как обращаться с баг-репортом?
Одним словом: профессионально. Обращайтесь с баг-репортами профессионально. Что это значит?
Давайте как можно больше информации в своих репортах. Баг-репорты – это форма коммуникации и записи. Когда вы не говорите толком ничего, кроме "ну, сломалось", это не поможет никому решить проблему. Давайте полезную, актуальную информацию, чтобы те, кто не находил этот баг, вникли в него достаточно, чтобы суметь помочь.
Приоритезируйте баги с умом. Находя проблему, исследуйте ее. Если вам нужно другое мнение, попросите о нем. Когда кто-то отправляет вам или команде баг-репорты, приоритезируйте их, исправьте баги, и отчитайтесь перед тем, кто сообщил о проблеме. Не игнорируйте проблемы и не давайте им гнить.
Относитесь к баг-репортам, как к историям. Баги – это обычно неожиданные, заковыристые сюрпризы. Информация в баг-репорте может быть неполной или даже неверной, потому что представляет из себя наиболее вероятные предположения о дефекте. Артефакт репорта – это живой документ, в него можно добавлять информацию и обновлять ее по ходу работы. Члены команды должны помогать друг другу предоставлением доступной информации.
Не стыдите и не стыдитесь. Баги случаются. Даже гениальный разработчик делает ошибки. Зрелая, здоровая команда тщательно заводит баги, быстро исправляет их, и предпринимает меры, чтобы в будущем избежать подобных дефектов. Разработчики не должны стигматизировать баги или пытаться ограничить количество багов. Тестировщики не должны хвастать количесвтмо найденных багов. Речь в репорте должна концентрироваться на ПО, а не людях. Сплетни и публичная порка за баги – это абсолютное "нет". Любой стыд за баги может толкнуть команду на путь плохих практик. Любые регулярно возникающие проблемы должны разбираться напрямую с ответственными, или с помощью менеджмента.
Хорошие баг-репорты – это важно.
Чтобы упростить работу тестировщикам и программистам, был разработан и стандартизирован отчет о дефектах. С одной стороны его задача — быть простым и понятным, а с другой стороны — быть эффективным.
Важно, чтобы программист при изучении данного отчета мог с легкостью воспроизвести описанный баг и понять ход мыслей тестировщика.
Шаблон отчета о дефекте, который отвечает запросам тестировщика и программиста, выглядит следующим образом:
1. Заголовок ошибки
2. Описание ошибки
3. Начальные условия
4. Шаги воспроизведения
5. Ожидаемый результат
6. Фактический результат
7. ВложенияВ зависимости от ситуации или компании, в которой вы работаете, шаблон может изменяться и отклоняться в разные стороны. Например, в некоторых случаях «Начальные условия» не пишут. Если дефект связан с графикой, то рекомендуется добавить скриншот. Также вводятся дополнительные атрибуты для указания Платформы или Барузера и т.д.
Теперь рассмотрим структуру шаблона подробно на конкретном примере. Допустим, мы тестируем сайт. На сайт есть раздел Контакты. В этом разделе находится Форма обратной связи.
Баг на сайте
Данный баг мы и будем описывать по шаблону.
Заголовок ошибки (Title)
По сути это краткое описание найденной ошибки. Его задача — в понятной и простой форме передать смысл найденной ошибки.
Наиболее эффективным описанием считается описание, которое отвечает на три вопроса:
— Что произошло?
— Где появилась ошибка?
— Когда или при каких условиях найден дефект?Также важно, чтобы заголовок был именно кратким, т.е. он должен содержать максимально полную и, в то же время, краткую информацию об ошибке.
Описание ошибки (Summary)
Попробуйте в паре предложений описать суть дефекта, а также когда он появляется и в чем выражен.
Правильное и качественное описание также позволяет сразу понять проблему и приступить к ее исправлению.
Начальные условия (Precondition)
В случае, если есть специфичные действия или шаги воспроизведения достаточно объемные, то указываются начальные условия. Например:
1. Быть авторизованным в системе.
2. Находиться на главной странице.Шаги воспроизведения (Steps To Reproduce)
Шаги, при которых повторяется найденная ошибка. Например:
1. Нажать на кнопку “Войти”
2. Ввести “Имя пользователя” и “Пароль”
3. Нажать на кнопку “Ок”Убедитесь, что у вас нет лишних или ненужных шагов воспроизведения, которые будут отвлекать и тратить время команды.
Ожидаемый результат (Expected Result)
Результат, который должен быть при выполнении шагов. В идеале, его можно найти в ТЗ (техническом задании). На практике, ТЗ бывает не всегда и ожидаемый результат определяется либо здравым смыслом, либо по аналогии.
Фактический результат (Actual Result)
Указывается результат, который получил тестировщик при выполнении описанных шагов. Также может отвечать на три вопроса “Что? Где? Когда?”.
Вложения (Attachments)
При необходимости тестировщики прикладывают скриншоты или видео воспроизведения ошибки. Также могут прикладывать логи выполнения программы.При соблюдении правил оформления баг-репортов, ваша работа станет более эффективной.
Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется специалистом по тестированию.
Серьезность имеет несколько параметров в зависимости от типа дефекта. Ее степень зависит от того, как она влияет на бизнес-логику (реализацию правил программы).
- S1 – Блокирующая (Blocker). Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее функциями становится невозможна.
- S2 – Критическая (Critical). Критическая ошибка, неправильно работающая бизнес-логика, проблема, приводящая в нерабочее состояние некоторую часть системы, но есть возможность для работы с тестируемой функцией, используя другие входные точки.
- S3 – Значительная (Major). Значительная ошибка, часть бизнес-логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
- S4 – Незначительная (Minor). Незначительная ошибка, не нарушающая бизнес-логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
- S5 – Тривиальная (Trivial). Тривиальная ошибка, не касающаяся бизнес-логики приложения, плохо воспроизводимая проблема, малозаметная по средствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
Из описания видно, что с помощью Серьезности мы указываем как найденная ошибка влияет на тестируемое приложение. Если из-за ошибки приложение полностью не работает, то Серьезность высокая. Если найденный дефект мало влияет на функционал и больше относится к визуальной части (например, опечатка в слове), то Серьезность низкая.
Давайте рассмотрим несколько примеров проблем и попробуем правильно определить их Серьезность. Чтобы было понятно, представим, что мы тестируем приложение по заказу такси.
1.Приложение «падает» при попытке найти свободное такси.
Чтобы правильно поставить Серьезность, необходимо определить влияние ошибки на дальнейшую работу функционала. Из названия видно, что после появления ошибки приложение перестает работать. Значит, влияние высокое.Сразу же отбрасываем Тривиальную и Незначительную Серьезность, так как из их описания понятно, что ошибка не должна сильно влиять на приложение.
У нас остается только три варианта: Значительная, Критическая и Блокирующая серьезности.
Подходит ли нам Значительная Серьезность? Очевидно, что нет. Во-первых, ошибка достаточно критична. Во-вторых, другим способом найти такси мы не можем, т.е. нет возможности работы с тестируемой функцией, используя другие входные точки. Более того, функционал работает не некорректно, а не работает вообще.
Остаются Критическая и Блокирующая серьезности. В нашем случае Блокирующая подходит больше, так как часть функционала не работает и нет других возможностей найти такси. Следовательно, мы выставляем Блокирующую Серьезность.
2. Невозможно указать адрес назначения с помощью “Указать на карте”.
Снова начинаем рассуждать. Тривиальная и Незначительная не подходят, потому что ошибка в какой-то мере нарушают бизнес логику работы приложения. Блокирующую можно не брать, т.к. функционал в целом работает и его можно использовать через другую точку входа, а именно ввести адрес вручную. Остается только два варианта: Критическая и Значительная. Мы уже сказали, что проблема не приводит к полной неработоспособности части функционала. Тем не менее это значительная ошибка, т.к. функционал частично не работает, следовательно остается только вариант Значительная. Его мы и укажем.Как вы могли понять, Серьезность относится к технической части приложения и указывает на то, как сильно ошибка влияет на работоспособность приложения.
Приоритет
Приоритет (Priority) – это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Проставляется руководителем или менеджером проекта.
Приоритет определяется исходя из масштабности проблем для пользователей и продукта. Для понимая можно использовать матрицу:
Матрица определения приоритета
Теперь, когда мы разобрались что означает каждый атрибут, давайте посмотрим в чем их различие:
Различия Серьезности и Приоритета
Если остались вопросы по определению параметров Серьезность и Приоритет, то задавайте их в комментариях к статье.
Читайте также: