Admin → 16. December 2008 14:16
Привет всем. На прошлой неделе не было регулярного поста в нашем блоге. Все потому что, все наша команда активно работает над бета-версией игры. Бета-версия неразрывно связана с вопросом тестирования и контролем качества игры. Но, наконец, настало время рассказать вам о…
Сначала я представлюсь. Меня зовут Леонид Черный, и в компании я занимаюсь (помимо прочего) процессом тестирования и контроля качества проекта.
Так вот. Сегодня нашей темой будет «Тестирование и контроль качества в проекте «Война в небе – 1917»». Она может быть условно поделена на три группы:
1) Сборка и тестирование версии
2) Проверка выполненных задач
3) Стабильность многопользовательских режимов игры и игрового процесса - охота за ошибками, последний (но не по важности) этап
Начнем, пожалуй, с самого начала.
Каждый день у нас новая версия. И каждый день в каждой новой версии у нас есть некоторое количество выполненных задач, некоторое количество исправленных ошибок, некоторое количество добавленной информации. Работа команды контроля качества на этом этапе заключается в том, что бы собрать все изменения, сравнить получившееся данные с предыдущей версией, исключить совпадения, и, наконец, подготовить новый, стабильный, правильный (в соответствии с понятием правильности, принятом в компании) и корректно работающий билд. Если все это происходит в соответствии с планом, полученная версия игры поступает в тестирование.
Каждая новая версия, получаемая нами ежедневно, содержит новую информацию. Нам необходимо проверить, все ли в ней работает правильно. Сделана ли действительно информация, отмеченная разработчиками как сделанная; будет ли она видна в игре; исправлена ли ошибка, отмеченная как исправленная, и работает ли каждый компонент игры так, как мы ожидали. Кстати, когда мы планируем новую функциональность, мы заполняем соответствующую форму в нашей системе учета задач, описывая наши ожидания и требования к визуальному результату и опираемся на эту информацию при проверке выполнения задачи.
В том случае, если визуальный результат отсутствует по определению, мы используем систему логирования, которая при анализе результатов дает нам понять, все ли работает так, как надо – то есть правильно.
На этом этапе мы не занимаемся поиском ошибок. Мы просто сверяем результат работы команды разработчиков с требованиями и ожиданиями.
И только после этого мы приступаем к самой грубой части процесса контроля качеств – отлову ошибок.
И вот тут я хочу передать привет нашим партнерам из компании «Revo Solutions». Эти ребята делают фантастическую работу. Спасибо.
Отлов ошибок в настоящий момент сфокусирован (опять же) на трех элементах. Первый - и наиболее важный сейчас - генератор миссий. Loft в дальнейшем непременно расскажет о генераторе более подробно. В любом случае, поверьте мне, тестирование генератора - очень трудоемкий процесс, занимающий большое количество времени и проходящий в несколько итераций.
Второй - не менее важный - элемент – это тестирование многопользовательских режимов игры. Он включает в себя тестирование стабильности работы, сетевой загрузки и поиск рассинхронизаций. Самая большая проблема в тестировании многопользовательских режимов -найти путь воспроизведения ошибки. Путь воспроизведения - это то, благодаря чему программист сможет повторить ошибку, выяснить, в чем проблема, и, наконец, исправить досадную помеху на пути к релизу. Вообще, в процессе тестирования есть только две больших проблемы, и поиск пути воспроизведения не самая большая из них. Самая большая – абсолютно фантастическая занудность процесса тестирования. Попробуйте делать одно и тоже несколько дней подряд в одном и том же окружении. Или представьте себе, что вы играете в одну и ту же игру, пусть и любимую, на одном и том же уровне, на протяжении 3-4 недель, по 9-10 часов в день, 5-6 дней в неделю. Звучит занудно. В любом случае, это лирика.
Если вернуться к физике, то есть обратно к теме разговора, мы сможем обратить внимание на еще одну важную вещь, связанную с тестированием. И это тоже может быть названо одним из топовых приоритетов в тестировании. В игре, причем в абсолютно любой, вы можете найти сотни и сотни разных элементов. И эти элементы очень плотно связанны друг с другом. Именно эта связь является задачей тестирования.
Позволю себе проиллюстрировать сие утверждение. Допустим, в нашей игре самолеты могут стрелять из пулеметов. Соответственно, при стрельбе может быть нанесен вред домам, наземной технике, другим самолетам, пилоту. Должна быть визуализация стрельбы, трассеры от пуль, попадание пуль в землю или воду. Соответственно, задача по тестированию стрельбы из пулемета включает в себя проверку нанесения вреда и моделей разрушения домов (включая неразрушаемые – надо же проверить то, что у нас они неразрушаемые), наземной техники и объектов, самолетов, проверка возможности убить пилота, систему проигрывания эффектов огня при выстреле, трассеров, эффектов попадания пуль в разные типы почвы, да и про воду тоже не забываем. Этот пример довольно груб и неполон, но в то же время довольно точен в показе вариативности задач, стоящих перед тестированием простого, как может показаться на первый взгляд, элемента. И подобное применимо к любой отдельно взятой части игры.
Ну ладно.
Давно, когда я был молодым и глупым, у меня была мечта. Я хотел тестировать игры. Это реально звучало как работа моей мечты. Ты играешь в игры, тебе за это платят. Только подумайте. Ты проводишь все свое рабочее время, играя в игрушки. Вау.
Повторюсь, я был молодой и глупый.
Сейчас, спустя 9 лет с того момента, как я пришел в эту индустрию, мне хочется сказать только одно – уважайте тестеров.