Что такое баг? Что такое баг-репорт? И для кого на самом деле нужны баги?

Прошлая часть: Что такое тест-план? И почему было бы неплохо если бы у вас он был...

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

"Основные атрибуты / поля бага";

"Приоритет и серьезность";

"Статус бага и жизненный цикл бага";

"Для кого на самом деле оформляется баг-репорт".

Теперь по теме. По стандарту, пройдемся по определениям.

Дефект / Баг / Bug (как ситуация) – это отклонение фактического результата от ожидаемого результата.

Дефект / Баг / Bug/ Баг-репорт (как документ) – это документ, подробно описывающий ситуацию или последовательность действий, когда фактический результат отличается от ожидаемого результата.

И сразу же конкретизируем пару моментов:

1. Тестировщики, в большинстве своем, пользуются терминами дефект или баг без явного указания что они имеют ввиду. Когда тестировщик консультируется с разработчиком или аналитиком «Посмотри, пожалуйста, вот тут у нас баг или так должно быть?» - он имеет ввиду баг / дефект, как ситуацию. А когда тестировщик говорит разработчику: «Я завел баг – возьми его в работу пожалуйста» - он имеет ввиду баг / дефект как документ (т.е. задачу в системе управления задачами)
2. Приписок вида «… при работе ПО» в определениях нет осознано. Баги случаются не только при работе ПО. Баги бывают в требованиях. Баги бывают в процессе сборки конкретных версий ПО. Баги бывают при установке конкретных версий ПО на тестовые стенды. Например, вы ожидали, что сборка определенной версии пройдет успешно, а она упала – это отличие фактического результата от ожидаемого, а следовательно баг.
3. Не каждый баг имеет баг-репорт. Всё разнится от проекта к проекту и от вашего взаимоотношения с членами команды разработки. Бывают случаи, что вам проще на словах договориться с разработчиком, в котором вы уверены, чтобы он внес исправления в пару строчек кода. Однако бывают и обратные случаи, когда вы настолько не уверены в коллеге, что на каждый баг будете заводить баг-репорт – тут всё сугубо индивидуально.
4. Баги – это то, с чем инженер по тестированию работает чуть ли не половину своего рабочего времени. Поэтому важно хорошо разобраться в этой теме – это даст вам половину успеха.

Ну а теперь давайте по-простому. Когда у вас при прочтении требований / при сборке версии ПО / при проверке работы ПО произойдет что-то, что не соответствует ожиданиям или здравому смыслу (баг) – вы создаете документ (баг) по общепринятым правилам, чтобы данное несоответствие было как можно быстрее исправлено другим членом команды.

Основные атрибуты / поля бага

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

• Идентификатор – уникальный номер бага, как задачи в системе управления задачами;
• Заголовок бага – краткое, ёмкое и понятное описание проблемы;
• Номер версии – номер версии / сборки, на которой произошла ошибка;
• Приоритет – показатель того, на сколько срочно необходимо взять дефект в работу;
• Серьезность – показатель того, на сколько сильно дефект влияет на систему или бизнес-процессы;
• Автор – инженер, который создал баг-репорт;
• Исполнитель – инженер, на которого назначены работы по дефекту;
• Статус – показатель этапа, на котором дефект находится в рамках жизненного цикла.

К эти полям бага также идет описание, которое должно быть заполнено примерно следующим образом:

• Входные данные – перечень дополнительной информации, которая так или иначе может помочь при исправлении бага;
• Выполняемые действия – подробный список последовательных действий, которые необходимо выполнить для воспроизведения дефекта;
• Ожидаемый результат – правильный результат, который ожидается получить после выполнения действий;
• Фактический результат – текущий неправильный результат, который получается после выполнения действий;

Ну и отдельным блоком идут:

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

