SQA

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

Статья была написана для www.dtf.ru и публикуется нами с разрешения автора.

Вступление

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

Кто такие тестеры в игровой индустрии?

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

А для чего нужны эти тестеры?

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

А если серьезно, то:

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

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

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

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

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

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

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

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

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

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