Дефект /Баг. Баг-репорт. Жизненный цикл бага.

На первом занятии мы уже обращались к определению бага. Простое его определение звучит так: баг — это любое отклонение ожидаемого поведения продукта от фактического результата.

Мы с вами даже смотрели на более формальное его определение, которое следует из причин возникновения бага: багом является любой недостаток в продукте, который может привести к тому, что продукт не сможет выполнять требуемую функцию.

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

Давайте вспомним, откуда берутся баги. Создают продукт люди, в работе они могут допускать ошибки (mistake), например прописать требование неточно. При разработке эта неточность переходит в код, тем самым создается дефект (bug), который в свою очередь приводит к неправильной работе продукта, а это называется сбой (failure).

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

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

Что значит поднять вопрос об исправлении ошибки? Это значит, что при нахождении любой подозрительной или негативной ситуации, которая приведёт к некачественному продукту, тестировщик выносит этот вопрос на обсуждение с участниками процесса. Например, если это ошибка в требованиях, тестировщик может напрямую обратиться к аналитику или заказчику и уточнить данный момент, может написать письмо, а может создать issue (ишью) в системе трекинга. Что такое issue и система трекинга, мы рассмотрим чуть позже.

Если же ошибка обнаружена в работе непосредственно продукта или его компонента, подсистемы и т. п., то также необходимо поднять этот вопрос. Однако тестировщик не заводит сразу баг-репорт, если, конечно, это не кристально понятная ситуация, где без дополнительных разъяснений мы решаем, что это баг. Прежде чем заводить баг-репорт (или отчёт об ошибке), необходимо в этом убедиться.

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

Во-вторых, можно уточнить данное поведение у коллег, аналитиков или тестировщиков, верно ли вы всё поняли и попросить подтвердить, баг ли это. Когда вы точно уверены, что продукт работает в данном месте неверно, смело можно заводить баг-репорт.

Итак, что такое баг-репорт и как его заводить? Обычно баги живут в баг-трекинговых системах, куда есть доступ у всех участников процесса, в них есть уже готовые шаблоны для заведения различных issue.

Вообще issue — это общее определение для любой проблемы. В работе тестировщику приходится много взаимодействовать с участниками процесса, и системы трекинга в этом помогают тем, что в них хранится вся информация по поднятым вопросам на проекте. В этих самых issue могут быть и баг-репорты, и какие-то запросы (request), и задачи (task), и ещё несколько других типов issue. Как это выглядит, мы посмотрим дальше при работе с джира.

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

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

Теперь давайте разбираться с атрибутами баг-репорта. Первое, что мы уже упоминали, — это название дефекта (или его summary). Оно должно быть кратким и ёмким, сразу отражать суть проблемы, например поле ФИО заблокировано для ввода значений.

Второе — это описание дефекта (description), где уже нужно подробно, в рамках разумного, конечно, описать проблему: при каких обстоятельствах она возникла, какие данные вводились в систему при этом, какие манипуляции производились в системе, что ожидали получить и что получили в результате. Что тут ещё важно? Вы не можете утверждать каждый раз, когда столкнетесь с какой-то проблемой в системе, что это баг и заводить его. Важны доказательства того, что это действительно баг, т. е. вы должны указать, на что вы опираетесь, когда делаете заключение о баге. Мы сейчас говорим о требованиях, т. е. в начале описания дефекта необходимо указать пункт требования, где описывается корректное ожидаемое поведение системы. Это упрощает исправление дефекта: во-первых, участники не тратят время на разбор, действительно ли тестировщик прав, заводя баг-репорт. Во-вторых, отсылка к требованию поможет разработчикам быстрее найти тот кусок кода, который они писали по данному требованию. Ну и в-третьих, для истории проекта, когда требования могут меняться, будет понятно, в рамках чего поднималась эта проблема. А также это повышает вашу квалификацию, демонстрируя ваше умение работать как с требованиями, так и с продуктом.

Требования требованиями, но баг-репорт должен явно содержать информацию об ожидаемом результате (expected result), чтобы быстро можно было понять, что должно произойти. В паре с ним тестировщик должен обязательно указать фактический результат (actual result). Этот пункт показывает, как на самом деле работает продукт и также доказывает наличие дефекта.

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