Ну и как говорится: «Лучше один раз увидеть, чем сто раз услышать» - рассмотрим пример бага. Представим, что у нас при проверке регистрации нового пользователя произошел баг – поле «Повторите пароль», которое по требованиям является обязательным для заполнения, не является обязательным. Имея всю информацию выше – нам надо оформить баг в системе управления задач. Выглядеть он будет примерно следующим образом:

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

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

Идентификатор – уникальный номер в системе управления задач, который сможет явно указать на какую-то конкретную задачу. В случае с нашим примером бага – уникальным идентификатором будет являться «PROJECT-3417». Также вы можете увидеть еще 2 идентификатора: «PROJECT-56» — это идентификатор задачи, в рамках которой разрабатывалась форма регистрации и «PROJECT-3001» — это идентификатор задачи релиза, в рамках которого был обнаружен баг.

Заголовок – в идеале, заголовок ваших багов должен отвечать на вопросы «Где? Что? Когда?». Т.е. он должен коротко описывать «В какой части вашего продукта это что-то пошло не так», «Что пошло не так» и «При каких обстоятельствах это что-то пошло не так». Также ваш заголовок бага должен быть написан таким образом, чтобы остальные члены команды могли бы понять суть проблемы, не открывая баг. Я, в большей части багов, также добавляю префикс к описанию – конкретно в этом баге это «Форма регистрации: …». Мало ли сколько у вас может быть форм, где есть поле «Повторите пароль». Например, может существовать форма смены пароля и на ней надо также подтверждать новый пароль в одноименном поле.

Номер версии – в нашем примере это номер сборки 01.004.17-35. Указывают ее для того, чтобы члены команды точно знали в какой версии/версиях этот дефект актуален. Дополнительно это позволяет избежать различных спорных моментов, когда разработчик говорит, что «У меня твой баг не воспроизводится, всё работает как надо» - после этого вы тратите N часов времени и по итогу выясняете, что разработчик пытается воспроизвести баг на более ранней версии, например, 01.004.17-21 и бага в ней действительно не было, а у вас на тестовом стенде развернута версия 01.004.17-35 и баг в ней есть.

Автор – тут сложно что-либо прокомментировать. Это либо вы, либо какой-то другой член команды, кто обнаружил и оформил баг-репорт. По этому полю команда разработки может легко понять к кому следует обратиться чтобы уточнить что-либо по дефекту.

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

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

Выполняемые действия – порядок действий, которые приводят к багу. Обратите внимание – если в тест-кейсе у нас на каждый шаг есть ожидаемый результат, то в случае с багом это не так. Причем вы должны расписать этот порядок действий таким образом, чтобы у исполнителя было четкое понимание как баг воспроизвести и не было ни единой возможности свернуть с пути воспроизведения бага и вернуться к вам со словами «не воспроизводится». Когда оформляете этот блок – держите в голове тот факт, что исполнителем-разработчиком может быть не тот же разработчик, который разрабатывал изначальную задачу, а перепроверяющим тестировщиком можете быть не вы. Из этого следует, что выполняемые действия должны быть понятны всем членам команды и ваша задача позаботиться об этом при оформлении бага.

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

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

Несколько фактов:

1. Вы оформляете баг в системе управления задачами – это достаточно умные системы, которые поддерживают поиск задач по содержимому конкретных полей, но не по содержимому файлов;
2. Иногда, вы будете добавлять во вложения так называемые «логи» — это текстовые файлы, в которые система последовательно записывает информацию о событиях, произошедших с ПО. И в некоторых случаях баг будет сопровождаться тем, что система записывает в лог информацию о произошедшей ошибке, а эта информация очень сильно поможет разработчику понять в каком месте кода произошла ошибка;
3. При заведении багов иногда случаются «дубли». Это когда один инженер заводит баг, когда в системе уже существует баг по той же самой проблеме.

