Знакомство с командой: Quality Assurance

Друзья!

Мы продолжаем знакомить вас с дружным коллективом разработчиков Skyforge и сегодня поговорим о контроле качества с Романом и Алексеем. Ребята согласились ответить на каверзные вопросы касательно работы своей команды. Из интервью вы узнаете, как проходит тестирование и выпуск обновлений, откуда берутся «баги» и почему они иногда возвращаются...

Предлагаю начать с вопросов, ответы на которые должен знать даже самый юный игрок. Откуда берутся «баги» (игровые ошибки) и кто им противостоит?

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

Баг — это когда что-то в игре происходит не так, как было запланировано (разработчиком), или не так, как ожидается (игроком). К слову, по конкретным моментам мнение этих групп может сильно расходиться.

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

Чтобы минимизировать потери обоих сторон и не допустить появления ошибок в игре, существует группа контроля качества.

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

АлексейCтарший QA-специалист в Allods Team

Почему ваша команда называется Quality Assurance? Разве QA и тестировщик не одно и то же?

Алексей: Тестировщики — это люди, которые проверяют продукт и выявляют в нем ошибки в основном с помощью ручного тестирования по заранее составленному перечню необходимых проверок. Зачастую они проверяют игру как «черный ящик»: без представления о том, как и почему ее элементы работают именно так, а не иначе.

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

Как тестируют Skyforge? Какие методы используются?

Роман: Самые разнообразные.

Ручное-регрессионное применяется, когда проводятся финальные проверки перед отдачей версии (обновления) для установки на игровой сервер. В ходе такого исследования мы обращаем внимание на конкретные элементы, которые должны войти в обновление.
Нагрузочные тесты запускаются по ночам: боты бегают по локациям, а днем мы анализируем результаты.
Существует ряд автоматических тестов, проверяющих целостность и адекватность игровых ресурсов и кода, часть из которых созданы самими QA.
Мы используем различные инструменты, которые банально не позволяют вносить изменения в игру, если они выглядят «багоопасными». Тут же загорается сигнал тревоги, и спецотряд QA отправляется тушить пожар. (Нет.)

Насколько глубоко тестировщик должен разбираться в игре и в процессах разработки? Что важнее?

Алексей: Отличный вопрос! Хороший QA должен овладеть обоими навыками.

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

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

Проводите ли вы плейтесты боссов?

Алексей: Безусловно! Это одна из важных частей работы именно моей команды (QA Game Mechanics). Уверен, вам будет интересно услышать, как мы проводим проверку особо «крупных» боссов (искажения, аватары).

У каждого такого босса есть QA, который контролирует работы по нему и отвечает за все проверки. Первые тесты проходят в одиночку: проверяется дизайн-документ, реализация способностей и визуальной составляющей босса. Если все работает, как и было задумано, проводится первый мини-плейтест для 4-5 человек из команды QA. Они проверяют работоспособность босса в бою с группой персонажей. После этого проходят тесты с внутренней «фокус-группой», в которую включаются QA из других команд, дизайнеры и другие опытные разработчики, которые прошли строгий отбор по престижу на основном сервере.

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

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

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

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

Как быстро разбираются запросы игроков, отправленные через специальную форму в игре (клавиша «U»)?

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

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

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

Большое количество информации значительно упрощает нашу работу, ведь чем больше обращений пришло о конкретной проблеме, тем с большим приоритетом ставится задача на починку разработчикам.

Алексей: Когда задачи расставлены, ответственный QA отчаянно пытается воспроизвести проблему, с которой столкнулись игроки. Зачастую это не так просто, как кажется. Успех предприятия сильно зависит от объема и качества информации, которая была получена из запроса.

К примеру, если написано лаконичное: «ПОЧИНИТЕ ХСА!!!1111», такую проблему найти будет значительно сложнее, чем если бы в тексте были описаны примерные действия игрока и последствия ошибки. А вот пример запроса, с которым было приятно работать: «Проблема с масс ПвП, если персонаж умирает и не успевает воскреснуть до того, как матч заканчивается. Нет возможности покинуть матч и выбрать награду, помогает только перезаход в игру». Есть ответы на три главных вопроса: «ГДЕ?», «КОГДА?», «ПРИ КАКИХ УСЛОВИЯХ?». Ну разве не прелесть?

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

Идеальное сообщение об ошибке, содержит в себе ответы на вопросы «Где?», «Когда?» и «При каких условиях?».

АлексейCтарший QA-специалист в Allods Team

Итак, решение проблемы найдено. Остается вопрос: когда оно попадет на live-сервер?

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

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

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

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

Алексей: Сборка такой финальной версии занимает порядка 8 часов. Поэтому версия зачастую готова за пару дней до того, как попадает к игрокам. Вносить изменения в нее можно, но время на ее пересборку может доходить до 8 часов. Тем не менее, все, что делают программисты, дизайнеры, художники и остальные разработчики, все равно попадает к игрокам.

Если же проблема не так критична, чтобы добавлять ее в ветку прямо сейчас, то она попадает уже в следующую ветку, которую выводят из общей версии. Связано это с тем, что каждый мердж — это риск: можно испортить больше, чем починить.

Как вы определяете приоритетность багов? Почему некоторые ошибки не чинятся так долго?

Алексей: Мы пользуемся достаточно обычной системой приоритезации задач: ToPatch, Bloсker, Critical, Major, Normal, Minor. Все ошибки сортируются согласно подробной инструкции по нескольким критериям, я перечислю несколько наиболее важных:

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

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

