Баланс между качеством и скоростью в тестировании

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

Немного о компании

Я являюсь сотрудником GameDev компании Blackhub Games, продуктом которой является мобильная онлайн-игра Black Russia. В неё ежедневно заходит более 800 тысяч человек и единовременно может играть около 100 тысяч пользователей.

Релизы новых фич, обновления контента у нас происходят на регулярной основе и затрагивают разные отделы: Client-часть (Android и iOS), Native-отдел (команда занимается работой над собственным движком, в который мы регулярно вносим улучшения), Server-отдел (поддержка более 70 игровых серверов), Web-отдел (API, платежи большое количество ботов для внешней инфраструктуры (VK, Telegram, Discrord, форум для игроков)).

Также часто добавляется новый 3D контент: машины, скины, аксессуары, локации и объекты окружения.

И все аспекты этой работы требуют тестирования…

Откуда рождается дедлайн?

В целом никакой проблемы бы не было, если можно было бы тратить неограниченное количество времени и делать релиз тогда, когда все отполировано до идеала, но:

1. Если в игре в течении длительного времени ничего не меняется, то игрокам становится скучно и они перестают заходить в неё;

2. Если анонсировать фичу, но не выпустить её к назначенному сроку или выпустить ее в низком качестве, то игроки также могут остаться недовольны, это приведет к тому, что они перестанут играть;

3. Бывают релизы, которые приурочены к конкретным датам, например события: Новый Год, 9 мая, Хэллоуин и так далее. Они также не могут быть перенесены.

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

Задача QA в этом деле – это сделать все возможное, чтобы фича попала в прод (дошла до конечного пользователя) в максимально высоком качестве.

Подготовка к тестированию

1. Декомпозиция и распределение

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

— Большое количество зависимостей между зонами ответственности разных людей. В таком случае будет практически невозможно найти границы для дробления фичи и 2 человека будет заниматься ± одним и тем же;

— Зависимость одного разработчика от нескольких разных тестировщиков (часть тестирует один, а часть — другой). Чем меньше людей, с которыми нужно поддерживать активный контакт в работе, тем быстрее и качественнее решаются возникшие вопросы. Поэтому, если есть возможность закрепить одного QA за одним разработчиком, то мы стараемся этим пользоваться;

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

2. Техническое задание/Геймдизайн документ

Любая фича начинается с ГДД. Это может быть неочевидным, но в нём тоже могут встречаться баги. Более того, баги, найденные на этапе вычитки ТЗ, приносят максимальную пользу потому, что они экономят х2 времени разработчиков (неправильная реализация + переделать).

Примеры багов, которые могут встречаться в ГДД :

— Логические нестыковки внутри фичи;

— Серые зоны;

— Конфликты с уже существующими механиками;

— Непрозрачное для игрока userflow (последовательность действий, которую он должен совершить);

— Наличие блокирующих (непроходимых) сценариев;

— Дисбаланс (механика слишком сильна или слишком слаба);

— Попытки использовать неподдерживаемые или ещё нереализованные возможности платформой системы.

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

Также это может способствовать предотвращению появления в системе проблемных багов.

3. Формирование чек-листа/тест кейсов

Обычная вещь для QA, надолго останавливаться тут не буду, но некоторые моменты хочу подсветить:

— Начните их формирование после того, как все ответы на ваши вопросы по ГДД получены, потому что решение некоторых из них может привести к существенным изменениям в документации и, как следствие, придется переделывать часть уже готовых чек-листов/тест-кейсов;

— Зафиксируйте что и от какого отдела вам нужно: сформировав полные списки, вы получите примерное понимание объема работы, который отделам нужно сделать. С помощью этого вы сможете корректно расставить приоритеты по тестированию;

— Заранее продумайте как, когда и что вы будете проверять. Если какие-то моменты будут занимать у вас много времени, то подойдите к разработчикам и скажите об этом: они без проблем реализуют возможность для получения нужного задания/скипа фазы/начисления ресурса или другие дебаг-команды. Они также как и вы заинтересованы в том, чтобы вы не тратили своё время просто так.

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

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

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

Разница между критичностью и приоритетом

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

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

Уровни готовности фичи можно классифицировать как:

1. Черновой вариант (прототип) — просто логика с минимальным визуалом и кросс-функциональностью. Основная задача на этом этапе – сделать так, чтобы можно было полностью пройти путь (даже если рабочим будет только 1 способ) от начала до конца.

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

— Цель этапа – запустить систему. Это означает то, что какие-то баги вёрстки, наличие в наградах объектов не как в ТЗ или отсутствие туториала не имеют критичности: разработчики и так знают о том, что они за это ещё не брались. Нет никакого смысла дублировать еще не выполненные задачи баг-репортами. А вот если система не запускается – то тут надо поднимать всех на уши с фразой: “Бросаем все - решаем конкретно эту проблему!” (приоритет: максимальный).

2. Полирование фичи. После того, как прототип закончен, гейм-дизайнеры могут начать заполнять JSON-ы (конфигурации), рассчитывать финальные цифры баланса, а разработчики могут начать добавлять оставшийся функционал. В теории считается, что на этом этапе разработчики все делают до конца и отдают пред-релизную версию, потом тестировщики проверяют на ошибки, составляют список из 5-10 багов, разработчики их исправляют, и все: катим в прод, но на практике:

— В момент “разблокировки доступа” ко всему функционалу багов появляется много.

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

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

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

Протестировать – понятно. Завести баг-репорты – понятно. А дальше?

…А дальше необходимо сформировать список того, что вам нужно в следующем билде: расставить приоритеты. Основа: сделать так, чтобы работала логика, но если какие-то минорные баги правятся, например, исправлением одной цифры, то почему бы и не исправить сейчас? Разгрузка таск-трекера лишней не бывает. Например: фича состоит из интерфейса на 5 окон. Вы смоканули и на двух из них есть блокеры. Написали разработчику: тут блокер 1, блокер 2 + (можно добавить что-то по мелочи за компанию, если оно правится 1-й минутой). И смотрите остальные. Вам разработчик отдает новый билд. Вы ему отдаете результаты тестирования 3-х других , а сами начинаете смотреть 2 исправленных.

4. Финальный этап – когда вся логика работает в положительных сценариях, то можно спокойно ковырять вёрстку и бегать негативные сценарии.

Тут уже можно “расслабиться” и просто накидывать в таск-трекер все подряд: обычно к этому моменту тяжелых для починки багов не остается и всё чинится почти сразу же.

Способы обхода проблемных багов

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

— Неготовность фичи со стороны другого отдела (Client/Server);

— Отсутствие JSON;

— Изменения в ТЗ (изменение серверной/клиентской логики);

— Ограничения платформ;

— “Legacy база”.

Варианты решения:

— Добавить заглушки/дебаг команды;

— Решить проблему на другой стороне (клиентскую на сервере или серверную на клиентской);

— Отредактировать принцип работы механики (изменение в ТЗ);

— Сдвинуть релиз (если решаемо, но долго);

— Временно изолировать систему от багованного сценария (костыль);

— Убрать функционал.

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

Павел, QA-engineer
Blackhub Games