Уровень 5                   Работа с дефектами

Извечные вопросы тестировщика: "Заводить баг или не заводить? Баг или фича?"

Баг

Для начала давайте же разберемся что такое этот пресловутый баг и что за дерзость такая - фича? 

 

Баг (англ. bug — жук, мелкое насекомое) — распространенное среди программистов название ошибок в программах.

Следует отличать баг от глюка, который есть не что иное как симптом бага, вызывающий у юзера нервно-истерическую реакцию.

 

Также имеется производное от «баг» понятие «бага». «Бага» — то же самое, что и «баг», только женского рода. Считается, что фиксить «багу» приятнее, чем «баг».

 

Термин «баг» обычно употребляется в отношении ошибок, проявляющих себя на стадии работы программы, в отличие, например, от ошибок проектирования или синтаксических ошибок.

 

Фича  (от feature; свойство, способность, возможность, функциональность и т. п.). Обычно используется в приложении к какой-то программе - "Важной фичей программы является возможность экспортировать отчет в таблицу Excell".

 

Также известна фраза «это не баг, это фича» (иногда «багофича»). Таким образом, любой задокументированный баг, не влияющий на работоспособность программы (да и влияющий — нередко тоже), переходит в категорию её функциональностей (особенностей). Подобной «багофичей» была невероятная возможность в windows 98 перезагрузить windows, не перезагружая компьютер. Надо было, нажимая «перезагрузку» в окне «Завершение работы», нажать шифт. Это сильно экономило время на перезагрузку, но при этом было как-бы багом.

Написание баг репорта​
Баг репорт

Баг репорт - это технический документ и поэтому язык описания проблемы должен быть техническим. Должна использоваться правильная терминология при использовании названий элементов пользовательского интерфейса (editbox, listbox, combobox, link, text area, button, menu, popup menu, title bar, system tray и т.д.), действий пользователя (click link, press the button, select menu item и т.д.) и полученных результатах (window is opened, error message is displayed, system crashed и т.д.).

 

Требования к обязательным полям баг репорта

 

Обязательными полями баг репорта являются: короткое описание (Bug Summary), приоритет (Prority), шаги к воспроизведению (Steps to reproduce), фактический результат (Actual Result), ожидаемый результат (Expected Result).

 

Ниже приведены требования и примеры по заполнению этих полей.

 
Принцип создания заголовка баг репорта​

Принцип "Где? Что? Когда?"

Как пример создание заголовка баг репорта. Заголовок или summary должен отображать всю суть бага и быть таким, чтобы без прочтения полного описание бага было понятно о чем идет речь

 

Для создания заголовка составьте предложение, в котором факты дефекта изложены в следующей последовательности:

  • Где? В каком месте интерфейса пользователя или архитектуры программного продукта находится проблема. Причем, начинайте предложение с существительного, а не с предлога.

 

  • Что? Что происходит или не происходит согласно спецификации или вашему представлению о нормальной работе программного продукта. При этом указывайте на наличие или отсутствие объекта проблемы, а не на его содержание (его указывают в описании). Если содержание проблемы варьируется, все известные варианты указываются в описании.

 

  • Когда? В какой момент работы программного продукта, по наступлению какого события или при каких условиях проблема проявляется.

Например:
Что: неправильный расчет данных
Где: на странице NNN
Когда: после ввода а поле Y отрицательного значения.

Старайтесь не писать фразы типа «я кликаю на ссылку», «я нажимаю кнопку» и им подобные. И заголовок, и описания шагов — это руководство к действию для тех, кто будет исправлять проблему, поэтому лучше формулировать как «кликнуть на ссылку», «нажать на кнопку»

Например:

Мобильная версия сайта > Фильтр записей по времени > При выборе двух значений дропдауна времени одновременно страница зависает

Отличие бага от баг репорта​
 

У вас, наверное, возник вопрос -  "в чем разница бага и баг репорта?". Уточню:  баг - это сама ошибка по сути, зато когда тестировщик её опишет по всем правилам, она превратится в баг репорт, про который обычно говорят: "Я открыл багу" или "Я завел баг". Кроме того, баг репорт может включать в себя как один конкретный баг, так и все найденные баги при тестировании программы/сайта/приложения. 

 