Думаю, что многие поняли к чему я веду, но доведем мысль до конца. Представим ситуацию, что вы нашли такой баг, в котором система записала в лог информацию об ошибке. Вы оформили этот баг и добавили лог во вложения. После этого ваш коллега наткнулся на тот же самый баг и решил проверить заведен ли дефект и начал искать по ошибке из лога – ничего не нашел. Потратил время, создал новый баг-репорт и по итогу выяснилось, что он завёл «дубль» вашего бага. Хотя этого потраченного времени можно было бы избежать, если в фактический результат был добавлен так называемый «блок кода», который содержал бы текст ошибки, не раздувал размер описания и при этом содержание этого «блока кода» относилось бы к полю «описание», по которому работает поиск системы управления задач.

Выглядит этот «блок кода» примерно следующим образом:

Но опять же – это просто небольшой совет, который позволит сделать ваш баг-репорт еще лучше и понятнее.

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

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

1) Задача «PROJECT-3001 Релиз 01.004.17». Тип связи «Обнаружен в» означает, что баг впервые обнаружен в релизе 01.004.17

2) Задача «PROJECT-56 Реализация формы регистрации пользователей». Тип связи «Относится к» означает, что текущий баг так или иначе относится к озвученной выше задаче.

Типов связей бывает множество: «Исправлен в <задаче>», «Относится к <задаче>», «Блокирует <задачу>», «Должен быть сделан до <задачи>», «Должен быть сделать после <задачи>», «Дублирует <задачу>» и так далее – на каждом проекте правила использования этих типов связей свои. Но они в любом случае интуитивно понятны, а также позволяют вам и вашим коллегам проще ориентироваться во взаимосвязях задач и быстро перемещаться между задачами.

Приоритет и серьезность

Эти два атрибута достойны отдельного блока для обсуждения. Начинающему инженеру они могут казаться одинаковыми по своей сути и иногда это действительно так, но иногда они могут иметь совершенно противоположные значения. Более того – вы можете оказаться на проекте, где одним из этих полей не будут пользоваться вообще. Например, у меня на текущем проекте не используется поле «Серьезность», а есть только поле «Приоритет». Тем не менее – вам необходимо очень хорошо разбираться в различии этих полей и вдумчиво подходить к выставлению приоритета и/или серьезности, т.к. от этого будет зависеть очередность взятия задач в работу.

Для начала давайте определимся какими значениями мы будем обозначать приоритет и серьезность. Вы наверняка уже посещали какие-нибудь сайты, где сначала рассказывают про эти два атрибута бага, причем сначала рассказывают что-то в стиле «Приоритет имеет значения Высокий / Средний / Низкий, а серьезность имеет значения Блокирующая / Критическая / Значительная / Незначительная / Тривиальная», а затем вдруг показывают скриншот с полем «Приоритет», где указан приоритет равный «Критический». Чтобы не приобретать когнитивные травмы, давайте определимся с двумя моментами:

1) Ранжировать и приоритет, и серьезность мы будем одними и теми же значениями – Блокирующий / Критический / Высокий / Средний / Низкий;

2) Вы вольны оценивать приоритет любыми значениями, в которых ориентируется ваша команда. Если ваша команда понимает приоритет «в морковках» - выставляйте его в морковках. Главное, чтобы все понимали, что приоритет «5 морковок» надо брать в работу раньше, чем приоритет «1 морковка»

Начнем с серьезности

Серьезность - показатель того, на сколько сильно дефект влияет на систему или бизнес-процессы. Перед указанием серьезности вам необходимо задаться простыми двумя вопросами «На сколько это критично для бизнес-процессов?» и «На сколько это критично для приложения?». Градация серьезности, опять же по нашим с вами договоренностям:

Блокирующая – блокирующая ошибка, приводящая систему в нерабочее состояние, в результате которого дальнейшая работа с системой и её ключевыми функциями невозможна;

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

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

Средняя – незначительная ошибка, не нарушающая работу бизнес-логики и/или системы;

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

Для примера давайте возьмем два крайних случая – баг с блокирующей серьезностью и баг с низкой серьезностью.

