Контроль качества в играх с сервисной моделью

Советы от 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 — процесс, в котором желательно, чтобы за каждым элементом, тест-кейсами, а также процессом тестирования проследил человек из смежной команды.

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

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

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

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

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

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

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

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

Code lock означает, что во время стабилизации ничего не добавляется, кроме исправления ошибок. Критерием окончания стабилизации является отсутствие блокирующих ошибок. На словах просто.

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

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

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

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

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

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

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

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

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

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

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

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

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

Стоит постоянно проводить анализ блокирующих багов, «прорвавшихся» в публичную версию на всех уровнях «обороны». Улучшать тест-кейсы, планы тестов, процесс и навыки специалистов.

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

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

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

#Рынок_игр