Отчет о дефекте (также известный как баг-репорт) – это документ, который описывает ошибку, неисправность или проблему, найденные в программном продукте, в том числе игровом. Это важный инструмент для команд разработки и тестирования, поскольку он помогает им понять, исправить и отслеживать проблемы в продукте. Это документ, который ты должен научиться разрабатывать в первую очередь. Отчет создается только для ОДНОГО дефекта.

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

1. Краткое описание (Summary)

2. Подробное описание (Description)

3. Шаги воспроизведения (Steps)

4. Ожидаемый результат (Expected Result)

5. Фактический результат (Result)

6. Критичность (Severity)

7. Приоритет (Priority)

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

Краткое описание (Summary) – название атрибута говорит само за себя. Задача тестировщика – максимально кратко и в то же время понятно описать найденный дефект. Иногда тестировщики говорят: «Всегда есть Description, где можно описать баг во всех деталях», но разработчики считают суперабилкой тестировщика именно его способность описывать баги кратко и понятно. Это объясняется простым фактом: в Jira и других баг-трекерах разработчик видит задачи списком, каждая задача представлена кратким описанием. Теперь представь, что таких задач (баг-репортов) несколько сотен, больше половины из которых непонятны без прочтения Description. Представь только, сколько времени потеряет разработчик для вникания в суть проблемы. И как он будет называть при этом тестировщика. Кроме того, при грамотном написании Summary в огромном списке задач довольно легко находить дубликаты.

Способность описать дефект в рамках поля Summary – действительно одно из главных достоинств и профессиональных навыков специалиста по тестированию. Есть несколько способов обучения этому навыку. Приведем три самых действенных и простых.

Метод «Что? Где? Когда?»

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

1. Что произошло и в чем суть неполадки?

2. Где был обнаружен дефект?

3. Когда и при каких обстоятельствах возник дефект?

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

Метод выделения ключевой информации

Весьма действенный метод, особенно когда у тебя уже есть длинное описание дефекта.

1. Попробуй описать дефект со всеми необходимыми деталями.

2. Внимательно прочитай свое описание и выдели из него ключевую информацию, то есть самые важные моменты.

3. Попробуй сложить эти ключевые моменты вместе.

То, что получится в итоге, и будет составлять Summary.

Метод тождественности атрибутов

Составь описание дефекта по следующей схеме.

1. Шаги воспроизведения

2. Ожидаемый результат

3. Полученный результат

Если все описано правильно, то «Полученный результат» и будет являться Summary дефекта. Если нужно, можешь добавить пару важных деталей.

Но вернемся к прочим атрибутам дефекта.

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

Следующие два атрибута – Шаги (Steps) и Ожидаемый результат (Expected Result) – берутся непосредственно из твоего тест-кейса[11], с помощью которого ты обнаружил дефект. Это и понятно. Разработчик должен сделать абсолютно то же самое, чтобы увидеть этот баг. О том, как проектировать тест-кейсы, я расскажу тебе чуть позже.

Фактический результат (Result) – это описание того, что ты увидел своими глазами, выполнив необходимые для проверки Шаги. Если он не отличается от Ожидаемого результата, мы можем быть уверены, что система функционирует как нужно. Любое отличие между Ожидаемым и Фактическим результатом будет означать только одно: перед тобой дефект.

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

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

Про эти два важнейших атрибута я расскажу более подробно чуть ниже.

Могут быть и другие атрибуты баг-репорта, крайне полезные для разработчика.

Повторяемость (Reproducibility)[12] – этот атрибут важен для определения Приоритета дефекта и показывает, насколько часто появляется дефект в определенных обстоятельствах, определяет его «назойливость». Он также дает понимание, что то, что ты описываешь, – действительно баг, а не однократный сбой неясной этимологии. С этим атрибутом необходимо быть очень внимательным. Часто тестировщики не видят разницы в оформлении повторяемости в процентном или числовом отношении. Однако есть разница, если баг имеет повторяемость 20 % (из 5 проверок) и когда он повторяется 2 из 5 раз. В первом случае повторяемость дефекта будет равной 1 из 5 раз, а во втором – в два раза чаще.

Дарья Касиманова, QA-менеджер Saber Interactive

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

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

Вложения (Attachments) – это материалы, иллюстрирующие проблему.

Для начала посмотрим, что именно может быть использовано в качестве Вложений.

1. Изображения

2. Видеофрагменты

3. Логи (файлы системных журналов)

4. Звуковой файл

5. Другие файлы

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

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

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

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

Вложения в баг-репорте обязательны и играют важную роль по нескольким причинам.

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

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

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

• Логи и дампы памяти могут предоставить ценную информацию о состоянии системы в момент возникновения ошибки. Это помогает разработчикам понять, какие процессы или условия могли способствовать возникновению проблемы.

• Вложения помогают обеспечить более четкое и эффективное общение между теми, кто сообщает о баге, и теми, кто его исправляет. Это сокращает количество необходимых вопросов и уточнений.

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

• В целом вложения делают баг-репорты более информативными, упрощают и ускоряют процесс их обработки и увеличивают шансы на то, что баг будет успешно исправлен.

Нина Резниченко, QA-менеджер Saber Interactive

В идеале после чтения саммари бага и просмотра вложения (прикрепленный файл – скриншот, видео, логи и т. д) должно быть понятно, в чем проблема и как ее фиксить. Если при взгляде только на прикрепленный к багу файл понятно, в чем баг, то поздравляю, вы достигли вершины искусства. Не стоит пренебрегать скринами даже, казалось бы, в простых проблемах. Сделать скрин и прикрепить его к багу занимает всего пару секунд, а бонус выходит +100 к ясности.

Часто можно встретить баги с названиями вроде «Неправильное отображение иконки». У меня к таким багам сразу вопрос: что значит неправильное? А как правильно? Или «Работает некорректно». Хорошо, а как корректно? Почему бы сразу не написать, в чем проблема, избегая выход на такие абстракции?

Уточнив, в чем проблема (например, иконка отображается лоу-резно, с темными краями и т. д.), и прикрепив дополнительно скрин или видео, вы сэкономите время как себе (потому что за уточняющим вопросом придут к вам), так и исполнителю.

Мой совет: всегда старайтесь уйти от широких понятий или давайте конкретные числа и данные, если все же их используете. Например, вы описываете баг про Low FPS. Укажите в цифрах, сколько это Low – 10–15 (5 и т. д.)? Кому-то и 60 мало:)

Суммируя сказанное выше, любая ошибка, найденная тестировщиком, должна быть описана как можно подробнее. Для этого в отчете о дефектах, который может представлять собой как обычную таблицу, так и задачу типа «баг» в одном из баг-трекеров[13], у любой ошибки есть атрибуты, которые необходимо заполнить. Эти сведения должны помочь тому, кто будет исправлять эту ошибку, сделать это наиболее рациональным способом.

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

1. Степень влияния на работоспособность игры, то есть насколько сильно дефект затрудняет игровой процесс.

2. Степень заметности для пользователя – насколько дефект заметен для большинства игроков[14].

3. Степень влияния на удобство использования – насколько дефект ухудшает удобство игрового процесса.

Только анализ всех этих факторов вместе позволит получить правильное представление о критичности бага.

С точки зрения критичности принято выделять следующие виды дефектов.

Blocker (Блокирующий, Блокер) – самый критичный и самый заметный дефект, который вызывает самые большие трудности при использовании игрового продукта. Более того, блокер, как правило, – это такой дефект, который не позволяет нам больше играть, и обойти это препятствие не представляется возможным. Помнишь синий экран смерти в Windows? Вот это как раз пример блокера! Другими примерами могут стать «вечный» фриз, утечка памяти и многие другие неприятные вещи. Но есть и хорошая новость для тестировщика: ты никогда не пропустишь блокер, если увидишь его, это просто нереально. Ты внезапно теряешь контроль над игровым процессом и получаешь его назад только после полной перезагрузки. Хотя и в этой ситуации, если подходить строго, блокеры можно разделить на софтлок (softlock) и хардлок (hardlock).

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

Хардлок – это ситуация, при которой игра перестает воспринимать любые команды ввода и единственный выход из ситуации – перезагрузка.

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

Critical (Критический) – этот баг очень похож на предыдущий. Он тоже может превратить игровой процесс в кошмар и выглядит как начало Армагеддона, но, в отличие от предыдущего дефекта, предполагает некий способ выхода из ситуации. Например, появляющееся каждые пять минут окно с ошибкой, останавливающее игровой процесс, можно закрыть, нажав Alt+F4, и продолжить игру.

В той же комнате, в которой ты оказался в первый раз, кроме запертой двери есть окно, в которое можно с трудом выйти. Люди не должны выходить в окна, но это альтернативный приемлемый выход из ситуации, не так ли?

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

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

Minor (Незначительный). Обычно такие баги не относятся к функционалу игры или влияют на него в очень незначительной степени. Тем не менее баг заметен и очевиден для тестировщика и для пользователя. Чаще всего так определяется дефект, который затрудняет нам удобство использования игрового продукта, раздражает игрока или связан с недочетами интерфейса. Очень часто в эту категорию попадают мелкие рендер-баги[15], отсутствие коллизий с какими-то неважными объектами на сцене и т. п.

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

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

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

Обнаружив дефект и оценив его критичность, необходимо понять, как быстро этот дефект должен быть устранен. Это важный вопрос, поскольку не всегда устранить дефект можно немедленно. Более того, обычно тут же это сделать не удается никогда, потому что разработчики заняты разработкой новых версий игры (билдов) или функционала. Поэтому нужно понять, как требование по немедленному устранению дефекта повлияет на весь процесс разработки.

Как правило, приоритет дефекта бывает трех видов.

1. High (Высокий)

2. Medium (Средний)

3. Low (Низкий)

и он часто (но не всегда) совпадает с критичностью. Например, Блокирующий или Критический дефект будет в обычной ситуации иметь самый высокий приоритет для исправления. И если с определением приоритета для упомянутых дефектов трудностей не возникает, то с дефектами другой степени критичности могут быть проблемы. Для определения приоритета исправления дефекта необходимо учитывать следующие факторы или их совокупность.

• Финансовые потери компании

• Репутационные потери компании

• Воспроизводимость дефекта

• Увеличение сроков разработки либо трудозатрат

Установка приоритета – это довольно сложный процесс, который отличается от определения критичности и относится к техническим аспектам. Приоритет вполне легко может быть определен по совокупности технических параметров. Давай рассмотрим несколько примеров.

Пример № 1. В игре только у одного персонажа имеется изображение свастики. Это дефект локализации; нужно определить его критичность и приоритет.

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

Но мы планируем выпуск этой игры на рынок Германии, где изображения «антиконституционной символики», к которой относится вся символика национал-социалистической партии, запрещены под угрозой уголовного наказания. Так что приоритет меняется: такой дефект должен быть исправлен немедленно.

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

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

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

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

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

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

1. Персонаж погибает

2. Противник не атакует

3. Транспортное средство отказывается ехать[16]

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

1. Непредоставление точной информации, которая может помочь в устранении дефекта.

2. Непредоставление критически важной информации, например в какой тестовой среде проводилась проверка.

3. Обнаружение дефекта в функционале, не предназначенном для тестирования.

4. Предоставление в любых полях баг-репорта недостоверной информации.

5. Отчет содержит сленговые и жаргонные слова, а также различные аббревиатуры и термины, понятные не всем.

6. Дефект содержит критику в сторону разработчиков.

7. Выставление заведомо неверного уровня критичности.

8. Отчет содержит большое количество языковых ошибок, не позволяющих понять смысл.

9. Непредоставление вложений: логов, дампов, скриншотов, без которых разработчик не видит дефекта.

10. Тестировщик не смог убедить разработчиков в критичности дефекта.

Пример № 1

Пример № 2

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

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

В разработке программного обеспечения, в том числе и игрового, традиционно применяются три подхода.

1. Классические модели

2. Гибкие модели[19]

3. Сочетания классической и гибкой моделей

У каждого из подходов, как часто бывает в жизни, есть свои достоинства и недостатки. Давай разберем каждый из них подробнее.

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

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

С точки зрения сути подходов (философии) к управлению проектами их принято разделять на две группы: классические и гибкие. Хотя это весьма условное деление, ведь классическое может быть весьма гибким, а гибкое рано или поздно становится классическим. Тем не менее в таблице ниже приведены существенные отличия этих двух групп.

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

Последовательная модель (на примере Waterfall model и V model)

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

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

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

Использование этой модели предполагает знание ее плюсов и минусов.

Водопадная модель

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

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

Другой минус использования «водопадной» модели – высокая цена ранних ошибок. Другими словами, если на этапе тестирования ты обнаружишь дефект, связанный с проектированием, то все работы по разработке, вероятно, придется выполнять заново, поскольку функционал был разработан на ошибочных требованиях. Я говорил о таких ситуациях выше. Как же с ними можно бороться?

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

V-модель

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

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

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

Спиральная модель (Spiral Model)

Спиральная модель

Спиральная модель – это концептуальный подход, в котором предполагается глубокий анализ разнообразных рисков.

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

1. Определение целей

2. Оценка рисков

3. Разработка и тестирование

4. Планирование

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

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

Совершенно противоположный по идеологии подход к разработке принято называть гибким (Agile). Считается, что он изначально появился как ответ на невозможность использования «водопадной» модели в сложных творческих проектах по разработке ПО. Один из центральных постулатов Манифеста Agile, на положениях которого основана вся философия гибкой разработки проектов, таков: изменения в проекте допустимы на любой стадии реализации. Для менеджеров – приверженцев классического подхода, как ты понимаешь, это делает управление проектом похожим на ад: все бюджетирование «идет лесом», сроки реализации проекта туманны, требования неясны. Но, если вдуматься, это и есть признаки типичного проекта по разработке видеоигры. Отчасти это и делает применение «гибких» методик в сфере разработки игр весьма распространенным.

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

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

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

Гибкая модель (на примере Scrum)

Когда речь заходит о гибких методологиях, практически у 90 % менеджеров в голове возникает одно слово – Scrum. Это одна из наиболее популярных итерационных моделей разработки ПО, относящихся к Agile. Методология хорошо задокументирована, и ты легко найдешь подробный материал для ознакомления. Я лишь кратко постараюсь осветить основные положения и процессы.

Основных ролей в Scrum три.

1. Владелец продукта (Product owner)

2. Команда разработки (Development team)

3. Scrum-мастер (Scrum master)

Владелец продукта (ВП) – это заказчик или представитель заказчика. Он обладает техническими знаниями в такой мере, чтобы формулировать требования к разрабатываемому продукту. Владелец продукта отвечает за формирование видения (vision) продукта и принятие окончательных решений. Инструмент ВП – Журнал Продукта (Product Backlog), который используется для записи требований к продукту в порядке их приоритета. В этом же журнале прописываются критерии готовности реализации требований (Definition of Done).

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

Команда разработки (КР) состоит из специалистов, задача которых – реализация задач по проекту и разработка финального продукта. Согласно идеологии Scrum к команде предъявляются следующие требования.

1. Команда должна быть способна к самоорганизации (и это понятно, ведь начальника в виде менеджера проекта или продюсера над ними нет).

2. Специалисты должны обладать всеми необходимыми навыками для реализации продукта, то есть команда должна быть многофункциональной.

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

При этом рекомендуемый размер команды – 7 ± 2 человека. Считается, что у команды большего размера неизбежно возникнут сложности с коммуникацией. Если же размер команды меньше, то она может не обладать всеми необходимыми компетенциями для реализации проекта.

Инструмент команды – Журнал Спринта (Sprint Backlog), в котором требования ВП преобразуются в конкретные задачи.

Итерация (стадия, временной отрезок), в рамках которой производится разработка продукта в Scrum, называется спринтом (Sprint). Спринт обычно составляет 1‒4 недели (40‒160 рабочих часов), и его продолжительность неизменна на всем протяжении разработки. Изменение продолжительности спринтов неизбежно приводит к потере командой рабочего ритма и снижению эффективности ее работы. Каждый спринт должен заканчиваться новой версией продукта (инкремент).

Итерация в Scrum

Спринт начинается с планирования, в ходе которого команда должна найти ответы на два вопроса: 1) какой объем работы можно выполнить в предстоящем спринте и 2) как она будет выполняться.

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

В течение спринта команда собирается на ежедневные «летучки»-совещания (Daily scrum), чтобы обсудить текущие проблемы.

Спринт завершается Обзором Спринта (Sprint Review), в рамках которого Владелец продукта предъявляет инкремент, то есть новый билд продукта с разработанным в рамках спринта функционалом.

После этого команда проводит Ретроспективу Спринта (Sprint Retrospective). На ней определяются области работы, требующие улучшений.

Такой порядок повторяется в конце каждого спринта.

Один из важнейших показателей при использовании Scrum – ритм работы команды, то есть скорость, с которой выполняются задачи без перенапряжения сил. Для поддержания рабочего ритма важно:

1. обеспечить фокус команды на задачах проекта без отвлечения на посторонние задачи;

2. правильно оценивать время выполнения задачи;

3. отслеживать прогресс по спринтам.

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

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

Пример диаграммы сгорания

Кроме того, несмотря на кажущуюся простоту, Scrum часто используют неправильно. Для таких случаев существует даже особое понятие – Ограниченный Scrum (ScrumBut); это использование лишь части принципов Scrum. Такой подход приводит к существенному ухудшению производительности по сравнению даже с отсутствием методологии. Классические примеры ScrumBut:

1. отсутствие критериев готовности (Definition of Done);

2. неодинаковая длительность спринтов;

3. длительность спринта более 4 недель;

4. проведение «летучек» (Daily Scrum) не каждый день;

5. отсутствие ретроспектив и т. д.

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

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

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

Разработка в разных ветках (branching) – это методология, которая позволяет команде разработчиков работать над различными версиями кода в отдельных ветках, которые могут быть слиты в основную (main branch) после того, как функциональность будет разработана и протестирована. Это позволяет разработчикам изолировать свои изменения от других членов команды, ускорить процесс разработки и снизить вероятность конфликтов в коде.

Ветки могут создаваться для различных целей.

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

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

3. Стабилизация результата. Когда стабильно работающий билд продукта отправляется заказчику или просто сохраняется как резервная копия для возможности возврата к ней в будущем. При этом работа над продуктом продолжается в основной ветке.

4. Тестирование и эксперименты. Когда нужно протестировать какую-то идею или провести эксперимент, команда может создать отдельную ветку, чтобы проверить идею и не повлиять на основной код.

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

Разработка в разных ветках – стандартная практика в большинстве команд разработки, особенно с большим количеством разработчиков. Это позволяет ускорить процесс разработки, улучшить качество кода и снизить вероятность конфликтов в коде.

Пример ветвления при разработке

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

Преимущества

• Изоляция изменений. Каждая ветка – это изолированная линия разработки, что позволяет разработчикам работать над изменениями без влияния на другие части кода. Это позволяет снизить количество конфликтов при слиянии изменений в основную ветку.

• Параллельная разработка. Можно работать над разными частями приложения одновременно, что ускоряет процесс разработки.

• Управление версиями. Каждая ветка может быть отдельно версионирована, что упрощает управление версиями приложения.

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

Недостатки

• Увеличивает сложность управления кодом, поскольку каждая ветка может иметь свои особенности и уникальные изменения.

• Увеличивает необходимость в тестировании и интеграции каждой ветки перед ее объединением с основной веткой.

• Может привести к проблемам слияния веток, если различные члены команды вносят изменения в одни и те же файлы.

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

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

