class="p1">Также настоятельно рекомендуется прибегать к помощи других специалистов, искореняя субъективность видения собственного проекта и «идеальности кода», когда «тут все нормально, ничего тестировать не надо». Со временем взгляд на свой продукт замыливается, поэтому имеет смысл еще на ранних этапах производства показывать игру другим гейм-дизайнерам (на конференциях, конкурсах и других площадках), чтобы получить отзыв от профессионала, способного предложить лучшие решения.

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

Чем занимается тестировщик и виды тестирования

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

Когда тестировщик мало пересекается с гейм-дизайнерскими идеями, основная задача – проверить, выполнены ли все работы в соответствии с требованиями визионеров и создателей, подтвердить теории и опровергнуть опасения заказчика. Обычно тестировщик работает с некой сущностью: он должен убедиться, действительно ли она реализована исполнителями качественно, соответствует ли ожиданиям заказчика и здравому смыслу в целом.

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

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

Первое, над чем работают QA, – SMOKE-ТЕСТЫ. Это быстрая проверка работоспособности текущего билда: что он вообще запускается, что можно зайти в игру, создать аккаунт и пр. Задача smoke-тестирования – быстро удостовериться, что продукт функционирует, базовые функции работают и последние изменения не конфликтуют с текущей версией игры. Если проблемы начинаются уже на этом этапе, проверять что-либо дальше не имеет смысла, можно прекращать тестирование и писать разработчику, что требуется новый билд.

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

Убедившись, что ваш билд функционирует, можно переходить к ТЕСТИРОВАНИЮ ЗАДАЧ. Базовая логика тестирования – сделать так, чтобы игра работала по заявленным требованиям. Здесь все понятно: если гейм-дизайнер обозначил условия для игрового события, QA должен проанализировать и сверить полученную информацию с той, что была заявлена, и проверить, не нарушает ли она общих стандартов функционирования продукта. Такая работа занимает 70 % работы QA-специалиста: он проверяет, что конкретная задача действительно выполнена и в полном объеме соответствует описанию. Поэтому чем больше информации тестировщик получит от заказчика, тем лучше будет результат.

Не стоит чего-то утаивать: напротив, нужно дать максимум ввод-ных данных, чтобы специалист мог верно оценить объем тестирования, а не тратить время на «найди то, незнамо что». Чтобы это работало эффективно, разработка должна вестись в рамках конкретных задач. Например, если вы используете Trello, можно перенести задачу в колонку Need test, откуда QA-специалист, в свою очередь, либо отправит ее в Done, либо сообщит об обнаруженных дефектах через баг-репорт и отправит карточку на доработку.

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

Есть еще РЕГРЕССИОННОЕ тестирование, направленное на поиск ошибок в уже проверенных участках кода. В любом проекте есть какое-то слабое, проблемное место. Как известно, баги – сущность живучая, поэтому нужно убедиться, что не вернулись ошибки, которые были исправлены ранее. Предположим, нам стало известно о некой архитектурной проблеме, и в нашем шутере игроки постоянно проваливаются под землю. Даже если программисты на определенном этапе смогли исправить этот дефект, важно зафиксировать и определить его ключевые детали и отправить на регрессионное тестирование, то есть добавить в базовую проверку последующих версий игры, ведь такая проблема серьезно влияет на геймплей. Это позволяет заранее предупредить команду о возвращении бага, а не ждать негативных отзывов от игроков.

Это могут быть и абсолютно новые дефекты – ключевое значение имеет то, что они появились в ранее проверенной и исправно работающей части программы; такие баги могут возникнуть при любом изменении кода. Название «регрессионное» такое тестирование получило, так как в ходе него проверяют, не стала ли система хуже, не «регрессировала» ли она.

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

ГЕЙМПЛЕЙНЫЕ ТЕСТЫ организуют для самих разработчиков, директоров, журналистов и т. д., чтобы те оценили игровые механики. На любом этапе разработки важную роль играют регулярные внутренние совместные плейтесты. Когда вся команда собирается вместе, чтобы поиграть в свою игру, шанс того, что кто-то перестанет понимать, что она собой представляет, сильно уменьшается. Такие встречи мотивируют дальше работать над проектом, ведь все видят результаты собственного труда, могут сразу заметить ошибки, обмениваться идеями и мнениями.

ФОКУС-ГРУППЫ – это специально подобранная аудитория, которой мы демонстрируем игру для проверки, насколько выбранным людям понравится то, что мы предлагаем. Скажем, мы хотим показать механику сражений на мечах историческим