Хочу в геймдев!

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

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

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

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

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

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

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

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

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