В зависимости от ситуации и проекта возможны разные подходы к разработке плана тестирования. Существуют стандарты, подробно описывающие план тестирования и его содержание, – международный стандарт ISO/IEC/IEEE29119–3:2013 и российский ГОСТ Р 56922–2016. Рекомендую тебе ознакомиться с ними более подробно, лишним это точно не будет. Хотя нужно сказать, что в подавляющем большинстве случаев тебе не придется писать многостраничные планы, соблюдая все требования стандартов. Достаточно хорошо проработанный план может занять всего 2–3 страницы и при этом быть отличным руководством для работы.

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

1. Что именно нужно тестировать? (Нужно описать объект тестирования, то есть сам игровой продукт. Это не только поможет быстрее адаптировать нового члена команды, но и во многом заменит отсутствующую документацию.)

2. Что будет тестироваться? (Тот функционал игры, который ты собираешься протестировать с максимальным покрытием.)

3. Как именно будет проводиться тестирование? (Нужно описать виды тестирования и типы проверок в рамках избранной стратегии тестирования и метрики для осуществления эффективного мониторинга.)

4. Когда именно будете проверять? (Это фактически информация о сроках и этапах тестирования.)

Кроме этого, в плане обязательно нужно отразить информацию о:

1. критериях начала и окончания тестирования;

2. программно-аппаратной части, используемой для тестирования (тестовой платформе);

3. потенциальных рисках продукта и проекта и плане управления ими.

Ну, и, конечно, тест-план должен учитывать и быть основанным на документе более высокого порядка – проектном расписании. Если изменения вносятся в него, то должен поменяться и тест-план.

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

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

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

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

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

Итак, ты подробно описал игру для понимания ожидаемых результатов, определил важные и второстепенные функциональные и нефункциональные требования, которые должны быть плотно, но без избыточности покрыты проверками в рамках выбранной стратегии. Сейчас самое время решить вопросы, связанные с определением области покрытия и возможностью проводить качественный мониторинг использования проверок. Есть много средств, позволяющих в наглядном виде отслеживать «здоровье» проекта, то есть его соответствие первоначальному плану. Их использование может быть обосновано применением различных моделей разработки или опытом менеджера, но все они применяются для упрощения процесса мониторинга. Один из таких инструментов, часто применяющийся в тестировании, – матрица трассируемости (Traceability Matrix).

Матрица трассируемости – это, по сути, таблица, в которой отображается связь тестируемых сущностей или проектных требований и спроектированных для такой проверки тест-кейсов. На пересечении соответствующих строки и столбца устанавливается отметка, означающая, что функциональность или выполнение требования покрывается тест-кейсом. Обычно матрица используется, когда имеются четко сформулированные требования, и проверка выполняется с целью тестирования выполнения программным продуктом этих требований. Но в случае с тестированием игр в качестве требований могут использоваться ожидания пользователя (и, естественно, твои как опытного пользователя и знатока игр) от игрового функционала, то есть так называемые «пользовательские истории» (user stories). Они могут быть объединены в укрупненные группы на основании определенной логики. Например, могут проводиться объединенные проверки функционирования оружия персонажа, состоящие из нескольких тест-кейсов (см. таблицу). Как правило, эти «пользовательские истории» используются в качестве атрибута «ожидаемый результат» проектируемого тест-кейса. Но об этом позже.

Матрица трассируемости – крайне полезная штука, поскольку дает нам ответ на два важных вопроса.

1. Остался ли в игре непокрытый тест-кейсами функционал или области?

2. Не будет ли проводиться избыточного тестирования, если по одному требованию / «пользовательской истории» есть несколько пересечений?

Она позволяет:

• визуализировать актуальное состояние реализации проекта;

• разбивать требования на более мелкие (атомизировать требования) и структурировать их;

• отслеживать, есть ли требования, на которые еще не запланирована разработка;

• отслеживать, реализовано ли требование в данный момент;

• отслеживать, покрыто ли требование тест-кейсом;

• наглядно отображать приоритизацию требований.

Кроме того, матрица трассируемости в чуть более сложном виде позволяет проследить связь между задачами разработчика, требованием / «пользовательской историей», приоритетом его реализации в проекте, критериями приемки и тест-кейсом для проверки его функционала. Это существенно упрощает управление проектом и экономит огромное количество ресурсов.

При разработке матрицы трассируемости можно выделить следующие этапы.

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

2. Второй этап – общение с командой разработки и проставление в матрицу задач на разработку к соответствующим требованиям. В результате получается трассируемость требований и задач на разработку. На этом же этапе устанавливаются критерии приемки реализованных требований и приоритет требования в проекте.

3. Третий этап – разработка тест-кейсов. Она проводится непосредственно перед тестированием.

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

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

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

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

В плане тестирования отражаются еще два важных критерия – начало и окончание тестирования.

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

Ты скажешь: «А что тут сложного? Берем проект и начинаем работать!» Хотелось бы, чтобы все в жизни было так просто, но как говорил Ежи Лец: «В действительности все совершенно иначе, чем на самом деле». Представь, что в палату заходит хирург и между ним и медсестрой в присутствии пациента происходит следующий диалог.

Хирург: Ну что? Мне все ясно! Будем оперировать.

Медсестра: Начинаем готовить пациента к операции?

Хирург: А чего тут готовить? Давайте скальпель, здесь все и сделаем.

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

Ниже приведены критерии начала тестирования.

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

2. Наличие спецификаций/требований к продукту, «пользовательских историй» или моделей, если используется стратегия тестирования на основе моделей.

3. Готовность самого объекта тестирования и функционала, который требует проверки. Согласись, что тяжело тестировать то, чего еще нет. Если разработчикам не удалось создать запланированный функционал, тестировщики не смогут его проверить, как бы ни хотели.

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

С окончанием тестовых активностей тоже должна быть ясность. Ниже приведены его критерии.

1. Все запланированные тесты выполнены.

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

3. Подтверждение соответствия продукта установленным критериям. То есть тестирование подтверждает, что продукт функционален, надежен, безопасен и т. д.

4. Превышение бюджета.

5. Истечение срока, отведенного на тестирование.

6. Решение заинтересованных лиц о выводе продукта на рынок.

7. Закрытие проекта.

Представь, что ты решил сделать ремонт в квартире. Что тебе для этого понадобится? Деньги для покупки материалов? Инструменты? Время для проведения ремонта? Помощники? А что случится, если чего-то из списка выше нет? Или есть, но недостаточно? Добьешься ли ты цели при отсутствии или недостатке ресурсов? Вряд ли.

Ресурсы – это источник покрытия проектных нужд. Они могут быть разными, и они требуют тщательного планирования.

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

• конкретных исполнителей задач;

• длительности задачи с учетом ограниченной доступности ресурсов;

• потребности в ресурсах в тот или иной период исполнения проекта;

• календарный график с учетом ограничений (недостаточности) ресурсов.

Проект по тестированию игрового продукта не может быть реализован без:

1. трудовых ресурсов – это команда тестировщиков и другие специалисты, участвующие в проекте;

2. материальных ресурсов – это оборудование, программы, мебель, коммунальные услуги и т. д.;

3. финансовых ресурсов – это те денежные средства, на которые приобретаются почти все остальные виды ресурсов;

4. информационных ресурсов – вся документация, требования и т. д., а также информация, получаемая из других источников, в том числе на различных планерках;

5. временных ресурсов.

Кроме того, все ресурсы могут быть рассмотрены с точки зрения их способности к воспроизводству. Здесь, как ты видишь, практически все ресурсы воспроизводимы: мы можем их приобретать, заменять, одалживать и т. д. Только один ресурс не является воспроизводимым: он дается в абсолютно одинаковом количестве всем и не может быть приобретен или одолжен где-то. Этот ресурс – время.

Воспроизводимые ресурсы могут быть внутренними и внешними.

На ресурсы можно смотреть по-разному

Поговорим о разных ресурсах подробнее.

Трудовые ресурсы

Трудовые ресурсы – это ты и твои коллеги, а в широком смысле все работающие над проектом люди. Я не буду уделять много времени вопросу планирования трудового ресурса для проекта; об этом ты подробнее можешь прочитать в специальной литературе. Отмечу только, что нужно понимать, что трудовой ресурс на проекте, как и почти любой другой ресурс, обладает двумя важными характеристиками.

1. Количественной. Сколько специалистов нужно привлечь для реализации проекта?

2. Качественной. Какими знаниями и навыками должны обладать эти специалисты?

Обе они должны учитываться при формировании команды проекта.

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

Зависимость производительности команды от времени формирования

1. Формирование

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

Производительность команды на этом этапе довольно низкая.

2. «Штормовая»

Это этап появления первых конфликтов, которые, если ими не управлять, станут для группы последними.

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

Производительность команды на этом этапе очень низкая.

3. Нормирование

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

Производительность команды на этом этапе – средняя с тенденцией к росту.

4. Деятельность

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

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

Производительность команды на этом этапе на пике.

5. Дезинтеграция

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

Производительность команды на этом этапе – высокая с тенденцией к снижению.

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

Материальные ресурсы

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

• Аппаратное обеспечение и комплектующие

• Программное обеспечение

• Средства связи

• Рабочее место сотрудника

• Объекты бытового назначения и т. д.

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

Инструменты бывают разные. Например, шуруп можно вкрутить отверткой, а можно электрическим шуруповертом – и это будет намного быстрее. Поэтому тебе необходимо понимать, какой «инструмент» нужен в каждом конкретном процессе проекта.

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

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

При планировании себестоимости[20] проекта нужно учитывать необходимые для его реализации материальные ресурсы.

Временные ресурсы

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

При планировании проекта нужно учитывать то, что время – невоспроизводимый ресурс, правильно учитывать время выполнения задач и связанные с ним риски.

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

Ниже приведены методы определения времени, необходимого для выполнения задачи.

1. Экспертная оценка, основанная на опыте (если команда работала на аналогичных проектах и выполняла похожие задачи, то в рамках планирования время для выполнения задачи может быть оценено исходя из опыта членов команды или самого руководителя тестирования).

2. Метод оценки по трем точкам (дается оценка реализации задачи с точки зрения времени по трем сценариям – пессимистичный (П), оптимистичный (О) и средний (С)). Оценка по всем сценариям дается с использованием экспертного метода (п. 1) и выражается в часах или днях. Затем полученные значения подставляются в формулу (П+О+4С)/6. Такая формула позволяет с одной стороны учесть возможные позитивные и негативные сценарии, а с другой – сгладить их влияние и получить более реальное значение оценки.

3. Оценка по аналогиям (в данном случае оценка проводится путем сравнения задачи с аналогичной из прошлого опыта команды или руководителя тестирования).

4. Метод триангуляции (часто используется в моделях гибкой разработки, таких как Scrum). Этот метод похож на предыдущий (п. 3), но сочетает в себе два подхода: метод аналогий и экспертную оценку. Задачи разбиваются на три типа:

• мелкая;

• средняя;

• крупная.

Каждой из них присваивается некоторое количество баллов. Например, мелкая – 1 балл, средняя – 3 балла, крупная – 5 баллов. При этом 1 балл равен некоторому количеству времени. Затем команда берет на себя обязательство по выполнению задач на некоторое количество баллов в течение одной итерации и в соответствии с этим строится диаграмма сгорания (Burndown Chart).

Информационные ресурсы

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

Информация – это то, что помогает мониторить и контролировать работы по проекту на всех его этапах. Обмен информацией происходит в рамках коммуникации между всеми участниками проекта и не только (о том, как это происходит и что получается, если коммуникация осуществляется неправильно, я расскажу ниже).

В рамках проекта тестировщик взаимодействует (получает и передает устную и письменную информацию) с разными специалистами.

• Разработчики (программисты, художники, гейм-дизайнеры, звукоинженеры, переводчики и проч.)

• Менеджеры проекта и продюсеры

• Руководители проектных групп (лиды)

• Коллеги, внешние эксперты

• Другие заинтересованные лица

Вся получаемая и передаваемая информация обладает важными свойствами.

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

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

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

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

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

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

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

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

5. Достоверность. Информация может считаться достоверной, если она отражает реальную ситуацию. Достоверность информации очень сильно влияет на качество принимаемых решений. Примеры недостоверной информации – дезинформация (преднамеренное искажение) и искажение в результате воздействия «помех».

В требованиях есть упоминание о том, что персонаж, принимающий участие в одной из военных операций Второй мировой войны, вооружен автоматом АК-47. Это требование не может быть достоверным, поскольку это оружие было принято на вооружение только в 1949 году, то есть через несколько лет после окончания войны.

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

Финансовые ресурсы

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

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

Для начала нужно хорошо понимать, что такое риск и чем он опасен. Риск может быть определен как возможность возникновения события или ситуации, которая выражается в нежелательных последствиях или потенциальной проблеме. При этом уровень риска можно определить через вероятность события и серьезность последствий (критичность).

Вероятность – это степень возможности наступления некоторого события, зависящая от разных факторов, к которым можно отнести:

• сложность технологии и команд;

• личностные проблемы и проблемы подготовки среди членов команд;

• конфликт внутри команды;

• слабое управленческое или техническое руководство;

• время, ресурсы, бюджет и давление менеджмента;

• отсутствие мероприятий по обеспечению качества;

• высокие темпы изменений;

• высокий темп выявления ранних дефектов.

Критичность – серьезность эффектов для пользователей, потребителей или других заинтересованных лиц. Факторы, влияющие на воздействие рисков проекта и продукта, включают:

• частоту использования затронутой функции;

• критичность функции для достижения целей;

• ущерб репутации;

• потенциальные финансовые потери;

• отсутствие разумных обходных путей и др.

Наша задача в период проведения тестовых работ – управление возможными рисками, которое проходит следующие этапы.

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

Идентификация рисков

Цель этого этапа – выявить некоторое количество неизвестных рисков проекта. Часто в управлении рисками вероятность возникновения и критичность риска рассматривается с точки зрения «причина – риск – эффект».

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

Анализ рисков

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

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

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

Карта рисков

Должна быть определена граница для критичности рисков. В примере выше эта граница определена как 6 баллов и выше. То есть риски, оцененные выше 6 баллов, рассматриваются как значительные.

Планирование рисков

Цель этого этапа – создание стратегии управления риском, которая устранит или уменьшит его последствия. Есть три основные стратегии.

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

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

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

Мониторинг и контроль рисков

Мониторинг и контроль рисков – это постоянный процесс поддержания информации о рисках в актуальном состоянии, который в упрощенном виде выглядит как:

• выполнение ревизии списка рисков, обновление их оценки и обновление устаревших планов;

• выявление случившихся рисков, принятие решения о внедрении запасных планов и обновление плана тестирования.

Тест-кейс (он же контрольный пример в ГОСТе, он же тестовый случай и т. д.) – это алгоритм действий для получения ожидаемого результата, включающий начальные условия и входные данные для проверки.

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

Во время этапа проектирования условия тестирования преобразуются в тест-кейсы и наборы тест-кейсов (тест-суитов). Таким образом, анализ и планирование отвечают на вопрос «Что тестировать?», а проектирование – «Как тестировать?».

Проектирование базово включает в себя:

• проектирование и приоритизацию тест-кейсов и наборов тест-кейсов;

• проектирование тестового окружения и определение необходимой инфраструктуры и инструментов.

На этапе проектирования и в последующем тестировании в качестве самостоятельного инструмента могут быть использованы чек-листы.

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

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

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

Чек-листы – важный инструмент для тестировщиков, который помогает им более эффективно проверять продукт на соответствие требованиям и выявлять ошибки и недочеты, что улучшает качество продукта.

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

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

Объективность. Используя чек-лист, тестировщик имеет точные критерии для оценки продукта. Это уменьшает вероятность субъективного восприятия и позволяет проводить более объективные оценки.

Систематизация. Использование чек-листа обеспечивает структурирование процесса тестирования и упорядочивает проверку каждого пункта.

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

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

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

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

Как и остальные документы тестирования, тест-кейсы имеют свою структуру и основные атрибуты.

• Идентификатор (ID) – номер кейса.

• Приоритет (Priority) – степень необходимости прохождения тест-кейса. Может варьироваться от «Умри, но выполни» до «Забей», потому что на каждом проекте названия и важность этого атрибута будут определяться индивидуально. Приоритет тест-кейсов помогает оценить жизнеспособность продукта. Например, три непройденных тест-кейса при проверке элементов интерфейса, имеющих низкий приоритет, не так критичны, как один тест-кейс, проверяющий загрузку клиента игры.

• Название (Title). Необходимо написать так, чтобы другим специалистам было понятно, о чем речь и что будет проверяться.

• Предусловия (Precondition) – состояние игры, необходимое для начала проведения проверок. Например, необходимо быть залогиненным под определенным аккаунтом на сервере и должен быть выбран определенный персонаж или включен графический режим Ultra.

• Шаги (Steps). Действия, выполняемые в процессе проверок, которые должны привести к «Ожидаемому результату». То есть в буквальном смысле – Выбрать персонажа 1, перейти в окно выбора оружия, выбрать оружие 1.

• Ожидаемый результат (Expected Result). Состояние игровой системы, в которое она должна перейти. Например, при нажатии клавиши W персонаж идет вперед и т. д.

• Статус (Status) – результат проверки. Он содержит в себе обозначения вроде Passed, Failed, In Progress, Blocked, Untested.

Тест-кейсы бывают двух типов – позитивные и негативные.

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

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

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

Испечь пирожки по такому рецепту обычному человеку вряд ли получится. Из кулинарной книги 1886 года

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

1. Passed – фактический результат равен ожидаемому.

2. Failed – фактический результат не равен ожидаемому. Найдена ошибка.

3. Blocked – выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. Найдена ошибка. Или функционал не реализован и не может быть протестирован.

Пример структуры проекта (ее части)

Хорошо составленный тест-кейс можно использовать при описании бага. Конечно, его нужно будет дополнить фактическим результатом, подробным описанием и прочими атрибутами дефекта типа критичности, но шаги (STR) и ожидаемый результат (Expected Result) у вас уже готовы.

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

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

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

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

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

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

4. Обязательно прикладывай необходимые аттачи[21], особенно если без скриншота непонятно, как этот тест-кейс проходить.

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

6. Тест-кейсы должны быть простыми для понимания, см. п. 3. Тест-кейс, написанный тобой, может выполнять новый сотрудник на проекте, поэтому тест-кейсы должны быть легко читаемыми и понятными для любого тестировщика.

7. Выработай привычку пересмотра своих тест-кейсов кем-то из твоих коллег или начальников. Пусть их посмотрит лид, руководитель отдела тестирования или разработчик. Это поможет добиться понятности и лаконичности, а тебе станет понятно, что другие специалисты ждут от подобных документов.

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

При проектировании тест-кейсов необходимо подумать о возможности и необходимости применения техник тест-дизайна – методик оптимизации ресурсов при проведении тестовых активностей. Своевременное и уместное применение техник тест-дизайна помогает серьезно сократить трудозатраты и время на само тестирование.

То есть тест-дизайн – это процесс, который позволяет создать оптимальное тестовое покрытие объекта при минимально возможных трудозатратах, используя определенные техники. Давай разберем некоторые из них.

Предугадывание ошибок (Error Guessing)

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

• знание того, как приложение работало в прошлом;

• знание того, какие типы и виды дефектов традиционно допускаются во время разработки;

• знание дефектов, которые были найдены в похожих приложениях.

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

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

Причина-следствие (Cause/Effect)

Метод предполагает проверку того, что ввод комбинаций условий (причин) приводит к получению определенного ответа от системы (следствие).

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

