Тестирование видеоигр, или Легкий способ попасть в геймдев

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

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

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

Миф № 2: лучшие тестировщики получаются из лучших игроков. Это не так. Да, тестировщики проводят сотни и тысячи часов за игрой, но, как правило, у них нет предпочтений, они «всеядны». Они исследователи. Им нравится копаться в играх, развиваться и получать достижения, а не совершенствоваться в искусстве дуэли. Тестирование – это дисциплина, умение переключаться в режим, в котором получение удовольствия от игрового процесса не является больше основным. Это способность проходить один и тот же путь десятки раз, отслеживая на нем малейшие дефекты. Кроме того, ты должен быть довольно настойчивым, потому что собираешься играть в сломанную и, возможно, скучную и часто незаконченную игру просто потому, что хочешь, чтобы она была качественной и доставляла удовольствие другим людям. Геймеры, которые ставят перед собой цель добиться победы и стать лучшим на игровой арене, скорее, испытают разочарование от такой работы.

Миф № 3: тестировщики – в подавляющем большинстве случаев мужчины. По собственному опыту скажем, что это утверждение не имеет под собой никаких оснований. По моим наблюдениям, пропорция скорее выглядит как 65 к 35 или даже 60 к 40 в пользу мужчин, но при этом девушки часто гораздо более успешны в профессии. Возможно, это связано с большей устойчивостью женской психики к стрессам, большей внимательностью к деталям, терпеливостью и настойчивостью.

Миф № 4: тестирование – это, несмотря ни на что, все-таки довольно легкое занятие. Со временем ты нарабатываешь некий алгоритм работы и все идет по накатанному. Это довольно странное заблуждение, потому что то же самое можно сказать вообще о любой профессии. Сказать можно вообще все что угодно. Важно, чтобы сказанное имело смысл. А смысл в том, что врач, принимая десяток пациентов ежедневно, несомненно, приобретает опыт и совершенствуется в профессии. Однако этот опыт не дает ему права назначать лечение одному пациенту просто на основании некоторой схожести симптомов с симптомами другого. Поэтому хороший доктор каждый раз очень тщательно проводит исследования и диагностику, чтобы лечение было наилучшим в каждом случае. Так и тестировщик пусть и знает особенности жанра тестируемого продукта, все равно проводит тщательную проверку всех областей и деталей, стараясь не упустить ошибок.

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

Освободившись от этих навязчивых мифов, ты теперь можешь приступить к освоению нелегкого ремесла игрового тестировщика. Я помогу тебе освоиться с важнейшими, фундаментальными принципами и подходами в нашей профессии, помогу даже подготовиться в сдаче экзамена и получения международного сертификата игрового тестировщика ISTQB® Certified Tester Game Testing. Но опыт ты должен будешь приобрести сам. И я очень рассчитываю, что по прошествии времени ты войдешь в число лучших специалистов в области игрового тестирования.

Глава 02. Самая большая ошибка – не исправлять ошибки

Чем больше надежд мы возлагаем, тем сильнее может быть разочарование…

Genshin Impact

• Что такое дефект?

• Чем дефекты отличаются друг от друга?

• Что такое баг-репорт и для чего он нужен?

• Что такое критичность дефекта и как ее правильно определить?

• Что такое приоритет дефекта?

• Что такое жизненный цикл дефекта?

• Когда и почему появляются дефекты?

• Как снизить риск их появления?

• Где место тестирования в разных моделях разработки?

• Как тестировщик взаимодействует с заинтересованными лицами проекта?

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

Пришло время поговорить о дефектах подробнее, ведь баг багу рознь. Один может запросто привести к крашу [10] игры, а другой будет выглядеть как «невинная» опечатка в слове на кнопке. «Какая разница? – скажешь ты. – Любой баг – это враг, которого нужно беспощадно уничтожать!» Это правда, но, как ты помнишь, над игрой могут трудиться множество людей, которые заняты множеством важных дел. И, наверное, они не будут очень рады, если каждый раз, получая от тебя отчет о дефектах, они будут видеть там бескомпромиссное «Свистать всех наверх! Бросайте все дела и срочно исправьте опечатку в меню!» Дефекты можно классифицировать по ряду признаков. Зачем это нужно? Чтобы лучше понимать, насколько большую опасность для проекта они представляют и как нужно с ними бороться. Другими словами, чтобы правильно определять их критичность.

10

Краш – полная поломка, аварийный сбой.

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

2.1. Отчет о дефекте (баг-репорт)

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

2.1.1. Атрибуты отчета о дефекте

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

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

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

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

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

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

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

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

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

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