Баг с блокирующей серьезностью – «Отсутствует кнопка «Зарегистрироваться» на форме регистрации». Кнопки нет – пользователи не могут зарегистрироваться и работать с функциями системы, а затем вообще уходят к конкурентам.

Баг с низкой серьезностью – «Не отображаются кнопки «Показать пароль» в браузере Internet Explorer на форме регистрации» - кнопки, конечно, несут полезную функциональность, но пользоваться ими будет один человек из ста, да и не отображается она только в Internet Explorer’е, которым пользуются еще реже, чем кнопкой «Показать пароль».

Теперь к приоритетам:

Приоритет – показатель того, на сколько срочно необходимо взять дефект в работу. В случае, если у вас в баге присутствуют и приоритет, и серьезность – вам необходимо будет при проставлении приоритета задавать себе только один вопрос – «На сколько быстро надо исправить этот баг?». По градациям приоритетов:

Блокирующий – баг необходимо брать в работу первым приоритетом;

Критический – баг необходимо брать в работу вторым приоритетом;

Высокий – баг необходимо брать в работу третьим приоритетом;

Средний – баг необходимо брать в работу четвертым приоритетом;

Низкий – баг необходимо брать в работу последним приоритетом.

Вот так вот бесхитростно мы охарактеризуем этот атрибут. Для лучшего понимания давайте разберем теоретическую ситуацию – вы тестируете две задачи - задача №1 и задача №2. По задаче №1 вы обнаруживаете 2 бага на финальном этапе проверок – одинаковой, высокой серьезности и выставляете багам высокий приоритет. Так как для завершения тестирования задачи №1 вам необходимо дождаться исправления багов – вы переключаетесь на задачу №2 и сразу же обнаруживаете третий баг, опять с высокой серьезностью, но при этом вы понимаете, что дальнейшие проверки проводить бессмысленно, так как после исправления бага №3 все проверки придется проводить заново. Времени у вас много, и чтобы совместить приятное с полезным вы выставляете багу №3 приоритет равный «Критический» и его исправлением разработчик займется в первую очередь. Что вы получаете из этой ситуации – баги №1 и №2 по задаче №1 будут исправлены вовремя, а баг №3 по задаче №2 будет исправлен быстрее чем надо, а следовательно у вас не будет так называемого «простоя» - когда ни по одной из задач не проводится тестирование.

А теперь разберем как раз те самые ситуации, когда приоритет и серьезность могут сильно отличаться друг от друга. Кстати говоря, вопрос «Можете ли вы привести пример бага с высоким приоритетом и низкой серьезностью, и наоборот?» очень часто встречается на собеседованиях.

Критическая серьезность и низкий приоритет

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

Пример №1:

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

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

Пример №2:

«На форме регистрации кривая верстка в браузере Internet Explorer». Т.е. когда пользователь заходит на форму регистрации именно в определенном браузере – поля на форме начинают накладываться друг на друга, в них сложно попасть курсором мыши и регистрация если не невозможна, то крайне затруднена. Данный баг определенно будет бить по репутации компании, но он влияет на минимальное количество пользователей (если конечно ваши целевые пользователи не используют Internet Explorer за целевой браузер), при этом для большей части пользователей проблема отсутствует, так как они используют целевые браузеры, под которые разрабатывается ваша система.

Низкая серьезность и критичный приоритет

И снова простыми словами – существует проблема, которая вообще не мешает работе системы, но ее надо исправить как можно скорее.

Пример №1:

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

Пример №2:

В вашей системе есть форма позволяющая выводить какую-то определенную финансовую отчетность в таблицу. На этой форме у числовых значений порядки отделены друг от друга пробелами, при этом явного требования к этому не было, как не было и требования этого не реализовывать, а «разработчик художник и так видит» – вместо «100000» отображается «100 000». Выяснилось, что пользователи копируют таблицу и вставляют ее в Excel, при этом вставка числовых значений с разделенными порядками происходит некорректно и вся заложенная в отчет математика не происходит без дополнительных преобразований. Данный баг практически никак не влияет на работоспособность системы, но при этом его надо исправить как можно скорее, чтобы сократить время пользователей на работу с отчетностью.