Каждый столбец этой таблицы – по сути, готовый тест-кейс.

Эквивалентное разбиение (Equivalence Partitioning)

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

Граничные значения (Boundary Value Analysis)

Техника граничных значений основана на том предположении, что много ошибок возникает на границах эквивалентных классов. Она связана с техникой эквивалентного разбиения и поэтому часто используется с ней в паре. Часто проблемы возникают, когда возрастные категории указаны «внахлест» (например, 0–18, 18 и старше). Например, игра содержит платный контент, и игрок может приобрести внутриигровую валюту или игровые предметы за реальные деньги. При этом оплату могут произвести игроки в возрасте от 18 лет. Тестировщику будет необходимо проверить, как система обработает запрос от совершеннолетнего игрока. То есть при использовании позитивных тест-кейсов нужно проверить: «пустое» значение, значение в диапазоне 1–17 (для несовершеннолетних игроков), 18 и любое значение больше 18 для совершеннолетних. То есть граничными значениями будут 0, 1, 18, 19. Графически решение этой задачи можно изобразить так:

Есть два подхода к определению граничных значений: двухточечный и трехточечный анализ. При использовании первого мы берем одно значение внутри диапазона значений (класса эквивалентности) и одно ближайшее значение вне диапазона. При втором – два значения внутри диапазона значений и одно ближайшее вне диапазона.

Давай рассмотрим пример с проверкой поля ввода возраста пользователя.

В этом случае мы рассматриваем следующие классы эквивалентности.

1. Класс 1 – валидные значения от 18 и больше

2. Класс 2 – невалидные значения от 1 до 17

3. Класс 3 – невалидные значения от ∞ до 0

4. Класс 4 – невалидные данные (не числа)

Все эти классы делятся на три типа.

1. Класс, который имеет только нижнюю границу (Класс 1)

2. Класс, который имеет нижнюю и верхнюю границы (Класс 2)

3. Класс, который имеет только верхнюю границу (Класс 3)

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

Для Класса 1:

• верхней границы нет;

• нижние значения – 18 (внутри класса) и 17 (ближайшее вне класса).

Для Класса 2:

• верхние значения – 17 (внутри класса) и 18 (ближайшее вне класса);

• нижние значения – 1 (внутри класса) и 0 (ближайшее вне класса).

Для Класса 3:

• нижней границы нет;

• верхние значения – 0 (внутри класса) и 1 (ближайшее вне класса).

Как видно из примера выше, некоторые значения совпадают, а значит, не стоит проводить одни и те же тесты. Проверяем:

1. – 1 (проверяем Класс 3);

2. 0 (проверяем Класс 2 и Класс 3);

3. 1–17 (проверяем Класс 2 и Класс 3);

4. 18 (проверяем Класс 1 и Класс 2);

5. 19 (проверяем Класс 1);

6. буквы, спецсимволы и т. д. (проверяем Класс 4).

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

Второй вариант определения граничных значений – трехточечный анализ.

Для Класса 1:

• верхней границы нет;

• нижние значения – 18 и 19 (внутри класса) и 17 (ближайшее вне класса).

Для Класса 2:

• верхние значения – 16 и 17 (внутри класса) и 18 (ближайшее вне класса);

• нижние значения – 1 и 2 (внутри класса) и 0 (ближайшее вне класса).

Для Класса 3:

• нижней границы нет;

• верхние значения – 0 и –1 (внутри класса) и 1 (ближайшее вне класса).

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

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

При проверке условия, при котором х ≥ 18, где х – возраст пользователя с использованием двухточечного анализа, мы проверим значения 17 (негативный тест) и 18 (позитивный тест). Представь, что разработчик по ошибке поставил вместо знака ≥ просто =. Проверка в случае использования двухточечного анализа не выявила бы этой ошибки, потому что при проверке с 17 обнаружилась бы ошибка, а тест с 18 завершился бы успехом. А вот использование трехточечного анализа, при котором проверялось бы еще значение 19, эту ошибку выявил бы, потому что проверка закончилась бы ошибкой, а ее быть не должно.

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

Попарное тестирование (Pairwise Testing)

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

Давай разберем это на примере тестирования совместимости. Задача тестировщика – протестировать игру на предмет обнаружения ошибок с отдельными аппаратными конфигурациями.

Ниже приведены исходные данные для составления конфигураций.

Видеокарта (GPU)

1. AMD Radeon HD6570

2. NVidia GeForce RTX 2070

3. NVidia GeForce GTX 1060

Оперативная память (RAM)

1. 8 МB

2. 16 MB

3. 32 MB

Процессор (CPU)

1. Intel i7 4790

2. Intel Core i5-3330

3. AMD A10 7890K

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

Количество конфигураций = 3 х 3 х 3 = 27.

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

Суть ее в том, что можно взять только комбинации пар каждых значений (отмечено в таблице зеленым) вместо комбинаций всех значений. То есть мы должны найти уникальные сочетания (не повторяющиеся в других строках) значений каждой строки столбца CPU с GPU, CPU с RAM и GPU с RAM.

Примерный алгоритм составления пар может выглядеть следующим образом.

• Выбираем параметр с самым большим количеством значений.

• Составляем уникальные пары со следующим параметром.

• Сравниваем остальные параметры с последним.

• Удаляем лишние пары.

• Добавляем необходимые проверки в случае необходимости.

Но в большинстве случаев нет необходимости вручную комбинировать каждую такую пару. Можно использовать готовые программные решения, в которых нам нужно указать только параметры и значения, а дальше приложение рассчитает все само. В числе таких приложений можно назвать PICT (Pairwise Independent Combinatorial Tool) от Microsoft.

Используя их, мы получаем 9 комбинаций для проверки вместо 27. Неплохо!

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

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

Тестирование на основе сценариев использования (Use Case Testing)

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

При этом тестовое покрытие мы определяем как процент протестированных вариантов поведения к общему числу вариантов.

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

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

Ниже приводится пример способа проектирования тестовых сценариев на основе анализа сценариев использования при создании учетной записи.

Действующие лица

Пользователь, Система регистрации и авторизаци

Цель

Пользователь: зарегистрироваться в системе и начать работать

Система: внести пользователя в базу данных и идентифицировать его права доступа

Предусловие

Пользователь не имеет учетной записи в системе

Успешный сценарий:

1. Пользователь запускает систему в первый раз. Система открывает сессию пользователя и предлагает зарегистрироваться.

2. Пользователь вводит логин, пароль, должность, e-mail и контактные данные в соответствии с условиями, обозначенными над полями ввода.

3. Система проверяет, есть ли данные пользователя в базе данных.

4. Если данные о пользователе в БД не дублируются, система высылает письмо на указанную электронную почту и просит подтвердить регистрацию через e-mail. При дублировании данных система предлагает вспомнить старую учетную запись.

5. После подтверждения регистрации система создает запись в истории авторизаций (IP-адрес пользователя, логин, дата, рабочая станция) и присваивает права в соответствии с должностью.

6. Система выдает пользователю сообщение по поводу успешной регистрации (ссылка на сообщение).

7. Пользователь заходит в систему, ему доступны разделы, соответствующие его правам.

Результат

Учетная запись пользователя была создана, права соответствуют должности. Информация о пользователе появилась в БД

На этой основе создаются тестовые сценарии.

Диаграмма перехода состояний (State & Transition Diagram)

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

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

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

Давай разберем применение этой техники на примере космической стратегии, в которой мы управляем личинкой инопланетного существа.

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

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

Таблица перехода состояний

Всегда ли необходимо применять техники тест-дизайна? Кто-то из тестировщиков скажет, что нет. Но они точно необходимы, когда:

• процесс тестирования предполагает множество однотипных действий;

• мы стремимся разработать тесты, которые помогут найти наиболее серьезные ошибки;

• мы хотим минимизировать количество необходимых тестов для проверки продукта при сохранении оптимального тестового покрытия;

• мы хотим избежать лишних трат времени и денег (то есть всегда!).

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

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

1. Структурирование проверок. Последовательность выполнения тест-кейсов помогает нам проверить, например, работу приложения от его запуска до закрытия, покрывая тестами работу всего ключевого функционала.

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

3. Мониторинг и контроль прогресса выполнения работ. При выполнении тестирования мы можем ясно видеть прогресс и проблемы, возникающие при реализации проекта.

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

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

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

Еще один способ комбинирования тест-кейсов – сценарий тестирования. Это последовательные тесты, при прохождении которых можно проверить внушительный набор функций. Сценарий тестирования может (и в идеале должен) ссылаться на остальные тест-кейсы, написанные для всех функций через поле Reference. Сценарий тестирования не получится сделать, просто накидав тест-кейсов из разных категорий: почти нереально подобрать из готовых тест-кейсов последовательность так, чтобы результат прохождения одного тест-кейса становился условиями (preconditions) для прохождения следующего.

Проектирование сценариев тестирования и их объединение в тестовые наборы может происходить разными способами, но тестировщики традиционно используют для этого специализированное ПО.

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

В связи с этим, проектируя проверку качества игры, тестировщик должен держать в голове мысль о том, что соответствие спецификации и требованиям безусловно важно. Но также важно, насколько то, что игрок видит на экране, соответствует его ожиданиям.

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

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

1. Что за продукт ты собираешься тестировать? К какому жанру он принадлежит? Это позволит тебе определиться с главными областями функциональных и нефункциональных проверок.

2. Какая у него целевая аудитория? Что эти люди ожидают от игры? Это позволит понять, что ждут от продукта разные игроки в соответствии со своим игровым опытом.

3. Как собираются в него играть разные типы игроков? Это позволит сразу придумать некоторое количество характерных сценариев использования с набором тест-кейсов для каждого из них.

4. Как продукт может работать неверно в проверяемых областях? Это поможет создать наборы негативных тест-кейсов.

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

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

Активности по завершении тестирования принято недооценивать. И действительно, зачем что-то специально готовить? Все тесты выполнены. Баги найдены или не найдены. Работа завершена. Всем спасибо, все свободны.

На самом деле процесс завершения тестирования такой же важный, как и все до него. Он состоит из следующих групп активностей.

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

2. Передача «наследия». Другими словами, любые ценные продукты тестирования должны быть переданы заинтересованным лицам: дефекты в полном объеме ответственным за их исправление лицам, наборы регрессионных тестов – команде поддержки, тестовое окружение и документация – команде тестирования на стадии поддержки. Кроме того, вся документация должна быть сохранена и проверена для последующего использования и находиться в структурированном и понятном виде.

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

4. Формализация. Разработка, подписание и передача всех необходимых документов.

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

После того как подтверждение получено, нужно подготовить список материалов и артефактов тестирования, которые надо передать команде поддержки, и тех материалов, которые необходимо сохранить для использования в будущем. Почему это важно? Потому что ядро тест-кейсов не меняется при тестировании игр одного жанра. Если ты тестировал Duke Nukem, то большое количество тест-кейсов подойдет и для тестирования последнего Doom: движение персонажа, подбор оружия, стрельба, переключение оружия, его перезарядка, нанесение урона, поведение мобов и т. д. Все это будет требовать проверки в любом FPS без исключений. Так зачем каждый раз изобретать велосипед, если можно использовать лучшие практики?

По окончании тестовых активностей (а часто и по завершении разных его этапов) создаются различные документы.

1. Отчет о результатах тестирования (Test Result Report)

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

2. Отчет о выполнении теста (Test Execution Report)

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

3. Отчет о ходе тестирования (Test Progress Report)

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

4. Аналитический отчет о тестировании (Test Evaluation Report)

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

5. Итоговый (сводный) отчет о тестировании (Test Summary Report)

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

Кроме этих документов, в разных компаниях могут быть приняты и другие виды отчетности, например отчеты о прохождении «вех» проекта (MS Report), отчет, который позволяет создавать различное ПО: системы управления тестированием или баг-трекеры.

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

И, наконец, на этом же этапе готовятся формальные документы, которые необходимо передать заинтересованным лицам. К таким документам относят прежде всего отчет о тестировании (Test Result Report, TRR), где дается оценка тестируемому продукту и проекту. Первый вопрос, на который нужно дать ответ себе, – для кого создается отчет?

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

1. Разработчики. Их приоритеты – количество и критичность выявленных багов и общее состояние продукта. Информация необходима для планирования процесса разработки.

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

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

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

Для какой бы целевой аудитории ни составлялся отчет, в нем должны содержаться обязательные следующие разделы.

1. Краткое описание. В краткой форме отражает основные достижения, проблемы, выводы и рекомендации. В идеале прочтения краткого описания должно быть достаточно для формирования полноценного представления о происходящем, чтобы не читать весь отчет.

2. Состав команды – список участников проектной команды, задействованных в обеспечении качества, с указанием их должностей и ролей.

3. Срок, за который составляется отчет.

4. Описание процессов тестирования, то есть какие работы были выполнены за отчетный период.

5. Расписание тестовых работ всей команды тестировщиков и/или личные расписания конкретных членов команды.

6. Статистика по дефектам. Это таблица, в которой представлены данные по обнаруженным за все время существования проекта дефектам. Как правило, в этот же раздел добавляется график, отражающий такие статистические данные.

7. Критичные и блокирующие проблемы, а также принятые меры по их устранению.

8. Результаты регрессионного тестирования (опционально).

9. Выводы и рекомендации по принятию тех или иных управленческих решений (изменению тест-плана, запросу или освобождению ресурсов и т. д.).

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

1. Выводы нужно делать, помня о целях, отраженных в плане тестирования.

2. Выводы должны быть краткими и информативными для целевой аудитории отчета.

3. Если делаются выводы, нужно добавить рекомендации.

4. Рекомендации должны быть краткими, выполнимыми и содержащими алгоритм действий и целей, к которым эти действия должны привести.

5. Рекомендации также необходимо обосновывать.

6. Обоснование строится на объективных фактах, а не на предположениях и интуиции.

Кроме этого, на этапе завершения тестирования тебе может пригодиться умение пользоваться некоторым дополнительным ПО.

Это не отдельный этап проекта, а постоянная работа руководителя тестирования (лид, тест-менеджер) для отслеживания хода выполнения проекта по тестированию со сравнением ситуации на проекте с планом. Контроль прогресса обычно проводится на контрольных точках проекта, которые называются вехами (milestones)[23]. При этом мониторинг осуществляется в постоянном режиме с использованием специальных метрик. Метрики – это показатели, которые позволяют менеджеру делать выводы о ходе выполнения проекта и его состоянии.

Пропуск дефектов

а. Количество пропущенных дефектов (Bugs Leakage). Используется для анализа причин ненахождения дефектов.

б. Процент (%) дефектов, найденных не тестировщиками (Bugs Reported Not by Testers). Используется для анализа того, почему другие участники процесса разработки находят пропущенные тестировщиками дефекты. Это может быть признаком недостаточной квалификации специалистов по тестированию.

в. Пропуск дефектов по категориям (Bugs Leakage by Category). Необходима для анализа, в каких областях нужно развивать компетенции тестировщиков. В качестве категории могут выступать функциональные области, уровни тестирования и т. д.

Тестовое покрытие

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

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

Следование плану работ

а. Срывы сроков по задачам (Schedule Slippage). Используется для выявления среднего срока срывов начала выполнения задач и включения его в план управления рисками.

б. Отклонение от плана работ (Schedule Variance). Позволяет рассчитать величину отклонения реального выполнения работ на проекте от плана. Используется для контроля выполнения проекта.

в. Превышение трудозатрат (Estimation Changes). Используется для проверки корректности проводимых плановых оценок трудозатрат по проекту.

Дефекты в продукте по категориям

а. В этой группе представлено несколько метрик для мониторинга количества дефектов в продукте по разным категориям: критичность, функциональная область, тип тестов и т. д.

Результаты тестирования

а. Пройденные/непройденные тест-кейсы (Passed/Failed Test Cases). Показывает процент работающей функциональности, качество и стабильность продукта.

б. Запущено тестов (Executed Test Cases). Показывает процент оставшихся работ по тестированию проекта.

Работа с дефектами

а. Процент исправленных дефектов (Bugs Fix Ratio). Используется для определения процента исправленных дефектов.

б. Процент неисправленных дефектов (Bugs Reject Ratio). Используется вместе с предыдущей метрикой для определения причин НЕисправления дефектов и оценки квалификации специалистов по тестированию.

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

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

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

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

Проверки по критериям могут быть отнесены к трем базовым группам.

1. Проверка готовности (Readiness check). Объект оценивается с точки зрения формальных признаков готовности.

2. Проверка на соответствие минимальным критериям (Must-meet criterion). Проверка того, что объект отвечает минимальным требованиям (например, системным).

3. Проверка на соответствие желаемым критериям (Should-meet criterion). Проверка того, что объект отвечает желаемым (рекомендуемым) требованиям.

Если результат работ какого-либо из этапов разработки отвечает приемочным критериям, и это подтверждается результатами проверки (тестов), то веха считается пройденной и проект получает гринлайт[24] для продолжения.

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

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

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

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

Практически в любой игре есть ключевые и второстепенные механики. Ключевые механики составляют основу геймплея любой игры, ее core gameplay loop – основной игровой цикл. Именно эти механики повторяются раз за разом, и именно они должны вводить игрока в состояние потока. Поэтому их работа тестируется особенно тщательно.

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

Игровой тестировщик должен уметь отличить основные механики от второстепенных. Каждый игровой жанр, как правило, характеризуется определенным набором ключевых механик. Знание и умение выделять эти механики помогут тебе выбрать проверки для включения в smoke-тест[25], определить очередность и важность тестов. Хороший тестировщик понимает, какие базовые тесты необходимо проводить для той или иной игры, даже не видя ее.

Нам нужно понять, как классифицировать игру, чтобы выделить в ней ключевые геймплейные элементы. И вот тут есть некоторые нюансы.

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

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

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

Были выделены три основных игровых жанра по действиям, которые игроки совершают в игре.

1. Игры общения (действия связаны с получением информации, общением, изучением мира).

2. Игры действия (действия связаны с перемещением в пространстве, использованием техники и оружия).

3. Игры контроля (действия связаны с контролем, добычей ресурсов, управлением, распределением средств).

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

В таблице ниже показано, как распределяются игры по жанрам.

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

Таким образом, получив игровой продукт в качестве объекта тестирования, тебе нужно:

1. внимательно изучить схему жанров для понимания, какие ключевые геймплейные элементы будут обязательно присутствовать в тестируемой игре и к какому жанру ее можно отнести;

2. подробно описать действия игрока во время игрового процесса с точки зрения присутствующих в игре ключевых геймплейных элементов.

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

Каждое из предложений, которое вошло в твое описание, будет Ожидаемым результатом (Expected result) будущих тест-кейсов. Так ты сразу будешь понимать примерный объем работы и процент тестового покрытия. И еще до начала работ по тестированию у тебя уже будет готов некоторый объем тест-кейсов.

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

Например, в ЛЮБОМ однопользовательском FPS (first person shooter), согласно таблице и нашему опыту, пользователь может совершать следующие действия.

Функциональное тестирование (критические функциональные области)

1. Перемещаться по уровню, используя кнопки управления (в случае PC).

Описание. Перемещение персонажа в игре происходит в следующих направлениях и способами: вперед, назад, шаг влево, шаг вправо, стрейф[26] влево, стрейф вправо, прыжок, присед.

2. Подбирать разные виды оружия.

Описание. Подбор оружия, как правило, происходит, когда персонаж проходит «сквозь» него.

3. Подбирать аптечки здоровья.