Почему так? Когда вы работаете с баг трекинговой системой, обычно на каждый баг создается свой отдельный электронный документ (баг репорт) и так далее, для каждого из них. А когда же вы работаете без баг трекинговой системы, то баги оформляются либо в текстовом документе либо в таблице и туда же записывают все другие найденные баги. Не будете вы создавать отдельный файл для каждого бага.  

 

Многие считают, что все тестирование сводится к поиску багов, но мы выяснили в первом уровне, что это не так. Но не будем приуменьшать значение этой работы. Все-таки 80-90% работы тестировщика - это поиск ошибок. Но важно запомнить одно - тестировщика ценят не за найденные им баги, а за не пропущенные.  То есть провал - это когда пользователи в полученном продукте обнаружили дефекты, особенно, если они мешают бизнес-процессу. Пропуск багов, которые трудно отловить или влияют на очень малое количество пользователей - не считаются провальными для тестировщика.

 

Еще немного про баг репорт
  • Алгоритм трекинга (учёта шагов по обработке сообщения об ошибке) дефектов может отличаться от проекта к проекту.

 

    Рекомендуемая схема трекинга ошибки:

  • Тестировщик  заносит сообщение об ошибке и адресует его ведущему тестировщику, предварительно указав приоритет ошибки.

 

  • Ведущий тестировщик - проверяет полноту описания ошибки (ссылки на требования, скриншоты, логи системы или приложения) и воспроизводимость ситуации, повлекшей сбой, а также уточняет приоритет и переводит ошибку в группу разработки.

 

  • Обратный трекинг осуществляется в обратной последовательности через все звенья пути трекинга.

  • Описание ошибки (bug, defect report) является, наряду с отчётом по тестированию, основным артефактом, за который отвечает тестировщик

 

  • Рекомендованная форма описания ошибок для систем, ориентированных на реализацию интерактивного диалога с пользователем:

    • Что я сделал

    • Что я ожидал

    • Что я получил

 

  • Виды дефектов соотносятся с видами тестирования, которые проводились для их выявления (уровень 2). Есть ещё дефекты, вызванные нарушением соглашений о кодировании, стандартов пользовательских интерфейсов и другие.

Моя думать, что ты устал, но силы зла не дремлют и хорошо подготовиться должен ты. Попытайся воодушевиться и сосредоточиться

Основные поля баг репорта :

Короткое описание (Summary)

Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.

Проект (Project)

Название тестируемого проекта

Компонент приложения (Component)

Название части или функции тестируемого продукта

Номер версии (Version)

Версия, на которой была найдена ошибка

Приоритет (Priority)

Наиболее распространена пятиуровневая система градации серьезности дефекта:

  • P1 Блокирующий (Blocker)

  • P2 Критический (Critical)

  • P3 Значительный (Major)

  • P4 Незначительный (Minor)

  • P5 Тривиальный (Trivial)

(подробнее смотрите ниже в разделе Приоритезация дефекта)

 

Серьезность (Severity)

 Серьезность дефекта:

  • S1 Высокий (High)

  • S2 Средний (Medium)

  • S3 Низкий (Low)

(подробнее смотрите ниже в разделе Градация серьезности)

Статус (Status)

Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)

Автор (Author) или Reporter

Имя создателя баг репорта

 

Назначен на (Assigned To)

 

Имя сотрудника, назначенного на решение проблемы

Окружение

ОС / Сервис Пак и т.д. / Браузера + версия / ...

Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования - имя и версия браузера и т.д.

Описание

Шаги воспроизведения (Steps to Reproduce)

Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.

Фактический Результат (Result)

Результат, полученный после прохождения шагов к воспроизведению

Ожидаемый результат (Expected Result)

Ожидаемый правильный результат

Дополнения

Прикрепленный файл (Attachment)

 

Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы

Приоритезация дефектов
Приоритезация дефектов

