Как правильно составлять баг-репорты
Правила оформления записей в баг-трекере в каждой компании свои — это зависит как от политики компании, технологии разработки, используемного баг-трекера, типа проекта и много чего еще. Но в любом случае хороший баг-репорт обладает определенными характеристиками.
Если кратко, то хороший баг-репорт позволяет:
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 — старший тестировщик/старший программист/менеджер или любой другой ответственный за это дело человек.
Если есть только одно поле, то выставляем его.
«Какой приоритет ставить багу?» На этот вопрос нет однозначного ответа, все зависит от каждого конкретного случая. Но старайтесь не увлекаться и не ставить всем багам подряд высокий или критичный приоритет, реально оценивайте их критичность для проекта.
Environment — есть во всех баг-трекерах. Это программно-аппаратное окружение, в котором проявляется проблема.
Укажите версию операционной системы, наличие сервис-паков, разрядность.
Если ваш проект зависит от каких-то компонентов — их наличие и версии обязательно! .NET, JRE/JDK и прочие SDK.
Интерпретируемый язык? Версию интерпретатора — обязательно!
Для веб-проектов — браузер, установленные плагины, если это влияет на работу проекта. Если что-то не работает в одном браузере, то проверьте, работает ли в остальных.
В какой версии исправить, на кого назначить — зависит от политики внутри компании. Не знаете, что поставить? Спросите коллегу.
Как правильно сообщать о багах, чтобы их быстро исправляли
В разгар сосредоточенной деятельности программистов отвлекают вопросы в скайпе. Иногда достаточно ответить, но бывает, выясняется, что на проекте возникла ошибка, требующая исправления, и мы начинаем уточнять детали, создаем задание в багтрекере, согласовываем сроки решения. А возвращаясь к прерванному делу, обнаруживаем, что прошло сорок минут. А потом менеджер спросит: «Вася, почему ты задачу оценил в 7 часов, а выполняешь второй день?»
Уважаемый заказчик! Когда на проекте обнаруживается неполадка, и вы хотите быстрее сообщить о ней в чат, помните следующее.
| Если изложить суть непонятно или сумбурно, на выяснение деталей уйдёт дополнительное время, которое оплачиваете вы. При этом от текущих дел отрываются один, а то и несколько сотрудников. |
| Может создаться иллюзия срочности. Например, разработчик попытается воспроизвести указанный дефект, не дождавшись ответов на уточняющие вопросы, и сразу попытается его исправить, что хорошо, если проблема критическая, плохо, если минорная (а есть более важные задания), и очень плохо, если вы вообще не планировали исправление. |
| Возможна и обратная ситуация: обсуждаемая в скайпе неполадка может там и остаться. Многие сотрудники справедливо полагают, что решение вопроса начинается с заведения задачи в багтрекере. Скайп — лишь инструмент коммуникации, где можно оперативно обсудить текущий проект. В багтрекере же фиксируются задания, комментарии и принятые решения. Разбор спорных ситуаций производится тоже по багтрекеру. Иными словами, если вы собираетесь написать в скайпе что-то вроде «было бы неплохо сделать так. », а потом, спустя неделю, возмущаться, почему до сих пор «так» не реализовано, то, пожалуйста, не надо. |
| Если вы не заведёте задачу в багтрекере, её заведём мы. Тогда следует проследить, что с ваших слов записано верно. |
Что надо сделать?
Время идёт, проект не готов, а бюджет не резиновый. Есть два варианта.
Первый. Наш сотрудник (тестировщик, специалист службы поддержки или менеджер проекта) воспроизведёт неполадку, уточнит её критичность, занесет информацию в багтрекер, мобилизует программистов и обозначит примерный срок завершения. Такая схема успешно применяется, если бюджет проекта позволяет оплатить участие дополнительного специалиста.
Второй. Вы можете завести задачу самостоятельно. Если хотите, чтобы проблема была решена быстро, она должна быть правильно понята. С этого момента подробнее.
Заголовок
Итак, возникла неполадка, о которой нужно заявить. Первое, что указываем при заведении задачи, — это заголовок, при первом взгляде на который должно быть понятно, что случилось. Заголовок должен отвечать на три вопроса.
«Что?» — что, собственно, произошло?
«Где?» — в каком месте интерфейса вы видите проблему?
«Когда?» — при каких обстоятельствах проявляется проблема?
Приведем примеры, когда заголовок не отвечает ни на один из вышеуказанных вопросов.
- «Снова ничего не работает» — непонятно, что конкретно не работает.
- «Неясная кнопка» — без комментариев.
- «Логин и пароль» — пожалуйста, не надо таких заголовков.
Примеры, когда заголовок отвечает только на часть вопросов.
- «Слетает вёрстка на сайте» — понятно, что на сайте есть ошибки с вёрсткой, но неясно, в чём суть.
- «Разная вёрстка текста» — напрашиваются дополнительные вопросы, потому что всё ещё непонятно, о чём речь.
- «Сбой в графике Dashboard» — что-то произошло на экране Dasboard, но непонятно, что считать за сбой. Возникнут дополнительные вопросы.
- «Не отображаются некоторые сообщения в личном кабинете» — заголовок уже можно считать неплохим. Здесь не хватает информации, какие сообщения и при каких обстоятельствах не отображаются, но выяснение требует времени, а сообщить об ошибке нужно быстрее.
- «С первого раза не осуществляется переход с вкладки «Мои камеры» на вкладку «Гостевой доступ» — а вот здесь не помешало бы уточнить, при каких обстоятельствах такое происходит: у разработчика проблема может и не воспроизвестись.
- «Ошибка при отправке Issue» — неплохо.
- «В административной части пропала возможность настройки кинотеатров» — случай, когда ответа на вопрос «Когда?» не требуется.
Примеры хороших заголовков, отвечающих на вопросы «Что? Где? Когда?».
- «Не все сообщения, доставленные как push, отображаются в ЛК» — сразу ясно, с чего начинать отладку.
- «IE 8 постоянно ругается на форме подачи объявления, начиная от первого шага» — здесь только непонятно, что подразумевается под «ругается», но, открыв форму подачи объявления в IE 8, мы всё увидим.
- «В панели фильтров цена не «инициализируется», когда поставлен фильтр по цене» — можно открывать участок кода, отвечающий за фильтр по цене, и смотреть что там не так.
- «При просмотре записи по-прежнему доступны кнопки управления поворотным механизмом» — в видеозаписях же нет смысла в поворотах камеры, значит забыли убрать кнопки поворота, скоро исправим.
- «Обходится ограничение на количество объявлений частного лица вводом прямой ссылки в адресную строку» — всё ясно, добавим перенаправление.
Описание
В большинстве случаев, при хорошо составленном заголовке описание проблемы может даже не потребоваться. С другой стороны, качественно заполненное поле «Description» может нивелировать недостатки заголовка, и даже указать на решение. Были случаи, когда ошибка, имеющая детальное описание, исправлялась в течение десяти минут, а без такового — несколько часов. В первом случае разработчик сразу понял, какую строчку кода ему править. Во втором — полдня отлаживал код, прежде чем выяснил причины сбоя.
Что нужно указать в описании задачи.
| Подробности | Помогающие воспроизвести неполадку и навести разработчика на возможную причину ошибки. Например, когда вы по пунктам описываете, что делаете, и как это приводит к проблеме. Выполняя эти шаги, разработчик воспроизведёт ошибку под отладкой и сможет приступить к её исправлению. |
| Фактический результат | Напишите, что конкретно происходит. |
| Ожидаемый результат | Напишите, что должно происходить. Упуская этот пункт, вы вынудите программиста искать ответ в требованиях, что займет время. Если явных требований не задокументировано, изложите собственное мнение, иначе разработчик всё равно обратится к вам и будет ожидать ответа, что отложит решение проблемы. Или исправит, как сочтет нужным, а его видение может отличаться от вашего. |
| Скриншот | В некоторых случаях заменяет тысячи слов, особенно если замечание касается интерфейса или дизайна. |
Приоритет
Создавая задачу, вы можете определить степень серьёзности, исполняя роль руководителя проекта (ведь вы, по факту, им и являетесь). Градации серьёзности следующие.
- Блокирующая (Blocker) — приступать стоит немедленно, без устранения дефекта всё остальное не имеет смысла.
- Критическая (Critical) — ошибку исправят оперативно, назначив лучших специалистов.
- Значительная (Major) — значение серьёзности по умолчанию. Заданий с таким приоритетом в проекте большинство.
- Незначительная (Minor) — вопрос не требует срочного вмешательства, к нему приступят после решения большей части прочих задач.
- Тривиальная (Trivial) — задания подобного рода будут выполняться в последнюю очередь.
Вот основное, что следует знать о заведении отчётов о дефектах в багтрекерах, и чаще всего этого достаточно для эффективного взаимодействия с разработчиками. Ну а если что-то действительно важное, всегда можно сообщить в скайпе: «Ребят, я там баг завёл срочный, вот ссылка на него. Когда исправите?».
Как сообщить команде о баге
- Портал
- Форум
- Тренинги
Что пишут в блогах
- Открытое образование
- Новости индустрии. VK Weekend offer для тестировщиков
- Пассивный залог в английском для тестировщиков
- RQA HH тренды май 2022
- Тестирование ISTQB на русском: как сдать в 2022 году?
- Стратегии нужна креативность! (часть 2)
- Знакомство с тренерами. Нина Агеева: гуманитарий, создавший собственный курс для тестировщиков
- Стратегии нужна креативность! (часть1)
- Расписание курсов для тестировщиков на июнь 2022
- Как начать работать тестировщиком
Конференции
Большая техническая конференция по тестированию Heisenbug 2022 Offline-день
21 июня, Санкт-Петербург
Профессиональная конференция по автоматизации в тестировании и рядом
27 и 28 июня, Москва, Radisson Slavyanskaya.
Что пишут в блогах (EN)
- The myth of perfect software – IT audit and governance aspects of the Post Office.
- Modernizing Software Quality Assurance with Visual Testing
- How many towels should a family of 5 have? Can you wash bath towels with.
- Sample More
- My first virtual “lean coffee” (May 24, 2022)
- Five for Friday – May 27, 2022
- Digital Transformation Podcast
- Introducing WordPress Starter: Make Your Mark
- AgileTD Open Air 2022 — A Unicorn Conference Outdoors
- Open Testing: Opening tests like opening source
Разделы портала
Онлайн-тренинги
| Создание хороших баг-репортов |
| 01.12.2020 00:00 |
|
/>Автор: Энди Найт (Andy Knight) Баги, баги, баги! Нельзя обсуждать разработку ПО, не затрагивая тему багов. Поначалу термин «баг» может казаться странным жаргоном для «дефекта». По коду и машинам что, бегают жучки и паучки? Как правило, нет, но иногда таки да! В 1947 году Грейс Хоппер нашла мертвого мотылька, застрявшего в реле гарвардского компьютера Mark II, и в отчете о «жучке» шутила, что нашла настоящего жука за компьютерным дефектом. Несмотря на то, что изобретатели вроде Томаса Эдисона использовали термин «баг» для описания технологических глюков задолго до 1947 года, именно этот мотылек зафиксировал терминологию для компьютеров и ПО. Баги случаются. Почему? Потому что никто не идеален, и поэтому не существует идеального ПО. Создание высококачественного ПО требует хорошего дизайна для устойчивости к багам, хорошего внедрения, дабы избежать багов, и хорошей обратной связи, чтобы сообщить о багах, когда они неизбежно возникнут. В статье я собрал лучшие практики для создания хороших баг-репортов. Что такое баг-репорт?Баг – это всего-навсего дефект. Термин относится исключительно к проблемам в ПО. Однако баг-репорт (или тикет) – это письменное описание, детализирующее дефект. Как правило, баг-репорты пишутся в инструменте управления проектом вроде Jira. Баг и отчет о нем – это две разные вещи. Естественно, что не обнаруженные баги могут отлично существовать в продукте, когда отчетов о них еще не существует. Когда надо писать баг-репорт?Баг-репорт надо писать, когда обнаружена новая проблема, которая выглядит как дефект. Проблемы обнаруживаются в ходе такой тест-деятельности, как прогон автотестов или ручное исследовательское тестирование. Их также находят при разработке новых фич. В худшем случае их найдут пользователи и начнут жаловаться! Заметьте, я использую термин «проблема», а не «дефект». Всем проблемам нужны решения, но не все проблемы – это действительно дефекты. Иногда сообщивший о проблеме пользователь не знает, как должна работать фича. Иногда дело в неправильно сконфигурированном окружении. Член команды, выявивший проблему или получивший жалобу от клиента, должен провести небольшое расследование, чтобы убедиться, что проблема действительно выглядит как дефект ПО. Первоначальное расследование нужно проводить немедленно, пока еще жив контекст. Если проблема выглядит реальным дефектом, а не недопониманием и не плохой настройкой конфигурации, детектив должен поискать эту проблему среди существующих баг-репортов. На нее или что-то похожее мог недавно наткнуться кто-то еще. Баги также могут появиться вновь даже после «исправления». Добавление информации в существующие репорты – куда лучшая практика по сравнению с созданием дубликатов. Что, если проблема неясна? Если я не уверен, баг это или другой тип проблемы, я спрашиваю коллег. Я пытаюсь задавать вопросы вроде «Выглядит ли это правильным? Что может вызывать такое поведение? Может, я что-то сделал не так?» Слепо плодить баг-репорты для каждой проблемы – вести себя как мальчик из сказки, который кричал «Волки»: команда будет менее чувствительной к предупреждением о реальных, важных багах. Небольшое расследование демонстрирует ваши хорошие намерения и во множестве случаев избавляет команду от лишней работы позднее. Несмотря на это, в случае сомнений создать репорт лучше, чем не создать. Небольшое количество ложноположительных результатов лучше риска реальных проблем. Зачем нужны баг-репорты?При обнаружении реального бага команда должна написать о нем репорт. Просто поговорить о баге проще и быстрее, особенно в небольших командах, но фиксировать это письменно важно для целостности процесса разработки ПО. Письменный отчет – это артефакт, который требует решения.
Баг-репорты помогают сделать исправление багов частью процесса разработки. Они привлекают к багам внимание, и их непросто игнорировать или проморгать. Что входит в баг-репорт?Вне зависимости от инструмента или процесса, хорошие баг-репорты содержат следующую информацию:
|