Описание. Аптечка подбирается, если количество очков здоровья (HP, health points) составляет менее 100. Персонаж подбирает аптечку, проходя «сквозь» нее. При подборе аптечки количество HP в HUD (head-up display) увеличивается на количество HP аптечки, но не более 100 в общем.

4. Подбирать патроны/снаряды/ammo.

Описание. Снаряды подбираются, если их количество для определенного вида оружия составляет меньше, чем определено в игре. Персонаж подбирает снаряды, проходя «сквозь» них. При подборе снарядов количество зарядов в HUD (head-up display) увеличивается на количество зарядов ящика со снарядами, но не более установленного для данного вида оружия в общем.

5. Уничтожать разных мобов или разрушать объекты на уровнях игры.

Описание. Разный урон наносится в зависимости от типа оружия. При этом выстрел из оружия должен сопровождаться: а) анимацией оружия (отдача – recoil, перезарядка – reload), б) спецэффектом (вспышка – muzzle flash), в) звуком, синхронизированным с анимацией.

6. Проходить на другие уровни.

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

7. Получать урон от противников разного уровня, погибать и возрождаться в игре.

Описание. Разные противники наносят разный урон. Урон также зависит от типа защиты, который имеется у персонажа. Возрождение может происходить по-разному: в начальной точке или специальной точке на карте с полным здоровьем или неполным здоровьем, с сохранением добычи и инвентаря, частичным сохранением или без сохранения.

…

Функциональное тестирование (некритические функциональные области)

8. Избегать прямого контакта с неигровыми персонажами (non-player character, NPC), если это обязательно по сюжету игры.

Описание. Финальную цель игры можно/нельзя достигнуть, не вступая в контакт с NPC и мобами.

9. Не накапливать / игнорировать игровую добычу (Loot), если она не необходима для прохождения игры.

Описание. Финальную цель игры можно/нельзя достигнуть, не накапливая игровую добычу.

10. Отказаться от выполнения дополнительных заданий, если это не необходимо для достижения финальной цели.

Описание. Финальную цель игры можно/нельзя достигнуть, не выполняя дополнительные задания.

…

Нефункциональное тестирование (критические области)

1. Иметь возможность установить продукт на конкретный PC с определенными системными требованиями.

Описание. Произвести успешную установку на конкретный PC.

2. Иметь возможность использовать игровой продукт на совместимой программно-аппаратной части.

Описание. Использовать игровой продукт на какой-то из игровых платформ (PC, игровая приставка или смартфон и т. д.) со стабильным показателем FPS и т. д.

3. Сохранять и загружать ранее сохраненную игру с сохранением игрового прогресса и достижений.

Описание. Произвести сохранение игры и последующую загрузку игры с сохраненным прогрессом и достижениями.

4. Взаимодействовать с игровым продуктом, включая использование настроек продукта в пользовательском интерфейсе (UI).

Описание. Производить настройки персонажа, игрового окружения графической и звуковой подсистем, подсистемы искусственного интеллекта (ИИ) посредством графического интерфейса пользователя.

5. Использовать адаптированный игровой продукт, имеющий корректный перевод на язык пользователя.

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

…

Нефункциональное тестирование (некритические области)

6. Иметь возможность продолжить игровой сеанс на другой платформе с использованием единого аккаунта пользователя (кроссплатформенное сохранение).

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

7. Иметь возможность настраивать игру в соответствии с собственными представлениями об удобстве пользования.

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

Представим полученную схему проверки критических функциональных областей FPS (first person shooter) в виде матрицы трассируемости.

В качестве другого примера можно рассмотреть более сложный жанр – RPG.

Функциональное тестирование (критические функциональные области):

1. Игрок управляет одним или несколькими уникальными персонажами.

2. Игрок играет определенную роль своего персонажа.

3. Игрок улучшает характеристики персонажа(ей), используя очки опыта, полученные за выполнение определенных действий.

4. Игрок улучшает характеристики персонажа(ей), используя элементы снаряжения.

5. Игрок находит новые игровые области (исследует мир).

6. Игрок находит предметы и хранит их в инвентаре персонажа(ей).

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

8. Игрок выполняет сюжетные задания.

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

…

Функциональное тестирование (некритические функциональные области)

10. Игрок создает дополнительных персонажей.

11. Игрок должен планировать развитие персонажа(ей).

12. Игрок выбирает путь из нескольких вариантов.

13. Игрок воздействует на игровой мир (открывает сундуки, обыскивает убитых врагов и проч.).

14. Игровой мир воздействует на персонажа игрока (опасные зоны, ловушки и проч.).

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

16. Сюжет зависит от решений и выбора игрока. Часть этих выборов имеют последствия для сюжета.

…

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

Можно подвести итог.

1. Игры одного жанра «устроены» примерно одинаково и совпадают в геймплейных элементах (см. схему выше).

2. Определив жанр игры, мы можем определить «ядро» ее геймплейных элементов и механик.

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

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

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

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

Кроме того, тестируя эффективность механик в конкретной ситуации, важно помнить о балансе игры. Это понятие включает в себя силу противников, параметры оружия, количество препятствий и общую структуру игрового уровня. Дефекты в балансе игры напрямую влияют на эффективность механик.

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

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

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

Под уровнем понимается некая локация игрового мира, где игрок проводит конкретный отрезок времени. Это может быть открытый мир, город, отдельное здание, определенная игровая карта, игровой раунд и т. д.

Термин был заимствован из ранних ролевых игр, где относился к уровням подземелья. Игроки начинали снизу (уровень 1) и должны были пройти через все уровни (которые становились сложнее), пока не доходили до поверхности, обретая свободу.

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

Концептуальный дизайн. На этом этапе дизайнер уровней обдумывает все особенности локации, которые сделают процесс игры интересным и увлекательным. Как правило, на этом же этапе художник делает набросок уровня. Выделяются различные зоны: места спавна[27] персонажей, места крафта ресурсов, интерактивные элементы и проч.

«Серый» прототип (Greybox, Blockout). Это недетализированный прототип уровня, часто состоящий из простых геометрических форм (кубов, параллелепипедов, конусов, цилиндров), имитирующих здания и другие объекты, которые дизайнер может передвигать или удалять. На этом этапе опытные дизайнеры уровней используют заранее подготовленные метрики для соблюдения масштаба и пропорций.

Пример greybox

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

Диспропорция укрытий

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

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

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

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

1. Пропасти в карте (Map holes)

2. Невидимые стены (Invisible walls)

3. Застревания (Stuck points)

4. Дефекты измененного ландшафта (Landscape changes defects)

5. Видимые стыки между текстурами (Visible texture seaming)

6. Дефекты разрушаемого окружения (Destructible environment defects)

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

Проваливание персонажа «под карту». WWZ © 2019, Saber Interactive

Например, в игре Fortnite: Save the World в одном из подземелий долгое время был «разрыв» на карте, куда персонаж мог провалиться и погибнуть.

«Разрыв» на карте. Fortnite: Save the World © 2017, Epic Games

Еще один пример map hole – неплотное примыкание скал и поверхности в игре Apex Legends. В эту дыру время от времени проваливались игроки.

Разрывы геометрии моделей на карте. В данном случае «пол» не примыкает к «стенам». Apex Legends © 2019, Respawn Entertainment

Невидимые стены (Invisible Walls) – как правило, результат неправильного моделирования объектов. Часто они появляются, когда видимая модель объекта не совпадает с моделью коллизий, то есть физической моделью объекта, которая придает осязаемость объекту.

Невидимая стена. Marvel’s Spider-Man © 2018, Insomniac Games

Иногда невидимые объекты в игре позволяют даже повиснуть на них. Assassin’s Creed: Unity © 2014, Ubisoft

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

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

«Застревания». Дефекты, связанные с застреваниями, могут быть вызваны различными причинами. Одной из причин может быть перестройка уровня и нарушение при этом использования навигационной сетки[28] (Navigation Mesh) или ее автоматической генерации. Например, при перестройке уровня были передвинуты модели, но навигационная сетка осталась старой. Как следствие, NPC могут «идти в стену» или любой другой предмет, который они не смогут обойти, и застрянут там (это как раз и есть один из случаев застревания – stuck point).

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

Склон сделали более пологим, а персонажи «повисли» в воздухе. Black Desert © 2015, Pearl Abyss

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

«Шов» между текстурами. WWZ © 2019, Saber Interactive

Дефекты разрушаемого окружения. Если окружение в игре не интерактивное, то есть игрок не может с ним взаимодействовать, уровень реалистичности такой игры остается довольно низким, даже если объекты окружения проработаны с безупречной точностью и четкостью. Понятие «разрушаемое окружение» относится к различным объектам: ландшафту (для этого существует специальный термин – деформируемый ландшафт), растительности, интерьеру, зданиям и сооружениям и т. д. Обычно особое внимание созданию разрушаемого окружения уделяется в играх, где это становится важной частью геймплея или даже игровыми механиками. Например, в игре Worms W. M.D., как и в ее предшественнице, разрушаемые уровни позволяют вносить в геймплей дополнительные возможности для игрока, влияя на его стратегию, и добавляют в игру изрядную долю веселья.

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

К дефектам разрушаемого окружения можно отнести следующее.

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

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

Объект не может быть разрушен после определенной стадии разрушения. Например, при выстреле из танка здание рушится, оставляя горящий остов, но далее постройку разрушить нельзя.

Деформируемый ландшафт может быть важной игровой механикой. Worms W. M.D. © 2016, Team 17

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

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

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

1. модели (персонажи, предметы, транспорт и т. д.):

a. коллизии моделей;

b. анимация моделей;

2. визуальные эффекты (VFX);

3. освещение сцены, отражения и тени.

Рассмотрим эти области графической подсистемы подробнее.

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

В процессе создания игровой модели выделяют несколько этапов.

Концепция (Concept). Здесь происходит выбор визуального стиля будущей модели. Именно на этом этапе закладывается фундамент для всей последующей работы.

Моделирование (High-poly). На этом этапе происходит создание 3D-модели в специальном редакторе[29]. Этот процесс может проходить по-разному, но в случае персонажей он похож на создание скульптуры, в котором мастер создает максимально реалистичную модель.

Ретопология (Low-poly). Игровая модель чаще всего состоит из полигонов, то есть многоугольников, угловые точки которых имеют точные координаты в 3D-пространстве и соединены между собой линиями. Чем выше детализация, тем большее количество полигонов должно быть использовано в моделировании (модели high-poly); чем она ниже, тем меньше нужно полигонов (модели low-poly). Этот этап предполагает упрощение геометрии модели и уменьшает количество использованных полигонов при сохранении достаточно высокого качества модели.

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

Пример low-poly, mid-poly и high-poly моделей

Развертка (UV mapping). Сетку полигонов, из которой состоит 3D-модель, необходимо «развернуть» в 2D-пространстве для последующего текстурирования. Другими словами, сопоставить X, Y и Z координатам 3D-модели координаты U и V «развертки» (буквы U и V используются, потому что X и Y уже заняты). UV-развертка похожа на детали выкройки, которые портной вырезает из ткани, чтобы потом сшить пиджак.

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

Текстурирование модели (Skinning), которое происходит на последующих этапах, заключается в наложении заранее подготовленных растровых текстур на 3D-полигональную модель для имитации рельефа, придания цвета и окраски.

На этом этапе могут возникнуть ошибки, связанные с:

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

• выбором некачественных текстур низкого разрешения;

• неверной настройкой прозрачности текстур, параметров отражения и преломления;

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

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

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

Дефекты моделей

Заметные швы между частями тела персонажа

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

Слишком большое количество полигонов

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

Несоответствие историческому (реальному) прототипу

Посмотри на изображение автомата на картинке дальше. Ничего странного не замечаешь?

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

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

Из такого АК-47 можно стрелять только в игре. Counter-Strike 1.6 © 2000, Valve

А вот T-34-85M полностью идентичен со своим прототипом. World of Tanks © 2010, Wargaming.net

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

Дефекты коллизий и хитбоксов

Ты наверняка замечал, что большинство случаев взаимодействия моделей основано на их касании друг друга. Чтобы игрок воспринимал такое взаимодействие как реалистичное, используются так называемые модели коллизий – объекты, невидимые игрокам, но обладающие физическими свойствами. Их называют коллайдерами (colliders). По сути, коллайдер – это невидимая упрощенная форма объекта, привязанная к нему, для расчета результата столкновения с другими объектами. Поэтому большинство объектов виртуального мира игры не проходят друг сквозь друга, а ведут себя естественно, а точнее, как их запрограммировал разработчик: персонажи не проваливаются сквозь землю и не проходят сквозь стены, потому что сами содержат коллайдер с настройками физики.

Часто взаимодействие персонажей происходит агрессивно, то есть с нанесением физического урона. Поэтому модель коллайдера включает в себя так называемый хитбокс (hit-box). Хитбокс – это часть физической модели, при столкновении с которой запрограммированный объект (например, пуля, копье, меч или кулак) «наносит урон», а точнее, если запрограммированный на нанесение урона объект сталкивается с хитбоксом физической модели (коллайдера) другого объекта, из переменной здоровья второго объекта вычитается определенное количество единиц здоровья (health points). На практике это выглядит так: «Персонаж стреляет из лука в кабана, стрела попадает в кабана (но не в голову или сердце), кабан визжит от боли и начинает спасаться бегством. Повторное попадание стрелы в кабана, скорее всего, его убьет».

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

Дефект коллизии объектов. NHL 16 © 2015, EA Vancouver

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

Еще одна задача – проверка корректного размещения хитбоксов и урона, наносимого объекту при взаимодействии с ними. Ошибки тут могут вызвать фрустрацию у пользователей. Например, в игре Battlefield 2042 физическая модель с хитбоксами у одной из моделей (Falck) была шире, чем ее видимая модель, что приводило к более частым смертям персонажа.

Хитбоксы, не соответствующие модели персонажа, позволяют поражать врага, стреляя мимо него. Counter-Strike 2 © 2023, Valve

Дефекты анимации

Специалист, который занимается анимацией игровых моделей помимо специального ПО, просто обязан знать основы анатомии человека, чтобы все делать правильно. В противном случае легко получить в игре неестественную анимацию, хаотичные движения конечностей персонажа, например, из-за некорректной работы системы сочленений и т. д.

Есть и другие примеры багов анимации.

Дефекты лицевой анимации (Facial Animation)

Лицевая анимация у модели может создаваться разными способами: на основе блендшейпов (Blend Shapes, форм для смешивания), а также мускульной или кластерной (на основе костей) модели. Распространенный способ с помощью блендшейпов подразумевает создание базовой модели лица персонажа с нейтральным выражением лица и производства на основе ее копий «выражений» (эмоций) в необходимом количестве с обязательным сохранением количества вершин полигонов и их нумерации (то есть их нельзя объединять, удалять или добавлять новые). Затем при создании анимации в редакторе указывается базовая модель и целевая модель (Target). После этого можно использовать управляющие элементы для плавного перехода от одной модели к другой (например, от нейтрального выражения до улыбки). Частный случай дефектов лицевой анимации – дефекты синхронизации губ (Lip Sync), когда отсутствуют блендшейпы отдельных фонем, используются неправильные последовательности блендшейпов или анимация отсутствует совсем.

Вибрация камеры (Camera Shake)

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

«Расчлененка» (Dismemberment Gore System, отрывы конечностей, разрыв тела)

Чтобы реализовать этот эффект, модель нужно подготовить – «разрезать» на мелкие части. Триггер эффекта – одновременное соблюдение некоторых условий.

1. Персонаж должен иметь менее определенного количества очков здоровья (health points).

2. Он должен получить урон из определенного вида оружия.

3. Выстрел из этого оружия должен быть произведен в определенную область персонажа.

При выполнении этих условий эффект выражается в отрыве части или «взрыве» модели с разлетанием ее частей и добавлением специальных эффектов крови и т. д.

К дефектам здесь можно отнести неестественный отрыв конечности, оставлением на месте одной или нескольких частей модели при «взрыве» тела, отсутствие спецэффектов.

Первые попытки реализовать расчлененку. Doom II: Hell on Earth © 1994, id Software

Переходы между анимациями

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

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

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

Дефекты, связанные с аппаратной частью

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

Разрыв экрана (Screen Tearing) – прямо не относится к проблеме графики, поскольку связан больше с аппаратной частью. Однако этот дефект имеет четкое визуальное воплощение – искажения в изображении сцены. Дело в том, что у каждого монитора есть такой показатель, как частота обновления экрана (характеристика, обозначающая количество возможных изменений изображения в секунду: 60 Гц, 144 Гц, 165 Гц, 240 Гц и т. д.). Если же видеокарта отправляет на монитор больше кадров, чем тот может отобразить, то кадры накладываются друг на друга, и получается «разрыв». В играх используется технология V-Sync, которая искусственно понижает FPS в игре, чтобы частота кадров в игре и частота обновления монитора совпадали.

Разрыв экрана. Слабая видеокарта или «тяжелая» сцена? MX Nitro: Unleashed © 2017, Saber Interactive

Неверный уровень детализации (Level of Detail) – на игровой сцене могут одновременно находиться много объектов, находящихся на разном «расстоянии» от камеры (для имитации перспективы). Для снижения нагрузки на аппаратную часть игровой платформы при разработке применяется технология, которая использует модели с разным уровнем детализации. Очевидно, что в играх нет необходимости воспроизводить каждый кирпич на стене удаленного объекта, если глаз все равно не в состоянии его различить. К тому же обработка данных о нескольких сотнях тысяч невидимых полигонов загрузит процессор бесполезной работой.

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

Модели с разным LoD для использования на разном «расстоянии» от камеры

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

Разработчики также меняют уровень детализации в зависимости от текущей частоты кадров, скорости движения объекта на экране и общего количества одновременно видимых объектов.

Пример использования LoD. Half-Life © Valve, 1998

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

Ошибка LoD. The Elder Scrolls V: Skyrim © 2011, Bethesda Game Studios

Фантомная графика (Ghosting) – это не дефект игры, а явление, при котором на экране отображается несколько смещенных изображений объекта. Это происходит, когда предыдущее изображение продолжает появляться на экране вместе с последним даже при переходе к следующему кадру, что дает размытый, «призрачный» эффект. Причины такой фантомной графики – частота обновления экрана и время отклика. Частота обновления экрана – это скорость, с которой твой монитор обновляет изображение на дисплее, а время отклика – время, которое требуется процессору на вывод на дисплей нового изображения поверх старого. Слишком короткое время отклика не позволяет быстро сменить предыдущее изображение на текущее. Повторим: это не дефект игры, но ты можешь рассматривать его как некоторый дефект аппаратной части, который требует устранения. Особенно это актуально для динамичных игр, в которых нужны быстрая реакция и высокая скорость движения.

Мерцание (Flickering) – часто встречающийся термин при описании бага. Обычно имеется в виду то, что объект (текстура, частицы и др.) мерцает, мигает, пропадает и появляется с определенной периодичностью. Мерцание также может быть связано с настройками времени отклика.

Некоторые графические баги могут быть связаны с проблемами клиппинга, или обрезки. Клиппинг (Clipping) – это метод обработки и оптимизации изображения так, чтобы не рендерить части изображения, находящиеся вне пределов видимости пользователя. Это помогает существенно экономить вычислительные ресурсы видеокарты. Представь себе луч фонаря в темноте. Ты видишь только то, что попадает в зону луча; все остальное остается невидимым. Зона или, вернее, объем видимости обычно имеет вид усеченной четырехугольной пирамиды (фрустум) с виртуальной камерой в вершине, то есть ограничен шестью плоскостями. Плоскости, перпендикулярные камере, называются Near Plane (ближняя плоскость, NP) и Far Plane (FP, дальняя плоскость). Таким образом, объекты, не попадающие в указанный объем, не будут учитываться при рендеринге, и пользователь их не увидит. Точнее, не должен видеть.

