Сидел я спокойно, как вдруг друг жалуется: «Детектор совсем сбрендил! Артефакты показывает то за неприступной стеной с колючей проволокой, то под землёй.»
Думаю, в чём проблема? Перелезь или лопату возьми! Я-то их тестирую, и пусть радуется, что они камни в почках буреломов за артефакты не считают, как раньше. Промолчал – а то вдруг ещё с монтировкой набросится!
© Механик «Бюрократыч»
Тестировщики в команде EXBO работают ещё со времен динозавров. Всё начиналось с инициативных и дотошных игроков, которые умели лучше других отлавливать и воспроизводить различные баги. Сейчас это крайне эффективная и дисциплинированная команда QA* из 13 человек, которая тестирует и помогает привести в порядок весь контент, добавляемый в игру.
Мы пообщались с ведущими инженерами по тестированию, Всеволодом «Veriford» Волковым и Максимом «Mongol» Скудаевым, и готовы рассказать вам, как устроена работа их отдела и насколько велика «подводная часть айсберга» под названием «баги Сталкрафта».
Эту статью будет особенно полезно почитать тем, кто хочет связать своё будущее с геймдевом, ведь QA действительно является удобной стартовой точкой для входа в индустрию и давно востребован на уровне программистов.
В этой статье вы узнаете:
- Чем они там, в своих каморках, вообще занимаются?;
- К каким тестам привлекают игроков;
- Все ли баги достойны исправления;
- Какие есть гигачады среди багов;
- Кто всё-таки выносит во время технических работ.
Суть работы тестировщика
Играть в STALCRAFT: X с баклажкой кваса, изредка репортить баги и всё равно пропускать их в релиз … Это, было бы возможно, если бы среди сотен паллет энергетиков, кофе и пенного в офисе можно было найти хотя бы один квас.
© Фанат кваса
На расслабоне поиграть и порепортить баги не получится — большинство новых фич и механик поступают к QA в совершенно неиграбельном состоянии, почти полностью состоя из багов. Сотни, а иногда и под тысячу багов! И все их нужно отловить, воспроизвести, описать, зарепортить разработчикам, дождаться фикса, а потом обнаружить на месте исправленного бага два новых — и так по кругу.
А ещё всё это нужно делать в темпе, ведь необходимо соблюдать график релизов. Любые переносы запускают цепную реакцию, отодвигая будущие релизы, а если впереди ивент — вообще улетают за горизонт. В общем, тут точно не найдется места ни для расслабона, ни для кваса.
На первый взгляд может показаться, что мы пытаемся вызвать сочувствие и показать всю суровость труда в «тестерских шахтах». Однако, тестировщики получают настоящее удовольствие от своей работы! Это почти как быть программистом, только без написания кода.
QA — часть команды разработки, и когда релизнутый продукт находит положительный отклик у игроков, это невероятно приятно. А завершение работы над релизом приносит драйв и прилив сил для новых вызовов!
© Mongol
Этапы тестирования
Работа в QA требует творческого подхода. Понять, как и почему ломается механика, — задача не из лёгких. Нужно не только найти проблему, но и предложить варианты её решения, а затем грамотно передать всю информацию разработчику. Чтобы в этом творческом хаосе появился порядок, процесс делится на этапы тестирования. Эти этапы помогают систематизировать работу тестировщиков и чётко определить их задачи.
Тестирование делится на следующие этапы:
- Статическое тестирование;
- Модульное тестирование;
- Регрессионное тестирование;
- Негативное тестирование;
- Интеграционное тестирование.
Статическое тестирование
Этот этап начинается ещё до того, как программист касается клавиатуры. Геймдизайнер отправляет тестировщикам документ с подробным описанием механики красочно и в деталях, жаль только без картинок.
Чем позже мы обнаружим баг, тем больнее будет его исправить. Если упустить ошибку в документации и передать механику в работу другим отделам, исправления впоследствии может стать практически невозможным или крайне затратным по ресурсам и времени.
© Veriford
После статического тестирования все последующие виды тестов проводятся уже непосредственно в игре.
– Наконец-то нам дадут поиграть!
– Ага, щас…
Модульное тестирование
На этом этапе механику исследуют в отрыве от остальной игры. «Живая» ли она сама по себе? Геймдизайнеры предоставляют тестировщику техническое задание, описывающее, за какие «ниточки» нужно потянуть фичу, чтобы понять, что она шевелится как положено.
Помимо стандартных взаимодействий, QA используют специальные инструменты — конфиги. Они позволяют изменять свойства и числовые значения объектов и явлений, такие как скорость мутанта, приоритет его целей для нападения или траекторию снарядов.
Опыт тестировщика тут на вес золота: он помогает понять, какие именно настройки нужно изменить в конфигах и где, вероятно, скрылись баги.
Все нестыковки QA заносит в отчёт, после чего распределяет по задачам на программистов и ждёт когда всё пофиксят, чтобы приступить к следующему этапу.
Регрессионное тестирование
После исправления всех багов специалист QA проводит регрессионное тестирование согласно ТЗ. Оно включает проверку не только исправленного, но и всей функциональности, даже той, что уже была протестирована. Свежепойманные баги отправляются в задачи к программистам, а тестировщики снова ждут, чтобы после фиксов пройти этот этап ещё раз. Да, снова, и да, душно, зато при деле.
А всё потому, что починка одной шестерёнки может вывести из строя целую машину. Это особенно важно, так как игровые механики переплетены друг с другом. Регрессионное тестирование выполняется всегда после любых изменений фичи: фикса, доработки или изменения её параметров. Даже если… нет, особенно если поменяли всего одну букву в коде.
Негативное тестирование
Это буквально как намазывать масло на хлеб кружкой. В принципе, возможно, но изначально явно не так задумывалось.
Если после регрессионного тестирования фича работает как задумано и все критичные баги исправлены, тестировщик приступает к негативному тестированию. Он проверяет вообще все, даже самые нелепые способы взаимодействия с механикой. Кто бы мог подумать, что кто-то решит нажать все кнопки одновременно или вылезти за пределы карты в сюжетном задании?
Иногда негативное тестирование проводится параллельно с регрессионным, но это не всегда удачно. Ведь если на предыдущем этапе найдётся серьёзный баг, негативное тестирование не имеет смысла. Его всё равно придётся проводить заново — через боль, пот и слёзы — снова и снова, после исправления пойманного «нарушителя».
Интеграционное тестирование
Затем механика проходит интеграционное тестирование на тестовом сервере с последней версией игры, чтобы проверить, как она стыкуется с другими механиками и элементами игры.
Например, когда добавили территории мутантов специально сделали так, чтобы они нападали только на очень близкой дистанции, чтобы монстры не убегали в закат вслед за игроком. Видимо, с кабанами перестарались, так как они не атаковали даже в ответ на удары.
Если возникают проблемы, команда возвращается на шаг назад, устраняет их и повторяет процесс до полной готовности. Именно на этом этапе отлавливают большую часть дюпов и других багов, опасных для экономики. И только после этого механика идёт на основной сервер, на котором играют все. После техработ, разумеется — но об этом чуть дальше.
Ура, победа! Вы протестировали одну механику и она действительно работает как надо. Выдохнули? Рано. Впереди ещё тысяча изменений, которые жаждут вашего внимания.
Это идеальный порядок тестирования в вакууме, но на практике всё обстоит иначе. На этапе документации команда оценивает, сколько времени займёт разработка, и на основе этого устанавливает сроки выпуска обновления. А так как параллельно разрабатывается множество других элементов, так формируется очерёдность релизов.
В этой очереди обычно стоят крупные проекты, наполненные множеством новых элементов. Порой один или несколько ключевых элементов проекта не готовы, и без них выпускать его нет смысла, поскольку он не будет работать. Плюс итоги тестирования всегда непредсказуемы. Могут вылезти такие заковыристые баги, что они откинут релиз далеко в конец очереди.
В таких случаях приходится переносить релиз. Но если основа полностью готова, то релизу быть в срок. Несущественные мелочи можно завести и попозже. Хочется же как можно быстрее вкинуть что-то новое.
Более мелкие фичи, такие как QoL, обычно не ждут очереди. Их заливают сразу по готовности. Иногда даже в последний момент перед техработами что-то добавляют, например, подсветку модулей и артефактов.
Ещё вне очереди обслуживаются проекты, жёстко привязанные колючей проволокой к конкретным датам. Это касается новых сезонов и ивентов. Варианта не успеть их доделать в срок просто нет. Если время поджимает, приходится перебрасывать все силы, даже с других важных проектов, — успеть нужно в любом случае.
Открытые и закрытые тесты
Однако не только QA тестирует новые механики и обновления. Есть ещё несколько групп, которые помогают улучшить качество выпускаемого контента. Давайте рассмотрим их — начиная с самых маленьких. В одной из таких групп, возможно, окажетесь и вы. Или попадёте туда в будущем, кто знает?
Фокус-группа
Небольшая группа прожжённых мастеров кубического мира исследует механики до их выхода через призму своего игрового опыта. Это касается сессионных боёв, ивентов, балансных правок и подобных им штук. Их основная задача — не искать баги, хотя и такое тоже бывает. Фокус-группа скорее оценивает поведение игроков в реальных условиях, проверяя, играется ли механика так, как она задумана. Они ищут проблемные моменты в геймплее и дают рекомендации по их устранению разработчикам. Такой своеобразный кринж-контроль. Кстати, расспрашивать, что они тестят, бессмысленно — у всех подписан договор о неразглашении.
Группа закрытых тестов
Перед релизом обновления «День Х» мы решились на этот эксперимент. Игроков специально брали разных — от бывалых гигачадов Зоны до новичков, впервые запустивших игру на тестах. Это позволило смоделировать близкий к реальному онлайн в рамках одной копии каждой локации. А разный уровень участников не позволил получить ложные данные, отражающие шкурные интересы отдельной группы. Всего в команде было 200 участников.
Эти ребята были призваны щупать глобальное преображение игры и тыкать пальцем во всё, что им кажется странным или неправильным. Новая система передвижения, северные локации, сюжет и другие механики, появившиеся после 10 июля. Многие элементы прогоняли по несколько раз в тесном контакте с ответственными разработчиками, чтобы отточить механики до играбельных версий.
Группа была закрытой: участники подписали соглашение о неразглашении, чтобы сохранить сюрприз для остальных игроков. Опасения по поводу утечек оказались напрасными: в этой группе произошёл лишь один случай разглашения по невнимательности.
Изначально думали уделить этим тестам всего две недели, но это оказалось так удобно в плане сбора статистики и обратной связи, что эти группы в разных составах работали несколько месяцев и работают по сей день, тестируя последние и грядущие изменения. В общем, опыт оказался довольно успешным. Скорее всего, в будущем наборы в эту группу ещё будут, так что поглядывайте за внутриигровой почтой и информацией на ресурсах.
Открытый тестовый сервер
Последний раз его открывали совсем недавно для проверки рейтинговой системы ивента «Черный рейд». Благодаря игрокам мы выявили слабые места системы, скорректировали её к моменту выхода и успели выкатить серию хотфиксов в первые дни после релиза. Помимо рейтингов, тестирование подсказало нам, что механика эвакуации должна быть более гибкой, а «Обращённым» из шёпота нужно выстрелить в колени. В результате, с новым патчем игроки теперь могут вызвать вертушку заранее и не мучиться в ожидании таймера, а «Обращённые» стали чуть слабее, создавая у выживших шанс на победу в схватке с ними.
Если вы с нами достаточно давно, то помните, как открытые тесты проводились перед релизами «Изнанки» и «Аномальных буранов». Несколько раз открытые тесты проходили перед глобальными ребалансами снаряжения и артефактов. А пару раз даже тестировался новый ИИ.
Было несколько итераций массовых тестов, когда мы сменили механизм поиска пути мутантов с “майнкрафтовского” на наш NavMesh. Это большая фича с множеством неожиданных ситуаций, и одной командой покрыть всё просто невозможно.
Вот в такие моменты на помощь и приходят игроки. Из интересного: впервые для ОТСа сделали отображение координат на экране, а раньше приходилось искать место по карте или скриншоту, который прилагал игрок.
По случаю этих тестов даже сделали уникальные брелоки в виде мутантов, покрытых сеткой NavMesh, и выдавали их как за участие, так и за нахождение редких багов.
© Mongol
Такие массовые тесты нужны для того, чтобы посмотреть, как будет вести себя уникальный режим или механика при полной загруженности, откорректировать баланс и оценить изменения свежим взглядом. Ну и бонусом — помогают найти некоторые свежие или давно забытые баги.
«Баг известен, когда уже фикс?!»
Несмотря на всю систему тестов, некоторые ошибки всё же просачиваются на основной сервер.
Да, большинство багов игроки никогда не увидят. Около 95% из них QA успевает выявить и исправить до того, как обновления выходят на продакшен, но вот эти пять процентов… Даже будучи обнаруженными, они могут довольно долго ждать своего шанса на исправление.
Скорость фикса каждого бага зависит от его критичности, приоритета, количества затронутых игроков и затрат ресурсов команды. Но это не взаимоисключающие друг-друга критерии, а наоборот комбинируемые. Чем больше влияние на игру, тем быстрее пофиксят.
В первую очередь исправляются дюпы и баги, которые делают невозможной дальнейшую игру, не позволяют продвинуться по сюжету или приводят к закрытию клиента.
Эти недочеты исправляются в первую очередь, несмотря на трудозатраты, так как они имеют иммунитет к заклинанию «невприоритетус».
Некоторые ошибки могут оставаться неисправленными долгое время, так как их исправление требует внимания конкретного программиста. Например, отвлекать разработчика от создания данжей ради исправления траектории движения крыс, которые бегут зигзагом вместо прямой атаки, зачастую нецелесообразно.
Кстати, не лишним будет напомнить, что делать, если на вас напал баг.
Паниковать ни в коем случае нельзя — баг чувствует страх! Нужно спокойно перейти в раздел официального сайта «Центр поддержки» и создать обращение, описав проблему конкретными фактами, без эмоций и максимально подробно, не забыв прикрепить фото и видео с доказательствами совершённого «преступления».
Теперь поговорим о награде. Вы уже наверняка знаете, что критичность бага и награду за его обнаружение определяет ответственный разработчик. Давайте рассмотрим весь процесс.
После того как вы сообщаете в поддержку о нахождении бага, вам отправляют форму, которую нужно заполнить полностью. Обязательно прикрепите фото, а лучше видео подтверждение. Затем баг передаётся на тестировщиков, а после — на фикс к разработчику, и после исправления снова на тест. Если баг очевидный, он идёт сразу на исправление к разработчику, а уже после устранения — на проверку.
Фото и видео нужны для того, чтобы QA смогли воспроизвести баг. Это обычно главный фактор, влияющий на скорость исправления — чем проще баг воспроизвести, тем проще начать планировать его исправление. Ну или использовать заклинание «неприоритетус»!
Когда баг попадает к разработчику, он оценивает, насколько баг опасен и стоит ли выдавать за него награду. Затем разработчик передаёт эту информацию специалисту поддержки, который сообщает об этом игроку, нашедшему ошибку.
Награда выдаётся за серьёзные баги, которые напрямую влияют на экономику или делают невозможной дальнейшую игру, и только первому, кто сообщил о нём в поддержку. Именно поэтому вы можете услышать фразу «О баге уже известно», когда несколько человек отправляют одну и ту же проблему. Это как раз тот случай, когда решают самые быстрые пальцы по эту сторону Миссисипи.
Самые неуловимые и сложные баги
Среди тех поганцев, что просачиваются на основу есть и те, кого не так просто вычислить. Их немного, но это не значит, что их не надо чинить. Вот вам парочка из таких, которые уже удалось вычислить и ликвидировать.
Старые аирдропы
Один из самых сложных багов был ещё на прежнем Севере — дюп наград из айрдропов. Чтобы он сработал, два человека должны были забрать все награды с точностью до миллисекунды, как только дроп активировался. Даже на тестовом сервере достичь этого было крайне сложно, а в реальной игре такое совпадение возможно один раз на миллион.
Омуты на краю карты
Точнее, появление артефактов в омутах на краю карты и в недоступных местах. Сложность была не в исправлении, ведь отключить спавн артефактов у аномалии — это проще простого. Проблема заключалась в том, чтобы выявить все аномалии, выбрасывающие артефакты за пределы карты…
Система настроена так, что по умолчанию все аномалии могут выбрасывать артефакты. Отключить эту опцию можно только вручную — для каждой аномалии отдельно. Соответственно, искать омуты, жарки и разряды, бросающие артефакты в недоступные места, приходилось почти что «пешком». И да, убрать аномалии с границ карты тоже не вариант, они должны там быть. Сами-то они находятся в пределах локаций, но вот плюются артами куда попало.
Эту проблему уже решили. Мы запросили у аналитиков базу данных сбора артефактов, посмотрели, где артефакты почти не поднимаются, и буквально “летали” по всем локациям, отлавливая аномалии, находящиеся за пределами зоны доступа игроков, и отключая их спавн.
© Veriford
В целом, таких аномалий должно остаться очень мало или не остаться вовсе. Если вы обнаружите такую аномалию, пожалуйста, сообщите об этом в Службу поддержки, указав точное местоположение и приложив скриншот. Мы обязательно исправим эту проблему.
Онлайн на технических работах
Последняя история с артефактами интересна тем, что исправить её можно было только на основном сервере. И она не единственная. Похожая ситуация происходила тоже с артефактами, но уже на за пределами карты, а в треклятых ржавых бочках.
Решили проблему не сразу — из-за различий между тестовым сервером и продакшеном, которые заключались в базах данных.
На тестовом сервере всё было в порядке, а на основном иногда артефакты падали в декор, и их было невозможно подобрать. Ну, вы знаете, как это было. Оказалось, проблема заключалась не в спавне, а в приоритете взаимодействий. Игра “считала”, что бочка важнее для игрока, чем артефакт. К счастью, эти времена канули в прошлое, оставив только ностальгические воспоминания о ветках калины и многогранниках в ржавых бочках.
Тестовая среда и продакшен — это как два близнеца с разными характерами. Некоторые баги, которые могут проявиться на основном сервере, просто невозможно поймать на ПТС.
Во время технических работ тестировщики сразу после залива обновлений заходят в игру и проверяют изменения уже на продакшене. Ведь важно, чтобы всё заработало как часы.
Тест обновления — финальная стадия технических работ. Сначала создаётся резервная копия, чтобы откатить изменения, если релиз пойдет не по плану. Затем загружаются изменения и новый контент на все серверы, что тоже занимает время, особенно с учётом того, что базы данных становятся всё больше и больше. После этого тестировщики заходят на сервер, чтобы убедиться, что обновление прошло успешно.
Отсюда и продолжительность технических работ: чем больше патч, тем больше данных нужно загрузить и тщательнее всё проверить.
Заключение
Ну вот, теперь вы приоткрыли завесу тайны и увидели, через какие круги тестирования проходит каждый кусочек нового контента. Заглянули за кулисы обновлений и узнали, кто там шуршит на технических работах перед запуском. И про баги, которые долго не исправляют, тоже поговорили. А, да, ещё вы теперь знаете, как в будущем можно и свою руку к некоторым тестам приложить.
Спасибо за внимание! Кстати, если вам было интересно, возможно, чтиво про работу аналитиков вам тоже зайдёт.
