Home

Оригинальная публикация: https://vc.ru/p/qa-test-game-services

Советы от 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, конечно, — это количество блокирующих багов, попавших в финальную версию. Все остальные вторичны.

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

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

Нажмите на картинку, чтобы увеличить изображение

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

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

Нажмите на картинку, чтобы увеличить изображение

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

Обсудить в форуме.