БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
QA — важнейший процесс в разработке игр. Ниже мы поделимся некоторыми вещами, чтобы сделать процесс тестирования более эффективным.
Содержание
- Поддерживайте активную коммуникацию с коллегами
- Будьте лаконичны, особенно при написании баг-репортов
- Используйте свой опыт игрока и/или разработчика игр
- Не только находите баги, но и оставляйте отзывы о различных сторонах игры
- Запрашивайте и применяйте функции/инструменты отладки там, где это целесообразно
- Помните, что ваши тесты будут улучшаться по мере того, как вы будете проводить больше времени с игрой
- Проводите тестирование по порядку, а не по сложности задач
1. Поддерживайте активную коммуникацию с коллегами
Нужно помнить, что QA — это роль поддержки. Тесное общение с разработчиками, дизайнерами, художниками и другими членами команды имеет крайне важное значение . Задавайте вопросы, чтобы понять, что вам нужно делать и на что обращать внимание, — это поможет вам эффективно справляться с задачами. Это также означает, что вся команда сможет работать быстрее и реже передавать задания друг другу.
Например, если вы принимаетесь за проект, разработка которого близится к завершению, то там будет много такого, с чем вы не знакомы. Нужно задавать вопросы, какими бы очевидными ни казались ответы. То, что кажется вам особенностью игры (фичей), на самом деле может быть ошибкой, и наоборот.
«Каждый раз, когда я падаю с платформы, я возрождаюсь в начале уровня, а не на ближайшей платформе. Так задумано или это похоже на баг?»
2. Будьте лаконичны, особенно при написании баг-репортов
QA-специалисту полезно быть лаконичным в разных ситуациях. Например, при написании тест-кейсов или даже если вы просто задаёте вопросы команде. В частности, лаконичность в баг-репортах (наряду с советом 1) поможет избежать недопонимание и частоту переписки между вами и командой разработчиков.
Важно давать как можно больше информации, ведь вы можете и не знать, насколько она полезна (тестирование — это не исправление ошибок, а их поиск и помощь в процессах, которые их предотвращают). Но эта информация также должна быть лёгкой для понимания. Если информация передается некорректно, то разработчики могут потратить время на решение проблемы, которой на самом деле нет. Это замедляет процесс разработки.
Сообщайте как можно больше информации в как можно меньшем объёме слов. Чтобы писать краткие баг-репорты, нужно помнить о некоторых вещах:
- Предоставляйте информацию в последовательности, которую легко воспроизвести. Например, Название → Шаги для воспроизводства → Ожидаемый результат → Фактический результат → Воспроизводимость → Версия → Платформа и т. д.
- По возможности используйте язык/терминологию разработчиков игр — это поможет быть описанию более конкретным. Например:
- Если вы пишете «игрок», вы имеете в виду пользователя или персонажа под управлением игрока?
- Если вы пишете «звук», вы имеете в виду звуковые спецэффекты (SFX) или музыку?
- Если вы пишете «взаимодействие между игроками», вы имеете в виду взаимодействие между моделями персонажей под управлением игроков или что-то другое?
- Включайте в баг-репорты как можно больше изображений и видео с понятными названиями. Например, вместо «Screenshot-20221125.png» используйте что-то вроде «ПрыжокНеСрабатывает-20221125.png».
3. Используйте свой опыт игрока и/или разработчика игр
Временами тестирование и поиск ошибок может показаться неким угадыванием, поэтому вам придётся смириться с тем, что вы не сможете обнаружить всё и сразу. Один из моментов, который следует учитывать, — это взгляд на игру с разных точек зрения. Попробуйте рассмотреть следующие точки зрения при поиске ошибок:
Взгляд со стороны пользователя
Человек, играющий в игры, может понять, где иногда что-то идёт не так (на основе ранее пройденных игр). Довольно часто, когда вы проводите много времени за тестированием игры, можно упустить нечто, что может увидеть пользователь (игрок) .
Например, вы уже много раз проходили уровень, поэтому точно знаете, куда идти. В платформере вам нужно двигаться только вправо, поэтому вы никогда не столкнётесь с ошибкой, возникающей при движении влево. Однако игрок может пойти в другом направлении (начать уровень, двигаясь влево).
Важнее, чем поломка игры в нештатных ситуациях, — это если игра ломается при комбинации переменных, которые с большей вероятностью могут быть замечены новым и неопытным игроком. Например, попадание в некое труднодоступное место в игре.
Взгляд со стороны разработчика
Если вы создаёте игры (или имеете некоторое представление об этом процессе), то понимание происходящего «под капотом» игры может помочь вам разобраться в том, что и где может пойти не так.
Например, иногда персонаж застревает во время возрождения (респауна) на уровне. Допустим, респаун произошел, когда персонаж был в состоянии приседа, и при новом появлении на уровне он находится в том же положении. Предыдущий опыт разработки игр мог научить вас тому, что подобные ошибки возникают часто. Поэтому вы знаете, что это нужно проверить в будущих играх с похожим геймплеем.
4. Не только находите баги, но и оставляйте отзывы о различных сторонах игры
Ваша цель — сделать продукт лучше. Поиск ошибок — лишь одна из сторон этого. Кроме того, полезно давать обратную связь о различных аспектах игры. Например:
- Вы можете обнаружить, что пользовательский интерфейс не совсем понятен.
- Какая-то часть игрового уровня вызывает негативное впечатление.
- Звуковой эффект начинает казаться монотонным и раздражающим после продолжительной игры.
Это те вещи, на которые вы можете обратить внимание. Предоставление такой обратной связи команде — ещё один способ внести свой вклад в улучшение продукта. Вы, как QA-специалист, — один из тех, кто проводит много времени с игрой, поэтому ваши отзывы особенно ценны.
Несмотря на то, что поиск решения той или иной проблемы не входит в ваши обязанности, ваши отзывы о различных составляющих игры могут быть полезны. После этого члены команды, отвечающие за соответствующие аспекты игры, могут внимательнее присмотреться к ним.
5. Запрашивайте и применяйте функции/инструменты отладки там, где это целесообразно
Может показаться, что этого нужно избегать, потому что их добавление отнимает время у разработчиков. Однако чем быстрее вы сможете проводить тестирование, тем лучше для всего процесса, потому что проблемы будут быстрее обнаружены и исправлены. В долгосрочной перспективе это удобно и особенно целесообразно для игр в стадии активной разработки, потому что вам придётся многократно тестировать новые версии. Вам определённо пригодится возможность сразу же начать тестировать нужную часть игры, без необходимости проходить её с самого начала.
Примером может служить ситуация, когда файлы сохранений не переносятся при выходе новой сборки, или когда вам приходится часто создавать новые файлы сохранений. Это может привести к тому, что вам постоянно придётся тратить много времени на повторное прохождение игры только для того, чтобы проверить что-то на нескольких последних уровнях. Если вы сталкиваетесь с подобным, стоит сообщить об этом разработчикам. Возможно, что они смогут реализовать какой-то инструмент, который разблокирует все уровни для вас, — ведь в итоге это сэкономит время всей команде.
6. Помните, что ваши тесты будут улучшаться по мере того, как вы будете проводить больше времени с игрой
Чем больше времени вы работаете над игрой, тем более детальными и точными будут разрабатываемые вами тест-кейсы. Это значит, что поначалу ваши тесты не будут идеальными и не сразу смогут охватить все особенности проекта.
Рассматривайте тест-кейсы и другие ресурсы для тестирования, как «живые документы» (living documets). То есть со временем они будут развиваться, становиться всё сложнее и обширнее. Поэтому важно держать их как можно более структурированными, даже если они могут быть недостаточно детальны с самого начала. Эти пробелы будут заполняться по мере того, как вы будете познавать игру.
Например, может оказаться, что каждый уровень в вашей игре требует определённых проверок, и один и тот же тест не подходит для всех уровней. Одной из причин может быть то, что на некоторых уровнях необходимо проверить триггеры достижений, требующих выполнения конкретных действий. Вы можете не учесть это в первой паре итераций теста на полное прохождение игры, но со временем вы обратите на это внимание и доработаете документацию.
Здесь важна структура теста, чтобы его можно было легко дополнить и при этом не нарушить порядок выполнения. Например, тест полного прохождения игры может быть ориентирован сверху вниз, разбит на разделы, которые удобно проходить по порядку. По мере выявления новых деталей, их можно будет включать в различные части теста. Например, Экран старта новой игры → Меню/Опции → Уровень 1 → Уровень 2 → Уровень 3 → DLC (дополнительный контент) → Сохранение/Проверка прогресса. Каждая секция, по сути, представляет собой небольшую группу связанных между собой тест-кейсов.
7. Проводите тестирование по порядку, а не по сложности задач
У вас может быть множество небольших задач, незначительных ошибок, которые уже исправлены, и мелких функций, которые были добавлены разработчиками в последнюю минуту и нуждаются в тестировании. Такое может произойти, когда команда приближается к релизу игры или новому патчу — в это время вы наиболее загружены. Может возникнуть желание сначала разобраться с самыми сложными или лёгкими из них, однако это может вызвать проблемы/доставить неудобства.
Выполнение заданий в том порядке, в котором они передаются вам (насколько это возможно), может положительно влиять на:
- Получение командой обратной связи по каждому пункту в кратчайшие сроки.
- Конфликты слияния (merge conflicts) в системе контроля версий. Выполнение задач согласно установленному порядку помогает этого избежать.
- Вашу загруженность (поскольку вы следуете чётко организованному процессу).
Например, вас попросили протестировать различные функции и исправления. Вы получаете их в следующем порядке:
- Исправления пользовательского интерфейса (легко протестировать)
- Особенности геймплея (сложно протестировать)
- Особенности пользовательского интерфейса (неизвестно, сколько времени займёт тестирование)
Допустим, вы уверены, что особенности геймплея будет сложнее всего протестировать, поэтому вы начинаете работать над ними раньше, чем над исправлениями пользовательского интерфейса. Это может показаться хорошей идеей, потому что сначала вы уберёте с дороги самый сложный и большой кусок работы. Однако даже если вы точно рассчитали требуемое на эту задачу время, это всё же может иметь такие последствия:
- Команда не получает своевременной обратной связи по изменениям, которые были частью исправления пользовательского интерфейса.
- Возможно, команда начала работать над смежными частями игры, например, над функциями пользовательского интерфейса. Однако, поскольку исправления интерфейса ещё не были объединены (поскольку они еще не были протестированы), могут возникнуть проблемы, которые перенесутся в новую сборку игры. Кроме того, если вы протестируете исправления интерфейса позже запланированного, может оказаться, что они конфликтуют с изменениями, недавно прошедшими слияние в системе контроля версий.
- Количество функций и исправлений, на которые нужно обратить внимание, неожиданно возрастает.
Подытожим. Хорошая коммуникация, понимание инструментов и терминологии разработки игр (или готовность учиться им) — это путь к повышению качества тестирования и эффективности. Мы надеемся, что этот список советов поможет вам в процессе разработки игр.
Перевод статьи «7 Tips to make your Game QA Testing process more effective».