Ещё два важных атрибута баг-репорта — приоритет и серьёзность (Priority and Severity). Что показывает тот и другой атрибут?

Начать стоит со второго атрибута, т. к. приоритет бага выставляется, опираясь на его серьёзность. Итак, серьёзность бага — это его критичность для продукта, она показывает, насколько серьёзно этот дефект влияет на работу продукта. В основном, выделяют четыре степени важности бага. Критичная (Critical) проблема приводит к критическим последствиям, например пользователи не могут совершать никакие действия в продукте, он зависает или отваливается доступ к нему, в результате чего компания теряет большие деньги. Или другая проблема, когда данные пользователей или денежных транзакций уходят куда-то на сторону. Это примеры ситуаций, когда продукт уже в руках пользователей, конечно, такого допускать не стоит, однако и такое случается. В некоторых компаниях есть политика штрафов за обнаруженные баги на проде, например если компания тестирует сторонний продукт.

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

Серьёзность ниже определяется, как высокая или значительная (Major). В таких ситуациях дефект приносит явно ощутимые проблемы в использовании, например продукт работает, но неверно выполняет какие-то функции, рассчитывает что-то неправильно, или даёт ответ долго.

Средняя серьёзность (Medium) — это ситуации, когда продукт в целом работает, но какие-то функции выполняются некорректно и их можно выполнить, приложив к этому дополнительные усилия. К примеру, оформить услугу можно не с главного экрана оформления услуг, а через личный кабинет клиента; или всплывает какое-то информационное окно и его нельзя закрыть, нажав на крестик, но можно, щёлкнув в любое другое место на экране. Таким образом, к средней серьёзности будут относиться любые функциональные дефекты, которые не наносят такой урон, как первые два.

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

Приоритет демонстрирует важность исправления этого дефекта среди других, т. е. насколько быстро его необходимо взять в работу программистам и исправить поведение системы. В команде у каждого значения приоритета зафиксированы сроки, в течение которых баг должен быть исправлен и закрыт, поэтому ставить высокий приоритет подряд всем багам может быть чревато тем, что вы подпортите работу над другими текущими задачами. Однако в работе при возникновении такой ситуации к вам просто придут и спросят, почему вы ставите везде высокий приоритет, и могут его оспорить, поэтому, если вы сомневаетесь в выставлении приоритета, посоветуйтесь со старшими коллегами или вашим руководителем. Чаще всего выделяют четыре приоритета: наивысший (highest) — такой дефект требует как можно скорейшего вмешательства и исправления, высокий (high) — дефект требует, чтобы его взяли первым из очереди остальных, средний (medium) — такие дефекты спокойно следуют своей очереди, и низкий (low или minor). Бывает еще самый низкий или тривиальный приоритет (lowest или trivial), его получают такие дефекты, которые обычно фиксируют, чтобы не забыть когда-нибудь исправить. Сразу хочу отметить, что подобные названия для срочности бага не обязательно будут в каждой команде. Вполне реально, что названия могут немного отличаться, важно понимать саму суть. Если вы скажете , что для самой срочной ошибки нужно выставить приоритет highest, а команда использует для этого название asap или urgent, это не будет ошибкой.

Помимо этих обязательных атрибутов баг-репорта, в нём вы должны указать, где такой баг возник. Что подразумевается под словом где? У команд бывают различные тестовые среды/окружения (под тестовой средой понимаем тестовый вариант приложения). Не все задачи релизятся в одну и ту же версию, или бывает что для разных версий приложения есть какие-то свои внутренние настройки, например операторы с различным уровнем доступа к данным, поэтому важно указывать в баг-репорте как раз версию продукта, которую вы тестируете.

После того как вы завели баг-репорт, ему необходимо назначить ответственного. В некоторых системах трекинга команда настраивает ответственного автоматически, в таком случае можно не думать о том, кому назначить баг-репорт, ответственный сам его распределит. Когда команды маленькие и гибкие и все участники понимают, кто и за что несёт ответственность, тестировщик сам определяет, на кого нужно перевести баг.

