Контроль качества в играх с сервисной моделью
Советы от 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-специалистов, «разрывает» их чудесный продукт в клочья. Наступает паника: оказывается, что игру невозможно пройти, она вылетает, не работает. Разработчики чинят половину блокирующих багов, продают игру, выпускают патчи и зарабатывают на этом какие-то деньги.
А что если ваша игра представляется сервисом? Во-первых, такой подход не работает. После первого же подобного обновления у вас останется меньше половины аудитории. А выпустив два неудачных обновления, проект можно смело закрывать.
Чем характерна игра как сервис? Тут вы всегда сперва создаёте дизайн, прежде чем приступить к разработке. Как правило, используется итеративная разработка, чтобы следить за требованиями рынка, быстрее на них реагировать.
На каждом этапе вы тестируете проект. У вас регулярно (раз в месяц) выходят обновления контента. А это довольно часто: ежемесячно нужно выдавать хороший продукт. У вас очень высокая стоимость блокирующих багов. Если они попадают в финальную версию, вы гарантированно теряете часть аудитории. При этом вы не можете позволить себе просто беспрестанно работать по ночам и выходным — из-за продолжительных сроков в таком режиме ваша команда просто «сгорит».
Мы используем трёхуровневую «оборону».
- 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, конечно, — это количество блокирующих багов, попавших в финальную версию. Все остальные вторичны.
Стоит постоянно проводить анализ блокирующих багов, «прорвавшихся» в публичную версию на всех уровнях «обороны». Улучшать тест-кейсы, планы тестов, процесс и навыки специалистов.
Меньше — лучше
Сердечки на схеме — это фичи. Есть релизы, в которых их много или мало. В первом случае наши отделы маркетинга и продаж счастливы — много фич легко продвигать и продавать. Во втором случае их дела обстоят хуже.
Однако в первом варианте остаётся меньше времени на тестирование. И где-то вы идёте на компромисс. Скорее всего, часть фич не работает, что чаще всего приводит к тому, что перестаёт работать и релиз.
Бизнес-отделы уже не так рады и рвут на себе волосы. Это последнее правило: меньше — лучше.
© vc.ru
