воскресенье, 20 февраля 2011 г.

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

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

image

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, сейчас активность в Пойнт Бланке

А сейчас - в Линейке


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

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

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

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

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

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

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

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

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

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

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

Side-effect

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

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

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

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

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

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

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

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

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

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




9 комментариев:

Эрик комментирует...

Очень познавательно, всегда было интересно узнать как построено тестирование игровых проектов. А вы знаете как устроенно тестирование у корейских коллег, пробовали перенимать опыт?

Julia Nechaeva комментирует...

2Эрик: конечно, общались с их QA-менеджерами на эту тему. Точно так же у них есть внутреннее и внешнее (бета) тестирование. Разница в объеме внутреннего. Они же новый софт пишут, с нуля, они разработчики.

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

Дело не только в бизнес-отрасли, а и в архитектуре самого приложения, в процессах разработки, в бюджетах и в сроках, в приоритетах и ресурсах.

Я вот тут http://jnechaeva.blogspot.com/2010/06/blog-post.html рассказывала общие подходы к тестированию игр.

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

katechka комментирует...
Этот комментарий был удален автором.
Ilya Ageev комментирует...

Схема интересная, и жизнеспособная, главное найти подходящих людей.:)

Несколько вопросов:

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

Есть ли ежедневные собрания в проектных командах?

Интересны Ваши обязанности как начальника отдела, связанны ли они как-то с тестированием или это больше people management?

Julia Nechaeva комментирует...

2Илья:

2Илья:
а найти подходящих людей - это вообще самое главное! =)

Про отдел тестирования - да, в основном присутствуют все. Не считаю получение информации о том, чем занимается сосед, лишней. Это расширяет информационное поле и не дает замкнуться только на своем проекте.

Что касается проектных команд - то зависит. В некоторых проводится, в некоторых - нет. На усмотрение руководителя проекта. Есть распределенные команды, там сложнее.

Мои обязанности в роли руководителя отдела тестирования - это практически только пипл-менеджмент. Хотя вначале я была тест-менеджером всех проектов.

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

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

Если заказчик тестирования хочет кого-то похвалить, или изменить процесс - это ко мне.

Ну и ещё куча всяких активностей, который под должностную инструкцию "руководитель отдела тестирования" вообще не попадают =)

Rax комментирует...

Юлия, интересная статья, спасибо!

У меня вопрос немного не по теме. Если у меня есть желание работать в отделе тестирование Innova. Как тяжело к вам попасть не имея опыта?
Какие требования?
Возможно стоить что то изучить и уже после этого направить к Вам резюме?

Julia Nechaeva комментирует...

2Rax:
Сейчас вакансий джуниоров нет, мне нужны 2 ведущих игровых тестировщика. Но если появляются, то одно из мест, где мы их вывешиваем, это dtf.ru

Конечно же - без опыта - это не значит совсем с улицы. Советую почитать литературу по тестированию.

Начните с Романа Савина. Участвуйте в бета-тестировании игр на форумах, например. Нам нужны оба скилла: тестирование и знание контента.

Rax комментирует...

Да, конечно я это понимаю, участвовал в ЗБТ и ОБТ SC2, La2ru(имел также продолжительный игровой опыт).
Надеюсь наши пути ещё пересекутся, так или иначе

Анонимный комментирует...
Этот комментарий был удален администратором блога.