Что делать если есть только поле «Приоритет»

Важно понимать, что поле «Приоритет» является относительным. Если у вас на проекте одна задача с приоритетом «Средний» - то эту задачу возьмут в работу в первую очередь. Если у вас две задачи – средняя и критичная – первую возьмут в работу критичную. Понимаете, к чему я веду? При выборе приоритета надо помнить о других задачах. Также следует помнить, что обозначенные выше примеры скорее исключение из правил и в большей части багов значения полей «Приоритет» и «Серьезность» будут плюс-минус равны.

Если у вас присутствует только одно поле «Приоритет» - то задавайтесь вопросами для выставления серьезности - «На сколько это критично для бизнес-процессов?» и «На сколько это критично для приложения?», а затем думайте про приоритет конкретно этого бага, относительно уже обнаруженных и выставляйте финальное значение. Из хороших новостей – от вас, как от начинающего инженера, никто не будет ждать невероятных свершений и не будут ждать, что вы безошибочно будете выставлять приоритет для каждого дефекта. В случае, если вы вдруг выставите приоритет критический, вместо высокого – у вас вежливо спросят почему вы выбрали именно этот приоритет, а затем попросят его скорректировать. Главное, чтобы не случалось ситуаций, когда явно багу с фактически критичным приоритетом вы выставляли низкий приоритет и наоборот.

Статус бага и жизненный цикл бага

Статус бага – это показатель этапа, на котором дефект находится в рамках жизненного цикла. Поле «Статус» предназначено для того, чтобы привести всю команду к единому пониманию что именно происходит с дефектом – на вопросы «Начались ли работы по исправлению дефекта?», «Дефект исправлен?», «Дефект актуален?», «Готов ли дефект к повторному тестированию?» отвечает именно поле «Статус».

Если вы уже насмотрелись на всякие картинки в интернете по поводу жизненного цикла дефекта и мучаетесь вопросом «А какой же жизненный цикл правильный?» - отвечу вам, что большинство из них «правильные», просто «правильные» они конкретно под ту компанию, автор которой писал ту или иную статью. Иными словами – нет какой-то единой и эталонной статусной модели бага, и каждая вторая компания адаптирует общепринятые принципы жизненного цикла бага под себя. Концептуально жизненный цикл бага можно представить следующим образом:

Теперь рассмотрим каждый из этапов детальнее:

Новый – статус. Баг-репорт создан в системе управления задачами. Оформление дефекта может быть еще не окончено, то есть в нем может отсутствовать описание или приложены не все необходимые файлы. По сути, этот статус означает что в системе управления задачами просто создана новая задача с типом «Дефект».

Открыт – статус. Оформление бага окончено полностью, он содержит в себе всю необходимую информацию, и исполнитель может начинать работу над багом.

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

• Соглашается с автором баг-репорта, что данный баг действительно является с багом и берет баг в работу;
• Аргументированно не соглашается с автором баг-репорта, что над данным дефектом необходимо вести работу и фиксирует своё несогласие в комментариях к багу. Дополнительно исполнителем бага назначается тот инженер, которому адресован комментарий (обычно это тестировщик). После этого тестировщик закрывает баг – подробнее в этапе «Закрыт».

Пример комментария №1: «Данный баг является дубликатом бага PROJECT-2005 и над ним уже ведется работа».

Пример комментария №2: «Данный баг не является багом – добавил во вложение переписку с аналитиком и заказчиком, а требования забыли уточнить».

• Не аргументированно не соглашается с автором бага, оставляя неоднозначные комментарии к баг-репорту. В таких случаях автор и исполнитель пытаются найти общее мнение в комментариях, а если его не находят – подключают дополнительных коллег: аналитиков, разработчиков, лидов от направления разработки или тестирования и так далее. Происходит это до тех пор, пока не придут к одному из решений из пунктов 1 и 2.

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

