понедельник, 28 февраля 2011 г.

Соратники needed

Привет!

Ищем пополнение в команду тестирования Инновы. Про наши проекты можно посмотреть здесь. На наши мордашки можно поглазеть здесь.



Как устроен отдел.
Как работают игровые тестировщики.
Как работает веб-направление - буду рассказывать на agiledays.

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

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

Нам нужно расширять направление нагрузочного тестирования, потому что у нас масштабные планы.

Знаете, что самое, на мой взгляд, крутое на этой позиции? Таких вещей две.

Первая - свобода. Свобода для реализации своих идей. Можно менять тулы, можно пробовать подходы, можно участвовать в планировании разработчиков - можно не участвовать =) Вы будете лидером направления.

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

Если Вы вместо Java знаете Python и умеете читать код на C++, я вам открою секрет, мне скоро понадобится и такой специалист.

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

Ну и напоследок, ведущие игровые тестировщики в два легендарных проекта Lineage II и Aion. Нам нужны люди, которые любят игру настолько, что готовы на ней работать. Которые готовы отдавать игре не 5 часов прогулянных пар, а 8 часов рабочего дня. Вы увидите мир игры изнутри. Вы узнаете пользователей с другой стороны.
Если Вы игрок и тестировщик - велкам.

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

Мы - хороший отдел тестирования. Руководство никогда не отказывает нам в расширении штата или приобретении инструментов. Чтобы стать ещё лучше - нам нужны новые коллеги.
Я требовательный руководитель. Мы требовательная команда. А уж требовательнее, чем наши пользователи, нужно поискать =)

Если не боитесь - пишите мне на yulia DOT nechayeva AT inn DOT ru. До встречи!

Читать далее...

воскресенье, 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 у такого подхода тоже есть. Ребята видят все стороны проекта, общаются со всеми участниками проекта, с почти всеми отделами в компании. Их видят, за ними наблюдают. И они растут.

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

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

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

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

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

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

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

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

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





Читать далее...

Отдел тестирования: цель первой итерации достигнута

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

Надо отметить, что тестировать у нас надо не только игрушки. У нас серьезный отдел разработки, который не дает нам скучать. Как, впрочем, и мы ему. Наш основной продукт разработки – это система, связывающая воедино все наши игры, игроков и партнеров. Пользователям он известен как Фогейм.

Сейчас отдел тестирования компании Иннова состоит из 2 подразделений. Группа тестирования игровых приложений и группа тестирования веб-приложений. Так исторически получилось, это действительно два совершенно различных направления тестирования, требующие от ребят в разных группах разных знаний и навыков. Тем не менее, связь между проектами очень тесная, и мы все вместе радуемся и злимся, отдыхаем и флудим в чатике.

Но, обо всем по порядку…


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

В то же время подходили к завершению переводы Атлантики. Значит, пора было начинать её тестировать. Как тестировали Атлантику – я уже писала. Над ней работали моя первая команда игровых тестировщиков.

Атлантику я провела как тест-менеджер: разработка тест-плана, общение с менеджерами нашей стороны и стороны разработчиков игры NDoors, сводки багов и срезы состояния качества продукта, заключение о готовности к закрытому бета-тестированию, организация сбора фидбеков от бета-тестеров.

После Атлантики, ребята уже самостоятельно организовывают тестирование больших обновлений. Почти каждый из них – тест-менеджер своего проекта. Работа организована так: «Чей проект сейчас активен, тот и главный». Это значит, что если сейчас в работе обновление Lineage II, то тест-менеджер может рассчитывать на руки и головы всей команды. Но во время тестирования другого проекта он сам станет тестировщиком на нём, попадая под управление своего коллеги.

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

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

Тестировать приходится по описаниям изменений в виде «Добавлено 20 новых квестов для асмодиан в Бездне» или «Изменены показатели умений Огня» . Поэтому мы проверяем только на работоспособность внесенных изменений и проводим регрессионное тестирование. На «логичность» изменений проверяют наши бета-тестеры. Именно они, люди, которые знают мир игры лучше всех, могут сказать, что «похоже, разработчики ошиблись. Не может этот шлем давать такой бонус! Это подорвет экономику сервера». И они часто оказываются правы.

Работа с бета-тестерами – это то достижение, которым мой отдел может гордиться. У моих ребят очень теплые отношения с бета-тестерами. Это отдельные группы людей, которым интересно нам помогать, и они сидят в скайп-конференциях, пишут в закрытой группе на форуме, выполняют задания и ждут новых обновлений. Заменить, например, группу из 40 человек постоянных помощников по тестированию Lineage II можно, конечно, группой специалистов по тестированию. Но это был бы худший вариант, так как точечные удары людей, хорошо знающих контент, в нашем случае намного эффективнее планомерного прочесывания со знанием подходов.


Но, игры сама по себе существовать не может, ей нужна очень большая инфрастуктура.
Основной проект нашей компании – Фогейм. Это не просто сайт. За ним стоит огромная система биллинга, связывающая пользователей с лицевыми счетами, нашу внутреннюю бухгалтерию с партнерскими, учитывающая юридические моменты, и, что самое главное, позволяющая с единым аккаунтом играть во все наши проекты. Которых будет становиться все больше!

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

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

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



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

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


В моих целях на 2010 одной из ключевых было написано:

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

Ну что ж, получилось! Мы успешная часть успешной команды.






Читать далее...