Градация Приоритета дефекта (Priority). При описании бага используются только английское название приоритета. 

  • Блокирующий баг (Blocker)
    Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.

 

  • Критический баг (Critical)
    Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системы.

 

  • Значительный баг (Major)
    Значительная ошибка, или самый стандартный баг, присваивается когда часть основной бизнес-логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.

 

  • Незначительный баг (Minor)
    Незначительная ошибка, не нарушающая бизнес- логику тестируемой части приложения или очевидная проблема пользовательского интерфейса.

 

  • Тривиальный баг (Trivial)
    Тривиальная ошибка, не касающаяся бизнес-логики приложения, плохо воспроизводимая проблема, малозаметная ошибка пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Градация серьезности дефекта (Severity)

  • S1 Высокий (High)
    Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критическим  для проекта.

 

  • S2 Средний (Medium)
    Ошибка должна быть исправлена, ее наличие не является критическим, но требует обязательного решения.

 

  • S3 Низкий (Low)
    Ошибка должна быть исправлена, ее наличие не является критическим и не требует срочного решения.

 

Порядок исправления ошибок по их приоритетам:

High -> Medium -> Low

 
Основные ошибки при составлении баг  репортов
  • Недостаточность предоставленных данных
    Не всегда одна и та же проблема проявляется при всех вводимых значениях и под любым вошедшим в систему пользователем, поэтому настоятельно рекомендуется вносить все необходимые данные в баг репорт.

 

  • Определение приоритета и серьезности
    Очень часто происходит завышение либо занижение серьезности дефекта, что может привести к неправильной очередности при решении проблемы.

 

  • Язык описания
    Часто при описании проблемы используются неправильная терминология или сложные речевые обороты, которые могут ввести в заблуждение человека, ответственного за решение проблемы.

 

  • Отсутствие ожидаемого результата

В случаях, если вы не указали, что же должно быть требуемым поведением системы, вы тратите время разработчика на поиск данной информации, тем самым замедляете исправления дефекта. Вы должны указать пункт в требованиях, написанный тест-кейс или же ваше личное мнение, если эта ситуация не была документирована.

 
Ответственные лица за оформление полей баг репорта
Работа с дефектами
(трекинг по статусам)​
Bug lifecycle / Cтатусы бага

На схеме изображен классический алгоритм обработки бага. Баги заводить может кто угодно, но обычно это тестировщик или саппорт (второй вариант плохой). После создания баг получает статус "new" и идет на проверку, получая статус "in review". Уточним, что не во всех компаниях делают баг-ревью, и тогда тестировщик сразу переносит баг в состояние "open". В случае ревью баг могут закрыть (если он не актуален), либо передать в отдела разработки для исправления, тот же "open". После исправления багу присваивается статус "resolved" и тестировщик приступает к проверке качества исправления дефекта. Тут два пути: вернуть на доработку со статусом "reopen" либо закрыть баг. В некоторых случаях можно даже переоткрыть закрытую багу, если она вдруг воскресла в новой версии. 

Resolution - причина присвоения статуса

Статусов в жизненном цикле дефекта ограниченное количество, а для того чтобы описать причину того или иного статуса использую резолюцию. Она объясняет причину установки статуса. Ведь все баги будут в конце концов закрыты, но причины закрытия у всех разные. Что-то исправили, что-то отложили, а кое-что и вовсе оказалось не багом. Выбор резолюций на проекте зависит от методологии разработки ПО. ДАвайте рассмотрим стандартный набор резолюций:

Резолюции багов

Fixed/Resolved - Лучший статус, баг исправлен : )

As designed/By design  - предложенный баг является фичей

Cannot Reproduce - баг более не воспроизводится, нужно его перепроверить и либо уточнить описание либо закрыть, если не получилось воспроизвести

Deferred/Postponed - отложен до лучших времен

Obsolete/Not relevant - баг устарел и ему "пора не пенсию" или он просто стал неактуален
Not a bug - ваш баг не признали таковым

Duplicate - такой баг уже есть и один из них следует закрыть

Won’t fix - не хотят  фиксить по разным причинам, например слишком маленькое влияние на пользователей при большой сложности починки