Готов к тестированию – статус. Работы со стороны разработчика по дефекту окончены, баг исправлен по мнению разработчика. Код с исправлениями попал в необходимую сборку, которую разработчик фиксирует в дефекте – обычно для этого есть специальный атрибут в баге. Баг-репорт назначен на ответственного тестировщика, который будет перепроверять внесенные в ПО изменения. Теперь баг-репорт ожидает, когда появится у тестировщика появится время на перепроверку бага.

На тестировании – статус. Тестировщик, который на предыдущем этапе был назначен исполнителем, начал заниматься работами по перепроверке бага. На этом этапе тестировщик выполняет аналогичные действия из блока «Описание» в баг-репорте и ожидает, что результат его действий совпадет с зафиксированным в описании ожидаемым результатом.

Принятие решения исправлен ли баг– логический этап, который не имеет отдельного статуса. На данном этапе исполнитель (чаще всего это инженер по тестированию) делает вывод – успешно или неудачно исправлена та проблема, которая существовала в ПО. Тут есть один из следующих вариантов:

• Исполнитель соглашается с тем, что баг исправлен. Это значит начиная с какой-то определенной сборки, которую указал разработчик, баг перестанет воспроизводиться. Исполнитель переводит баг в статус «Закрыт»;
• Исполнитель не соглашается с тем, что баг исправлен. Например, разработчик мог проигнорировать один из пунктов ожидаемого результата или просто неправильно понял проблему и исправил её так, как он посчитал нужным. Исполнитель переводит баг в статус «Открыт», чтобы разработчик взял его в работу, когда у него появится время. Дополнительно исполнитель фиксирует в комментариях к баг-репорту что именно пошло не так во время перепроверки и номер сборки, на которой проводилась перепроверка.
• Исполнитель не смог начать перепроверку, так как был обнаружен новый баг, мешающий перепроверке. Исполнитель оформляет новый баг-репорт в системе управления задачами и связывает новый баг-репорт с текущим блокирующей связью. Текущий баг-репорт исполнитель возвращает в статус «Готов к тестированию» и оставляет комментарий «При перепроверке на версии с номером … был обнаружен баг …, который блокирует перепроверку этого бага.».

Закрыт – статус. Данный статус бага говорит о том, что над ним не нужно больше проводить каких-либо работ. Исполнителем по багу обычно остается тестировщик, который переводил баг-репорт до этого статуса. Особенностью статуса «Закрыт» является то, что при переводе в этот статус появляется дополнительный атрибут у бага – резолюция или по-простому финальное решение по багу в целом. Как мы уже выяснили выше, к статусу «Закрыт» мы можем прийти несколькими путями:

1. На этапе принятия решения «Является ли баг багом» команда решила, что баг не является багом и поведение системы соответствует ожидаемому – просто забыли актуализировать требования. Баг переводится в статус «Закрыт» и ему проставляется «Резолюция» равная «Не баг», например. Или на том же этапе вы выяснили, что баг является дубликатом другого бага – текущий баг закрывается с резолюцией «Является дублем»;
2. На этапе принятия решения «Исправлен ли баг» инженер по тестированию решил, что баг исправлен. Баг переводится в статус «Закрыт» и ему проставляется «Резолюция» равная «Исправлен». В случае успешной перепроверки будет хорошим тоном оставить в баге подтверждения исправления (например, снимки экрана) и написать в комментарии номер сборки, на которой перепроверка прошла успешна.

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

