Что такое fixed version у дефекта
Как правильно оформить баг-репорт
Больше интересного на эту тему
При тестировании возникает необходимость документирования найденных дефектов. Это позволяет исправить их в кратчайшие сроки.
Если кратко, то хороший баг-репорт позволяет:
Что такое баг, типы багов
Критичность и приоритет бага. Атрибуты баг-репорта
Необходимо рассказать о приоритете и критичности бага. Важно понимать разницу между ними. Примеры приведу из личного опыта. Объектом тестирования в моей работе является ПО приёмников цифрового телевидения. Главной задачей ПО приёмника является расшифровка контента, передаваемого в зашифрованном виде. Для успешной расшифровки абонент должен приобрести у оператора подписку на соответствующий пакет телеканалов.
Критичность бага – это атрибут, который характеризует влияние бага на общую функциональность разрабатываемого ПО.
По критичности баги делят на:
S1. Блокирующий (Blocker). Всё тестируемое ПО не может работать без устранения бага. Например, приёмник начинает перезагружаться сразу после включения, мы не сможем больше ничего протестировать из-за этого бага.
S2. Критический (Critical). Большая часть ПО не может корректно работать. Например, приёмник не может открывать закодированные каналы. До устранения этого дефекта можно протестировать UI, а также функционал, не связанный с расшифровыванием каналов.
S3. Значительный (Major). Блокирует работу одной из основных логических цепочек ПО. Например, неправильное сообщение об ошибке при отсутствии подписки на пакет оператора.
S4. Незначительный (Minor). Не нарушает основные логические цепочки приложения, с ним можно продолжать работать почти без потери качества. Здесь можно привести неточный перевод с русского на английский в меню приёмника.
S5. Тривиальный (Trivial). Эта степень присваивается, когда баг вообще не влияет на общее качество работы ПО. Например, незначительное пересечение элементов в меню.
Приоритет бага — это то, в каком порядке нужно решать проблемы. Существует три степени приоритетности:
P1. Высокий приоритет (High). Нужно исправить немедленно, потому что баг является крайне важным для всего релиза. Например, старое сообщение об отсутствии подписки на пакет, хотя обновление текстов являлось целью этого релиза.
P2. Средний приоритет (Medium). Точно нужно будет исправить, баг достаточно важен, но не требует немедленного решения. Например, некорректный перевод в меню приёмника.
P3. Низкий приоритет (Low). Нужно будет исправить, но баг не очень важный и не требует немедленного решения. Например, это могут быть баги в функционале, который уже не используется оператором, но ещё не был удалён из кода.
Что такое баг репорт, его типичная структура
Но можно сказать и проще: баг репорт (bug report) – это технический документ, который содержит в себе полное описание бага, включающее информацию как о самом баге (краткое описание, критичность, приоритет и т.д.), так и об условиях возникновения данного бага.
Состав баг репорта приведен в таблице:
Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Название тестируемого проекта
Компонент приложения (Component)
Название части или функции тестируемого продукта
Номер версии (Version)
Версия, на которой была найдена ошибка
Наиболее распространена пятиуровневая система критичности:
S1 Блокирующий (Blocker)
S2 Критический (Critical)
S3 Значительный (Major)
S4 Незначительный (Minor)
S5 Тривиальный (Trivial)
Статус бага. Зависит от используемой процедуры и жизненного цикла бага. Например:
Создатель баг репорта
Назначен на (Assigned To)
Имя сотрудника, назначенного на решение проблемы
Информация об окружении, на котором был найден баг: операционная система, сервис пак, имя и версия браузера, версия ПО чипа, версия библиотеки и т.д.
Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Прикрепленный файл (Attachment)
Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы
Как правильно оформить баг-репорт
Ошибки при создании баг-репорта
Здесь перечислим проблемы, которые чаще всего встречаются при написании баг репорта.
Заголовок не понятен. Есть риск, что ни разработчик, ни коллеги не обратят внимания на довольно критичную проблему.
Отсутствуют шаги для воспроизведения. Есть риск, что разработчик, не поняв как повторить проблему, вернёт баг со статусом «Не воспроизводится».
Неправильно назначен баг. Возможно, баг по ошибке был назначен не на того разработчика или вообще остался в статусе “не назначен”. Есть риск, что багу долгое время не будет уделено внимание.
Недостаточность предоставленных данных. Не всегда одна и та же проблема проявляется при всех вводимых значениях и под любым вошедшим в систему пользователем, поэтому настоятельно рекомендуется вносить все необходимые данные в баг-репорт. Иначе баг будет отклонён разработчиком, и придётся потратить время на его детальное описание.
Отсутствие ожидаемого или полученного результата. В случаях, если вы не указали, что же должно быть ожидаемым поведением системы, вы тратите время разработчика на поиск данной информации, тем самым замедляете исправления дефекта. Рекомендуется указать ссылку на пункт в требованиях, написанный тест кейс или же ваше личное мнение, если эта ситуация не была задокументирована.
Жизненный цикл бага
Итак, баг найден, репорт составлен, что дальше? Дальше ведётся работа над багом в соответствии с жизненным циклом, который может быть настроен в системе багтрекинга. На практике это зависит от процессов в компании.
Если кратко, то после создания баг-репорта статус бага может выглядеть следующим образом:
Более наглядно жизненный цикл бага можно посмотреть на диаграмме:
При использовании системы тест менеджмента TestIT существует возможность интеграции с системами баг-трекинга. В нашей компании это JIRA. Достаточно нажать “save and create bug” и мы получаем почти готовый баг репорт в JIRA.
Нужно только добавить несколько полей связанных с текущим проектом.
В разделе Description уже есть разделы steps, actual result and expected result, что особенно актуально для начинающих тестировщиков и позволит им не пропустить важные разделы в баг репорте.
Вместо заключения
Если тестировщик не сообщает об ошибке правильно, программист, скорее всего, отклонит эту ошибку, заявив, что она не воспроизводится.
Поэтому, чем лучше тестировщики будут писать баг-репорты, тем дешевле обойдётся компании исправление этих дефектов.
Как составить безупречный баг-репорт?
Профессия тестировщика ПО очень многогранна, ведь она требует внимания к деталям, креативности, коммуникативных навыков и усидчивости. Последнее качество особенно пригодится для такой части работы QA-инженера, как составление тестовой документации.
Один из примеров ― баг-репорт (от англ. bug report ― отчёт об ошибке), который содержит описание всех найденных дефектов в работе приложения. Не имеет значения, тестируете ли вы компьютерную игру, приложение для банка или сайт онлайн-магазина ― составление правильного отчёта является залогом продуктивного QA-процесса.
Баг-репорт содержит ответы на следующие вопросы:
С этим техническим документом предстоит ознакомиться разработчикам, которые внесут изменения в программный код и исправят ошибки. Именно поэтому баг-репорт должен быть лаконичным, понятным и содержать максимум полезной информации.
Разберёмся, как добиться этого сочетания.
Как выявляют баги?
Вы, как инженер по обеспечению качества, можете узнать о наличии дефектов в программном обеспечении несколькими способами:
Идеальный сценарий ― первый, когда дефекты выявляются до релиза специалистами по обеспечению качества. Но иногда до начала составления баг-репорта тестировщику приходится изучать чужой опыт взаимодействия с ПО при появлении ошибки.
Какой инструмент используют для документирования дефектов?
Самой распространённой системой для отслеживания дефектов является JIRA. Данный ресурс позволяет фиксировать ошибки и следить за их жизненным циклом. Но эта программа не такая простая, особенно для новичков в ИТ. Поэтому важно ознакомиться с её функционалом.
Студенты QA Academy уже на базовом курсе получают необходимый багаж знаний для эффективной работы с JIRA, а в этой статье мы подробно рассказали, как прокачать своё мастерство поиска в этой баг-трекинговой системе.
Некоторые компании отдают предпочтение и менее известным инструментам, например, Redmine или Mantis.
Каких правил придерживаться при написании баг-репорта?
Правило №1: следуйте принципу «1 дефект = 1 баг-репорт». Это позволит сохранить прозрачность процессов на проекте и детально следить за исправлением недочётов.
Правило №2: пишите баг-репорт простым и лаконичным языком, ведь от того, насколько быстро разработчик поймёт суть проблемы зависит скорость внесения правок в код.
Правило №3: описывайте дефект кратко, но с сохранением максимума полезной информации.
Правило №4: удостоверьтесь в воспроизводимости ошибки до заведения баг-репорта, повторите свой алгоритм действий и по возможности сократите число шагов.
Правило №5: проверьте, нет ли идентичного дефекта, который уже был зафиксирован.
Если всё в порядке, можно переходить к описанию.
Из каких элементов состоит баг-репорт?
Форма заполнения баг-репорта включает несколько полей (атрибутов). Туда тестировщик вносит характеристики дефекта. Число атрибутов может варьироваться в зависимости от баг-трекинговой системы и особенностей проекта, но с некоторыми тестировщики работают постоянно. Рассмотрим их:
Summary (заголовок)
Первый элемент баг-репорта — это краткое описание сути проблемы. В этом поле мы должны коротко и ясно описать выявленный дефект. Уже на этом этапе вы можете придерживаться правила «Где? Что? Когда или в каких условиях?». Не лишним будет добавить и данные о тестовом окружении, под которым выявлен дефект. Формулируйте этот атрибут в виде связного предложения, так будет проще вникнуть в суть проблемы.
Давайте рассмотрим конкретный пример. Представьте, что вы тестируете площадку объявлений menyaemsya.com. Согласно требованиям, поле с описанием товара должно содержать максимум 350 символов. Но вы видите, что система пропускает описание, которое превышает данный лимит. Для этого дефекта вам нужно составить баг-репорт. Воспользуемся подсказкой «Что? Где? Когда?», чтобы составить заголовок. Получается:
«Ограничение на ввод символов в поле с описанием товара отсутствует на всех страницах».
При тестировании мобильных приложений важно внести и название платформы, iOS или Android.
Заголовок готов. Можем двигаться дальше.
Description (описание)
Содержание этого поля отличается в зависимости от баг-трекинговой системы. Например, JIRA или Redmine предполагают описание шагов воспроизведения ошибки. Пользователи Mantis тут могут более подробно описать суть проблемы, а для описания пути воспользоваться атрибутом «Steps to reproduce» (в пер. с англ. «действия по воспроизведению»). Выглядеть это описание может следующим образом:
Если же предстоит выполнить слишком большую последовательность действий, то вы можете начать с описания условий.
«Пользователь авторизован на сайте menyaemsya.com и перешёл в корзину».
Actual/expected result (фактический/ожидаемый результат)
Нам предстоит ещё раз указать на суть дефекта и добавить информацию о том, как элемент ПО должен работать корректно.
Пример заполнения данного раздела:
«При внесении информации в поле “Описание” количество вводимых пользователем знаков не лимитируется. Ожидается, что после внесения 350 символов система не будет выводить на экран знаки и предложит пользователю сократить текст».
Attachments (вложения)
Этот элемент репорта позволяет проиллюстрировать суть бага и поделиться дополнительными данными. Вы можете прикрепить скриншоты, фото, видеозапись или иные файлы. Это упростит понимание сути проблемы и поможет быстрее сориентироваться.
Priority (приоритет)
Это важное поле, которое содержит информацию о срочности исправления дефекта. Данные этого атрибута помогают менеджеру планировать работу на проекте, ведь чем выше приоритет, тем скорее необходимо внести изменения.
Системы определения важности могут отличаться, но скорее всего вы встретитесь с подобной градацией:
Высокий приоритет имеют критические дефекты, которые необходимо исправить в кратчайшие сроки. Категория P3 включает те баги, которые не влияют на работу системы и могут быть устранены в последнюю очередь.
Severity (серьёзность)
Ошибки имеют и другую характеристику ― степень серьёзности влияния на систему.
Status (статус)
В этом поле находится актуальная информация о том, в каком состоянии текущая задача. Содержание этого атрибута может варьироваться в зависимости от баг-трекинговой системы. Вы можете столкнуться со следующими обозначениями:
Такими являются основные элементы баг-репорта, с которыми приходится встречаться чаще всего. Но в отчёте могут содержаться и дополнительные поля:
Резюмируем
Написание баг-репорта ― важный элемент QA-процесса, который позволяет ускорить устранение дефекта и подготовить качественное ПО к выходу на рынок. До начала написания документа важно:
Хороший отчёт об ошибке написан простым и понятным языком, содержит максимум полезной информации. Ключевыми атрибутами баг-репорта являются заголовок, описание, приоритет и статус ошибки. Стоит придерживаться порядка написания отчёта и заполнять все поля в зависимости от особенностей трекинговой платформы и требований проекта.
Умение составлять подобные репорты является важным для тестировщика навыком, который вы можете развить, ежедневно тренируясь. А освоить азы вам помогут наши замечательные преподаватели, сотрудники международной ИТ-компании, на курсе «Основы тестирования ПО». Присоединяйтесь!
Жизненный цикл “бага”
Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цикла:
Использование данных отчета о дефекте
Информация по дефектам – это записи о просчетах в качестве, а значит – список возможностей для улучшения качества на ваших будущих проектах. Если вы собираете некую информацию о дефектах (например, после релиза или только на больших проектах), тогда, возможно, Вы захотите улучшить этот процесс.
Информация о дефектах, которая может быть полезна для улучшения качества, включает следующие вопросы:
Когда Вы анализируете информацию о дефектах, то ищите те дефекты, которые обнаруживаются регулярно, и те, затраты на устранение которых высоки. Вот как раз таких дефектов и нужно избегать в будущем (или, по крайней мере, устранять их на более ранней стадии разработки), именно такая тактика гарантированно будет способствовать улучшению качества.
Атрибуты отчёта о дефекте
В зависимости от инструментального средства управления отчётами о дефектах внешний вид их записи может немного отличаться, могут быть добавлены или убраны отдельные поля, но концепция остаётся неизменной.
Свойства качественных отчётов о дефектах
Отчёт о дефекте может оказаться некачественным (а следовательно, вероятность исправления дефекта понизится), если в нём нарушено одно из следующих свойств:
Логика создания эффективных отчётов о дефектах
При создании отчёта о дефекте рекомендуется следовать следующему алгоритму:
Типичные ошибки при написании отчётов о дефектах
Ошибки оформления и формулировок:
Логические ошибки:
Жизненный цикл “бага”
Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цикла:
Обнаружен (submitted) — начальное состояние отчёта (иногда называется «Новый» (new)), в котором он находится сразу после создания. Некоторые средства также позволяют сначала создавать черновик (draft) и лишь потом публиковать отчёт.
Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто-то из проектной команды назначается ответственным за исправление дефекта. Назначение ответственного может производится решением лидера команды разработки, коллегиально, по добровольному принципу, иным принятым в команде способом или выполняется автоматически на основе определённых правил.
Исправлен (fixed) — в это состояние отчёт переводит ответственный за исправление дефекта член команды после выполнения соответствующих действий по исправлению.
Проверен (verified) — в это состояние отчёт переводит тестировщик, удостоверившись, что дефект на самом деле был устранён. Как правило, такую проверку выполняет тестировщик, изначально написавший отчёт о дефекте.
Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий. Здесь есть некоторые расхождения в жизненном цикле, принятом в разных инструментальных средствах управления отчётами о дефектах.
Открыт заново (reopened) — в это состояние (как правило, из состояния «Исправлен») отчёт переводит тестировщик, удостоверившись, что дефект по-прежнему воспроизводится на билде, в котором он уже должен быть исправлен.
Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте может быть переведён из множества других состояний, чтобы вынести на рассмотрение вопрос об отклонении отчёта по той или иной причине. Если рекомендация является обоснованной, то отчёт переводится в состояние «Отклонён».
Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно описанных в пункте «Закрыт»: если средство управления отчётами о дефектах предполагает использование этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту.
Отложен (deferred) — в это состояние отчёт переводится в случае, если исправление дефекта в ближайшее время является нерациональным или не представляется возможным, однако есть основания полагать, что в обозримом будущем ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска специалист по необходимой технологии, изменятся требования заказчика и т.д.)
Рис. 3.2. Жизненный цикл отчёта о дефекте
Использование данных отчета о дефекте
Информация по дефектам – это записи о просчетах в качестве, а значит – список возможностей для улучшения качества на ваших будущих проектах. Если вы собираете некую информацию о дефектах (например, после релиза или только на больших проектах), тогда, возможно, Вы захотите улучшить этот процесс.
Информация о дефектах, которая может быть полезна для улучшения качества, включает следующие вопросы:
Когда была создана эта проблема? Какое именно действие при разработке явилось ее источником? Это была проблема в требованиях? Проектировании системы? Коде? Тестировании?
Когда проблема была выявлена? Может, она и не была сразу же устранена, но что нас интересует: сколько она существовала до того, как мы ее обнаружили?
Каким образом была найдена эта проблема? Способ обнаружения можно внедрить в постоянно используемую практику.
Можно ли было обнаружить ее раньше? Есть ли какой-либо процесс контроля качества, который мог бы ее выявить, будь он эффективнее?
Сколько стоило устранение этой проблемы? Этот момент очень легко недооценить. Убедитесь, что Вы учли процесс диагностики проблемы и всю работу по ее устранению, которую Вам пришлось сделать, включая ре-дизайн, переписывание кода, ре-компиляцию, переработку тестов, повторное тестирование, повторный релиз, выпуск заплатки, формирование отчета по дефекту, отчет по статусу проекта и т.д. (не забудьте еще возможные затраты на исправление подпорченной репутации на рынке ПО).
Какого рода была эта проблема? Когда у Вас огромное количество дефектов, то их категоризация облегчает анализ и обучение.
Когда Вы анализируете информацию о дефектах, то ищите те дефекты, которые обнаруживаются регулярно, и те, затраты на устранение которых высоки. Вот как раз таких дефектов и нужно избегать в будущем (или, по крайней мере, устранять их на более ранней стадии разработки), именно такая тактика гарантированно будет способствовать улучшению качества.
Атрибуты отчёта о дефекте
В зависимости от инструментального средства управления отчётами о дефектах внешний вид их записи может немного отличаться, могут быть добавлены или убраны отдельные поля, но концепция остаётся неизменной.
Идентификатор (identifier) представляет собой уникальное значение, позволяющее однозначно отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В общем случае идентификатор отчёта о дефекте может представлять собой просто уникальный номер, но (если позволяет инструментальное средство управления отчётами) может быть и куда сложнее: включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить суть дефекта и часть приложения (или требований), к которой он относится.
Подробное описание (description) представляет в развёрнутом виде необходимую информацию о дефекте, а также (обязательно!) описание фактического результата, ожидаемого результата и ссылку на требование (если это возможно). В отличие от краткого описания, которое, как правило, является одним предложением, здесь можно и нужно давать подробную информацию. Если одна и та же проблема (вызванная одним источником) проявляется в нескольких местах приложения, можно в подробном описании перечислить эти места.
Шаги по воспроизведению (steps to reproduce, STR) описывают действия, которые необходимо выполнить для воспроизведения дефекта. Это поле похоже на шаги тест-кейса, за исключением одного важного отличия: здесь действия прописываются максимально подробно, с указанием конкретных вводимых значений и самых мелких деталей, т.к. отсутствие этой информации в сложных случаях может привести к невозможности воспроизведения дефекта.
Воспроизводимость (reproducibility) показывает, при каждом ли прохождении по шагам воспроизведения дефекта удаётся вызвать его проявление. Это поле принимает всего два значения: всегда (always) или иногда (sometimes). Можно сказать, что воспроизводимость «иногда» означает, что тестировщик не нашёл настоящую причину возникновения дефекта. Тестировщику нужно потратить много времени на то, чтобы удостовериться в наличии дефекта (т.к. однократный сбой в работе приложения мог быть вызван огромным количеством посторонних причин). Разработчику тоже нужно потратить время, чтобы добиться проявления дефекта и убедиться в его наличии. После внесения исправлений в приложение разработчик фактически должен полагаться только на свой профессионализм, т.к. даже многократное прохождение по шагам воспроизведения в таком случае не гарантирует, что дефект был исправлен (возможно, через ещё 10–20 повторений он бы проявился).
Важность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. В общем случае выделяют следующие градации важности:
Срочность (priority) показывает, как быстро дефект должен быть устранён. В общем случае выделяют следующие градации срочности:
наивысшая (ASAP, as soon as possible) срочность указывает на необходимость устранить дефект настолько быстро, насколько это возможно. В зависимости от контекста «настолько быстро, насколько возможно» может варьироваться от «в ближайшем билде» до единиц минут.
высокая (high) срочность означает, что дефект следует исправить вне очереди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем.
обычная (normal) срочность означает, что дефект следует исправить в порядке общей очерёдности. Такое значение срочности получает большинство дефектов.
низкая (low) срочность означает, что, в обозримом будущем, исправление данного дефекта не окажет существенного влияния на повышение качества продукта.
Симптом (symptom) — позволяет классифицировать дефекты по их типичному проявлению. Не существует никакого общепринятого списка симптомов. Более того, далеко не в каждом инструментальном средстве управления отчётами о дефектах есть такое поле, а там, где оно есть, его можно настроить. В качестве примера есть следующие значения симптомов дефекта: Косметический дефект (cosmetic flaw), Повреждение/потеря данных (data corruption/loss), Проблема в документации (documentation issue), Некорректная операция (incorrect operation), Проблема инсталляции (installation problem), Ошибка локализации (localization issue), Нереализованная функциональность (missing feature), Проблема масштабируемости (scalability), Низкая производительность (low performance), Крах системы (system crash), Неожиданное поведение (unexpected behavior), Недружественное поведение (unfriendly behavior), Расхождение с требованиями (variance from specs), Предложение по улучшению (enhancement).
Комментарий (comments, additional info) — может содержать любые полезные для понимания и исправления дефекта данные. Иными словами, сюда можно писать всё то, что нельзя писать в остальные поля.
Приложения (attachments) — представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.)
Свойства качественных отчётов о дефектах
Отчёт о дефекте может оказаться некачественным (а следовательно, вероятность исправления дефекта понизится), если в нём нарушено одно из следующих свойств:
Тщательное заполнение всех полей точной и корректной информацией. Нарушение этого свойства происходит по множеству причин: недостаточный опыт тестировщика, невнимательность, лень и т.д.
Правильный технический язык. Это свойство в равной мере относится и к требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой документации, а потому не будем повторяться.
Специфичность описания шагов. Говоря о тест-кейсах, мы подчёркивали, что в их шагах стоит придерживаться золотой середины между специфичностью и общностью. В отчётах о дефектах предпочтение, как правило, отдаётся специфичности по очень простой причине: нехватка какой-то мелкой детали может привести к невозможности воспроизведения дефекта. Потому, если у вас есть хоть малейшее сомнение в том, важна ли какая-то деталь, считайте, что она важна.
Отсутствие лишних действий и/или их длинных описаний. Чаще всего, это свойство подразумевает, что не нужно в шагах по воспроизведению дефекта долго и по пунктам расписывать то, что можно заменить одной фразой.
Отсутствие дубликатов. Когда в проектной команде работает большое количество тестировщиков, то может возникнуть ситуация, при которой один и тот же дефект будет описан несколько раз разными людьми.
Очевидность и понятность. Описывайте дефект так, чтобы у читающего Ваш отчёт не возникло ни малейшего сомнения в том, что это действительно дефект. Лучше всего это свойство достигается за счёт тщательного объяснения фактического и ожидаемого результата, а также указания ссылки на требование в поле «Подробное описание».
Прослеживаемость. Из содержащейся в качественном отчёте о дефекте информации должно быть понятно, какую часть приложения, какие функции и какие требования затрагивает дефект. Лучше всего это свойство достигается правильным использованием возможностей инструментального средства управления отчётами о дефектах: указывайте в отчёте о дефекте компоненты приложения, ссылки на требования, тест-кейсы, смежные отчёты о дефектах (похожих дефектах; зависимых и зависящих от данного дефектах), расставляйте теги и т.д.
Отдельные отчёты для каждого нового дефекта. Существует два незыблемых правила:
в каждом отчёте описывается ровно один дефект (если один и тот же дефект проявляется в нескольких местах, то эти проявления перечисляются в подробном описании).
при обнаружении нового дефекта создаётся новый отчёт. Нельзя для описания нового дефекта править старые отчёты, переводя их в состояние «открыт заново».
Соответствие принятым шаблонам оформления и традициям. Как и в случае с тест-кейсами, с шаблонами оформления отчётов о дефектах проблем не возникает: они определены имеющимся образцом или экранной формой инструментального средства управления жизненным циклом отчётов о дефектах. Но, что касается традиций, которые могут различаться даже в разных командах в рамках одной компании, единственный совет: почитайте уже готовые отчёты о дефектах, перед тем как писать свои. Это может сэкономить вам много времени и сил.
Логика создания эффективных отчётов о дефектах
При создании отчёта о дефекте рекомендуется следовать следующему алгоритму:
Типичные ошибки при написании отчётов о дефектах
Ошибки оформления и формулировок:
Плохие краткие описания (summary). Формально, эта проблема относится к оформлению, но фактически она куда опаснее: чтение отчёта о дефекте и осознание сути проблемы начинается именно с краткого описания. Суть отчёта о дефекте: ответить на вопросы «что?», «где?», «при каких условиях?».
Идентичные краткие и подробные описания (summary и description). Да, изредка бывают настолько простые дефекты, что для них достаточно одного краткого описания (например, «опечатка в имени пункта главного меню “File” (сейчас “Fille”)»), но, если дефект связан с неким более-менее сложным поведением приложения, стоит продумать как минимум три способа описания проблемы:
краткий для поля «краткое описание» (его лучше формулировать в самом конце размышлений);
подробный для поля «подробное описание» (поясняющий и расширяющий информацию из «краткого описания»);
ещё один краткий для последнего шага в шагах по воспроизведению дефекта.
Отсутствие в подробном описании явного указания фактического результата, ожидаемого результата и ссылки на требование, если они важны, и их представляется возможным указать.
Игнорирование кавычек, приводящее к искажению смысла. Как Вы поймёте такое краткое описание, как «запись исчезает при наведении мыши»? Какая-то запись исчезает при наведении мыши? А вот и нет. Оказывается, «поле “Запись” исчезает при наведении мыши». Даже если не дописать слово «поле», кавычки подскажут, что имеется в виду имя собственное, т.е. название некоего элемента.
Общие проблемы с формулировками фраз на русском и английском языках.
Лишние пункты в шагах воспроизведения.
Копии экрана в виде «копий всего экрана целиком». Чаще всего нужно сделать копию какого-то конкретного окна приложения, а не всего экрана, тогда поможет Alt+PrintScreen. Даже если важно захватить больше, чем одно окно, практически любой графический редактор позволяет отрезать ненужную часть картинки.
Копии экрана, на которых не отмечена проблема. Если обвести проблемную область красной линией, то это в разы повысит скорость и простоту понимания сути проблемы в большинстве случаев.
Откладывание написания отчёта «на потом». Стремление сначала найти побольше дефектов, а уже потом их описывать приводит к тому, что какие-то важные детали (а иногда и сами дефекты!) забываются. Если «на потом» измеряется не минутами, а часами или даже днями, то проектная команда не получает важную информацию вовремя. Вывод простой: описывайте дефект сразу же, как только обнаружили его.
Пунктуационные, орфографические, синтаксические и им подобные ошибки.
Логические ошибки:
Выдуманные дефекты. Одной из наиболее обидных для тестировщика причин отклонения отчёта о дефекте является так называемое «описанное поведение не является дефектом» («not a bug»), когда по какой-то причине корректное поведение приложения описывается как ошибочное.
Неверно указанные симптомы. Это не смертельно и всегда можно подправить, но, если изначально отчёты будут сгруппированы по симптомам, это создаёт множество раздражающих неудобств.
Чрезмерно заниженные (или завышенные) важность и срочность. С этой бедой достаточно эффективно борются проведением общих собраний и пересмотром отчётов о дефектах силами всей команды (или хотя бы нескольких человек), но, если эти показатели занижены именно чрезмерно, есть высокая вероятность, что пройдёт очень много времени, прежде чем до такого отчёта просто дойдёт очередь на следующих собраниях по пересмотру.
Концентрация на мелочах в ущерб главному. Здесь стоит упомянуть хрестоматийный пример, когда тестировщик нашёл проблему, приводящую к краху приложения с потерей пользовательских данных, но записал её как косметический дефект (в сообщении об ошибке, которое «перед смертью» показывало приложение, была опечатка). Всегда думайте о том, как произошедшая с приложением неприятность повлияет на пользователей, какие сложности они могут из-за этого испытать, насколько это для них важно, тогда шанс увидеть реальную проблему резко повышается.
Техническая безграмотность. Представьте себе такое краткое описание (оно же идентично продублировано в подробном, т.е. это и есть всё описание дефекта): «Количество найденных файлов не соответствует реальной глубине вложенности каталога». А что должно? Это ведь почти то же самое, что «цвет кошки не соответствует её размеру».
Указание в шагах воспроизведения неважной для воспроизведения ошибки информации. Стремление прописать всё максимально подробно иногда принимает нездоровую форму, когда в отчёт о дефекте начинает попадать чуть ли не информация о погоде за окном и курс национальной валюты.
Отсутствие в шагах воспроизведения информации, важной для воспроизведения дефекта.
Игнорирование «последовательных дефектов». Иногда один дефект является следствием другого (допустим, файл повреждается при передаче на сервер, а затем приложение некорректно обрабатывает этот повреждённый файл). Да, если файл будет передан без повреждений, то второй дефект может не проявиться. Но может и проявиться в другой ситуации, т.к. проблема никуда не исчезла: приложение некорректно обрабатывает повреждённые файлы. Потому стоит описать оба дефекта.