Тестирование игр в Иннове: рассказ о работе отдела

Это словесная экскурсия в группу игрового тестирования моего отдела. Это как раз те ребята, о которых говорят, что они "играют на работе" :)



Внешняя среда

Начну с описания внешней системы. У нас 13 игровых проектов. Они разного размера, их разрабатывают разные компании (чаще всего корейские), у них разные процессы, разный жизненный цикл, разная частота обновлений, разное качество и разные изначальные требования к качеству.

На первый взгляд кажется, что Иннова занимается только локализацией, и, казалось бы, что тут тестировать? Нам же дают готовый продукт, тестируйте только локализацию. Но вот эти разные изначальные требования к качеству продуктов играют свою роль. Разные компании-разработчики считают нормальным выпускать продукт на свой (корейский) рынок с определенным количеством известных багов. И это количество у всех, как вы понимаете, разное.

Мы же стараемся свести это количество к минимуму во всех наших играх. Потому что как только мы выпускаем игру в России, она становится «нашей». Мы так считаем.

Процесс тестирования

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

То есть, план тестирования обновления выглядит примерно так:

- тестирование локализации:
--- списки для проверки, сроки

- тестирование новой функциональности:
--- чек-листы для проверки, приоритеты, сроки

- тестирование сборки:
--- смоук-тесты, сроки

- бета-тестирование:
--- задание для игроков, сроки

Я рассказывала про полный цикл тестирования локализованной игры на примере Атлантики.

Процесс взаимодействия с разработчиками зависит от проекта и от компании-разработчика. Баг-репорты могут оформляться в BTS, на нашей или на их стороне, могут собираться в Excel или Google-docs. Взаимодействуют по их исправлению с разработчиками чаще всего тестировщики, но кое-где вся коммуникация проходит через руководителя проекта. Мы подстраиваемся под проект, но вносим в процессы изменения для их оптимизации.

Тестовая среда

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

На QA-стенде проводится внутреннее тестирование, до того, как отдать игрокам на ПТС.

Не любое обновление игры проходит весь путь QA-стенд -> ПТС -> боевые сервера. Некоторые обновления невозможно поставить на ПТС, не задев боевую систему. Такие сразу идут в бой после внутреннего тестирования. Некоторые наоборот, не могут быть нормально протестированы на внутреннем стенде, и они сразу идут вовне к нашим бета-тестерам.

Качество боевого продукта

И все же, приходится выпускать продукты с известными багами. И – бывает, что с критичными. Например, последнее большое обновление легендарного проекта Lineage II High Five Part 4, установленное на сервера 28 декабря, принесло серьезный баг: случайным образом у пользователей клиент игры вылетал с критической ошибкой при телепорте.

Это может зависеть от того, что, например, этот баг проявляется при нагрузке на серверы. И тогда он всплывает только в боевой эксплуатации. Мы не воссоздаем нагрузку в нашем цикле тестирования, потому что это делает компания-разработчик. Но, не всегда результативно. Так как часто обновления запускаются в одно время с Кореей и часто раньше Европы, мы идем на риск запуска с неизвестными багами.

Это может зависеть, например, от запланированного срока запуска обновления, которого ждут все игроки.

Это может зависеть от неопределенных сроков по решению проблемы от разработчиков.

Я уверена, что если устроить опрос среди игроков, пострадавших от бага с телепортом в High Five, согласились бы они играть без обновления и по сей день, то они все равно выбрали бы предновогоднее обновление.

Конечно же, об известных ошибках игрокам сообщается. И статус их решения постоянно обновляется. И, конечно же, они недовольны ответом «Отправлено компании-разработчику, они работают над этим»!

Организация команды

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

В его задачи входит:

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

Тест-менеджер взаимодействует по работе:

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

«Заводы стоят, одни менеджеры в стране», - скажете вы :) Конечно же, тест-менеджер – это не должность, а роль. В эту роль мой сотрудник входит тогда, как на его проекте есть активность по тестированию. В остальное время – он тестировщик. Он – «руки другой головы». Один человек никогда не справится в срок с тестированием большого обновления большой игры. Поэтому, когда ему нужно, вся команда к его услугам. В момент активности его проекта – он главный, он ставит задачи и собирает результат.






Кроме того, если требуется массированная атака (например, проверить сборку клиента на всех серверах проекта), то тут на помощь приходит команда поддержки пользователей: они знают контент игры и готовы помочь. Здесь тестировщик опять же выступает в роли постановщика задачи.

Планирование работы команды на день происходят на утренних стендапах. Основные вопросы, которые обсуждает команда, это:

- «Я сегодня буду заниматься этим»
- «Мне сегодня нужно 4 человека на тестирование этого»
- «Я сегодня не загружен, кому нужно помочь?»

Подход владельца

У нас в компании есть понятие «драйвер задачи». Это значит «быть её владельцем», быть самым заинтересованным в её решении. Понятно, что тестировщик многого не может сделать самостоятельно:

- он не может напрямую повлиять на скорейшее исправление бага разработчиками
- он не может напрямую повлиять на ускорение установки
- он не может управлять инженером
и т.д.

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

Человек, который в случае возникновения трудности, просто напишет письмо, сложит руки и будет ждать – нам не подходит.

Мои тестировщики – это менеджеры своих проектов. Проектов по тестированию проектов. Владельцы процесса.

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

Я считаю неправильным самой делать это за всех, поэтому я учу делать это своих ребят. Это развивает их, и это дает свободу мне как руководителю заниматься более стратегическими задачами.

Side-effect

Правда, side-effect у такого подхода тоже есть. Ребята видят все стороны проекта, общаются со всеми участниками проекта, с почти всеми отделами в компании. Их видят, за ними наблюдают. И они растут.

Некоторые растут в другие отделы. Двое из моих игровых тестировщиков ушли в младшие менеджеры проектов. При этом один из них – на том проекте, на котором работал, а второго цапнул руководитель соседнего проекта. Прямо сейчас он (мой бывший тестировщик) в Сеуле налаживает коммуникации с компанией-разработчиком. Ещё один уходит в отдел аналитики игровых продуктов, как раз сейчас ищу ему замену. Я радуюсь за них. Значит, я хорошо работаю.

И не меньше я радуюсь за тех, для кого тестирование – это та отрасль, где они хотят развиваться и приносить пользу. Они растут как тестировщики, как тест-менеджеры, и не собираются никуда вострить лыжи.

На уровне компании

Не все проекты тестируются отделом тестирования. У нас в Иннове полностью и целиком за свой проект отвечает его руководитель. В том числе и за его качество, и за его тестирование. Я как руководитель сервисного отдела, являюсь владельцем своего направления, и, чтобы оставаться конкурентоспособной, должна предоставлять проектам услугу тестирования с таким качеством, чтоб руководители у меня её заказывали. То есть, если вдруг мои тестировщики начнут лажать, то руководитель проекта вправе отказаться от услуг моего отдела и обустроить себе тестирование самостоятельно. Любыми методами.

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

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

В таких проектах мы выступаем как носители экспертизы: можем подсказать, помочь написать тесты, подсказать, как правильно оформить артефакты.

У нас трудно, но интересно. Нас ругают и нам говорят спасибо пользователи. Мы боремся с системой и дружим с разработчиками.

Спасибо вам, ребята!