когда следует заводить новый дефект в баг трекинговой системе
Как правильно составлять баг-репорты
Правила оформления записей в баг-трекере в каждой компании свои — это зависит как от политики компании, технологии разработки, используемного баг-трекера, типа проекта и много чего еще. Но в любом случае хороший баг-репорт обладает определенными характеристиками.
Если кратко, то хороший баг-репорт позволяет:
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 — старший тестировщик/старший программист/менеджер или любой другой ответственный за это дело человек.
Если есть только одно поле, то выставляем его.
«Какой приоритет ставить багу?» На этот вопрос нет однозначного ответа, все зависит от каждого конкретного случая. Но старайтесь не увлекаться и не ставить всем багам подряд высокий или критичный приоритет, реально оценивайте их критичность для проекта.
В какой версии исправить, на кого назначить — зависит от политики внутри компании. Не знаете, что поставить? Спросите коллегу.
Статья дополнена правильными замечаниями из комментариев.
говориМ о тестировании
простым языком
Основы тестирования. Жизненный цикл бага
Какой же путь проходит баг и какую роль в его жизненном цикле играет тестировщик? Давайте разбираться.
Ошибка, дефект, но чаще всего баг. Именно так называется то, что находят тестировщики в процессе работы.
Определение бага
Bug в переводе означает “жук, насекомое”. Первая ошибка, которая была задокументирована, возникла как раз из-за жука. В середине 40-х годов 20 века ученых Гарвардского университета вызвали для того, чтобы определить причину сбоя в работе вычислительной машины Mark II. Покопавшись в этой громадной куче приборов, соединенных проводами, они обнаружили бабочку, застрявшую между контактами электромеханического реле. Стало ясно, что именно она и явилась причиной сбоя. Одна из сотрудниц университета, Грейс Хоппер, так и сформулировала результат исследований: “неполадку вызвал баг”. Извлеченное насекомое было вклеено скотчем в технический дневник, с соответствующей сопроводительной надписью. Ее, как говорят, до сих пор можно увидеть в этом журнале, хранящемся в университетском научном музее.
В наше время большинство багов вызвано не насекомыми, как раньше, а преимущественно людьми.
Если обратиться к терминологии, то получается, что баг — это расхождение ожидаемого результата с фактическим. В нашем случае, ожидаемый результат – это поведение программы или системы, описанное в требованиях, а фактический результат — это поведение системы, наблюдаемое в процессе тестирования.
Баг в программе не появляется просто так, у него всегда есть источник. Например, ошибка программиста при написании кода. Дефекты встречаются, потому что люди склонны ошибаться, существует нехватка времени, сложность кода, сложность инфраструктуры, изменения технологий и/или много системных взаимодействий.
Что еще интересно, что программ, не содержащих ошибок, не бывает. По статистике на каждую тысячу строк программного кода, который пишут программисты, приходится несколько ошибок, а количество строк в сложном программном обеспечении достигает нескольких миллионов. Поэтому поиск и исправление этих ошибок – очень трудоемкое дело, составляющее до 45% всех затрат на разработку программного обеспечения.
Жизненный цикл бага
Давайте вкратце разберем каждый этап жизненного цикла
Данную схему можно изобразить в текстовом виде. Вот несколько вариантов прохождения багов (можно просто нарисовать на листочке на собеседовании):
1. Новый (new) —> Отклонен (rejected) —> Закрыт (closed)
2. Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed)
3. Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed) —> Переоткрыт (re-opend)
Жизненный цикл бага с точки зрения команды
Давайте для большей наглядности рассмотрим жизненный цикл бага с точки зрения участников команды и их функций.
Сначала тестировщик находит баг. Далее заносит его в систему учета ошибок. После этого программист начинает изучать отчет о дефекте. Именно на этом этапе он решает баг это или нет.
Давайте посмотрим сначала сценарий, в котором разработчик принял баг. Перед ним сразу встает задача пофиксить его, то есть исправить и залить (отдать заново на проверку). Как только разработчик все сделал, баг снова отправляется к тестировщику, который производит тестирование исправлений, а также проверяет смежные участки (регрессионное тестирование).
Если баг больше не воспроизводится, то тестировщик закрывает баг.
Если баг снова воспроизводится, то мы возвращаем его программисту. И снова проходим все шаги, начиная с 3-го шага (рассмотрения проблемы программистом).
Теперь другой сценарий — разработчик не принял баг. Если баг не принят, то разработчик возвращает его нам. Наша задача — рассмотреть проблему. Если баг вернули из-за некорректного описания, то значит переписываем его. Если невозможно воспроизвести дефект, то заново проверяем все шаги, может мы что то упустили при описании. Если разработчик прав и бага нет, то мы закрываем баг. А если баг все же есть, то вносим необходимые коррективы и опять возвращаемся на шаг 3.
Именно так выглядят основные этапы жизненного цикла бага. Иногда могут добавляться дополнительные этапы, это вызвано особенностями процессов тестирования внутри фирмы. Неизменным всегда останется то, что баг создается и закрывается (прекращает существование) по различным причинам.
Жизненный цикл бага
В данном материале рассмотрим жизненный цикл бага и статусы, которые присваиваются багу на каждом этапе жизненного цикла. Следует отметить, что жизненный цикл бага может отличаться в зависимости от потребностей конкретного проекта и сложившихся корпоративных стандартов и используемых инструментов. Но прежде чем говорить о жизненном цикле бага давайте скажем пару слов о том, где жизненный цикл бага удобно прослеживать после созданного баг репорта.
Содержание
Баг-трекинговые системы
Немного терминологии. Инструмент управления дефектами (defect management tool), инструмент отслеживания дефектов (defect tracking tool), инструмент отслеживания помех (bug tracking tool): Инструмент, обеспечивающий фиксирование дефектов и изменений, а также поддержку их состояний.
Инструмент управления инцидентами (incident management tool): Инструмент, который обеспечивает запись и отслеживание статуса инцидентов.
Часто имеет процессно-ориентированные возможности для поддержки и контроля распределения, исправления и повторной проверки дефектов, а также возможности отчетности.
Теперь перейдем непосредственно к жизненному циклу бага.
Жизненный цикл бага: статусы
Кружочки могут называться по-разному, но основная логика будет оставаться.
Примечание: Открытые (open) баги. Открытыми являются баги в состояниях Обнаружен (submitted), Назначен (assigned), Открыт заново (reopened). Иногда к открытым относят и баги в состояниях Исправлен (fixed) и Отложен (deferred).
Резолюция (Resolution) – пояснение к статусу в жизненном цикле бага
Опять-таки нужно помнить, что резолюции для бага могут отличаться в зависимости от потребностей конкретного проекта и сложившихся корпоративных стандартов и используемых инструментов. Вместе с тем ниже приведены наиболее распространенные резолюции для пояснения статуса бага.
В общем мы рассмотрели жизненный цикл бага (дефекта) и на этом можно закончить, в заключение хочется сказать:
Помните, критичный баг, найденный тестировщиком в последний день, является багом в работе самого тестировщика! А так же не все баги должны быть исправлены.
Жизненный цикл “бага”
Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цикла:
Использование данных отчета о дефекте
Информация по дефектам – это записи о просчетах в качестве, а значит – список возможностей для улучшения качества на ваших будущих проектах. Если вы собираете некую информацию о дефектах (например, после релиза или только на больших проектах), тогда, возможно, Вы захотите улучшить этот процесс.
Информация о дефектах, которая может быть полезна для улучшения качества, включает следующие вопросы:
Когда Вы анализируете информацию о дефектах, то ищите те дефекты, которые обнаруживаются регулярно, и те, затраты на устранение которых высоки. Вот как раз таких дефектов и нужно избегать в будущем (или, по крайней мере, устранять их на более ранней стадии разработки), именно такая тактика гарантированно будет способствовать улучшению качества.
Атрибуты отчёта о дефекте
В зависимости от инструментального средства управления отчётами о дефектах внешний вид их записи может немного отличаться, могут быть добавлены или убраны отдельные поля, но концепция остаётся неизменной.
Свойства качественных отчётов о дефектах
Отчёт о дефекте может оказаться некачественным (а следовательно, вероятность исправления дефекта понизится), если в нём нарушено одно из следующих свойств:
Логика создания эффективных отчётов о дефектах
При создании отчёта о дефекте рекомендуется следовать следующему алгоритму:
Типичные ошибки при написании отчётов о дефектах
Ошибки оформления и формулировок:
Логические ошибки:
Баг. Жизненный цикл бага
Общие сведения
Баг/дефект — это несоответствие фактического результата по отношению к ожидаемому, который зафиксирован в требованиях к продукту. Если требований на проекте нет, чаще возникают спорные ситуации. Тогда статус данного состояния (дефект или особенность) уточняется несколькими вариантами:
— приходится опираться на реальные знания о системе (они есть только у разработчика и тестировщика);
— на видение продукта (оно есть у product owner’а);
— на поведение аналогичных систем (их изучает аналитик);
— на влиятельность заказчиков, столкнувшихся с проблемой.
Для команд с горизонтальной структурой должен быть заранее всеми участниками согласован алгоритм (исключающий эмоции, игнорирующий ораторские способности сторон и ограниченный по времени реализации) согласования.
Свойства дефектов
Виды дефектов по приоритету
Жизненный цикл бага
Работа с новым дефектом (New/ToDo/Open)
Действия тестировщика при обнаружении бага:
Баг-репорт (In Progress)
Bug report — это документ, который описывает дефект в приложении.
2. Environment. Описывается окружение, в котором запускалось приложение (операционная система, браузер и его версия, расположение файла).
3. Build (version). В какой сборке обнаружен дефект.
4. Priority. Указание приоритета дефекта в зависимости от баг-трекинговой системы. Здесь приоритет выставляется согласно критичности данного дефекта с точки зрения бизнес-логики.
5. Severity. Отражает критичность с технической точки зрения. В Jira это поле может быть добавлено администратором по необходимости.
6. Description. Описание проблемы. Состоит из:
— Pre-condition. Подготовительные действия для формирования контекста.
— Steps to Reproduce. Шаги, которые необходимы для воспроизведения дефекта.
— Actual Result. Описание получаемого результата.
— Expected Result. Описание ожидаемого в требованиях результата.
— Additional Info. Информация, которая может помочь в исправлении дефекта. Например, указание на работающую часть функционала, если он составной.
Ответ разработчика (Resolution)
Переоткрытие дефекта (Reopened)
Возможно для отклоненного дефекта, отсроченного дефекта, проработанного дефекта.
Закрытие дефекта (Closed)
Для избежания накапливающихся ошибок потери учета данное действие должно выполняться исключительно QA специалистом.