Что ещё требуется от тестировщика, когда он репортит баг? Порой, чтобы не предоставлять большое описание проблемы, можно для наглядности показать её скриншот, сделав снимок приложения и подсветив красным проблемное место, например. Это вообще лучше делать всегда, потому что так вы имеете доказательство дефекта и оно поможет отследить в дальнейшем изменения в случае смены требований или дизайна. Вообще, помимо скриншотов, можно прикреплять всё, что доказывает дефект и помогает его скорейшему исправлению. Это могут быть сообщения от сервера, от другой системы, логи.

Ещё уделим немного времени логам. Вы как начинающий тестировщик должны знать, что это такое, а затем учиться с ними работать на практике. Лог (log) или лог-файл — это файл, который в хронологическом порядке содержит всю информацию о работе пользователя в системе, о внутренней работе самой системы, об ответах от сервера и всё тому подобное. По сути, это чёрный ящик для нашего продукта. Логи нужны для того, чтобы анализировать работу приложения, собирать его статистику, а в случае возникновении проблем по нему можно восстановить последовательность действий, приведшую к такому результату. Логи хранятся в специально отведённых для них местах. У каждого продукта может быть свой подход: они могут храниться в специальной папке на сервере или записываться в какой-то сервис, например, grayLog или Kibana. Обычно логи представляют из себя текстовый файл с расширением .txt или .log, и их можно просматривать в текстовом редакторе (Блокноте, например). Лог-файлы могут содержать различные типы сообщений, например все подряд или только сообщения с ошибками, или информационные сообщения. Это называется уровнем логирования: т. е. мы настраиваем запись логов, указывая для них тот уровень, который необходим. Работая с логами, вы лучше станете понимать, как устроен продукт, как и какие процессы происходят. Лог-файлы со временем удаляются или перезаписываются новой информацией, поэтому в баг-репорте вы должны предоставить актуальные логи, демонстрирующие вашу проблему.

Повторим, пожалуй, самые основные атрибуты баг-репорта: Название, Описание, Шаги воспроизведения, Ождаемый результат, Фактический результат, Приоритет, Серьезность. Они используются в каждой команде, при этом вы можете встретить другие атрибуты, зависящие от проекта и от того, что требуется там указывать дополнительно.

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

Баг-трекинговая система. Знакомство с Jira.

Теперь давайте разберемся с тем, что же такое система трекинга и как там живётся баг-репорту. Системы трекинга — это специальные программы, которые позволяют хранить и отслеживать все поднятые проблемы на проекте. Более узкое их название — баг-трекинговые системы, и оно встречается намного чаще, нежели первое. Зачем нужна такая программа на проекте? Для того, чтобы ни одна проблема и задача не потерялась, а была решена. С помощью баг-трекинговой системы можно контролировать все поднятые проблемы и задачи команды и управлять ими. Почему это возможно? Потому что все проблемы видит вся команда, для каждой issue есть свой процесс, по которому она идёт, в системе легко можно видеть, на какой стадии сейчас та или иная issue.

Давайте знакомиться с одной из таких программ — Jira. Название она получила от японского Gojira, и это некая отсылка к их конкуренту Bugzilla. Jira — это не только система трекинга, это ещё и инструмент управления проектом. Здесь можно легко вести свой проект независимо от того, по какой модели он идёт. Итак, какие инструменты есть в Jira? Проект (Project) — это по сути контейнер или хранилище всех задач, проблем, баг-репортов и т. п., которые ведутся и создаются в рамках разработки вашего продукта. Project можно представить, как полку с папками документов, а вот папки, которые хранят определенные документы, — это issue. Issue — это общее название для любых проблем проекта, для определённого типа issue есть свой шаблон, т. е. набор полей, которые заполняют пользователи.