1. Завожу баг на скорую руку, чтобы не забыть его зарегистрировать. Баг в статусе «Зарегистрирован».
2. Заканчиваю оформление бага, корректирую описание, добавляю логи. Перевожу баг на разработчика и в статус «Открыт».
3. Разработчик переводит баг в статус «На исправлении» и начинает вносить изменения в коде. Время от времени приходит с уточняющими вопросами в почте или в комментариях бага.
4. По окончанию изменения в коде разработчик представляет эти изменения своим коллегам на оценку. Переводит баг в статус «На рассмотрении».
5. Разработчики подтверждают, что написанный код отвечает их внутренним стандартам. Разработчик переводит баг в статус «Готов к тестированию» и указывает в комментарии номер сборки, в которую попало исправление. Исполнителем указывает меня.
6. Когда появляется время на работу с багом – перевожу его в статус «На тестировании». Выполняю перепроверку. Перепроверка неудачная, оставляю комментарий «Баг воспроизводится на сборке … скриншоты в аттаче» и снова перевожу баг в статус «На исправлении» и назначаю на разработчика.
7. Снова проходят этапы «На исправлении» - «На рассмотрении» - «Готов к тестированию».
8. Выполняю повторную перепроверку, переводя баг в статус «На тестировании». Перепроверка успешная, оставляю комментарий «Баг не воспроизводится на сборке …», прикладываю скриншот успешной работы системы к баг-репорту.
9. Перевожу баг в статус «Закрыт» и проставляю резолюцию «Исправлен».

Несмотря на то, что в данном примере статус «Новый» заменен на статус «Зарегистрирован», а этап «На исправлении» разделен по сути на два – «На исправлении» и «На рассмотрении» - ничего концептуально не поменялось.

Для кого на самом деле оформляется баг-репорт

Завершающей мыслью в этой главе будет ответ на вопрос «Для кого на самом деле оформляется баг?». И ответ на данный вопрос поможет понять почему необходимо качественно и осмысленно подходить к оформлению баг-репортов. Вот если бы вас спросили прямо сейчас «Для кого на самом деле оформляется баг?» - что бы вы ответили? Наверняка, ответ был бы в лучшем случае «Для разработчика, чтобы он понял ошибку, которую необходимо исправлять», а в худшем «Для команды тестирования или моего начальника, чтобы он видел мою продуктивную работу». Рассмотрим кто из команды пользуется багом и как:

Системный аналитик – к системному аналитику с багом обычно приходит либо разработчик, если ему что-то необходимо уточнить, либо тестировщик, если тестировщику непонятно какой ожидаемый результат должен быть при работе системы. Также системный аналитик может ориентироваться на существующие баги при проведении аналитики по будущим доработкам системы. Например, он может в явном виде прописать в задаче, что при её разработке надо исправить существующие баги №1 … №N.

Разработчик – самый активный «пользователь», работающий с вашими багами, потому что именно разработчики занимаются исправлениями дефектов. Причем стоит иметь ввиду, что не всегда разработчик будет исправлять именно свой код. То есть очень даже реальна ситуация, когда разработчик №1 будет исправлять незнакомый код за разработчиком №2, а следовательно, чем понятнее вы оформите дефект – тем лучше.

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

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

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

Как вы можете обратить внимание – почти все члены команды будут так или иначе работать с вашими баг-репортами. Я привел общие случаи использования баг-репорта членами команды – в реальной работе этих вариаций может быть гораздо больше. Думаю, что вы уже поняли, что ответ на вопрос «Для кого на самом деле оформляется баг?» будет – для всех членов команды. А теперь сформулируем одну простую мысль и ответим «Каким же должен быть идеальный баг-репорт?». Идеальный баг-репорт – это баг-репорт, на который каждый из заинтересованных членов команды потратит минимальное количество времени, чтобы выполнить свою работу.

Уважайте своих коллег и заводите подробные, понятные и качественные баг-репорты!

Следующая часть: Виды тестирования ПО

Поддержать или поблагодарить можете:

Лайком;

Комментарием;

Подпиской на канал;

#Блог_тестировщика #QA #Тестирование_ПО #Тестирование_с_нуля #Баг #Дефект #Баг-репорт