Область видимости определяется шестью плоскостями отсечения. Объекты Б и В находятся вне объема видимости и будут отсечены при рендере

Дефектом клиппинга называют ситуацию, когда вместо ожидаемой невидимости объекта (например, когда он не входит в область видимости или блокируется другим непрозрачным дефектом) он становится видимым. Яркий пример такой ситуации – иллюстрация ниже.

Ошибка клиппинга. WWZ © 2019, Saber Interactive

Кроме того, для оптимизации вычислительных ресурсов применяются и другие методы, позволяющие отсекать те части сцены, которые пользователь видеть не должен, – например, отсечение (culling). Впрочем, часто эти понятия (clipping и culling) используют как синонимы.

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

Все, что должно оставаться невидимым, стало видимым. Watch Dogs © 2014, Ubisoft

Сшивка (Z-Fighting, Stitching) – дефект рендеринга, при котором два примитива начинают попеременно перекрывать друг друга, вызывая мерцание на экране. Это происходит из-за того, что они оба находятся так «близко» к камере, что графический процессор не понимает, что он должен отобразить в конкретном пикселе на экране и какую информацию необходимо взять из Z-буфера, который отвечает за «глубину»; координаты примитивов очень близки или совпадают. При изменении сцены (например, когда игрок чуть отходит и снова приближается к этому месту) дефект проявляет себя как мерцание, графические шумы, потому что один из двух примитивов попеременно «выигрывает» борьбу, и его данные используются для окрашивания пикселей экрана.

Z-fighting во всей красе

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

Дефекты, связанные с «человеческим фактором»

Отсутствующие текстуры (Missing Textures) – дефект проявляется в том, что на месте отсутствующих текстур появляются «заглушки». То есть в программном коде содержится информация о текстурах и их местонахождении, тогда как самих текстур в этом месте нет или графический процессор не может достаточно быстро подгрузить их из места хранения и вывести на экран. Однако бывают ситуации, когда разработчики просто забыли заменить временные текстуры или не положили их в нужную папку.

Отсутствующие текстуры. Не подгрузились или их никогда там не было? Mount & Blade II: Bannerlord © 2020, TaleWorlds

Визуальные артефакты и графические «глюки» (Visual Artifacts and Graphical Glitches) – если честно, то это дефекты, которые я не могу отнести в вышеперечисленные группы. Иногда даже бывает сложно понять причину появления таких багов. «Глюки», как правило, связаны непосредственно с нестабильной работой графического процессора, его драйверов и др. К таким дефектам можно отнести «блуждающие пиксели» – артефакты, возникающие вокруг объектов и пропадающие при смене угла зрения.

Визуальный дефект. The Elder Scrolls V: Skyrim © 2011, Bethesda Game Studios

Визуальные эффекты традиционно разделяют на:

1. геймплейные эффекты: визуализация магии, эффекты оружия, взрывы, разрушения и т. д.;

2. природные эффекты или эффекты окружений: водопады, туман, дождь, снег и т. д.

Чтобы ориентироваться в теме визуальных эффектов, тестировщику можно воспользоваться знанием принципов их создания.

1. Правило трех форм

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

Примеры визуальных эффектов, которые основаны на использовании трех форм

2. Правило трех цветов

Согласно этому правилу, эффект будет нескучным и произведет на зрителя впечатление, если специалист по спецэффектам будет соблюдать правило 70:30. То есть отношение основного цвета к вторичному и третичному вместе будет 70 к 30, а отношение вторичного к третичному – тоже 70 к 30.

3. Правило трех значений контрастности

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

Пример трехцветного визуального эффекта с тремя уровнями сатурации. Tanks a Lot! © 2018, Highcore Labs LLC

4. Принципы анимации

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

«Ожидание» эффекта поражения древней стрелой. The Legend of Zelda: Breath of the Wild © 2017, Nintendo Entertainment Planning & Development

«Действие» эффекта поражения древней стрелой. The Legend of Zelda: Breath of the Wild © 2017, Nintendo Entertainment Planning & Development

«Реакция» эффекта поражения древней стрелой. The Legend of Zelda: Breath of the Wild © 2017, Nintendo Entertainment Planning & Development

5. Вторичная и третичная анимация

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

Сравни эти взрывы. Какой тебе кажется эффектнее?

6. Время эффекта

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

7. Физические законы

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

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

Для примера разберем эффект, который называется Muzzle Flash (Вспышка выстрела).

Можно выделить примерные этапы данного эффекта.

• Начальное свечение дула – происходит непосредственно перед тем, как пуля покидает ствол оружия. Создается сильно разогретым газом, выталкивающим пулю из ствола.

• Основная вспышка – происходит в момент вылета пули и смеси разогретых газов из ствола оружия. Вспышка имеет разные цвет, форму и интенсивность.

• Искры – создаются несгоревшей частью пороха, вылетающего из дула, после выстрела.

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

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

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

Пример слишком высокой плотности «тумана»

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

Свет может быть искусственным и естественным, может иметь направление, отражаться, преломляться и иметь разную интенсивность.

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

Тени от объектов падают в разные стороны. Сколько в небе Солнц? Assassin’s Creed IV: Black Flag © 2013, Ubisoft Montreal

Здесь светильник слева светит, но ничего не освещает. WWZ © 2019, Saber Interactive

Реалистичное отражение на разных отражающих поверхностях – довольно сложный процесс. Для его реализации разработчики используют различные технологии: от «зеркальных» уровней и виртуальных камер (planar reflections) в очень старых играх до кубических текстур (cubemaps) и трассировки лучей (ray tracing) в современных проектах. В дальнейшем появятся и другие технологии для решения таких задач.

То, что игрок видит в зеркалах, – «виртуальные камеры» для имитации отражения

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

Кубические текстуры или кубическая карта (Cubemaps) – это методология создания отражений объектов на отражающей поверхности путем отображения координаты текстуры в трехмерном пространстве в тексель[30] (то есть получения изображения пикселя на экране, которое имеет свой цвет и другие характеристики и является отражением какого-то объекта на отражающей поверхности). Для этого используется развертка шести граней куба (подобная UV-развертке, о которой говорилось выше), на каждой из сторон которого заранее «запечена» текстура.

Пример кубической карты

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

Текстурная выборка из кубической карты с вектором направления «зрения» из центра куба

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

Иногда персонажи «превращаются в вампиров», забывая отражаться в зеркальных поверхностях. Watch Dogs © 2012, Ubisoft

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

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

Так устроен процесс построения модели с использованием трассировки лучей

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

Из-за высоких требований к вычислительным ресурсам отражениям не хватает детализации и объема. Marvel’s Spider-Man © 2018, Insomniac Games

К дефектам освещения можно отнести также нарушенную автоэкспозицию (Auto Exposure или Eye Adaptation). Представь себе, что ты выходишь из темного подвала, где провел полдня, на открытое ярко освещенное пространство двора. Ты непроизвольно жмуришься от обилия света до тех пор, пока глаза не адаптируются к освещению. В играх такой прием используется в аналогичных ситуациях, чтобы добавить реалистичности. Иными словами, уровень экспозиции сцены меняется, делая сцену или ее части ярче/темнее и имитируя адаптацию зрения. Это позволяет добавить реалистичности происходящему.

Еще один дефект освещения – неправильное использование или работа бликов (Lens Flare Effect). Блики используются для придания освещению сцены реалистичности и имитации очень ярких источников света.

Lens Flare Effect хорош, но кажется, что в глаза игрокам направлены сразу несколько очень мощных прожекторов, причем почти постоянно. Syndicate © 2012, Electronic Arts

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

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

• геометрии объектов;

• текстур;

• физических моделей;

• моделей коллизий.

Цель этого тестирования – улучшить качество моделей перед экспортом в игровой движок. Большой опыт и доступ к средствам разработки позволяют художникам, 3D-моделлерам и аниматорам находить дефекты гораздо быстрее и эффективнее.

Техническое тестирование призвано обнаружить дефекты, связанные, например, с:

• форматом графических файлов;

• наличием необходимых графических файлов в соответствующих каталогах;

• целостностью этих файлов;

• соответствием модели требованиям игрового движка с точки зрения ограничений на количество полигонов;

• другими техническими аспектами, например с проверкой дистанций для переключения моделей (LoD).

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

Звуковая подсистема игры – это один из очень важных игровых элементов, увеличивающих иммерсивность, то есть погружение игрока в сюжет.

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

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

1. Сигнал. Определенный звук сигнализирует о нехватке ресурсов, захвате базы врагами, удачном выстреле и т. д.

2. Ориентация в пространстве. Такие звуки помогают игроку понять, находится ли он в закрытом помещении или на открытой местности.

3. Ориентация на местности. Игрок использует звуки для ориентации в пространстве, например, когда передвигается в различных средах: по воде, песку, снегу и т. д.

4. Оповещение. Звуки используются для сообщения о событиях, которые визуально не воплощаются на экране: например, игрок достигает определенного уровня.

5. Атмосфера. Это звуки окружения для усиления погружения в игровой процесс: звуки города, фермы, боевых действий и т. д.

6. Усиление эффекта. Звуки используются для акцента на игровом событии. Например, после взрыва гранаты игрок может слышать писк или приглушенные звуки для имитации контузии и снижения слуха.

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

Одни и те же звуки могут выполнять различные функции. Например, звуки, которые выполняют сигнальную функцию и функцию оповещения, могут использоваться и для создания определенной атмосферы в игре (вспомни «Killing Spree! – Rampage! – Dominating! – Unstoppable! – GODLIKE!» в Unreal Tournament).

Весь игровой звук можно разделить на шесть групп.

• Фоновая музыка

• Звуки интерфейса

• Звуки окружения

• Звуки персонажей

• Звуковые эффекты

• Голосовая озвучка персонажей

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

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

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

Звуки персонажей (Foley) – это все звуки, производимые персонажами, за исключением речи. Это могут быть звуки шагов, открывающихся дверей, звон ключей в связке и проч., то есть все те звуки, которые придают игре больше реализма. Эта группа звуков, как и профессия человека, занимающегося их производством (Foley artist), была названа в честь Джека Донована Фоули – одного из первопроходцев в области звуковых эффектов для кинематографа.

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

Голосовая озвучка персонажей (Voiceover) может быть записана для игровых и неигровых персонажей для увеличения звукового разнообразия. При этом у нее есть некоторые особенности.

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

2. Персонажи могут не быть озвучены вовсе, и это не повлияет на атмосферу игры. Например, главный персонаж в Quake или Half-Life не произносит ни единого слова за всю игру, а в The Legend of Zelda: Breath of the Wild не озвучен ни один NPC (non-player character).

Чтобы погрузить пользователя в атмосферу игры, специалисты по созданию звукового сопровождения часто используют различные приемы: от использования повышенного уровня звука в обычных сценах (например, громкость ударов и падений в драках) до сложных звуковых эффектов и тонкой настройки звуковых зон[31].

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

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

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

Однако при всем многообразии игровых звуков и звуковых эффектов все дефекты, связанные с ними, могут быть сгруппированы в три категории.

1. Отсутствие звука

2. Проигрывание неправильного звука

3. Неправильное проигрывание звука

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

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

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

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

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

Далее в рамках контентно-аудиального тестирования, самого масштабного этапа тестирования звука, тестировщик проверяет следующее.

1. Наличие звука у конкретного игрового события.

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

• Стоя у водопада, игрок не слышит звука падающей воды.

2. Соответствие созданных звуков объекту, игровой ситуации и сеттингу игры (при условии, если это не гениальная задумка гейм-дизайнера).

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

• Эффекты накладываемых магических заклинаний будут звучать неуместно в игре про Вторую мировую войну.

• При взрыве ручной гранаты игроки слышат звук, напоминающий звук разрывающейся авиабомбы.

• Персонаж передвигается по песку, а звук такой, будто он идет по луже.

3. Отсутствие неуместных звуковых включений и артефактов в звук события.

• К звуку взрывов примешаны голоса людей, которых нет в сцене.

• В звуке отсутствуют посторонние вкрапления: щелчки, стуки и т. д.

4. Отсутствие раздражающих игроков звуков (вроде звука трения пенопласта по стеклу).

5. Громкость созданных аудиофайлов.

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

6. Неправильное позиционирование звука в зависимости от его источника.

• Кузнец кует оружие в кузнице рядом с таверной, непрерывно ударяя молотом по куску металла. Однако игрок слышит этот звук из угла своей комнаты.

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

7. Неправильно настроена зона звукового покрытия.

• Отойдя на небольшое расстояние от кузницы, персонаж перестает слышать удары молота кузнеца.

• Все звуки производства пропадают, как только персонаж выходит за ворота фабрики.

8. Соответствие записанных актерами реплик персонажей игровому сеттингу и ожиданиям игроков.

• Голос актера не соответствует полу и возрасту персонажа.

• Голосовые характеристики актера озвучки не соответствуют ожиданиям игроков. Например, персонаж из страны Ближнего Востока говорит с выраженным ирландским акцентом.

9. Соответствие звуков звукам реальных прототипов (историческая достоверность).

• Голос исторического персонажа, известного публике, звучит совершенно не похоже на прототип.

• Звук граммофона звучит как звук современной аудиосистемы.

10. Сочетание всех звуков, включая музыку.

• Фоновая музыка заглушает важные для игрового процесса звуки.

11. Зацикливание, искажение, пропадание, задержки, прерывания.

• Игроки слышат, как звук начинает трещать или шипеть.

• При выстреле из орудия звук воспроизводится дважды.

• Во время кат-сцены (внутриигрового видео) персонаж начинает говорить, но звук его голоса начинает звучать гораздо позже момента, когда его губы начинают двигаться.

12. Отсутствие необходимых эффектов, добавляющих реалистичности звуковому сопровождению.

• Персонаж, находясь в пещере, громко зовет напарника. При этом полностью отсутствует эхо.

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

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

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

• В игре можно включать и выключать звуки и/или музыку.

• Можно изменить громкость.

• Все аудиофайлы названы с соблюдением единого формата и распределены по каталогам в проекте.

• На игровой карте правильно расставлены источники звука и звуковые зоны.

• Звуки совместимы на разных аудиосистемах: наушники, колонки, мониторные колонки, 5.1, 7.1, домашний кинотеатр и другие используемые системы и технологии.

Финальной проверкой в этом процессе может стать тестирование производительности для проверки влияния озвучки на работу аппаратной части игровой платформы.

Критерии оценки звуковой картины, которые должны учитываться тестировщиком:

• созданное звуковое сопровождение не уменьшает количество FPS озвучиваемой сцены;

• созданное звуковое сопровождение не является причиной утечек памяти[32];

• установленные при разработке игры лимиты по звукам соблюдены (например, лимит на количество одновременно проигрываемых звуков);

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

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

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

Чаще всего искусственным интеллектом наделены персонажи, которых игроки называют ботами и чья главная задача – противостоять или помогать игроку. Требований к игровому ИИ не так много: реалистичное поведение, создание трудностей для игрока и реализация всего этого в реальном времени.

Принципы работы игровых ИИ не меняются, и вряд ли это произойдет в ближайшем времени. Базовый алгоритм остается прежним: «сбор информации → анализ → действие». На каждом из этих этапов разработчики могут усложнять алгоритмы и, таким образом, делать персонажей «умнее».

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

Похожим образом устроены другие «органы чувств» – слух и обоняние.

Тело главного персонажа разделено на 8 частей. Если лучи, исходящие из «глаз» противника, пересекают две и более из них, то противник «видит» персонажа даже за укрытием. Tom Clancy’s Splinter Cell: Blacklist © 2013, Ubisoft

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

В старых играх ИИ представлен довольно примитивными алгоритмами, типа предопределенного набора правил (rule-based AI), как в Pac-Man. В более современных продуктах для принятия решений и совершения действий используются более сложные архитектуры и их модификации:

• конечный автомат (Finite State Machine, FSM);

• поведенческое дерево (дерево принятия решений, Behavioral Tree);

• различные миксы этих архитектур (например, иерархические конечные автоматы);

• служебный ИИ (Utility AI).

ИИ в Pac-Man был основан на простейшем алгоритме: один противник всегда поворачивал влево, второй – только вправо, третий – в обе стороны, и только четвертый преследовал игрока. Pac-Man © 1980, Nintendo

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

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

Логика поведения персонажа определяется полученной информацией в том состоянии, в котором персонаж находится. В зависимости от новых условий (полученной информации) персонаж переходит в другое состояние.

Использование поведенческого дерева предлагает другой подход к программированию поведения персонажа. Здесь все состояния персонажа организованы в виде ветвящейся структуры с понятной иерархией.

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

Архитектура поведенческого дерева с использованием алгоритма Монте-Карло, когда ИИ выбирает наиболее подходящее состояние в текущей ситуации, исследуя разные ветки дерева

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

Когда персонаж, основная задача которого – патрулирование на автомобиле, теряет этот автомобиль (например, его уничтожает игрок) и после потери игрока из вида должен вернуться к патрулированию, он может «зависнуть», не найдя средство передвижения. Дерево поведения позволяет персонажу выбрать свое новое состояние и перейти на пешее патрулирование без всяких проблем. Это дает более плавный и более реалистичный переход между разными состояниями персонажа.

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

Искусственный интеллект персонажа, перейдя в состояние боестолкновения, выбрал наилучшую тактику боя, после чего вновь вернулся в состояние патрулирования

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

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

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

Из-за сложности этих процессов в поведении персонажей под управлением ИИ нередко наблюдаются сбои, классифицируемые как дефекты ИИ.

Для завершения темы разработки ИИ в игре необходимо рассмотреть еще один вопрос: как персонаж передвигается в пространстве уровня (по горизонтали и по вертикали), чтобы попадать в различные ситуации.

Для обозначения пути, по которому может перемещаться персонаж, используются навигационные сетки (Navigation Meshes, NavMeshes). Это некоторая структура данных, которая описывает поверхности игрового мира так, что позволяет персонажу находить путь из одного места в игровом мире в другое (Pathfinding).

Ошибка с NavMesh приводит к тому, что персонаж не сможет перейти через «разрыв»

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

1. Неправильное взаимодействие персонажа с ИИ с игровыми объектами и игроком. Как правило, эти баги связаны с неправильными настройками алгоритмов ИИ. Например, ваш помощник перестает помогать вам, враги не нападают на вашего персонажа и т. д.

2. Отсутствие движения персонажа, «застревания» во время движения. Нарушен pathfinding вследствие некорректной навигационной сетки или объектов, блокирующих передвижение персонажа по NavMesh. Персонаж с ИИ не может продолжить движение и застывает на месте или продолжает «идти» в невидимую стену.

На скриншотах ниже представлены примеры таких дефектов.

Задача тестировщика при проверке работы искусственного интеллекта – смоделировать возможные ситуации в виде тест-кейсов для проверки логичности и реалистичности поведения ИИ в них.

Один из неигровых персонажей циклично пугается главного героя даже тогда, когда последний не обращает на него никакого внимания. The Witcher 3: Wild Hunt © 2015, CD Projekt RED

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

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

В играх с элементами стелса стражник после того, как увидел персонажа игрока, может не сразу поднять тревогу, а сначала подойти поближе. За это время игрок может снова спрятаться или устранить противника.

