DTF.RU - Статьи [http://dailytelefrag.ru/articles/]

Организация процесса тестирования компьютерной игры

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

http://dailytelefrag.ru/articles/read.php?id=1269


Леонид Черный
27 лет, в 2000 году закончил Московский Государственный Университет Печати, факультет экономики и менеджмента. В индустрии с 2000 года. Работал тестером в Cybiko, в мае 2002 года перешел в компанию Nival Interactive. Участвовал в проекте "Операция Silent Storm", "Silent Storm: Часовые"

Вступление
Эта статья написана по мотивам доклада на КРИ2004 "Организация и процесс тестирования компьютерной игры", но не является его компиляцией - это в некотором смысле дополнение и расширение того, о чем было или не было рассказано в ходе конференции.

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

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

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

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

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

Главная причина необходимости отдела тестирования: время разработчиков, потраченное на тестирование, это время, не использованное на разработку.

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

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

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

Существует несколько вариантов:

1. Проектно-ориентированная структура. Структура выстроена так же, как и любой другой отдел из числа входящих в проект. Руководитель проекта - Ведущий тестер - Тестеры. Эта структура не очень гибкая, но она обладает значительным запасом прочности. Ее плюсами являются "погружение в проект" и соответственно понимание того, что происходит в настоящий момент, какие планы стоят на ближайшее время, свободные контакты с любым сотрудником проекта - в обе стороны. И еще, большим плюсом для проекта при использовании текущей схемы работы является наличие полного административного контроля со стороны руководителя проекта над старшим тестером, так же как над ведущим программистом, ведущим дизайнером или ведущим художником. Конечно, минусы тоже есть. Весь вал работ, сопровождающих тестирование, ложится на одного человека. Составление любой документации по тестированию, внутренние разборки между членами команды, планирование работ, оценка текущего состояния проекта, разбор ошибок, найденных за период времени, осуществление коммуникаций между тестерами и разработчиками. В результате ведущий тестер становится узким местом проекта.

1a. Расширением первого варианта является подчинение подразделения проекта, ответственного за контроль качества, не руководителю проекта, а ведущему дизайнеру.

2. Отдел тестирования как отдельная структура внутри компании. Эта структура обладает такой же формой, как и проект. Менеджер, непосредственно подчиненные ему несколько лидов и некоторое количество тестеров, подчиненных одному из лидов. Такая схема напоминает пирамиду, и наложив такую структуру на структуру проекта, имеющую аналогичный вид, мы сможем увидеть практически полное соответствие этих структур, в связи с чем можно предположить, что покрытие возникающих задач по проекту с помощью тестирования будет полным. Это является самым большим плюсом такой схемы организации тестирования. Но влияние проекта на работу внутри такой структуры будет практически сведено к нулю. Теряется фактор административного контроля. Теряется тесная связь тестера и разработчика. Это две проблемы, которые, являясь минусами предложенной схемы, удерживают значительное число разработчиков от перехода к ним. Понятно, что компании, достигшие определенного уровня (5 или больше одновременно разрабатываемых проектов), уже не смогут выстраивать структуру тестирования внутри самого проекта, но до тех пор, пока критический предел не пройден, наличие таких минусов удерживает разработчиков от перехода к этому варианту.

3. Комбинированная структура. Возьмем за основу вариант два, как обладающий большим потенциалом в перспективе грядущего роста компании, и постараемся встроить в него связь группы тестирования с группой разработки и административный контроль со стороны проекта.

Рассмотрим вариант, при котором в компании, на этапе, предполагающем тестирование, одновременно находится два проекта. Допустим, что лиды тех групп, которые отвечают за тестирование, подчинены проекту, а не руководителю отдела тестирования. Соответственно, они будут иметь двойное подчинение, что не очень хорошо, но это на самом деле является вопросом расстановки приоритетов в отношениях между QA manager-ом, руководителем проекта и lead tester-ом.

Правильной расстановкой приоритетов в рамках этой схемы будет являться такая: для лид-тестера, приписанного к какому-либо проекту, первичным является подчинение руководителю проекта (или ведущему дизайнеру игры), а вторичным - подчинение QA manager-у. Чем хороша эта схема, так это тем, что она имеет значительный потенциал по гибкости и хорошие перспективы развития по мере роста числа проектов.

Также за проектом остается административный контроль над процессом. Ну и конечно, когда в проекте существует человек, знающий что, как и где происходит, и отвечающий за качество проекта в каждый отдельный момент времени и способный в каждый отдельный момент составить отчет по состоянию текущей версии - это безусловный плюс. Самым значительным минусом предложенной схемы является значительное увеличение стоимости тестирования. Компьютеры, рабочие места, зарплата, хотя бы минимальный, но соцпакет - это довольно значительные расходы в случае наличия в команде 20-25 тестеров.

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

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

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

Доступные опции:

  1. Тестирование (игры в целом, геймплея, интерфейсов, multiplayer, новых features)
  2. Проведение и организация плейтестов
  3. Тестирование на совместимость с программными и аппаратными средствами
  4. Составление и вычитка документации
  5. Взаимодействие с отделом тестирования издателя
  6. Участие в postproduction - работа с конечными пользователями, подготовка материалов для патчей
  7. Взаимодействие с отделом маркетинга (скриншоты, журналисты, прохождения)
  8. Многое другое

Определились? Отлично. Составьте список, и теперь можно переходить к забавному этапу "В третьих".

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

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

Наконец был найден человек, который в принципе вам подходит. Позвали на собеседование. Отлично. Почти наверняка этот человек тестировал прикладное ПО, а не компьютерные игры. И, как результат, у него могут иметься такие представления о будущей работе:

  • Автоматическое тестирование - ключ к тестированию игр
  • Тестировать игры проще, чем прикладное ПО - в них же еще и играть можно
  • Игра как раз в моем любимом жанре, и я в нее буду играть в рабочее время. Мне еще и платить за это будут
  • Игры? А что это такое? А, помню, играл лет десять назад в арканоид, мне не понравилось
  • Зачем нужны дизайнеры, и так все имеют представление о том, как должен выглядеть WarCraft 7

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

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

Нашли старшего тестера? Просто супер. Но в одиночку он может немногое. Нужны тестеры, которые смогут обеспечивать вал. Искать несоответствия во время Alpha, ошибки на этапе Beta, и обеспечивать финальное качество во время Gold Master.

Найм тестеров.
С тестерами все гораздо проще. После того, как у вас в компании появился человек, который отвечает за тестирование, сразу возникает логичное желание возложить на него подбор собственно тестеров. Так как тестирование - это обычно part-time работа, основными соискателями ее станут школьники и студенты. Соответственно, объявления о наборе тестеров следует размещать в местах скопления этих категорий наших с вами сограждан. После того, как потенциальный тестер откликнулся на объявление, на него необходимо посмотреть, поговорить с ним, выяснить, подходит ли он. Для этого используются различные приемы. Лично я использую следующий. Кандидату на должность тестера выдается лист бумаги, ручка, и 30 минут времени. На листе бумаги есть 4 вопроса, по два с каждой стороны.

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

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

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

Сколько нужно тестеров.
Расчет очень простой. Проект делает X программистов, Y художников, Z Дизайнеров. Соответственно, тестеров на этот проект вам надо (X+(Y/2)+Z)/3

Можно больше, но меньше не рекомендуется. Задачи на проверку поступают постоянно. В большинстве случаев время на проверку задачи сопоставимо со временем конечной реализации этой задачи финальным исполнителем (читай - программистом), то есть: дизайнер придумал (4 часа), художник нарисовал (2 часа), программист вставил в игру (4 часа), тестер проверил (1 час), проверил внимательно (1 час), проверил через 3 месяца (2 часа). Ну, и проверил перед релизом (20 минут). Это то, что касается реализованных задач. А еще бывают ошибки, на поиск которых требуется время, а потом еще время требуется на проверку исправления. Так что тестеров много не бывает. К сожалению, иногда их бывает мало. Но в таких случаях можно найти еще.

Все сделано. Мое уважение. И поздравления. У вас в компании появился отдел тестирования.

Теперь самая простая задача. Составить общие правила для тестера и разработчика. Мой вариант таков:

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

  • Реализация должна быть специфицирована:
    Что бы что-то проверить, необходимо иметь информацию о том, как это сделано. Иногда еще помогает информация класса "Почему это было сделано именно так"

  • Встраиваемые утилиты:
    Если есть возможность встроить в код игры дополнительные вещи типа автоматической генерации репорта об ошибке при вылете игры, лога консоли, контроля целостности ресурсов и так далее, это надо сделать. Это облегчит жизнь всем.

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

  • Распределение нагрузки по тестированию:
    Если есть возможность создать внутри группы тестеров проекта несколько подгрупп, и соответственно разделить их по специализации, это надо сделать. Четкая специализация обязанностей позволит больше времени уделать конкретным деталям.

  • Документация для сверки:
    В принципе, этот пункт пересекается с "Реализация должна быть специфицирована". Под этим пунктом обычно подразумевается общее место, где можно прочитать всю информацию о проекте (например, внутренний сайт). Этот источник информации наполняется всеми участниками проекта разработки, и, как результат, имеется актуальный на любой момент времени дизайн-документ, с которым могут согласовать свои действия все участники процесса разработки компьютерной игры.

Я сознательно опустил финансовые вопросы, типа бюджетирования, учета затрат, стоимости содержания отдела. Каждая компания должна решить этот вопрос самостоятельно. И не забывайте про ПРИЧИНУ!


Вы можете скачать запись выступления Леонида Черного (в формате OGG) и соответствующую презентацию (в формате PPT) с официального сайта КРИ.

[29.07.2004]

Copyright © 1999-2019 DTF Ltd. Все права защищены.
Замечания и предложения отправляйте по адресу team@dtf.ru