Давайте перейдем к знакомству с интерфейсом в Jira. Когда вы логинитесь под своими учетными данными по дефолтному состоянию вы попадаете на страницу, которая называется Your Work. Если в вашей команде настроено иначе, не пугайтесь, со временем во всем разберётесь. Сначала эта страница будет пустой, затем по ходу курса вы увидите, как она будет наполняться. Итак, что есть на этой странице? Reсent Projects — проекты, которые вы недавно посещали, заходили посмотреть на какие-нибудь карточки/issue. Ниже — карточки, с которыми вы работали (Worked on), которые просматривали (Viewed), карточки, которые переведены на вас (Assigned to me) и карточки, которые отмечены вами звездой, что-то типа выделения популярных для вас, для быстрого доступа, например.

Кнопка в левом верхнем углу позволяет переключаться в другие приложения, связанные с Jira. Если у пользователя есть определённые права, то тут можно настроить быстрый доступ к нужным вам приложениям. Рядом с ней кликабельный логотип jira, он также может выглядеть по-разному в разных командах. Кликнув по нему, вы приходите на домашнюю страницу Your Work. Выпадающая кнопка Your Work дает возможность быстро переключиться к каким-то карточкам или местам в jira, например к тем, которые переведены на вас, или на доску вашей команды. Доска — это то место, где отображаются все карточки вашей команды, над которыми планируется, идёт или завершена работа. Projects — проекты, доступные вам. Filters — это настроенные вами фильтры, которые позволяют сразу переходить к нужным карточкам. Dashboards — доски, предоставляющие быстрый доступ к карточкам, по которым идёт работа или, например, доски, отображающие рейтинг каких-то задач. Доски вы можете сами настраивать для себя и также их можно настраивать для своей команды. В каких-то версиях jira, как раз раздел Dashboards является домашней страницей, на которую вы попадаете после логина. People — тут найдете всех участников вашей команды и других команд в вашей организации. Кнопка Apps даёт возможность добавлять сторонние приложения. Кнопка Create позволяет вам создавать различные issue.

В правой части — строка Поиск, которая позволяет искать всё, что угодно: проекты, issue, людей, доски, в зависимости от ваших пользовательских прав. Значок Оповещения даёт возможность видеть все новые оповещения для вас, новый комментарий, например, или новую задачу, которую перевели на вас. Help содержит документацию для помощи пользователям. Дальше идут Settings, для обычных пользователей опций настроек будет меньше, чем у админов. И в самом конце — Вкладка пользователя, тут находятся ваши персональные настройки и профиль.

Теперь давайте посмотрим, как выглядит страничка проекта. Кликнув на проект, мы туда попадём. Наш проект создан по шаблону канбан, это тоже можно настроить по-разному. Эта таблица представляет собой стадии жизненного цикла задач. Задача мигрирует из колонки в колонку, тем самым различные участники команды подключаются к работе над ней. Вверху над таблицей есть строка поиска, с помощью которой можно искать нужную вам информацию на доске. Например, вам нужны все карточки, где идёт работа над авторизацией: по ключевому слову Jira подсветит вам карточки, где используется это слово. Далее, нажав на иконку пользователя, можно отфильтровать все карточки, которые сейчас висят на нём и он по ним работает. Помимо этого всего, есть возможность группировать карточки по различным принципам.

Давайте теперь познакомимся с основными типами issue, которые есть в дефолтной настройке в Jira. Начнём с наиболее знакомой нам — Story (происходит от User story). Это описание функциональности продукта простыми, общими словами, составленное с точки зрения конечного пользователя. Она пишется с целью разъяснить, как именно эта функция программы принесёт пользу клиенту. Story оформляется по определённому шаблону, содержащему три ключевых пункта: пользователь, цель, причина.

Я, как <тип пользователя> As s

Хочу <какая-то цель> I want

Чтобы <какая-то причина> So That

Например, я как премиальный клиент приложения хочу иметь возможность получать бонусы, чтобы оплачивать покупки со своего счета.

Историй может быть много для работы в рамках одного куска продукта, и они содержатся в Epic (Эпике). Над эпиком могут работать несколько разных команд, это большой объём работы над продуктом, поэтому их дробят на более мелкие части — истории.

Ну а сами story тоже могут разбиваться на более мелкие задачи, которые так и называют — Задача и подзадача (Task и Sub-task).