Сюда же относится то, что охранники в этих стелс-миссиях почти никогда не поворачиваются назад. Это сделано исключительно для сохранения интереса у игрока. Ведь любой игрок разочаруется, если после нескольких минут планирования и скрытого преследования противника тот в последний момент просто развернется и выстрелит в героя. Поэтому противники остаются стоять спиной, чтобы было легче подкрасться к ним и провести «неслышный прием».

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

Соблюдение законов физики не вызывает сомнения у большинства игроков применительно почти к любой игре. Безусловно, гейм-дизайнер может придумать свой собственный мир и объяснить, что передвижение вверх ногами в его игре – механика, а не баг. Тем не менее нарушение физических законов – это как раз то, что убивает реалистичность в игре и может фрустрировать игрока.

У игровой физики много задач, но самая главная – сделать игру интуитивно понятной и увлекательной. Когда объекты ведут себя непонятно, пользователь не понимает правила игры.

При этом мы, как тестировщики, должны понимать, что строгое соблюдение физических законов в игре очень часто не требуется, а иногда может убить все веселье. Только представь Need for Speed, в которой реализованы реальные законы физики. Любое столкновение на трассе каждый раз будет приводить к фатальному результату, и в игру невозможно будет играть. Если бы Марио подчинялся реальным физическим законам, то он никогда бы не прошел даже первый уровень, потому что в реальном мире (кроме индийского кино, конечно) не бывает «двойного» прыжка. А если бы в снайперском симуляторе игроку пришлось бы учитывать скорость и направление ветра, скорость движения цели, освещение, угол выстрела и другие факторы, то игра бы усложнилась многократно и нашла гораздо меньше поклонников.

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

1. Дефекты разрушений

2. Дефекты поведения объектов

В играх физика делится на две категории: физика твердого тела и мягкого тела. Физика мягкого тела описывает силы, которые воздействуют на объект и тем изменяют его форму (например, флаг, вода или одежда персонажа; по сути, к этой категории можно отнести все элементы, которые могут деформироваться при воздействии внешних сил).

Если представить твердое тело в виде скопления точек, то эти точки всегда будут находиться на одном расстоянии друг от друга. Для создания физики мягкого тела перемещение этих точек ограничивают: расстояние между ними может меняться, но отделиться друг от друга у них не получится. Именно с помощью использования таких ограничений удается создать более-менее реалистичную физику.

В некоторых случаях, например в реализации «физики женской груди» (breast physics, jiggle physics), по факту являющейся мягким телом, могут использоваться технологии физики твердых тел.

3D-модель персонажа состоит из «костей», соединенных суставами и покрытые «кожей» из полигонов, на которые наложены текстуры. Для того чтобы грудь двигалась, аниматоры крепят «суставы» к грудной клетке и плечам персонажа и заставляют «кости» груди двигаться в соответствии с физическими правилами игрового движка.

Реализация физики груди с помощью дополнительных костей и суставов

При этом грудь персонажа двигается неестественно и может долго сохранять колебательный импульс.

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

Пружина, которая может двигаться в разных направлениях (влево-вправо, вверх-вниз), становится «основой» для анимации женской груди

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

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

И все же чаще всего под игровой физикой понимается физика твердого тела (Rigid Body Physics, RBP).

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

• силы тяжести (объект левитирует или взмывает вверх на значительную высоту);

• силы инерции (при резкой остановке быстро двигающийся тяжелый объект мгновенно останавливается);

• силы трения (тяжелый объект долго скользит по нескользкой поверхности);

• центробежной силы (автомобиль на огромной скорости входит в поворот по внешней полосе и без торможения проходит его) и др.,

или в том, что объекты обладают свойствами, невозможными в реальном мире, – например, огромной скоростью.

Левитация игрока в игре. NHL 16 © 2015, EA Vancouver

Летающие повозки – пример дефекта игровой физики. Red Dead Redemption © 2010, Rockstar

Отдельно нужно упомянуть дефекты, возникающие в тех случаях, когда скорость одного объекта настолько высока, что коллизия с другим объектом (особенно небольшим) не успевает регистрироваться системой. Речь идет о различных пулях, снарядах, стрелах и т. д. (Projectile). Таких проблем можно избежать, используя технологии излучения (Raycasting) и сканирования попадания (Hitscan), которые не требуют создания физической модели снаряда. Алгоритм реализации выстрела выглядит следующим образом.

1. Определяется направление, в котором указывает ствол оружия.

2. Из ствола оружия выпускается луч на заданное расстояние.

3. Используется raycasting для определения того, пересекся ли луч с каким-либо объектом.

Если игровой движок определил, что объект находится на линии огня, то он «сообщает» ему, что в него «попала» пуля. После этого объект может выполнить все действия для того, чтобы система зарегистрировала его повреждения.

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

Основное достоинство Raycasting в том, что он быстро вычисляется и не требует дополнительной памяти или процессорного времени на создание нового физического объекта (пули).

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

Попадание пули во врага происходит одновременно с дульной вспышкой (Muzzle Flash). Halo: Combat Evolved © 2001, Bungie

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

То есть эта технология не может обеспечить реалистичность, что огорчает многих игроков. И зачастую начинающие тестировщики определяют стрельбу, реализованную с помощью этой технологии, как дефект именно из-за отсутствия реалистичности.

Поэтому довольно часто в играх используют другую технологию для стрельбы – баллистику снаряда.

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

В играх, где предпочтение отдается реалистичности, преимущества баллистики снаряда проявляются в полной мере.

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

2. Можно использовать гранаты и снаряды с отложенным эффектом попадания/взрыва.

3. Использование дополнительной визуализации полета пули – Bullet time.

Полет пули в режиме bullet time в slow mo выглядит эффектно. Hunting Simulator © 2013, Neopica

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

Большинство существующих игровых движков способно обрабатывать оба типа симуляций пуль – Hitscan и Projectile ballistic. Это позволяет предоставлять игрокам огромный выбор оружия. Например, в том же Halo с Assault Rifle используется Hitscan, а с Needler – баллистика снарядов.

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

Если разбирать выстрел с точки зрения физики Projectile ballistic во время тестирования, то нужно учитывать следующее.

1. Объект-снаряд должен создаваться в точке, совпадающей с выходом из дула оружия (так устроено большинство видов оружия).

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

3. Траектория перемещения снаряда должна соответствовать условиям и среде, в которой находится объект (например, стрелы и пули в воде быстро теряют скорость и поражающую способность).

4. При попадании в объект-цель снаряд обычно уничтожается, а на объекте должны появиться следы от попадания и другие последствия (об этом я говорил выше, см. «Расчлененка» и «Дефекты VFX»).

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

6. Снаряд, как любой физический объект, может быть уничтожен другим снарядом (например, попадание одной ракеты или ее осколков в другую).

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

8. Снаряды могут состоять из различных материалов, в том числе жидкостей, поэтому на них по-разному влияют фундаментальные силы (например, GES Bio Rifle в Unreal Tournament).

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

10. В зависимости от свойств объекта, с которым происходит соприкосновение снаряда, снаряд может проходить сквозь этот объект с уменьшением потенциального урона и пути полета после прохождения (например, возможность простреливать деревянные стены постройки из автоматического оружия).

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

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

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

Если говорить проще, то это тестирование того, «как» работает игровой продукт. Нефункциональное тестирование так же важно, как и функциональное, поскольку очень влияет на удовлетворенность пользователей.

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

• Интерфейс пользователя (GUI)

Окно выбора оружия и одежды персонажа GUI. Assassin’s Creed: Odyssey © 2018, Ubisoft

• Head-Up Display (HUD, проекционный дисплей), который может включать следующее.

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

· Мини-карта для лучшей ориентации игрока на уровне.

· Текстурные наложения: указатель прицела, пиктограммы оружия, радар и т. д.

· Компас или направление к цели.

HUD обеспечивает быстрый доступ игрока к нужной информации и важным функциям. World of Warcraft © 2004, Blizzard Entertainment

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

• Индикатор урона (Damage indicator), который показывает направление и силу получения урона персонажем.

Damage Indicator показывает направление получения урона и пораженную область. World of Tanks © 2009, Wargaming.net

• Агония (Pain Effect) – это дополнение к индикатору здоровья. Проявляется покраснением экрана, дрожанием экрана и другими эффектами, в том числе звуковыми для индикации того, что персонаж находится в критическом состоянии и ему срочно требуется пополнить здоровье.

Здоровье персонажа находится на критической отметке. Diablo III: Reaper of Souls © 2010, Blizzard Entertainment

• Подсказка (Hint) – это элемент графического интерфейса. Используется как дополнительное средство для предоставления информации пользователю во время обучения. Могут быть двух видов.

· Внутриигровые (появляются при наведении курсора на интересующий пользователя объект или для обучения пользователя).

· Загрузочные (появляются во время загрузки, чтобы пользователь мог лучше ознакомиться с особенностями игры).

Подсказка в режиме обучения игрока. Genshin Impact © 2020, miHoYo Limited

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

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

• GUI правильно масштабируется при разном разрешении экрана.

• Текст не содержит ошибок и отформатирован.

• Текст читаем на фоне.

• Дизайн унифицирован (цвет, шрифт, размер элементов).

• В интерфейсе отсутствуют пустые участки.

• Элементы интерфейса не накладываются друг на друга.

• При выделении и/или наведении курсора на элементы (кнопки, надписи, поля и т. д.) они меняют внешний вид.

• Элементы анимированы, и анимация не «притормаживает».

• Нередактируемые поля выглядят одинаково и отличаются от редактируемых.

• Дублированные формы имеют одинаковые названия.

• Если элемент недоступен или отключен (disabled), есть пояснение, почему.

• Возможно перемещать и выделять элементы с помощью клавиатуры.

• При наведении на некоторые элементы могут появляться всплывающие подсказки.

• Работают все «горячие» клавиши и ярлыки.

• При ожидании действия появляется элемент загрузки.

Когда я говорю о GUI-элементах, то подразумеваются описанные ниже. Для каждого из них есть свои проверки и ожидаемое поведение.

• Текстовое поле (Text field)

· Внутри элемента может находиться поясняющий текст, который пропадает при вводе данных пользователем.

· Работает выделение текста с помощью Ctrl+A / Shift+стрелка.

· Невозможно использовать больше символов, чем указано.

· Невозможно использовать пустое поле или меньше символов, чем указано.

· Отсекаются пробелы в начале, конце (а иногда и в середине).

· Невозможно использовать символы, отличные от указанных, специальные символы или код.

· При ошибке валидации поле выделяется и выводится текст, поясняющий ошибку.

· При вводе пароля в соответствующее поле вводимые символы меняются на звездочки (*).

• Радиокнопка/Переключатель (Radio button)

· Расположен рядом с соответствующим текстом.

· Одновременно может быть выбран только один элемент.

• Флажок (Check box)

· Расположен рядом с соответствующим текстом.

· Одновременно может быть выбрано несколько элементов.

· При большом количестве элементов может быть специальный элемент для отметки/снятия выделения всех.

• Кнопка (Button)

· Имеет состояния: наведение курсора, нажатие, недоступна.

· При нажатии клавиши мыши на кнопке, если последующее отпускание клавиши мыши было в другой области, элемент не активируется (кнопка не нажимается).

• Выпадающий список (Drop-down list)

· Текстовые значения в списке располагаются в алфавитном порядке, числовые – по возрастанию.

· Самые популярные значения списка должны находиться сверху, последующие значения следуют по алфавиту.

· Если значение из списка выбрано, то оно должно находиться сверху или быть выделенным в списке.

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

· При наборе букв на клавиатуре подбираются подходящие значения.

• Подсказка (Tooltip)

· Не должна выходить за рамки экрана.

· Не нуждается в прокрутке.

· Может быть пропущена или обязательна к просмотру.

• Прокрутка (Scroll)

· Не появляется, если содержимое не выходит за рамки экрана.

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

· Крайнее верхнее и крайнее нижнее положения должны быть достижимы.

Отсутствует текст на элементах интерфейса пользователя. WWZ © 2019, Saber Interactive

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

Задача тестировщика – подготовить необходимое тестовое окружение и тест-кейсы для проверки интерфейса с точки зрения вышеописанного функционала.

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

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

1. Тестирование совместимости с аппаратной частью (hardware)

2. Тестирование совместимости с OС и сторонним ПО

3. Тестирование совместимости с программно-аппаратным комплексом

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

1. Тестирование приложения на разных разрешениях экрана

2. Тестирование приложения с различными подключаемыми устройствами (наушники, карта памяти, контроллеры и т. д.)

3. Тестирование взаимодействия приложения с датчиками (гироскоп, геопозиция и т. д.)

4. Тестирование приложения на разных конфигурациях (оперативная память + процессор)

5. Тестирование управления приложением посредством свойств экрана (тач, свайп, мультитач)

Для PC актуальность проверок та же, кроме проверок совместимости с дополнительными датчиками и устройствами типа гироскопа. При этом количество потенциальных конфигураций в этом случае – тоже цифра с большим количеством нулей.

Для игровых консолей проверка совместимости проводится с различными видами контроллеров. Кроме того, могут проводиться проверки совместимости игр с приставками предыдущих и последующих поколений, а также разными версиями устройств внутри одного поколения (например, PlayStation 4 и PlayStation Pro).

Другое направление тестирования – тестирование совместимости с OС и другим ПО. Среди такого ПО можно назвать:

• антивирусы;

• мессенджеры;

• программы для снятия скриншотов;

• программы для удаленного управления компьютером и прочее.

Иногда при появлении уведомлений из некоторых популярных мессенджеров игровое приложение сворачивается в трей[33] или «зависает». Другими примерами дефектов могут быть:

• возникновение отказов (см. ниже) при использовании некоторых видеокарт (например, относящимся к минимальным требованиям или, наоборот, только появившимся на рынке);

• несовместимость контроллеров некоторых производителей;

• несовместимость игры с конкретной OС;

• нарушенный режим воспроизведения звуков в разных устройствах;

• нарушенный режим воспроизведения графического контента из-за несовместимости с драйверами устройств.

Тестирование совместимости важно еще и потому, что во время его проведения могут быть выявлены общие функциональные и контентные проблемы игрового продукта. На определенных системах баги могут проявляться со 100 %-ной вероятностью, а на других – практически с нулевой.

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

Зависание, фриз (Freeze)

Фризом, как правило, называется «замирание» картинки на экране на определенное время или насовсем. Опционально при этом также останавливается звук.

Заедание, статтер (Stutter)

Считается, что основная причина фризов в игре – низкая производительность аппаратной части игровой платформы (например, слабая видеокарта или недостаток оперативной памяти). Однако часто возникают ситуации, когда игра начинает «притормаживать», но производительность платформы остается высокой – 60 FPS. Именно это и называется «заеданием».

Чтобы лучше понять проблему «заедания» в играх, нужно немного углубиться в историю развития геймдева. Раньше разработчики создавали игры, учитывая частоту кадров, с которой работал дисплей. Скорость передвижения объектов измерялась не в пикселях в секунду, а в пикселях «в кадр»: например, скорость персонажа в Sonic The Hedgehog для Sega была 16 пикселей на один кадр.

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

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

Если разработчик не знает (а он не знает), с какой частотой кадров работает игровая платформа, ему потребуется измерить текущую частоту кадров и адаптировать скорость анимации под нее, чтобы на экране игровой объект передвигался плавно с одной видимой скоростью. Например, если один кадр занимает 1/60 секунды (при 60 FPS), или 16,67 миллисекунды, а скорость объекта на экране 10 метров в секунду, то в каждом кадре расстояние, на которое он перемещается, будет равно 1/6 метра. Но если FPS «упадет» в два раза (до 30 кадров в секунду), то объект должен будет перемещаться уже на 1/3 метра в каждом кадре, то есть в два раза быстрее, чтобы пользователь наблюдал одну и ту же скорость объекта.

Скорость рендеринга кадров совпадает с частотой монитора, поэтому объект двигается плавно и с постоянной скоростью

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

Как ты понимаешь, при таких обстоятельствах синхронная работа центрального процессора (ЦП) и процессора графического адаптера (ГП) становится все более сложной. Часто происходят ситуации, когда ЦП отдает команду ГП произвести рендеринг сцены, а последний сохраняет ее в буфере. ЦП сообщает ГП о конце кадра, и эта команда не считается приоритетной, поскольку все еще происходит рендеринг сцены. То есть новый кадр ГП покажет только тогда, когда закончит выполнять предыдущие задачи. Поэтому способ вычисления временной разницы между началами соседних кадров уже не работает так хорошо, как раньше.

Время начала кадра, измеряемое игрой, начинает колебаться. Игра считает, что FPS «упал», и показывает предыдущий кадр, чтобы дать время ГП сгенерировать следующий, хотя в игре поддерживается стабильно высокий показатель FPS. Это и есть «запинание»: анимация, сгенерированная для нестабильного FPS, но отображаемая с фиксированным FPS.

Рендеринг кадра 3 у ГП занимает слишком много времени, поэтому кадр 2 повторяется в третий раз

Частота кадров, фреймрейт (Frame Rate)

Как я уже говорил, FPS – это количество кадров, сменяющих друг друга за одну секунду игрового процесса. От него зависит плавность картинки, эстетичность спецэффектов и в целом реалистичность происходящего на экране. В игры этот параметр пришел из кинематографа, где показатель количества кадров в секунду одинаков на протяжении всего фильма – 24.

На показатель частоты кадров непосредственное влияние оказывают:

• быстродействие оперативной памяти;

• монитор с высоким коэффициентом обновления кадров;

• графический адаптер (видеокарта), мощность которого обеспечивает скорость вычислительных процессов при рендере сцен;

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

Графический адаптер рендерит каждую сцену в зависимости от сложности с разным количеством затраченного времени. «Легкие» кадры поддаются воспроизведению гораздо проще «тяжелых», чье длительное пребывание на экране способствует задержке данных и «тормозит» игровое движение. Сейчас мы говорим о случаях реального падения FPS из-за того, что аппаратная часть игровой платформы не в состоянии обрабатывать игровые сцены с постоянно высокой скоростью.

Для этого и производится замер FPS прямо во время игры. Делается это с помощью специального ПО, о котором я расскажу в отдельной главе.

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

• видимая для пользователя подгрузка высокополигональных моделей или каких-либо других объектов на сцену;

• отсутствие текстур на поверхностях объектов на сцене;

• разрывы экрана;

• невозможность загрузить уровень или его очень долгая загрузка;

• очень долгая установка игры;

• невозможность запустить игру на платформе с минимальными требованиями.

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

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

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

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

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

Длительная работа приложения

Пользователь может проводить в игре долгое время, а работа игровых серверов вообще подразумевает функционирование в режиме 24/7. Значит, игровое приложение должно правильно и быстро функционировать все это время.

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

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

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

Еще одна ситуация, приводящая к утечкам памяти и отказу системы, называется «состояние гонки» (Race Condition), или «конкуренция». Игровые платформы используют многоядерные ЦП, в которых происходят многопоточные вычисления. Последовательность вычислений, происходящих на одном ядре, называется потоком. Разные вычисления занимают разное время. Происходящее в разных потоках обычно неизвестно другим потокам, и для корректной работы приложения существуют функции, которые синхронизируют полученные в разных потоках результаты и тем самым обеспечивают целостность данных.

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