Incomplete - незавершённый баг - хула и порицание тестировщику, которому вернули баг с таким статусом ибо не сумел он описать все правильно
Merged - фикс слит с другим функционалом либо задача включена в основной код и более не является самостоятельным кодом
SF Closed - и такое бывает, баг самоликвидировался

 

Статусы могу быть и другими в конкретной компании, а выше перечисленны все стандартные статусы.

 
Серьёзные шутки

Баги классифицируются по степени их вредности:

  • showstoppers

  • серьёзные

  • мелкие

  • фигня

  • придирки тестировщиков

 

По частоте появления:

  • постоянно

  • иногда (самый сволочной тип бага, «плавающий»)

  • только на машине у заказчика

 

Также баги классифицируются по тому, кто и где заметил симптомы. Например, если баг заметил Мегабосс Всех Заказчиков на уже запущенной системе, то баг будет исправлять все выходные весь IT-отдел, включая уборщицу.

 

Особо приятные баги — showstoppers, найденные в пятницу вечером. Они могут доставить несказанное удовольствие любому программисту, который любит уходить с работы в субботу утром.

 

Баги в больших количествах производятся индусами и китайцами, а также различными быдлокодерами. Продукты, содержащие передоз этих багов, называются багодромом.

 

Имеется специальное заклинание: «Это не баг, это фича», которое позволяет избавиться от бага с наименьшими потерями, то есть, ничего не делая. Однако этим колдовством владеют только самые опытные программисты.

 
Боевое наставление

Перед тем как начать самому оформлять баги, просмотрите пример расставления приоритетов для багов. Каждого бага по приоритету - так сказать. Уточним также, что в нашей классификации приоритет первичный, а серьезность вторична. Это значит, что вначале определяется приоритет бага, а каждый из приоритетов, в свою очередь,  делится на 3 уровня серьезности  для того, чтобы выделить баг среди его друзей. Для данного примера взяты баги с сайта по покупке печеньев (уровень 4).

Blocker  

При покупке печенья, при нажатии на кнопку  "Добавить в корзину" переводит на неожиданную страницу. Нет возможности перейти на страницу с корзиной покупок. Нет workaround

Critical

Нет возможности купить конфету на палочке (конкретный вид). При нажатии на кнопку "Купить" ничего не происходит. Падает консольная ошибка "Unexpected error", не увеличивается количество товара в корзине

Major

В галерее кексов на главной странице не работает одно из изображений. Крутится вечный прелоадер. Шаги воспроизведения: прокрутить галерею на 5 картинок ...

Minor

Орфографическая ошибка в ссылке "купить печенье чичас" на главной странице

Trivial

Ссылка "купить печенье чичас" на главной странице при переходе по ней не меняет свой цвет. ОР: кликнутые ссылки фиолетового цвета

Видеоурок - все о баг репорте на практике 
Практика

Cкопируй себе таблицу моего баг репорта. Выбери последний принятый и оцененный баг из последнего домашнего задания и оформи его по всем правилам. 

Практическое задание

Приветствую тебя мой ученик! Хочу поблагодарить тебя за отличное тестирование. Мне очень понравились баги, которые ты мне прислал, поэтому я хочу больше багов!

Но теперь, когда ты все знаешь о багах, они должны быть идеально офрмленны.

 

Итак, задание:

Протестировать сайт и найти все баги. Баги нужно оформить согласно примеру баг репорта.

 

Это самый простой сайт из тех, что тебе приходилось тестировать, поэтому будет 2 равносильных оценки: 

за найденные дефекты и правильность оформления баг репорта -  верное описание, правильный приоритет и пр. 

Должен ознакомиться ты с некоторыми 

програмами, юный тестировщик. Jiing и Joxy - это важные программы, которые помогут тебе записывать видео и скриншоты для багов. Скачай и установи, а скрины сбрось в форме c тест-планом у R2D2 или добавь в баги.

Уровень 6

Для перехода на уровень 6, необходимо набрать минимум 18 балла (60%)  за задания уровня 5.