[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "create", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-158433683", "adfox_url": "//ads.adfox.ru/228129/getCode?p1=bxbwd&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid21=&puid22=&puid31=&fmt=1&pr=" } } ]
{ "author_name": "Vladislava Rakhmanova", "author_type": "self", "tags": ["\u0440\u044b\u043d\u043e\u043a_\u0438\u0433\u0440","gamedev"], "comments": 4, "likes": 15, "favorites": 7, "is_advertisement": false, "section_name": "default", "id": "23163" }
Vladislava Rakhmanova
1 598

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

Советы от QA-менеджера Crytek по тестированию игр, которые требуют регулярного обновления.

Поделиться

В избранное

В избранном

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

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

Warface

Про игру

Warface — онлайн free-to-play-шутер. Практически пять лет игра находится на стадии оперирования и больше восьми лет — в разработке. Это самый большой free-to-play-шутер на территории СНГ. Три года назад мы поставили официально зарегистрированный рекорд Гиннесса — 145 тысяч пользователей в онлайне на одном сервере.

Если посчитать по всем территориям, PCU (peak concurrent users) больше — около 200 тысяч человек. Ежедневно в игру заходят около 700 тысяч уникальных пользователей. Каждый год мы выдаём около 12 крупных обновлений.

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

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

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

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

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

Мы используем трёхуровневую «оборону».

  • Development QA — высокая экспертиза, очень опытные ребята.
  • Integration QA — средняя экспертиза, важна их усидчивость.
  • Public test server — обычные игроки.​

Development QA

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

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

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

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

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

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

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

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

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

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

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

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

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

  • «X» — то, что мы разрабатываем.
  • «X-1» — на стадии стабилизации.
  • «X-2» — интеграция территорий присутствия перед оперированием.
  • «X-3» — готовится к стадии оперирования.
  • «X-4» — на стадии оперирования.

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

Integration QA

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

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

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

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

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

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

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

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

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

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

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

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

Меньше — лучше

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

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

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

#Рынок_игр

Популярные материалы
Показать еще
{ "is_needs_advanced_access": false }

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

0 новых

Популярные

По порядку

Прямой эфир

Хакеры смогли обойти двухфакторную
авторизацию с помощью уговоров
Подписаться на push-уведомления