Результаты вычисления потока записываются в память. Любой записанный в памяти блок информации имеет «адрес» – условное обозначение того, где именно записана информация. Из-за неконтролируемого доступа к общей памяти состояние гонки может приводить к различным ошибкам. Ошибка происходит из-за того, что запись потока по адресу, где уже есть записанные данные, происходит быстрее, чем предыдущие данные могут быть прочитаны. Это и есть состояние гонки. При этом попытка повторения ошибки в схожих условиях работы в целях отладки и исправления может оказаться безуспешной. Тем не менее есть шанс появления такой ситуации, как и «снежного кома». Метод тестирования – длительная работа приложения под контролем внешних программ-мониторов, которые отслеживают состояние тестируемого приложения.

Пиковые нагрузки

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

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

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

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

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

Отказ, падение, краш (Crash)

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

• Попытки чтения или записи памяти, которая не предназначена для чтения или записи этим приложением.

• Попытка выполнить привилегированные или недействительные команды.

• Попытки выполнить операции ввода-вывода на устройствах, к которым в приложении нет разрешения на доступ.

• Попытка получить доступ к другим системным ресурсам, к которым у приложения нет разрешения.

Отказ в игре. Snowrunner © 2020, Saber Interactive

Реакция на отказ (краш)

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

Чтобы ответить на эти вопросы, мы должны искусственно вызвать зависание или отказ приложения. Мы не будем использовать многочасовой сценарий, при котором приложение будет работать с перегрузкой. Это состояние системы мы будем форсировать, намеренно увеличивая величину пиковой нагрузки или продолжительность такого пика. Например, если в нормальных условиях приложение должно пережить пик в 200 % от расчетной нагрузки длительностью 1 минуту, то здесь пик будет 800 % и 15 минут.

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

После отказа системы проверяются целостность данных (падение не должно повредить ресурсы), возможность приложения запуститься снова и др.

Этот особый вид тестирования не связан напрямую с поиском дефектов, а задача тестировщика в этом случае – узнать предел производительности тестируемой системы, то есть испытать игровой продукт в ситуации, когда нагрузки на него в используемых сценариях тестирования достигают своего пика[34]. Например, на игровом сервере одновременно находятся несколько тысяч игроков. Однако не всегда нагрузочное тестирование может быть связано с многопользовательскими играми.

Нагрузочное тестирование может проводиться по-разному:

1. с применением автоматизированного тестирования и дополнительного программного обеспечения;

2. в рамках плейтестов большой группой тестировщиков;

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

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

Ключевыми метриками в игровом тестировании называют:

• время отклика (например, на пользователя, время на загрузку ресурсов);

• потребление ресурсов (например, загрузка процессора, памяти, пропускная способность сети, сетевая задержка, доступное место на диске, интенсивность подсистемы ввода-вывода);

• время обработки пакетных операций (например, время ожидания, время обработки, время полного выполнения операций, время ответа базы данных);

• время на выполнения операций (например, для вставки, чтения, обновления и удаления данных).

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

Методы, используемые при анализе, могут включать:

• сравнение результатов с заявленными требованиями;

• определение тенденций в результатах;

• выявление ошибок;

• сравнение ожидаемого и полученного результатов;

• сравнение результатов с результатами предыдущих испытаний.

Понимание связи между метриками помогает понять, в какой момент производительность системы начинает снижаться. Например, какое количество запросов в секунду было обработано, когда загрузка процессора достигла 90 % и работа системы замедлилась?

Анализ может помочь определить причины снижения производительности или отказа, а проведение повторного тестирования – устранило ли эту причину внесение исправлений.

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

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

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

1. Перевод текстов: игровые диалоги, субтитры, всплывающие подсказки, описания и сообщения, имена персонажей, название предметов, заставок, пунктов меню.

2. Перерисовка графических файлов: изображения, символика, текстуры.

3. Подбор актеров, дублирование и запись звуковых файлов.

4. Поддержка технических требований.

5. Поддержка правовых требований региона.

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

В Steam указывается, какие локализации поддерживает игра

Тестирование локализации – это очень большая тема, достойная отдельной книги. Я постараюсь осветить лишь основные моменты; ты найдешь больше информации по ссылкам и литературе в конце книги.

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

Перевод текстов

В тестирование локализации входит проверка правильности переведенного контента, различных элементов интерфейса, ошибок и системных сообщений, проверка раздела FAQ/Help и вспомогательной документации.

Цель проводимого тестирования перевода – проверка контента игры (включая интерфейса игры, субтитров, реплик персонажей и т. д.) на наличие ошибок перевода.

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

• Ошибки формата чисел, денежных единиц, календаря, дат

• Ошибки, связанные с адресами, телефонами

• Некорректное использование и конвертация единиц измерения или валют

Другими словами, сообщение в игре «Вы движетесь со скоростью 62 мили в час» может вызвать непонимание у игрока из России, а сообщение «Вы движетесь со скоростью 100 километров в час» приведет в ступор игрока из США. В таких случаях необходимо изменять не только цифру, но и формулу расчета в зависимости от локализации.

• Отображение числовой информации

• Ошибки перевода имен собственных

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

То же касается:

• названий исторических событий;

• праздников;

• реалий;

• пословиц и поговорок;

• топонимов (географических названий);

• просторечной и ненормативной лексики;

• аббревиатур.

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

• торговая марка;

• логотип;

• сокращение;

• наименование товара (например, продукты питания – сэндвич, гамбургер, автомобили – джип, кроссовер, одежда – блейзер, макинтош, техника – смартфон. Иными словами, англицизмы, вошедшие в другие языки).

• Искажение или игнорирование особых символов (например, неправильное отображение диакритических знаков во французском, иврите, арабском)

• Несоответствие перевода ситуации

Ситуация, когда перевод выглядит смешно или чужеродно, обычно возникает из-за того, что переводчикам приходится работать, не понимая контекста, в котором произносится та или иная фраза. Отсюда и возникают легендарное «Потрачено!»[35] как перевод «Wasted» и масса других, которые неизбежно становятся мемами.

• Использование фраз или слов, которые могут восприниматься как оскорбление

Иногда даже не сами слова, а их употребление в неуместном контексте может спровоцировать большой скандал. В файтинге Kakuto Chojin разработчики назвали одного из героев Асад. Он проводит бои на ринге, оформленном в арабском стиле, а в музыкальный трек вставлено пение муллы, в котором явно слышна фраза «Allah Akbar». При попытке выйти на ближневосточный рынок локализаторы решили, что эта фраза привлечет игроков. Эффект оказался прямо противоположным: исламское общество посчитало оскорблением использование священной фразы в такой ситуации. Во всех исламских странах игра была запрещена.

А игра Devotion была запрещена в Китае после того, как проверяющие увидели в ней оскорбительные послания в адрес Председателя Компартии КНР. На одной из карт были размещены иероглифы с именем Си Цзиньпина и с Винни-Пухом, с которым его ассоциируют.

Перерисовка графических файлов: изображения, символика, текстуры

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

Разработчики решили, что проще сделать все дорожные знаки в игре изображениями, локализаторы решили оставить все как есть. Test Drive Unlimited © 2006, Eden Games

Подбор актеров, дублирование и запись звуковых файлов

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

• Неестественно звучащая речь

Проблема возникает, когда реплики персонажей игры озвучивались в разное время, а затем соединялись в диалоге на стадии производства. В итоге полученные реплики звучат неестественно, с разными интонацией и тембром. Проблема усугубляется, когда актеры не знают контекст реплики или произносят фразы с излишней театральностью. Похожая ситуация наблюдалась с русской локализацией The Elder Scrolls V: Skyrim.

• Неподходящие голоса актеров озвучки

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

• Национальные и индивидуальные особенности речи персонажей

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

Поддержка технических требований локализации

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

• Искаженные символы (Mojibake, Garbage characters)

Речь идет о появлении искаженного текста в результате выбора неправильной кодировки символов. Он выглядит как набор символов из другой системы письма, как правило, совершенно нечитаемые. Например, фраза «База захвачена!» с исходной кодировкой Windows-1251 при декодировании в ISO 8859-1 будет выглядеть как «Áàçà çàõâà÷åíà!»

Не поддерживается шрифт или кодировка. Minecraft © 2011, Mojang Studios

• Локализованный текст не помещается в отведенные границы (обрезается, появляется скроллинг)

Нередко перевод слова с английского языка требует большее количество символов из-за того, что слова в английском существенно короче, чем во многих других языках. Например, английское «Reload now» содержит в себе 10 символов, а на русском соответствующий этому «Перезагрузите сейчас» – 20 символов, в два раза больше. И если на кнопке нет достаточно места для 20 символов, то строка не может уместиться целиком.

В строке не хватает места для большого количества символов на другом языке. WWZ © 2017, Saber Interactive

• Смещение/искажение текста и элементов интерфейса

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

• Перекрытие/наложение

Два или несколько элементов после локализации интерфейса перекрывают друг друга.

• Неверный шрифт/размер

В разных регионах используются разные шрифты и размеры по умолчанию. Например, в азиатских странах обычно используют шрифт размера 9 по умолчанию, а в США – шрифт размера 8.

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

• Неправильное направление текста

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

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

Пример перекрытия. Mudrunner © 2017, Saber Interactive

• Неправильные «горячие» клавиши

Проблемы с «горячими» клавишами могут быть следующими:

· потерянная «горячая» клавиша (при локализации забыли назначить «горячую» клавишу, и в локализованной игре отсутствует возможность использовать этот функционал);

· дубликат «горячей» клавиши (используются две «горячих» клавиши для выполнения одного и того же действия);

· «горячая» клавиша не работает.

• Переменные в тексте и их особенности

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

Одна из наиболее распространенных ошибок разработчиков – делить на части предложения, содержащие переменные. Например, используется переменная для генерации боевых сообщений вида «You take X hit points». Если поместить части предложения («You take» и «X hit points») в разных местах кода, не предупредив об их взаимосвязанности, после перевода можно легко получить следующий текст: «Вы берете 2 единицы урона» вместо «Вы получаете 2 единицы урона».

Существует понятие «грамматический строй целевого языка», и это едва ли не главный краеугольный камень локализации. Зачастую при добавлении переменных разработчики не учитывают, что в ряде языков их значение может менять построение фразы. Речь идет не только об окончаниях в русском языке (1 единица, 3 единицы, 10 единиц), но и, скажем, об артиклях в немецком.

Когда переменных несколько, иногда нельзя поменять их местами (хотя обычно это признак не очень хорошо написанного продукта). Но переводчикам эта возможность нужна, поскольку в разных языках различные правила построения предложений: если в оригинале сначала стоит переменная X, а потом Y, то в иностранном порядок может быть иной – Y и затем X. Рассмотрим пример с теми же боевыми сообщениями: «You take 10 hit points, 3 points blocked». Красивый перевод будет иметь вид «Вы заблокировали 3 единицы урона, получив 10 единиц». Но если возможности менять переменные местами нет, то смысл фразы меняется в корне.

• Рассинхронизация звукового ряда оригинала и перевода

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

Обратный случай: в русской локализации The Witcher 3: The Wild Hunt длина фраз в диалогах зачастую сильно отличается от оригинала. Компенсируется такая разница технически: реплики персонажей ускоряются или замедляются.

• Несовпадение звучащей речи и субтитров

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

• Отсутствие/порча файлов перевода в папках назначения

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

Поддержка требований производителей аппаратной части

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

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

Поддержка правовых требований региона

Во время тестирования локализации необходимо учитывать правовые требования, касающиеся возраста игроков, различных стран и регионов. Например, в России совершеннолетие наступает в 18 лет, в США в зависимости от штата этот возраст варьируется от 18 до 21 года, а в Японии молодые люди считаются совершеннолетними с 20 лет. И это важно учитывать.

Таблица возрастных ограничений в зависимости от контента игры

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

1. ACB (Австралия): M

2. РСВР (Россия): 18+

3. PEGI: 12+

4. ESRB: T – для подростков

5. USK (Германия): 6+

В России игре присвоен самый суровый рейтинг. По всей видимости, причина столь жесткого суждения в том, что цензоры увидели в ней нарушение следующего пункта закона о защите детей: «К информации, запрещенной для распространения среди детей, относится информация, отрицающая семейные ценности, пропагандирующая нетрадиционные сексуальные отношения и формирующая неуважение к родителям и/или другим членам семьи»[36].

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

• Изображение крови (неважно какого цвета)

• Трупы убитых должны исчезать мгновенно

• Изображение женоподобных мужчин

• Порнографические сцены

• Название игры совпадает с названием ранее изданной игры

• Изображения вульгарных сцен и элементов, а также того, что существенно расходится с понятиями базовых социалистических ценностей (что бы это ни значило)

• Азартные игры

• Предрассудки и предсказания будущего

• Ограничения на ежедневное использование «коробок добычи» (loot-box, лутбоксы) и др.

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

К другим ограничениям законодательного порядка можно отнести следующие.

• Изображение нацистской символики и пропаганду нацизма

• Изображение символики различных международных организаций (например, Красный Крест)

• Расовая дискриминация

• Неуважение к религии

• Пропаганда наркотиков

• Реклама запрещенных напитков и продуктов (например, энергетиков)

• Порнография

• Информация об изготовлении оружия, взрывчатых веществ

• Информация о различных способах суицида

• Информация, содержащую описание или изображение сексуального насилия

• Лимит времени для нахождения в игре несовершеннолетних

• Лимит суммы денег на покупку внутриигрового контента

• Наличие системы родительского контроля и т. д.

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

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

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

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

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

Известно настороженное отношение некоторых народов к цифре 13 как символу неудачи. А в Китае и Южной Корее такая участь постигла цифру 4, произношение которой созвучно со словом «смерть». В Японии люди стараются избегать цифры 9, которая произносится так же как «страдание». Для христиан число 666 традиционно ассоциируется с Антихристом и злом в целом. Одним словом, иррациональный страх перед некоторыми цифрами есть у многих народов, и это необходимо учитывать при локализации игры для конкретного рынка и ее последующего тестирования.

Все народы относятся с уважением к собственной истории. Часто некоторые исторические события, особенно военные конфликты, могут интерпретироваться разными народами по-разному. Известна история с неудачной попыткой Age of Empires выйти на южнокорейский рынок с эпизодом, когда японское вторжение в Корею закончилось захватом страны практически без сопротивления. Несмотря на достоверность этих событий, корейцы считают этот исторический эпизод постыдным, и игра была допущена на рынок только после того, как разработчики переделали эту часть, добавив героическое сопротивление корейцев. В России вызовут возмущение игры, основанные на событиях Второй мировой войны, где Берлин захватывают американцы, которые также «героически» приписывают себе и освобождение концлагеря Освенцим.

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

1. Юмор

2. Религия, включая оккультизм

3. Отношение к инвалидам, сексуальным меньшинствам, животным, детям и т. д.

4. Сексуальные отношения

5. Предрассудки и стереотипы, связанные с культурой и самими людьми

6. Терроризм

Политика, в том числе специфический взгляд разных стран на историю

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

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

Но подумай: точно ли ты не можешь получить никакого опыта до того, как придешь на собеседование? Конечно можешь! Во-первых, многие компании предоставляют возможность пройти производственную практику. Во-вторых, ты можешь предложить свои услуги (бесплатные) по тестированию игрового проекта, например, инди-разработчикам[42] и таким образом сформировать портфолио для собеседования. Такие проекты представлены на любой игровой выставке или конференции по разработке игр.

Другой источник первоначального опыта – краудтестинговые платформы и биржи фрилансеров. Зарегистрировавшись там, ты можешь предлагать свои услуги по тестированию и продолжать формировать портфолио.

Наконец, еще один источник опыта – открытые и закрытые бета-тестирования игровых продуктов (ОБТ и ЗБТ). Будем откровенны: для 95 %, если не больше, игроков ОБТ – это просто способ познакомиться с игровым продуктом раньше других. Но ты должен войти в оставшиеся проценты, потому что тестировать продукт ты будешь по-настоящему, с оформлением баг-репортов и предоставлением обратной связи разработчикам. Потому что твоя задача – приобрести опыт и подтвердить это своими знаниями и навыками на собеседовании для получения работы своей мечты. Так что записывайся на ближайший бета-тест, и вперед на поиск багов!

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

• Информация о проектах, в которых ты принимал участие как тестировщик, с подробным описанием обязанностей на проекте (составление тест-плана, проектирование тест-кейсов, выполнение тестирования и т. д.)

• Время работы на проекте

• Информация о том, была ли это командная или индивидуальная работа

• Виды и типы тестирования, которые ты выполнял (функциональное, нефункциональное)

• Функционал, который тестировался

• Инструментарий, который ты использовал, включая инструменты управления тестированием и т. д.

• Модель, которая использовалась в разработке и тестировании игрового продукта

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

Естественно, ты не должен включать в портфолио информацию, если подписывал NDA или разработчик прямо не разрешил использовать информацию для портфолио. О том, можно ли будет использовать информацию с проекта в портфолио, разработчика нужно спросить заранее.

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

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

Посмотрим на условия, которые влияют на «стоимость» специалиста.

1. Уникальные навыки в профессиональной сфере

2. Экспертные знания в профессиональной и смежных отраслях

3. Отличное владение актуальными инструментами

4. Значительный опыт участия в успешных проектах

5. Развитые личные качества (софтскиллс – коммуникативные навыки, способность к обучению и адаптации, умение работать в команде и т. д.)

6. Незначительное количество специалистов этой профессии на рынке труда

7. Повышенный спрос на специалистов данной профессии

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

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

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

Первый из них – «Сколькополучатель» от hh.ru. С его помощью ты сможешь узнать о действующих на рынке воронках дохода. Все, что нужно сделать, – выбрать регион, интересующую тебя профессиональную область, роль, стаж и должность и нажать кнопку «Узнать уровень дохода». Ты тут же получишь данные об уровне зарплат при наличии открытых вакансий на hh.ru.

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

1. Нужно зайти на hh.ru, в верхнем левом углу выбрать вкладку «Соискатели» и нажать на значок фильтров в строке поиска.

2. В открывшемся окне установи нужные фильтры. Если нужно, используй язык поисковых запросов для конкретизации поиска. Например, заключив поисковый запрос в кавычки – «Тестировщик игр», – ты получишь результаты, включающие только это сочетание. Ты также можешь исключить из поиска ненужные слова, выбрать конкретный регион и просматривать только вакансии, где указано финансовое предложение работодателя.

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

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

1. Резюме не должно содержать грамматических, пунктуационных и других ошибок. Резюме – это характеристика человека. Сразу заявляя о собственной безграмотности, не стоит рассчитывать на то, что к тебе проявят интерес люди, работа и профессия которых – обнаружение ошибок.

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

3. Используй больше конкретики, особенно когда это касается твоего профессионального опыта. Фраза «занимался тестированием игр» гораздо хуже, чем «участвовал в тестировании производительности и совместимости игр для ПК».

4. Самое важное напиши в самом начале. Рекрутер должен вдумчиво прочитать много резюме в день. И часто, не найдя нужной информации на первой странице, он теряет внимательность и интерес к соискателю. Поэтому о своих самых значительных достижениях, навыках и знаниях стоит написать в самом начале.

5. Специалист по найму персонала будет тебе очень признателен, если ты структурируешь свое резюме. Читать сплошной текст и выискивать в нем ответы на вопросы – то еще занятие! Попробуй использовать стандартную структуру.

• Шапка: здесь нужно разместить свою фамилию и имя, способ связи, возраст и город проживания.

• Технические навыки: напиши об инструментарии тестирования, которым ты владеешь на хорошем уровне.

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

• Образование: Перечисли оконченные и неоконченные учебные заведения (особенно профильные), курсы по тестированию и в смежных областях, которые ты проходил. Но не нужно писать о средних баллах и цвете диплома, работодателя это вряд ли заинтересует.

