Контроль качества в играх-сервисах

Советы от QA-менеджера Crytek.

Чем дольше живёт проект — тем критичнее случайные баги. Внезапно появившиеся ошибки могут оттолкнуть от него значительную часть аудитории. QA-менеджер Crytek Евгений Скачков поделился на конференции Games Gathering 2016 опытом контроля качества проекта Warface, разработанного киевским филиалом компании.

DTF публикует расшифровку выступления.

Warface — онлайн free-to-play шутер. Практически пять лет игра находится на стадии оперирования и больше восьми лет в разработке. Это самый большой free-to-play шутер на территории СНГ. Три года назад мы поставили официально зарегистрированный рекорд Гинесса — 145 тысяч пользователей онлайн на одном сервере. Если посчитать по всем территориям, PCU (peak concurrent users) больше, около 200 тысяч человек. Ежедневно в игру заходят около 700 тысяч уникальных пользователей. Каждый год мы выдаём около 12 крупных апдейтов.

Как происходит разработка обычного, «коробочного» продукта (утрированно)? Программисты и дизайнеры что-то создают, креативят, прототипируют, и в какой-то момент решают, что игра готова. Её нужно протестировать. Что-то они проверяют своими силами, но этого недостаточно. Собираются QA-команды и начинается «zerg rush».

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

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

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

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

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

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

Начинается обсуждение дизайна — в нём уже обязательно участвуют QA-специалисты. Они тестируют самые первые сборки, всегда планируют. Мы называем это «plan draft» — небольшие списки того, что нужно проверить для каждой ключевой «фичи», отличающиеся у разных команд.

«Execution» включает в себя написание тест-кейсов, тестирование. «Cross-review» — желательно, чтобы за каждым элементом, написанными тест-кейсами, а также процессом тестирования проследил человек из смежной команды.

Целостное тестирование. У нас очень жёсткие критерии для подтверждения изменений. Не пройдя чек-лист, ни одно изменение не попадёт в код.

Тест-кейсы — важная часть проекта. Раньше можно было что-то протестировать и без них, но теперь это невозможно. У нас больше 10 тысяч тест-кейсов: если вы что-то протестировали и думаете, что вспомните об этом через три года — скорее всего это не так.

Строгая актуализация: если добавляется какая-то «фича», она обязательно должна быть внесена в тест-кейсы.

​Прекрасная документация — без неё никуда. Она обновляется так же, как тест-кейсы. Для новых «фич» создаётся с нуля, для обновления старых — актуализируется.

«Bullet proof» чек-листы: нет смысла каждый раз описывать контент тест-кейсами. Он универсален, работает одинаково и нужно просто проверить, соответствует ли очередная «пушка» ряду критериев.

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

У нас итеративная разработка, и в конце каждой итерации мы собираемся с ребятами из всех команд, и они презентуют свои «фичи». Это позволяет эффективнее реагировать на баги. До этого бывали ситуации, когда человек на протяжении нескольких релизов не знал, что что-то поменялось. Для того, чтобы это всё работало, нужен качественный QA-процесс, который я кратко описал.

На схеме две фазы — разработка «фичи» и её стабилизация. На второй фазе development-специалист QA проверяет все новые элементы, всё, на что они могли повлиять, и какие-то критические вещи, которые не проверить нельзя. «Code lock» означает, что во время стабилизации ничего не добавляется, кроме исправления ошибок. Критерием окончания стабилизации является отсутствие блокирующих ошибок. На словах просто.

А так ситуация выглядит на деле. Схема демонстрирует единовременно существующие версии релиза.

Всё это тестируется. Не так страшно, если не учитывать, что и территорий присутствия несколько. И на всех появляются баги, которые нужно исправлять.

У них много работы. Во вторую команду должны входить очень трудолюбивые QA-тестеры. Самый главный критерий отбора — любовь к прохождению чужих тест-кейсов (потому что свои они, скорее всего, никогда писать не будут).

Они также должны любить исследовать сложные баги. Пользователь написал «у меня игра не работает» — надо понять, почему. Эта часть «обороны» — связующее звено между разработкой и оперированием. Все баги и панические крики о них на форумах они должны превратить в нормальные проблемы и добавить их в JIRA.

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

Мы стараемся автоматизировать всё, что можно. Когда у вас в игре 200 видов огнестрельного оружия, невозможно каждый раз проверять, не сломалось ли что-то. А оно сломается. Поэтому есть автоматические скрипты, которые проверяют нахождение файлов и другие аспекты.

Инструменты тестирования. Чем их больше (полезных, конечно) — тем лучше. Анализ логов, телеметрии и консольные команды, которые помогают как-то ускорить процесс. Также важна «testability» — возможность протестировать элемент. Если ваш программист говорит, что что-то невозможно проверить — пусть сначала докажет.

Стресс-тестирование тоже автоматизируется. Вы никогда не наберёте команду на MMO free-to-play шутер, чтобы сделать стресс-тестирование силами офиса. Тестирование производительности автоматизируем, поскольку это самая нудная часть работы.

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

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

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

Ещё два правила: если у вас есть QA, который обожает тестировать back-end — не заставляйте его проверять уровни. И проводите больше тренингов и образовательных мероприятий.

Основной KPI, конечно, — это количество блокирующих багов, попавших в финальную версию, все остальные вторичны.

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

На ещё одном важном моменте остановимся подробнее.

Сердечки на схеме — это «фичи». Есть релизы, в которых их много или мало. В первом случае наши отделы маркетинга и продаж счастливы — много «фич» легко продвигать и продавать, всё отлично. Во втором случае им хуже.

​Однако в первом варианте остаётся меньше времени на тестирование. И где-то вы идёте на компромисс. Скорее всего, часть «фич» не работает, что приводит чаще всего к тому, что не работает и релиз.

Бизнес-отделы уже не так рады и рвут на себе волосы. Это последнее правило: меньше — лучше.