Например, мы обнаружили последовательность движений, которая приводит к очень неприятной проблеме: персонажа выкидывает с сервера и в течении 30 минут не пускает обратно. С одной стороны — катастрофа, бежать, чинить! Но, если это последовательность действий похожа на «начать произносить заклинание “Буран“, прервать, сесть на транспорт, два раза подпрыгнуть, сменить класс, поменять главное оружие, вернуться к классу “Криомант” и снова прервать воспроизведение способности», приоритет такой ошибки будет небольшим. Но! Если та же самая ошибка будет приводить к любым потерям игровых данных (даже с таким сложным воспроизведением), приоритет будет высоким.

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

РоманCтарший QA-специалист в Allods Team

Звучит разумно, но все же: почему в игре «так много» багов? Как так происходит, что уже исправленные ошибки иногда «возвращаются»?

Алексей: Зачастую количество багов говорит о сложности и масштабе проекта. MMORPG – достаточно непростой жанр для тестирования. Здесь присутствует большое количество систем, которые тесно связаны, и изменение в одной из них может отразиться совершенно в другом месте. Прослеживание и предугадывание такой зависимости тоже входит в обязанности QA.

Я достаточно часто слышу на работе фразу: «Леш, я тут немного код поправил, может бомбануть где угодно, проверьте пли-из!». Конечно, перепроверять всю игру и запускать полный регрессионный цикл после каждого исправления невозможно. Однако мы стараемся проверять все места, на которые могло повлиять то или иное действие. Бывает, что ошибки рождаются скоростью разработки, когда времени на проверку сложной системы выделяется немного, но отложить запуск нельзя.

Роман: Разработка игры не останавливается ни на секунду! Чтобы избавить крупный проект от всех багов, нужно либо очень много времени и ресурсов, либо прекратить разработку. И даже полное отсутствие ошибок не гарантирует вселенского счастья. Помните, о чем я говорил в самом начале? Что разработчик считает фичей, то игрокам может казаться багом.

Алексей: Что касается «возвращения» ошибок: это может происходить по самым разным причинам. Часто бывает, что внешне одинаковые проблемы вызваны кардинально разными ошибками в двух независимых системах.

Роман: Обычно это происходит либо на стыке «код-данные», либо при неудачном тиражировании контента. Я постараюсь объяснить.

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

Приведу примеры. У нас в ресурсах есть специальная галочка, которая отвечает за «опускание объектов на землю». Работала она адекватно, но при проверке одной из локаций выяснилось, что при определенных условиях галочка не эффективна. Программисты поправили код «опускания объектов на землю», что в ряде случаев вызвало обратный эффект. К примеру, в заброшенном форте Гарун из-за этого все турели дружно поднялись на 7 метров над землей!

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

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

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

Роман: Обычно это происходит по одной из двух причин.

1) Бывают ошибки, которые только кажутся очевидными. К примеру, все помнят проблему с божественным откровением, той самой книжкой, которая выдается в награду за победу в чемпионском поединке. Казалось, все просто: босс убит, награды нет. Как такое пропустили? На самом деле, чтобы ее не получить, надо было пройти приключение c рейтингом «D». В нормальной ситуации это невозможно (убийство босса это уже минимум «C»), но оказалось, что одно из случайных «дополнительных заданий» не повышало оценку за прохождение, из-за чего в этом приключении стало возможно и босса убить, и получить «D».

2) Ошибка была найдена, но признана некритичной для текущей версии. К примеру, завершая работу над новогодним праздником, мы сделали одно сюжетное задание излишне сложным. Но событие ждут все, анонс уже был, а необходимое задание большинство игроков уже завершило. Да, была вероятность, что какое-то количество игроков столкнется с ошибкой, но откладывать ради этого праздник не стали.

Как вы считаете, какие навыки или знания важнее всего для современного QA?

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

Из личных качеств можно отметить:

Умение концентрироваться. Часто приходится проверять много раз одно и то же. «Играть в игру» и «проверять игру» — разные вещи.
Внимательность, дотошность. Потенциально опасную ошибку можно выявить на ранней стадии, если заметить небольшую проблему и выяснить, откуда взялось такое странное поведение.
Увлеченность играми. Дело, которым занимаешься, должно увлекать, иначе не добиться хороших результатов.

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

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

Опишите самую забавную или самую необычную проблему, с которой вы сталкивались.

Алексей: Смешных было достаточно много (большая их часть была в ранней стадии разработки проекта). У нас есть целая страница с видео забавных багов. Один из моих любимых — это лучники, стреляющие оленями! В том случае олень использовался для отладки эффекта. Это хороший способ понять, что эффект «играется», что он повернут в нужную сторону и т.п. Естественно, оленя нужно было заменить на нормальный эффект, но это сделать забыли. И вот однажды утром перед нами предстал лучник, стреляющий оленями. Было забавно.

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

И напоследок традиционный вопрос. Что можете посоветовать всем желающим попасть в игровую индустрию? Какие навыки и личные качества необходимы?

Роман: Главное – это желание делать хорошие игры, остальное приложится.

Алексей: Играйте и старайтесь анализировать процесс. Если ваше желание действительно велико, у вас все получится.

На этом все. Если у вас появились вопросы, задавайте их в комментариях! Постараемся ответить на самые интересные из них.