• Дополнительная информация: перечисли другие свои навыки, которые могут быть полезны работодателю. Вряд ли работодатель придет в восторг от того, что у тебя есть права категории А и B. Но вот владение английским языком на уровне «Upper-Intermediate» и сертификат ISTQB® GaMe Testing точно выделит тебя из массы других соискателей.

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

7. Расшифровывай аббревиатуры. Это прежде всего касается названий учебных заведений. Если МГУ, МФТИ, ISTQB рекрутеры способны расшифровать сами, то менее известные комбинации букв точно поставят их в тупик.

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

9. В идеале можно написать сопроводительное письмо к своему CV, в котором подробно изложить, почему ты направляешь резюме именно в эту компанию. Это точно поможет лучше продемонстрировать твою заинтересованность в вакансии.

Пример резюме ты найдешь в конце этой книги. Можешь использовать его как образец для написания своего.

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

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

2. Не нужно говорить позвонившему тебе рекрутеру, что ты никак не можешь встретиться с ним в назначенное время, потому что будешь проходить собеседование в другом месте; когда освободишься, то будешь готов немедленно встретиться. Поверь: больше ты этого человека не услышишь.

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

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

1. Найден более подходящий кандидат на должность.

2. Не было представлено резюме соискателя, позволяющее оценить его профессиональные качества.

3. Вакансия закрылась.

4. Должность была предложена сотруднику компании.

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

Его можно изобразить в виде схемы.

Примерный процесс приобретения первой работы

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

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

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

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

Ниже приведен список базовых навыков и знаний, обязательных для любого начинающего тестировщика в области игрового тестирования.

пайплайн[43]

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

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

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

1. Образование

2. Опыт работы

3. Определенный уровень профессиональных знаний и навыков

4. Дополнительные знания, требующиеся для выполнения конкретной работы (например, знание английского языка для тестировщика, занимающегося сертификационным тестированием приложений для игровых консолей)

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

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

Это будет твоя первая встреча с представителем компании. Ее цели следующие.

1. Понять, насколько твой опыт, знания и навыки подходят к требованиям вакансии. Рекрутер будет задавать тебе разные вопросы. Цель некоторых тебе может быть непонятной, потому что люди, составляя резюме, в попытках сделать его максимально привлекательным частенько приукрашивают действительность. Задача HR-специалиста на этом этапе – понять, насколько ты «приукрасил действительность» или, наоборот, упустил важные детали, которые резко повышают твою профессиональную ценность.

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

3. Узнать, насколько ты действительно открыт для предложения компании и насколько мотивирован работать в игровой индустрии.

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

Ниже приведен список вопросов, которые ты можешь услышать на предварительном собеседовании.

Общие

1. Расскажите немного о себе. Почему решили сменить сферу деятельности (если это не первая работа)?

2. Какое у вас образование?

3. Проходили ли вы какое-то обучение, связанное с тестированием?

4. Почему выбрали именно нашу компанию?

5. Чем для вас интересна профессия тестировщика?

6. Что для вас приоритетно в работе? Зарплата? Коллектив? Уютный офис? Удобное расположение? Другое?

7. Какие, по вашему мнению, есть возможности профессионального роста для тестировщика?

8. Есть ли у вас опыт работы, связанный с игровой индустрией?

9. Какие у вас зарплатные ожидания?

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

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

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

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

Пирамида мотивации сотрудников

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

По игровому тестированию

1. Зачем нужны тестировщики при разработке игр? Какие у них обязанности?

2. Как выглядит процесс тестирования? Из каких этапов он может состоять?

3. Гарантирует ли тестирование профессиональной командой отсутствие дефектов в игре?

4. Какие жанры игр вы знаете? Какие из них ваши любимые и почему?

5. На что влияет жанр игры в процессе тестирования?

6. Если бы вам пришлось тестировать игру вашего любимого жанра, что бы вы стали проверять в первую очередь? Почему?

7. Если нет письменных требований, откуда можно получить информацию о том, как должен функционировать игровой продукт?

8. Какие критерии (критерии входа) должны быть выполнены до начала тестирования?

9. Чем игра отличается от прикладного ПО?

10. Что такое ошибка в игре?

11. Приведите пример бага, который вы встречали во время игры. Что, по-вашему, привело к возникновению этого дефекта?

12. Какие еще бывают баги? Какие из тех, что вы назвали, вы бы определили как самые критичные для игры? Почему?

13. Какие виды тестовой документации вы знаете?

14. Что такое тест-план? Для чего он нужен?

15. Что такое чек-лист? Для чего он нужен?

16. Что такое тест-кейс? Для чего он нужен?

17. Что такое отчет о дефектах (баг-репорт)? Для чего он нужен?

18. Как вы себе представляете жизненный цикл дефекта с момента его документирования?

19. Почему считается, что тестирование нужно начинать как можно раньше?

20. Можете ли вы привести примеры звуковых дефектов в игре? Дефектов уровня? Дефектов локализации?

По игровой разработке

21. Какие виды игровой документации вы знаете? Для чего она разрабатывается?

22. Знаете ли вы основные этапы разработки игры?

23. Что такое игровой движок? Какие движки вы знаете?

24. Знаете ли вы какие-либо модели разработки ПО? В чем между ними разница?

25. Можете ли кратко рассказать об основных этапах создания 3D-модели персонажа для игры?

26. Можете ли вы привести примеры основных игровых механик?

По игровому «железу»

27. На какой игровой платформе вы обычно играете? Какие платформы вы знаете? В чем между ними различия?

28. От каких компонентов PC больше всего зависит производительность в игре?

29. Какие виды игровых контроллеров вы знаете?

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

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

Вот примеры некоторых таких задач.

1. Перед вами два мотка веревки. Если взять их концы и поджечь, то каждый моток сгорает за один час. Вопрос: как правильно отмерить 45 минут, применяя два таких мотка веревки, при условии, что веревку нельзя делить?

Ответ на задачу. Одновременно поджечь один моток с двух концов, а второй – с одной стороны. Ровно через 30 минут первый моток полностью выгорит, а второму останется гореть 30 минут. Чтобы получить желаемые 15 минут, его придется снова поджечь с обеих сторон.

2. Есть три стакана: с черникой, земляникой и смесью ягод. Каждый стакан помечен неверно. Вы можете достать одну ягоду из одного стакана, при этом заглядывать внутрь нельзя. Как узнать содержимое всех стаканов и правильно расставить метки?

Ответ на задачу. Так как стаканы подписаны неверно, ни в одном из них не лежит то, что указано на пометках. Стоит начать с надписи смесь (С). Достанем ягоду. Черника? Значит, этот стакан с черникой. Остаются два стакана с пометкой черника (Ч) и земляника (З). В стакане (З) может быть черника или смесь. Но так как чернику мы уже нашли, то в стакане с пометкой (З) может быть только смесь. В последнем стакане с пометкой (Ч) останется земляника.

3. У вас в запасе бесконечный источник воды, а также два сосуда – на 5 литров и 3 литра. Как отмерить 4 литра, используя только этот инвентарь?

Ответ на задачу. Для начала необходимо наполнить емкость в 5 литров и вылить часть воды в трехлитровый сосуд. Сейчас в меньшем сосуде находится 3 литра, в большом – 2. Затем нужно опустошить маленькую емкость и перелить в него оставшуюся воду из большого. После этого заново наполнить пятилитровый сосуд и перелить из него воду в трехлитровую емкость. За счет уже имеющихся 2 литров доливать придется всего литр, а в большей емкости останется 4 литра.

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

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

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

Наталья Шевякова, HR и психолог Bytex

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

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

2. Разберитесь в основах тестирования. Необходимо понимать, что такое тест-кейсы, как оформлять баг-репорты, и основы методологий тестирования (например, ручное и автоматизированное тестирование).

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

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

5. Улучшайте свои коммуникативные навыки. Тестировщику важно уметь четко и ясно описывать обнаруженные проблемы, а также эффективно работать в команде.

6. Подготовьте примеры своей работы. Если у вас есть опыт тестирования (даже если это личные проекты), подготовьте примеры баг-репортов или описаний тест-кейсов.

7. Изучите компанию и продукт. Перед собеседованием узнайте как можно больше о компании и тестируемой игре. Это покажет вашу заинтересованность и готовность к работе именно с их продуктом.

8. Будьте готовы к практическим заданиям. На собеседовании могут предложить выполнить тестовое задание – например, найти баги в игре или написать тест-кейс.

9. Проявите энтузиазм и готовность к обучению. Показывайте, что вы готовы учиться и развиваться в данной области.

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

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

Но что делать, если пришел отказ?

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

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

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

• Адекватно ли ты оценил себя на конкретном рынке труда?

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

• Структурированы ли твои навыки и достижения в резюме?

Проверь еще раз, отвечают ли указанные тобой навыки и знания требованиям конкретной вакансии.

• Хорошо ли ты презентуешь себя на встрече?

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

• Умеешь ли ты отвечать на популярные вопросы нанимателя?

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

• Не мешают ли соцсети или активность в Интернете вашей карьере?

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

• Подходящее ли фото ты выбрал для резюме?

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

• Соблюдаешь ли ты правила прохождения интервью: не опаздываешь ли, уместен ли твой внешний вид?

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

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

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

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

Схема сертификации тестировщиков International Software Testing Qualification Board

До сих пор нет единого мнения, стоит ли разделять тест-анализ и тест-дизайн. Однако между ними есть разница.

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

• проанализировать пользовательские истории и продуктовые требования;

• описать в удобном виде и проанализировать объект тестирования (то есть игровой продукт);

• выбрать методы тестирования в конкретной тестовой среде;

• проанализировать тестовое покрытие;

• приоритизировать задачи тестирования.

На основе целей и задач такого специалиста я могу описать эту специализацию примерно так следующим образом.

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

Тест-аналитик – это специалист, планирующий процесс тестирования на основе анализа продукта

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

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

2. Тест-дизайнер на основании информации, полученной от тест-аналитика, разрабатывает тест-кейсы, применяя соответствующие техники тест-дизайна для оптимизации ресурсов.

3. Тестировщик проводит тестирование по уже готовым тест-кейсам и составляет отчет о дефектах.

Однако в реальности такое разделение на специализации встречается довольно редко (только в очень крупных компаниях). Поэтому зачастую анализ и дизайн выполняет один специалист. Я буду здесь называть его тест-аналитиком.

Одна из задач тест-аналитика – определить методы проведения тестирования продукта. Для этого он использует разные инструменты, облегчающие восприятие и анализ объекта тестирования, – например, интеллект-карту (mind map). Ниже представлен пример интеллект-карты для описания одного из элементов игрового продукта.

Процесс построения интеллект-карты связан с декомпозицией продукта на мельчайшие части. При этом есть важное правило декомпозиции: все объекты одного уровня, являющиеся компонентами одной системы (то есть составляющими объекта верхнего уровня), объединяет один общий признак. Например, компонент «Метательное оружие» состоит из подкомпонентов «Лук» и «Копье», а компонент «Пистолеты» – из «Walther» и «Beretta». Декомпозиция нужна для более ясной визуализации продукта и для увеличения покрытия функционала игрового продукта тестами. Описывая процесс тестирования игровых механик, мы говорили о декомпозиции игрового продукта на пользовательские истории с учетом жанровой принадлежности. Глубокая компонентная декомпозиция игры позволяет ясно увидеть объем, который нужно покрыть проверками. Глубина декомпозиции должна быть такова, чтобы четко увидеть все функциональные и нефункциональные области, требующие тестирования.

Пример части интеллект-карты

Пример декомпозиции по объективному признаку

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

Приоритизация чаще всего основывается на следующих факторах.

1. Требования заказчика (владельца продукта).

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

3. Временные ограничения. Если идет предрелизное тестирование, тестировать нужно самый важный для этого релиза функционал.

Тест-аналитик может использовать следующие методы приоритизации.

1. Оптимизация тестов (в том числе их количества).

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

2. Оптимизация рабочих процессов.

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

3. Применение инструментов.

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

4. Выбор стратегии тестирования.

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

5. Применение автоматизированного тестирования.

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

После анализа несколько десятков вакансий «Тест-аналитик» у меня получился следующий список ожиданий работодателя от такого специалиста.

• Общее понимание жизненного цикла разработки ПО, особенностей разработки игр и места контроля качества в нем

• Анализ требований, технической документации и тестового покрытия

• Организация сбора и автоматизации игровых данных

• Контроль полноты покрытия требований

• Декомпозиция требований

• Оценка покрытия функционала

• Приоритизация тест-кейсов

• Знание и умение использовать техники тест-дизайна

• Составление графика тестирования

• Выявление причин пропуска инцидентов в релизных сборках

• Понимание принципов командной разработки продукта, в частности игрового

• Передача результатов и составление рекомендаций для заинтересованных лиц

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

Если ты решил развивать навыки программирования, но не хочешь уходить из тестирования, твой вариант карьерного роста – SDET (Software Development Engineer in Test).

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

SDET – это разработчик, специализирующийся на тестировании

Часто такого специалиста путают с тестировщиком, занимающимся автоматизированным тестированием.

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

Другими словами, от SDET в компании, которая занимается разработкой и тестированием игровых продуктов, будут ожидать:

• понимания сути процесса тестирования и пайплайнов проекта;

• способности осуществить проверку работоспособности автотестов;

• умения разрабатывать и поддерживать тест-кейсы для автотестов;

• планирования и реализации автотестов;

• способности разрабатывать фреймворки[44] автоматизации тестирования;

• автоматизации тест-кейсов с использованием фреймворков;

• разработки вспомогательных инструментов для ручного и исследовательского тестирования;

• хорошего владения Python;

• хорошего владения C#/C++;

• помощи в устранении дефектов;

• способности настраивать базы данных;

• взаимодействия со всеми заинтересованными лицами проекта.

Как ты заметил, SDET – это суперпрокачанный QA-инженер. Он играет важную роль в обеспечении высокого качества ПО, помогает сократить время на тестирование и улучшить процесс разработки.

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

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

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

Тест-менеджер (QA-менеджер) – управленец высшего звена в тестировании

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

1. Планирование и организацию тестирования, включая определение приоритетов, составление тестовых планов, оценку рисков и разработку стратегии тестирования.

Определение приоритетов тестирования – это процесс определения того, какие функции или части приложения должны быть протестированы в первую очередь.

Этот процесс включает в себя несколько шагов.

• Оценка рисков

• Анализ функциональности

• Планирование времени и других ресурсов

• Обработку обратной связи от клиентов

• Определение зависимостей между функциями приложения для понимания того, что тестируется в первую очередь

Эти шаги используются для разработки плана тестирования, который позволит максимально эффективно использовать ресурсы.

2. Управление процессом тестирования, включая назначение задач тестировщикам, контроль за выполнением тестов, мониторинг результатов тестирования и своевременное информирование о проблемах.

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

Можно кратко выделить важнейшие этапы управления процессом тестирования.

• Определение целей и стратегии тестирования. Важно четко определить, чего нужно достичь в результате тестирования, а также какие методы и инструменты использовать.

• Создание тест-планов и тест-кейсов. На этом этапе необходимо определить, какие тесты нужно провести, какие данные использовать и какие ожидаемые результаты. Тест-план должен быть основным документом, описывающим все процессы тестирования.

• Выбор и управление ресурсами. Необходимо определить, какие ресурсы понадобятся для тестирования, включая оборудование, программное обеспечение и персонал. Кроме того, необходимо контролировать расходы на тестирование и управлять временем.

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

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

• Управление процессом тестирования. Требует внимания к множеству деталей и умения координировать различные аспекты всего процесса тестирования.

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

Для обеспечения эффективной координации тестировщиков и разработчиков на проекте используются следующие подходы.

• Раннее вовлечение тестировщиков в проект. Тестировщики могут принимать участие во всех этапах проекта, начиная с планирования, анализа требований, проектирования и т. д. Это поможет им понять цели проекта, а также обеспечить более раннее выявление и устранение дефектов.

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

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

• Установление единой системы работы с багами. Разработчики и тестировщики должны иметь доступ к общей системе управления багами, в которой они могут фиксировать, отслеживать и устранять дефекты. Это поможет избежать дублирования работы и снизить время на устранение ошибок.

• Разработка тест-кейсов. Тестировщики должны иметь доступ к требованиям проекта, чтобы разработать тест-кейсы, которые помогут выявить дефекты в соответствии с этими требованиями. Разработчики должны иметь доступ к результатам тестирования, чтобы убедиться в соответствии своего кода требованиям.

• Установление общих целей и приоритетов. Разработчики и тестировщики должны иметь общее понимание целей проекта и приоритетов задач. Это поможет им более эффективно сотрудничать, сосредотачиваясь на наиболее важных для проекта задачах.

4. Оценка качества программного продукта и разработка мероприятий по улучшению его качества, включая проведение анализа дефектов и определение причин ошибок.

Первопричина – это корень проблемы, которая приводит к дефекту. Я уже говорил о том, что определение первопричин дефектов в игровых продуктах – важная задача для тестировщиков и навык, который приходит с опытом.

5. Оценка и выбор инструментов тестирования и управления тестированием.

При оценке инструментов необходимо учитывать следующие факторы.

• Тип игры: в зависимости от него могут потребоваться разные инструменты тестирования. Например, инструменты тестирования для шутера от первого лица могут отличаться от инструментов для игры-головоломки.

• Платформа: выбранные инструменты тестирования должны быть совместимы с платформами, на которых разрабатывается игра, такими как РС, консоли, мобильные устройства и т. д.

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

• Цели тестирования. Необходимо определить, что конкретно должно быть протестировано в игре: графика, звук, пользовательский интерфейс, игровой процесс или производительность. Затем нужно выбрать инструменты, предназначенные для этих областей.

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

• Совместимость. Выбранные инструменты должны быть совместимы с другими используемыми инструментами, такими как ПО для отслеживания ошибок, инструменты управления проектами и инструменты автоматизации.

6. Разработка отчетов о тестировании и документации, включая описание тест-кейсов, результаты тестирования и оценку качества.

Написание отчета о проведении тестирования компьютерной игры требует следования определенным правилам.

• Структура: отчет должен содержать введение, методику тестирования, результаты тестирования и заключение. Каждый раздел должен быть четко обозначен и иметь свой заголовок.

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

• Четкость и краткость. Краткие предложения и параграфы облегчают чтение и понимание информации.

• Объективность: отчет не должен содержать личных мнений или предубеждений. Описываются только факты и результаты тестирования.

• Детали тестирования: в отчете следует указать детали тестирования, включая инструменты и методы, использованные для проведения тестирования, количество участников тестирования, его продолжительность и т. д.

• Рекомендации: в отчете следует дать рекомендации по улучшению игры на основе результатов тестирования.

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

Ожидания работодателей к тест-менеджеру обычно включают в себя следующие.

• Опыт в области тестирования, чтобы понимать процесс тестирования и управлять им.

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

• Навыки управления проектами, чтобы планировать, координировать и контролировать процесс тестирования.

• Коммуникативные навыки для взаимодействия с различными участниками проекта, такими как разработчики, бизнес-аналитики, менеджеры и клиенты.

• Аналитические способности для анализа данных тестирования и принятия решений на основе этих данных.

• Опыт работы с автоматизацией тестирования может значительно повысить эффективность и качество тестирования.

• Сертификация в области тестирования типа ISTQB, чтобы продемонстрировать свои знания и навыки в этой области.

Тест-менеджер (руководитель тестирования, QA manager) – это фактически высшая ступень в иерархии тестировщиков.

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

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