Фантастические баги и места их обитания

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

Знакомьтесь, мистер BUG!

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

Приоритет (priority) — указывает на очередность устранения дефекта. Распространенными считаются приоритеты high, medium и low.

• Баг приоритета High требует немедленного исправления и отличается высокой критичностью для функционирования.
• Баг приоритета Medium не является критичным, но при этом требует обязательного решения.
• Баг приоритета Low не требует срочного решения и его наличие не является критичным.

Серьезность (severity) — атрибут бага, показывающий влияние дефекта на работоспособность проекта. Чаще всего выделяют пять типов этого атрибута: blocker, critical, major, minor и trivial.

• Blocker — Характеризует нерабочее состояние системы.
• Critical — Показывает наличие критической ошибки.
• Major — Говорит о некорректной работе части системы. Исправление ошибки не критично, поскольку возможно использование других входных точек.
• Minor — Идентифицирует наличие несущественной проблемы пользовательского интерфейса.
• Trivial — Касается проблемы, не оказывающей никакого влияния на общее качество продукта.

Например, если бы на стартовой странице популярного поисковика вместо буквы “Н” появилась “П”, серьезность данного бага можно оценить как Trivial. А вот приоритет отнести к категории High, поскольку баг требует срочного исправления.

Таким образом, приоритет бага отвечает на вопрос "Как быстро фиксить?", серьезность — "Насколько сильно ошибка влияет на работоспособность проекта?"

А теперь — фича! Мы сказали — фича!

Нередко на форумах разработчики проекта на вопросы пользователей и тестировщиков отвечают: "Это не баг, а ФИЧА!". Так в чем же их отличие? Не впадая в заумные крайности, можно сказать, что фича — это баг, который так сильно понравился геймдизайнеру или пользователям, что стал ключевой особенностью проекта. Существует даже выражение: "Фича есть баг, одетый во фрак". И чтобы это доказать, обратимся к примеру из далекого 1978 года.

Space Invaders не только стала лучшей аркадной игрой по версии Книги рекордов Гиннесса, но и привнесла в игровую индустрию одну из крутейших фич. В то время процессор просто не мог заставить антагонистических инопланетян двигаться с такой скоростью, как это было нужно. Но при этом, чем больше инопланетян убивал выстрелами игрок, убирая их с экрана, тем сильнее ускорялась игра. И именно этот баг "кривой" сложности стал фичей, во многом определившей дальнейшее направление развития видеоигр. Ведь сейчас усложнение игры с каждым новым уровнем — не нонсенс, а стандартное требование. Поэтому, находя в игре баг, не кидайтесь сразу тапками, возможно, именно это несоответствие сделает ваш проект знаменитым.

Bugs have feeling too

Общее представление о багах и фичах получено. Теперь — пара инструкций по работе с ними.

Правило №1. Баги не любят быть забытыми.

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

Правило №2. Сохраняйте воспоминания.

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

Правило №3. Говорите.

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

Правило №4. Зрите в корень.

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

Правило №5. Не надо слонов!

Не пытайтесь приукрасить влияние ошибки на работоспобность проекта. Иногда тестировщики прибегают к тактике "завышения приоритетов", чтобы быстрее обратить внимание на найденный баг. Этого делать нельзя! Указывайте только правильный приоритет и серьезность ошибки, а если сомневаетесь — спросите совета у коллег.

Багтрекеры, или Немного о среде обитания

Как и у магозоолога Ньюта Саламандера, в арсенале тестировщиков есть "чемоданчики", в которых обитают баги. Это багтрекеры — специальные программы, разработанные с целью учета и контроля дефектов, которые найдены в тестируемых проектах. Один из главных профитов багтрекера — возможность отслеживания процесса исправления отклонений и общение с разработчиком или клиентом.

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

Среди самых популярных трекеров: Jira, Redmine, Trello, YouTrack, Bugzilla. У каждого из них — свои плюсы и минусы.

Jira, пожалуй, самый часто встречаемый и используемый трекер. Среди главных достоинств стоит отметить отличную адаптивность. Кроме того, есть

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

Из минусов — достаточно высокая стоимость.

Что касается Redmine, здесь главные "плюшки":

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

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

К плюсам Trello стоит отнести:

• удобство использования дашборд для работы в команде
• и простоту в освоении.

Из минусов:

• достаточно малый функционал для крупных проектов. Этот трекер больше ориентирован не на гигантов рынка, а на малые проекты,
• также есть ограничения по встроенным инструментам оценки времени
• и недоработки с системой сообщений.

Если рассматривать YouTrack, стоит сказать:

• об удобном дашборде и диаграмме,
• возможностях выделения статусов и приоритетов.

Среди недостатков:

• неудобство выноса Workflow-редактора в отдельное приложение,
• отсутствие кнопок для форматирования текста и возможности отслеживания времени на выполнение задачи.

В отличии от него, Bugzilla:

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

Минусом можно считать невозможность регулирования workflow и интерфейс.

Конечно, указанные недостатки и достоинства имеют субъективный характер, и выбор у каждого свой. Но независимо от выбранного багтрекера основными атрибутами при создании бага будут: summary, description, severity/priority.

summary или краткое описание

Суть summary заключается в одной фразе: "Прочитав, я должен понять, в чем состоит проблема".

При составлении краткого описания вам нужно уместить весь смысл бага в одном предложении. И здесь подойдет принцип "Где? Что? Когда?".

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

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

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

description или детальное описание

Здесь жизненное кредо следующее: "Прочитав, я должен знать строку кода, которую необходимо править".

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

severity/priority

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

Вместо заключения

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

Текст: Артем Лукьянов, Роман Морозов, Bytex, QA
Иллюстрации: Дмитрий Смирнов, Bytex, Development