Тестирование видеоигр, или Легкий способ попасть в геймдев
Александр Александрович Торговкин
Российский компьютерный бестселлер. Гейм-дизайн
Играть в игры и получать за это деньги? Звучит как работа мечты! Но чем на самом деле занимаются тестировщики?
Тестирование – критически важный этап при создании видеоигр, позволяющий разработчикам исправить ошибки и недочеты, а игрокам – сполна насладиться геймплеем.
На страницах книги ты найдешь ответы на самые важные вопросы о профессии QA-специалиста в области игровой разработки, множество практических советов, рекомендаций, а также разборы реальных кейсов из жизни компаний.
• Почему игры необходимо тестировать и чем они отличаются от другого ПО?
• Чем занимается тестировщик игр и что нужно знать, чтобы им стать?
• Какие бывают баги, почему они случаются и как с ними работать?
• Чем отличается тестирование игр для разных игровых платформ?
• Как начать карьеру в области тестирования и куда развиваться?
После прочтения книги ты станешь лучше понимать процесс продуктовой разработки, узнаешь все о работе тестировщика и сможешь внести свой вклад в создание видеоигры.
В формате А4 PDF сохранён издательский макет.
Александр Торговкин
Тестирование видеоигр, или Легкий способ попасть в геймдев
© Торговкин А.А., текст, 2024
© Оформление. ООО «Издательство «Эксмо», 2024
* * *
Благодарности
Автор выражает признательность людям, оказавшим помощь при подготовке этой книги.
Компании Saber Interactive[1 - Saber Interactive – международная компания по разработке и изданию компьютерных игр. Офисы разработки находятся в России, Армении, Испании, Беларуси, Швеции и Португалии. – Здесь и далее прим. авт.] и лично:
Виктору Гляненко
за веру в проект подготовки специалистов в области игрового тестирования, за поддержку при подготовке материалов и рецензирование книги;
Нине Резниченко
за массу полезных замечаний и жизненных историй, которые, несомненно, сделали изложение материала более интересным;
Даше Касимановой
за оценку материала, независимое мнение и помощь в структурировании материала;
Максу Филиппову
за энтузиазм при рецензировании материала и примеры из жизни тестировщика, без которых не удалось бы раскрыть всю суть профессии.
Компании Bytex[2 - Bytex – российская компания, специализирующаяся на тестировании компьютерных игр любого жанра на любых платформах.] и лично:
Вадиму Луковатому
за апробирование материала еще до публикации книги и подтверждение правильности изложенных в ней мыслей на практике;
Сергею Унгеру
за экспертизу при описании специфики тестирования на разных игровых платформах;
Наталье Шевяковой
за помощь в подготовке раздела, касающегося карьеры тестировщика и замечания к материалу с точки зрения HR и психологии.
RSTQB[3 - RSTQB (Russian Software Testing Qualifications Board) – российское представительство открытой международной организации ISTQB, занимающейся развитием тестирования программного обеспечения через обучение и сертификацию.]
и лично:
Андрею Конушину
за вдохновение и демонстрацию того, что можно добиться многого при желании и правильной организации дела;
Александру
«Дедушке русского тестирования» Александрову за мудрость, демонстрацию абсолютного спокойствия в любой ситуации и десятки часов совместной работы над силлабусом ISTQB® GaMe Tester;
Павлу Шарикову
за энтузиазм и массу бесподобных примеров для подготовки по программе ISTQB® GaMe Tester, которые позволили сфокусироваться и не расплескать мысль при обработке материала.
Моей дочери Маше
за конструктивную критику стиля изложения (без нее книга была бы совсем другой) и предложения по его улучшению.
А также всем, без кого публикация этой книги была бы невозможной.
От автора
Я надеюсь, что эта книга будет полезна тем, кто хочет попасть в игровую индустрию, но еще никогда не принимал участия в создании игровых продуктов и не знает, как устроен мир разработки.
Важное преимущество профессии тестировщика – то, что со временем ты очень четко будешь разбираться во всех игродельных процессах и нюансах, будешь понимать и выявлять первопричины ошибок. А значит, впоследствии сможешь управлять процессом разработки, точно зная, как делать НЕ надо.
В основе тестирования компьютерных игр лежат те же принципы и применяются те же методологии, что и при тестировании прикладного программного обеспечения. Однако в играх есть области, которые отличают их от любого другого ПО, и в этой книге я бы хотел обратить особое внимание как раз на них.
С другой стороны, если ты уже сейчас разрабатываешь игровые продукты, здесь много полезной информации для того, чтобы понимать, каким образом обеспечивается и поддерживается их высокое качество.
Важно понять, что, прочитав эту книгу, ты не превратишься мгновенно в суперпрофессионала игрового тестирования. Но в ней точно содержится информация, которая позволит тебе пройти собственный путь гораздо быстрее и легче.
На этих страницах изложен опыт, накопленный за годы работы в компаниях, занимающихся не только тестированием игр и их разработкой, но и подготовкой кадров в этой сфере. Надеюсь, что в ней ты найдешь ответы на многие свои вопросы. Главное – эти знания помогут тебе построить карьеру в игровой индустрии.
Желаю удачи!
Глава 01. Путь в тысячу ли начинается с первого шага
– А далеко до этой комнаты?
– По прямой – метров 200. Да только тут не бывает прямых.
S.T.A.L.K.E.R.
• Почему игры необходимо тестировать?
• Чем отличается игра от другого программного обеспечения?
• Чем занимается тестировщик игр?
• Что нужно знать, чтобы стать тестировщиком?
• В чем смысл 7 принципов и 5 мифов тестирования?
Практически на любом промышленном предприятии был отдел, который назывался ОТК. В нем, как правило, трудились люди, проработавшие на этом предприятии очень солидное время и знавшие от и до не только выпускаемую продукцию, но и все нюансы ее производства. Название отдела расшифровывалось как «отдел технического контроля», а его сотрудники каждый день приходили на работу, чтобы искать в продукции, которую выпускало их любимое предприятие, не полезные качества, которые помогли бы ее продать, а… дефекты и недостатки. Солидные дяденьки и тетеньки брали детский велосипед, присоединяли колесо передачей к двигателю и наблюдали, как оно вращалось по много часов подряд, имитируя долгую поездку на дачу и обратно. Если в процессе испытаний происходило что-то, не похожее на нормальную работу велосипеда (а о том, как ДОЛЖЕН работать велосипед, эти люди знали все), сотрудники ОТК скрупулезно фиксировали эти случаи в специальных документах, попутно добавляя информацию о том, по каким причинам такое могло произойти и что стало причиной брака.
А ты помнишь старые велосипеды? Стальная рама, кованая «звездочка», «неубиваемые» педали, цепь, которая удержит и быка. И через 30 лет такой велик скрипит, но едет без единой поломки. Новый велосипед, с его тридцатью тремя скоростями, пневмоподвеской, подшипниками, звездочками и тормозами, над которыми трудились десятки инженеров, хотя и позволяет нам ехать гораздо быстрее, однако более подвержен различным «болезням». Это и понятно. Чем сложнее система, чем больше в ней элементов, чем чаще они взаимодействуют друг с другом, тем более она уязвима для различных поломок.
Теперь представь, что было бы, если велосипеды, производимые на заводе, отправлялись бы сразу в магазины без всяких испытаний. Последствия могли бы быть самые разные: от противного раздражающего скрипа сиденья до лопнувшей цепи посреди долгой дороги. В любом из этих случаев человек, купивший велосипед, испытал бы разную степень возмущения, разочарования и досады по поводу неудачного приобретения… если бы выжил, когда на полном ходу у него бы отвалилось колесо.
Развиваются не только велосипеды; развивается вообще все. Все становится сложнее, быстрее, технологичнее. И компьютерные игры – главная цель обсуждения в этой книге – не исключение. Стремительное развитие игровой индустрии привело к их распространению на множестве различных платформ. Игры стали масштабнее, реалистичнее и требовательнее к техническим ресурсам. Как и все люди, разработчики компьютерных игр допускают ошибки в работе, а чем затейливее становятся применяемые технологии, тем больше дефектов может возникнуть при их использовании. В то же время аудитория игроков значительно увеличилась, стала более искушенной и требовательной к качеству. Они хотят еще большей реалистичности, новых технологий, новых ощущений! И поскольку они платят за это довольно большие деньги, они вправе ожидать качественный продукт.
Игра, которая запускается на телефоне, компьютере или игровой приставке, – это разновидность программного обеспечения. А значит, все, что справедливо для тестирования ПО в общем смысле, справедливо и для тестирования игр.
Но интернет-магазины, приложения для построения маршрутов движения, сервисы для просмотра фильмов и прочие программы в первую очередь важны своим функционалом и удобством использования. В играх же, помимо этого, важна интересность, увлекательность, вызов. Пользователь запускает игру, чтобы нескучно провести время, развлечься, получить яркие эмоции.
Поэтому для игры важно, как она ощущается, является ли захватывающей, хочется ли запустить ее снова или поискать другой способ досуга.
Если рассматривать игру как систему, то можно заметить, что она состоит из подсистем, каждая из которых сама по себе очень сложна. Ниже перечислены некоторые из них.
• Графическая подсистема
• Звуковая подсистема
• Подсистема игровой логики
• Подсистема искусственного интеллекта
• Физическая подсистема
• Подсистема взаимодействия с пользователем
• Подсистема хранения данных и др.
А еще не забудь про историческую достоверность в играх, соответствие прототипу и локализацию.
Так же как специалист, испытывающий велосипед, должен знать, как он устроен и принцип его работы, тот, кто считает себя игровым тестировщиком, должен знать, как создаются и анимируются 3D-модели, как записываются звуки и где они хранятся в игре, как в игровом движке настраивается освещение, откуда в игре появляются невидимые стены, почему враги атакуют разных персонажей по-разному, почему в Китае нельзя выпустить игру со скелетами и почему персонаж должен оставлять разные следы на разных поверхностях.
Хороший тестировщик должен разбираться в продукте, который он тестирует. А без большого игрового опыта в разных жанрах это практически невозможно.
Ты скажешь: «Получается, что стать игровым тестировщиком невероятно сложно?» И да и нет! Всему можно научиться, все знания систематизировать и каталогизировать, если подойти к этому процессу правильно.
После выхода Cyberpunk 2077 пользователи базовых версий PlayStation 4 и Xbox One пожаловались на практически неиграбельные версии продукта. В версиях для обеих консолей наблюдались графические артефакты, падения частоты кадров и частые подзагрузки окружения и текстур. По данным Digital Foundry, Cyberpunk 2077 на PlayStation 4 работает с разрешением 720–900p (для сравнения, на PlayStation 4 Pro разрешение игры держится в районе 1080p), а частота кадров при этом в некоторых местах падает до 15.
14 декабря 2020 года компания CD Projekt RED официально прокомментировала ситуацию, извинившись за проблемный старт и анонсировав работу над двумя большими обновлениями, которые должны были выйти в январе и феврале 2021 года и были призваны исправить самые серьезные проблемы игры на консолях предыдущего поколения. Также студия пообещала вернуть всем желающим средства, потраченные на покупку игры.
Чтобы понять, чем занимается игровой тестировщик и кто это такой, давай попробуем разобраться с одним из определений этой профессии. «Тестировщик – это специалист, который занимается тестированием программного обеспечения с целью выявления ошибок в его работе и повышения уровня общего качества продукта». Если честно, понятнее не стало. Может быть, нужно почитать определение тестирования? «Тестирование – это процесс проверки соответствия заявленных к продукту требований и реализованной функциональности, осуществляемый путем наблюдения за его работой в искусственно созданных ситуациях и на ограниченном наборе тестов, выбранных определенным образом». О! Это уже лучше, и можно попробовать разобраться. «Процесс» означает, что мы занимаемся этим некоторое время и в рамках этого занятия происходит последовательная смена различных состояний.
С реализованной функциональностью все вроде бы понятно: мы можем ее увидеть, услышать и почувствовать, когда используем какой-то продукт, в том числе и видеоигру. А вот как быть с заявленными требованиями? Кем заявленными? Где они записаны и как их узнать? Давай порассуждаем. Если они кем-то заявлены, то мы имеем право ожидать, что они и реализованы. Так ведь? Какие требования и функционал пользователь вправе ожидать, например, от старого доброго «шутана»?[4 - Шутан (от «шутер», англ. shooter) – жанр игры от первого или третьего лица, в котором игровой процесс основан на использовании в сражениях огнестрельного оружия.] Очевидно, что в нем геймплей будет развиваться по законам игрового жанра, а перед игроком будут стоять соответствующие задачи. То есть игрок ждет, что в игре он получит возможность использовать различные виды оружия для уничтожения различных видов умных и не очень врагов, восполняя свое здоровье и запасы патронов, находя на уровнях аптечки и ящики с амуницией. При этом ему необходимо будет добраться живым от точки А на первом уровне до точки Б на последнем.
А дальше начинается самое интересное. Чтобы протестировать игру, нам, оказывается, нужно будет наблюдать за ее работой в искусственно созданных ситуациях, используя для этого некоторое количество тестов. Вопросов больше, чем ответов! Что это за ситуации и почему ограничено количество тестов? С последним, правда, еще можно разобраться: у тестировщиков нет бесконечного запаса времени, как у игроков, чтобы попытаться воплотить все многочисленные игровые ситуации и сценарии. А что значит «искусственно созданная ситуация»? Тут многих уже должны терзать смутные сомнения. Разве тестировать не значит играть в свое удовольствие и одновременно находить какие-то изъяны в игре? Неужели нет?!
Тут я вынужден развенчать один из самых распространенных мифов среди желающих попасть в игровую индустрию через тестирование. Ты не поверишь, как часто при собеседовании очередного кандидата в игровые тестировщики на вопрос «Как ты представляешь себе работу?» можно услышать: «Я играю в игру и по ходу прохождения обращаю внимание на разные баги[5 - Баг – жаргонное название дефекта. В индустрии ходит такая легенда о появлении этого термина. В 1945 году при испытании компьютера Mark II случился сбой в работе, вызванный мотыльком, закоротившим собой контакты реле. В журнале была сделана соответствующая запись о первом подтвержденном случае обнаружении бага (жука). Так с тех пор называют любой дефект программного или аппаратного обеспечения.], потом просто сообщаю об этом своему руководителю». Это утверждение очень-очень далеко от истины.
Просто поиграть тестировщику удается редко, если только во время знакомства с новым проектом или во время плейтестов[6 - Плейтест (англ. playtest) – метод тестирования игры путем предоставления ее группе представителей целевой аудитории для обнаружения потенциальных дефектов и сбора отзывов.].
Обычный пользователь запускает игру, чтобы ее пройти, победить соперников или приятно провести время. Тестировщик же проверяет соответствие игры требованиям, записанным в спецификации (если повезет и такие требования ему дадут[7 - Продукт развивается, и требования могут быстро устаревать. Если требования не актуализируются, то, как правило, использовать их в работе нет никакого смысла. Поэтому одна из важных задач в проекте – поддерживать требования к продукту в актуальном состоянии.]), или, основываясь на многих факторах, старается понять, как устроена эта игра и как в нее играть. Другими словами, делает все, чтобы пользователь потом прошел игру, победил врагов и приятно провел время. Причем сама игра может не совпадать с личными предпочтениями тестировщика, так как предназначена совсем для другой аудитории. Тем не менее тестировщик будет раз за разом проходить один и тот же уровень, чтобы проверить, например, правильность отображения игровых объектов.
Кроме того, помимо самого игрового процесса игра содержит множество различных элементов, которые тоже необходимо проверять. Тестировщики могут обнаружить изъяны в архитектуре игрового ПО уже на ранних этапах разработки, найти ошибки в звуковом сопровождении или выявить дефекты в тексте уже готовой к выпуску игры. Обычно тестировщик занят проверкой порученной ему небольшой части игры, и его задача – убедиться, что его 10 % игры работают на 100 %.
Вот тебе факт № 1: «тестировать игру» не равно «играть в игру». Но про то, что ты геймер, тоже забывать не нужно.
Нина Резниченко, QA-менеджер Saber Interactive
Ты, наверное, замечал, что иногда выходят игры, которые вроде хорошо сделаны, но при этом играть в них особо не хочется. Как-то раз мы проводили в команде плейтест игры среди тестировщиков и просили заполнить форму с фидбеком. Открыв эту форму, мы очень удивились, увидев там всего лишь один фидбек из 20, поскольку почти все тестировщики вместо фидбека написали список багов.
Одна из «побочек» работы геймдев QA – смещение фокуса, когда спустя некоторое время работы человек видит в игре одни лишь баги и теряет связь с геймерской частью себя («я – игрок»). Геймдев – это творческая среда, но за багкаунтом зачастую теряются эмоции и интерес, а это тоже очень важно.
Например, для игрока всплывающие подсказки в игре могут просто бесить и раздражать, но это не будет являться багом с точки зрения их функционала. Фича работает в соответствии с ГДД[8 - ГДД (гейм-дизайн-документ) – детальное описание разрабатываемой компьютерной игры.], подсказки действительно нужны, они работают. Но для игрока они навязчивы, прерывают геймплей в неподходящий момент, а отключить их невозможно.
Тестируя игру с позиции игрока, спрашивай себя, понятна ли фича для игрока. У тебя, как у QA[9 - QA (Quality Assurance) – это любой систематический процесс определения соответствия продукта или услуги определенным требованиям.], есть ГДД или описание фичи или какие-то подробности от разработчиков. Но представь, что ты видишь ее в первый раз. Спроси себя: «Как игрок найдет эту фичу? Понятно ли, как ею пользоваться и для чего? Сможет ли он ее абьюзить?»
Примеряя на себя разные роли и рассматривая проект с нескольких сторон и уровней, QA могут помочь выпустить не просто правильно работающую игру, но еще и интересную, в которую приятно играть.
Если ты мечтал попасть в геймдев, чтобы создавать, то, став тестировщиком, ты должен быть готов услышать факт № 2: твоей основной задачей будет разрушать, находить способы «сломать» игру, обнаруживать в ней изъяны – и чем больше, тем лучше. Но, разрушая игру, ты делаешь ее лучше, избавляешь ее от зловредных багов, находясь на первом рубеже защиты.
Для того чтобы эффективно выполнять свою работу, ты должен понимать, из чего состоит рабочий процесс выбранной тобой профессии. Ты, как врач, будешь иметь дело с пациентом, организм которого не работает так, как нужно. Чтобы поставить правильный «диагноз», тебе необходимо правильно провести обследование и сделать необходимые «анализы». Также потребуются инструменты и знания о том, как проводится диагностика органов (подсистем игры). Ты должен знать, где у твоего «пациента» находятся самые уязвимые места, и придумать тесты, которые помогут найти там дефекты. А после такой диагностики очень важно тщательно и грамотно записать полученные результаты. Чем точнее ты «поставишь диагноз», тем быстрее будут устранены дефекты, игра «выздоровеет», и игроки смогут насладиться качественным продуктом.
Одна из важнейших задач тестировщика – предоставление актуальной информации по разрабатываемому проекту для исправления дефектов. Причем эти дефекты могут быть связаны не только с исследуемым игровым продуктом, но и с процессами его создания.
1.1. Как устроена профессия?
Нужно понимать, что тестирование – это профессия и, как любая другая профессия, требует времени для овладения ею. Овладение профессией в долгосрочной перспективе проходит по нескольким этапам.
Ремесло. Это период, когда ты должен овладеть основами профессии, приобрести необходимые компетенции. Никто никогда не станет Паганини или Менухиным, не потратив определенного времени, пиля сольфеджио на скрипке. Никто не станет знаменитым хирургом, не зная анатомии и не сделав 5000 разрезов скальпелем. На этом этапе тебе придется много читать, чтобы понимать профессиональную терминологию, методологию и теорию тестирования, пробовать создавать документы, по которым ты проведешь свои первые тесты, изучать необходимые для работы инструменты и многое другое.
Опыт. Это период, в котором ты будешь приобретать практический опыт выполнения реальной работы. Чем больше операций производится, тем лучше координация движений и понимание процессов. Чем больше процессов прошел адвокат, тем больше он знает о том, как действовать в тех или иных ситуациях. Чем больше тестов ты проведешь, тем лучше станешь понимать, как, когда и зачем проводятся те или иные виды тестирования, почему появляются дефекты и научишься точнее их описывать.
Мастерство. Это тот период, когда ты, имея очень хорошие навыки и опыт работы, будешь способен импровизировать в работе, не отклоняясь от основного процесса, а только улучшая сам процесс и его результат. Ты станешь признанным мастером, к которому будут обращаться за советом начинающие специалисты. Будешь писать планы тестирования и организовывать работу тестовых команд. Будешь понимать первопричины возникновения дефектов и помогать решать проблемы на самых ранних стадиях разработки.
Конечно, не любой может стать тестировщиком. Давай посмотрим, какие качества и знания могут помочь сделать первые шаги в профессии. Выше я говорил о том, что тестирование – это, по сути, поиск расхождений между ожидаемым результатом и фактическим при эксплуатации какого-либо объекта в определенных условиях в ограниченных временных рамках. Хотя некоторые специалисты не согласны с таким определением, считая, что пользователь имеет право ожидать всего чего угодно и на основании своих «хотелок» записывать в дефекты то, что таковым не является. Но я исхожу из того, что пользовательские ожидания от игры основаны не на оторванных от реальности фантазиях, а на чем-то связанном с:
1. игровым опытом;
2. пониманием жанровых особенностей игры;
3. здравым смыслом;
4. общими (фоновыми) знаниями.
То есть на основании того, на чем обычный человек и строит свои умозаключения по поводу того, что ждать от игрового продукта.
Поэтому еще раз важно подчеркнуть, что тестировщик сам должен иметь богатый игровой опыт, который помогает ему ориентироваться в игровых жанрах, игровых механиках и т. д. Чем больше такой опыт, тем больше шансов, что суждения об ожиданиях от игры будут правильными.
А что делать, если ты не накопил тысяч игровых часов? Источниками информации, формирующими ожидания об игре, могут быть:
• более опытные коллеги, которые могут подсказать и помочь в сложной ситуации;
• эксперты индустрии, которые пишут и снимают различные игровые обзоры, из которых мы можем почерпнуть сведения об игровом продукте;
• похожие между собой игры (Doom, Quake, Unreal и т. д.);
• ранние версии игры (серии игр Diablo, Warcraft, Call of Duty и т. д.);
• общие знания (например, в области физики, химии, истории и т. д.);
• знания в области игровой разработки (например, понимание процесса создания 3D-моделей, анимации, гейм-дизайна, левел-дизайна и т. д.).
Как ты догадываешься, все вышеперечисленное помогает нам лишь понять, что ждать от конкретного игрового продукта, что является его «нормой». Это как норма частоты сердечных сокращений или показатели артериального давления, с которыми мы сравниваем свои измерения и, если они отличаются, начинаем беспокоиться и идем к врачу. То есть для того, чтобы сделать вывод о том, имеем ли мы дело с дефектом, нам нужно получить реальный результат для сравнения с ожиданиями. А еще определить, в каких подсистемах игры чаще всего бывают скопления багов. А еще организовать свою работу так, чтобы потратить минимум времени при наилучшем тестовом покрытии (то есть проверить в игре как можно больше). А еще… много чего еще.
Вадим Луковатый, заместитель руководителя отдела Bytex
Профессия тестировщика игр требует уникального сочетания навыков и качеств. Среди них выделяются внимание к деталям для выявления неочевидных ошибок и багов, терпение и настойчивость, необходимые для многократного выполнения задач и обнаружения неполадок. Важны логическое мышление и аналитические способности для анализа сложных систем и предсказания потенциальных проблем, а также коммуникативные навыки для четкой документации найденных ошибок и взаимодействия с командой разработчиков. Страсть к играм значительно помогает в понимании игровых процессов и повышает мотивацию. Не менее важно умение работать в команде, гибкость и адаптивность к быстро меняющимся технологиям, инструментам и методологиям тестирования, а также знание игровых платформ и технологий для повышения эффективности тестирования.
Тут тебе пригодятся знания в следующих областях.
• Теория тестирования (нужно знать методологию, разные виды тестирования, терминологию и многое другое).
• Игровое «железо», от которого в игре зависит многое, начиная от невозможности выставить желаемый графический режим при слабой видеокарте до недостатка оперативной памяти, из-за которого игру вообще не удается запустить.
• Организация рабочего процесса и базового цикла тестирования (чтобы правильно организовать свое рабочее место в зависимости от платформы тестирования, планирования тестовых активностей, анализа рисков, проектирования тест-кейсов, применения техник тест-дизайна для оптимизации времени и т. д.).
• Инструменты тестирования (например, для поддержки и управления процессом тестирования или снятия скриншотов с экрана, записи видео или сохранения необходимой информации).
• Модели разработки (чтобы понимать место тестирования в процессе разработки).
1.2. 7 принципов и 5 мифов тестирования
А еще как дважды два ты должен знать семь принципов тестирования, которые помогут тебе выполнять свои обязанности и продуктивно общаться со всеми, кто заинтересован в твоей работе. Конечно, это не значит, что ты должен вывесить их на своем рабочем месте и повторять их как мантру ежедневно или начать свою профессиональную карьеру, поклявшись жить по этим принципам. Но по мере приобретения опыта ты будешь убеждаться в их правдивости и справедливости, что поможет тебе обобщить свой опыт и сделает выбранную профессию понятнее. Итак, вот они.
1. Тестирование демонстрирует наличие дефектов, а не их отсутствие
Это означает, что, потратив 150 часов на тестирование игры, ты все равно не сможешь сказать, что в ней нет дефектов. Как ни тяжело это признавать, но ты просто на текущий момент не нашел их. Уверен, что у тебя для этого были веские причины: не было всего нужного оборудования (во всех его многочисленных конфигурациях) или не было достаточно времени. Одним словом, гарантировать, что в игре нет багов или того, что они не появятся на каком-то оборудовании или при каких-то очень специфических обстоятельствах ты, к сожалению, никак не можешь. Задача тестировщика – придумать такие сценарии использования игры и в таком количестве, при котором они максимально полно покроют ее функциональную и нефункциональную области и позволят найти дефекты в них.
2. Исчерпывающее тестирование недостижимо
Этот принцип логически вытекает из предыдущего. Тебе физически не хватит времени провести тестирование, которое полностью покроет весь функционал игры и все ее части во всех возможных вариантах и случаях ее использования. Такое тестирование возможно только в очень незначительном количестве тривиальных случаев. Поэтому вместо того чтобы пытаться объять необъятное, стоит научиться использовать различные подходы и методологии, чтобы, распределив силы и расставив приоритеты, сосредоточиться на максимально возможной в плане эффективности проверке. В некоторых случаях (например, когда мало времени) тестирование, основанное на анализе рисков, будет наиболее эффективным и предпочтительным.
3. Раннее тестирование сохраняет время и деньги
Большинство проектных менеджеров подтвердят, что ресурсов всегда не хватает. Не хватает квалифицированных сотрудников, необходимого аппаратного обеспечения, денег и времени, чтобы с минимумом проблем завершить проект. Они также подтвердят, что ошибка, сделанная на раннем этапе разработки, может привести к серьезным последствиям на более поздних этапах. А учитывая то, что ресурсов и так не хватает, последствия ранних ошибок могут стать катастрофическими. Одна из главных задач и одно из самых ценных умений тестировщика – понимание и обнаружение первопричин дефекта, то есть самых ранних действий, которые и привели к возникновению в игре бага. И поскольку любой проект развивается в рамках определенных стадий, то можно только представить, к каким последствиям приведет ошибка, сделанная на этапе разработки требований. Все усилия разработчиков по реализации задач, основанных на ошибочных требованиях гейм-дизайнера, будут перечеркнуты, поскольку они будут также ошибочными по определению. Есть ли выход из подобной ситуации? Конечно! Тестирование должно начинаться как можно раньше. В разработке игр – часто даже раньше разработки требований, еще на этапе концепции (идеи), а иногда и еще раньше – на этапе гипотезы, когда принимается решение о том, стоит ли вообще начинать разработку продукта на текущем этапе.
4. Кластеризация дефектов
Многие тестировщики замечают, что дефекты могут «кучковаться», как жучки, выползающие на теплый камень в солнечную погоду. Часто это объясняется тем, что определенные области игрового продукта особенно подвержены «заражению», и, обнаружив такую область, мы найдем большее количество багов, чем в других местах. Знания, где начинать поиски багов в игре, могут помочь в тех ситуациях, когда нам серьезно не хватает времени. Например, в мобильной игре мы можем начать с проверки реализации адаптации игры под разные разрешения экрана. Другой пример – проверка настроек моделей персонажей и их взаимодействия между собой.
5. Парадокс пестицида
Впервые аналогию между тестированием программного обеспечения и обработкой полей пестицидами в сельскохозяйственной практике провел Борис Бейзер еще в 1990 году. Под парадоксом он имел в виду то, что постоянное использование одного и того же набора тест-кейсов для поиска дефектов приводит к тому, что он перестает обнаруживать баги так же, как использование одних и тех же пестицидов для борьбы с вредными насекомыми. Они попросту адаптируются к яду, и он постепенно перестает на них действовать. Красивая аналогия. Но почему это происходит в действительности? Прежде всего потому, что невозможно использовать все тест-кейсы: это противоречит одному из ранее изложенных принципов тестирования. Но даже простые приложения, например «Тетрис», требуют использования довольно большого количества тест-кейсов для проверки всех возможных сценариев и комбинаций данных. Кроме того, функциональность продукта изменяется со временем, и, внося изменения в один из элементов системы, мы не можем не изменить всю систему. А раз система меняется, то следует искать новые способы обнаружения дефектов в ней. Ну и, наконец, тестировщик должен модифицировать тест-кейсы, исходя из человеческой психологии. Причем не своей, а разработчика и конечного пользователя.
Виктор Гляненко, QA-директор Saber Interactive
Один из ярких примеров эффекта пестицида на практике я встретил в начале своего пути тестировщика. При работе над своим первым проектом – шутером – команда QA была поделена по игровым уровням, которые ежедневно проверялись с точки зрения прохождения. В какой-то момент уровень решил пройти коллега, который его не смотрел, и практически в самом начале нашел баг, который блокировал прохождение, так как его персонаж «застревал в геометрии» и не мог больше двигаться.
А произошло это потому, что ребята, которые регулярно проверяли уровень, проходили его практически с закрытыми глазами, знали, куда бежать, что активировать в игре, и эти маршруты для них изо дня в день были одинаковые. А для того, чтобы персонаж «застрял», нужно было всего-то сделать шаг в сторону.
6. Тестирование зависит от контекста
Разное по своей сути и назначению программное обеспечение требует разного подхода и методологии тестирования. Сузив этот принцип до тестирования видеоигр, можно утверждать, что не только тестовое окружение (то есть программно-аппаратная часть, необходимая для проведения тестовых активностей), но и методология будет отличаться в зависимости от жанра и типа игры.
7. Заблуждение об отсутствии ошибок
Даже если представить невозможную ситуацию, при которой были найдены и исправлены 100 % дефектов (мы помним, что такое невозможно в принципе!), не будет никаких гарантий того, что тестируемая нами видеоигра будет успешной у пользователей. Наша работа – обеспечить качество продукта, но привлекательность самого продукта мы обеспечить не в силах.
Ты скажешь: «Ладно, я понял, что не все так просто и что тестирование – это настоящая профессия, которая, как любая другая, требует времени на овладение и приобретение опыта, чтобы стать настоящим профессионалом. Но скажи честно: я что, буду тестировать игры до 60 лет? Я с трудом представляю себе дедушку, который увлекается тем же, что его внуки, и днями напролет торчит в компьютере, играя и тестируя, тестируя и играя».
Среди моих коллег есть поговорка: «Нет ни одного тестировщика, который не хотел бы стать разработчиком». И это вовсе не значит, что тестировщики стоят на более низкой ступени эволюции в игровой индустрии. Это значит, что ребята, которые стремятся любым способом попасть в игровую индустрию, не понимают, что тестирование – это важная и неотъемлемая часть разработки, без которой последняя невозможна, и имеют весьма отдаленное представление о связях профессий в индустрии. Кроме того, у большинства разработка ассоциируется с программированием и заблуждением о том, что программисты – это и есть люди, которые целыми днями занимаются креативом. На самом деле это миф № 1 в игровой индустрии, который необходимо развеять.
С точки зрения производства разработка видеоигры очень похожа на съемку кинофильма. И если в кино мы видим происходящее так, как это задумал режиссер, то в игровой индустрии такую функцию выполняет человек, профессия которого называется гейм-дизайнер. Именно он придумывает в игре практически все, и именно он является главным игровым демиургом.
А еще нужно знать, что в разработке игр принимают участие люди не одного десятка профессий, и они занимаются реализацией различных частей проекта. Кто-то пишет сценарии и диалоги персонажей (сценаристы), продумывает игровые механики и экономику (гейм-дизайнеры), кто-то воплощает задумки в программном коде (программисты), кто-то делает 3D-модели (3D-моделлеры, риггеры, аниматоры), а кто-то записывает музыку и звуки (звукоинженеры и композиторы).
Есть и те, кто фиксируют ошибки, появляющиеся на разных этапах разработки и помогают определить первопричину их появлений. Так вот, это и есть мы – тестировщики. И, научившись со временем понимать первопричины ошибок, начинаешь также понимать, как делать игру НЕ нужно и как правильно выстраивать процессы, чтобы минимизировать количество ситуаций, которые приводят к появлению дефектов.
Миф № 2: лучшие тестировщики получаются из лучших игроков. Это не так. Да, тестировщики проводят сотни и тысячи часов за игрой, но, как правило, у них нет предпочтений, они «всеядны». Они исследователи. Им нравится копаться в играх, развиваться и получать достижения, а не совершенствоваться в искусстве дуэли. Тестирование – это дисциплина, умение переключаться в режим, в котором получение удовольствия от игрового процесса не является больше основным. Это способность проходить один и тот же путь десятки раз, отслеживая на нем малейшие дефекты. Кроме того, ты должен быть довольно настойчивым, потому что собираешься играть в сломанную и, возможно, скучную и часто незаконченную игру просто потому, что хочешь, чтобы она была качественной и доставляла удовольствие другим людям. Геймеры, которые ставят перед собой цель добиться победы и стать лучшим на игровой арене, скорее, испытают разочарование от такой работы.
Миф № 3: тестировщики – в подавляющем большинстве случаев мужчины. По собственному опыту скажем, что это утверждение не имеет под собой никаких оснований. По моим наблюдениям, пропорция скорее выглядит как 65 к 35 или даже 60 к 40 в пользу мужчин, но при этом девушки часто гораздо более успешны в профессии. Возможно, это связано с большей устойчивостью женской психики к стрессам, большей внимательностью к деталям, терпеливостью и настойчивостью.
Миф № 4: тестирование – это, несмотря ни на что, все-таки довольно легкое занятие. Со временем ты нарабатываешь некий алгоритм работы и все идет по накатанному. Это довольно странное заблуждение, потому что то же самое можно сказать вообще о любой профессии. Сказать можно вообще все что угодно. Важно, чтобы сказанное имело смысл. А смысл в том, что врач, принимая десяток пациентов ежедневно, несомненно, приобретает опыт и совершенствуется в профессии. Однако этот опыт не дает ему права назначать лечение одному пациенту просто на основании некоторой схожести симптомов с симптомами другого. Поэтому хороший доктор каждый раз очень тщательно проводит исследования и диагностику, чтобы лечение было наилучшим в каждом случае. Так и тестировщик пусть и знает особенности жанра тестируемого продукта, все равно проводит тщательную проверку всех областей и деталей, стараясь не упустить ошибок.
И, наконец, миф № 5: игровое тестирование – это удел молодых людей, пока еще не получивших образования и могущих себе позволить образ жизни, сочетающий несложную работу и развлечение. На самом деле это совсем не так. В последние годы игры стремительно меняются: они становятся сложнее, технологичнее и, самое главное, становятся очень-очень похожими на реальный мир. Во время тестирования таких игровых продуктов в качестве ожидаемого результата часто выступает наша реальность со всеми ее законами. И нужно очень хорошо понимать, как устроена эта реальность. Без жизненного опыта это, увы, невозможно. Возможно, именно поэтому средний возраст тестировщика сейчас приблизился к 25–26 годам (а зачастую и гораздо больше).
Освободившись от этих навязчивых мифов, ты теперь можешь приступить к освоению нелегкого ремесла игрового тестировщика. Я помогу тебе освоиться с важнейшими, фундаментальными принципами и подходами в нашей профессии, помогу даже подготовиться в сдаче экзамена и получения международного сертификата игрового тестировщика ISTQB® Certified Tester Game Testing. Но опыт ты должен будешь приобрести сам. И я очень рассчитываю, что по прошествии времени ты войдешь в число лучших специалистов в области игрового тестирования.
Глава 02. Самая большая ошибка – не исправлять ошибки
Чем больше надежд мы возлагаем, тем сильнее может быть разочарование…
Genshin Impact
• Что такое дефект?
• Чем дефекты отличаются друг от друга?
• Что такое баг-репорт и для чего он нужен?
• Что такое критичность дефекта и как ее правильно определить?
• Что такое приоритет дефекта?
• Что такое жизненный цикл дефекта?
• Когда и почему появляются дефекты?
• Как снизить риск их появления?
• Где место тестирования в разных моделях разработки?
• Как тестировщик взаимодействует с заинтересованными лицами проекта?
Выше я говорил о процессе тестирования как о процедуре сравнения ожидаемого результата с реально полученным и заявил, что любое расхождение между ними и есть дефект, если разработчик игры громко не утверждает обратного.
Пришло время поговорить о дефектах подробнее, ведь баг багу рознь. Один может запросто привести к крашу[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 в огромном списке задач довольно легко находить дубликаты.
Способность описать дефект в рамках поля Summary – действительно одно из главных достоинств и профессиональных навыков специалиста по тестированию. Есть несколько способов обучения этому навыку. Приведем три самых действенных и простых.
Метод «Что? Где? Когда?»
Нет, это не связано с привлечением знатоков из одноименного интеллектуального клуба. Этот способ подразумевает описание, которое дает ответы на три следующих вопроса.
1. Что произошло и в чем суть неполадки?
2. Где был обнаружен дефект?
3. Когда и при каких обстоятельствах возник дефект?
Это довольно действенный способ, и я рекомендую взять его на заметку.
Метод выделения ключевой информации
Весьма действенный метод, особенно когда у тебя уже есть длинное описание дефекта.
1. Попробуй описать дефект со всеми необходимыми деталями.
2. Внимательно прочитай свое описание и выдели из него ключевую информацию, то есть самые важные моменты.
3. Попробуй сложить эти ключевые моменты вместе.
То, что получится в итоге, и будет составлять Summary.
Метод тождественности атрибутов
Составь описание дефекта по следующей схеме.
1. Шаги воспроизведения
2. Ожидаемый результат
3. Полученный результат
Если все описано правильно, то «Полученный результат» и будет являться Summary дефекта. Если нужно, можешь добавить пару важных деталей.
Но вернемся к прочим атрибутам дефекта.
Подробное описание (Description) – это поле служит для того, чтобы тестировщик мог добавить более подробное описание и дать больше деталей. Здесь указывается любая дополнительная информация, относящаяся к багу, которая может помочь в исправлении дефекта.
Следующие два атрибута – Шаги (Steps) и Ожидаемый результат (Expected Result) – берутся непосредственно из твоего тест-кейса[11 - Тест-кейс – это детально описанный сценарий или инструкция, которая позволяет тестировщикам выполнить определенные шаги для проверки определенной функциональности или поведения программного продукта. Это основной инструмент в процессе тестирования программного обеспечения, включая компьютерные игры.], с помощью которого ты обнаружил дефект. Это и понятно. Разработчик должен сделать абсолютно то же самое, чтобы увидеть этот баг. О том, как проектировать тест-кейсы, я расскажу тебе чуть позже.
Фактический результат (Result) – это описание того, что ты увидел своими глазами, выполнив необходимые для проверки Шаги. Если он не отличается от Ожидаемого результата, мы можем быть уверены, что система функционирует как нужно. Любое отличие между Ожидаемым и Фактическим результатом будет означать только одно: перед тобой дефект.
Критичность (Severity) – это основное, чем баги отличаются друг от друга. Определяя Критичность, ты информируешь разработчика, что тобой был выловлен баг, бажик или бажище.
Приоритет (Priority) – это фактически скорость, с которой разработчики должны отреагировать на найденный дефект. Похоже на то, как скорая помощь реагирует на разных больных: на скорость реагирования влияют признаки, характеризующие степень тяжести больного. В большинстве случаев определением приоритета занимается менеджер проекта или тест-менеджер, обладающий большей информацией о проекте и продукте, но иногда тестировщик также может выразить свое мнение по этому вопросу.
Про эти два важнейших атрибута я расскажу более подробно чуть ниже.
Традиционно ответственность за определение критичности найденных дефектов лежит на тестировщиках. Они обладают исчерпывающими знаниями контекста, в котором появился баг, и того, насколько серьезно его влияние на игровой процесс.
А вот чтобы определить приоритет, нужно гораздо больше информации: понимание загруженности команд разработки, потенциального влияния дефекта на репутацию разработчика и массу другого. Поэтому определением приоритета занимается как минимум руководитель той команды, которая допустила и будет исправлять дефект, а в идеальном случае – менеджер проекта или продюсер, ответственный за разработку.
Могут быть и другие атрибуты баг-репорта, крайне полезные для разработчика.
Повторяемость (Reproducibility)[12 - Иногда также называется Repro Frequency.] – этот атрибут важен для определения Приоритета дефекта и показывает, насколько часто появляется дефект в определенных обстоятельствах, определяет его «назойливость». Он также дает понимание, что то, что ты описываешь, – действительно баг, а не однократный сбой неясной этимологии. С этим атрибутом необходимо быть очень внимательным. Часто тестировщики не видят разницы в оформлении повторяемости в процентном или числовом отношении. Однако есть разница, если баг имеет повторяемость 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 мало:)
2.1.2. Критичность дефекта (Severity)
Суммируя сказанное выше, любая ошибка, найденная тестировщиком, должна быть описана как можно подробнее. Для этого в отчете о дефектах, который может представлять собой как обычную таблицу, так и задачу типа «баг» в одном из баг-трекеров[13 - Баг-трекер (англ. bug tracking system, bug-tracker – «система отслеживания ошибок») – прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки и неполадки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий.], у любой ошибки есть атрибуты, которые необходимо заполнить. Эти сведения должны помочь тому, кто будет исправлять эту ошибку, сделать это наиболее рациональным способом.
Давай посмотрим на дефект с точки зрения степени его влияния на возможность использования игры, то есть попытаемся определить его критичность. Для этого тестировщику нужно проанализировать совокупность следующих факторов.
1. Степень влияния на работоспособность игры, то есть насколько сильно дефект затрудняет игровой процесс.
2. Степень заметности для пользователя – насколько дефект заметен для большинства игроков[14 - В некоторых компаниях для определения этого фактора может быть использовано отдельное поле. Оно может так и называться – влияние на пользователя (User effect), в английском варианте еще употребляется User impact, Probability. То есть то, насколько вероятно, что пользователь встретит этот дефект. Сам посуди, если баг возникает при прохождении основного сюжетного квеста в игре, то вероятность его встретить 100 %, а если эта проблема где-то на краю локации в подземельях и туда еще надо добежать, то понятное дело, что не каждый игрок найдет это место, а значит и баг.].
3. Степень влияния на удобство использования – насколько дефект ухудшает удобство игрового процесса.
Только анализ всех этих факторов вместе позволит получить правильное представление о критичности бага.
С точки зрения критичности принято выделять следующие виды дефектов.
Blocker (Блокирующий, Блокер) – самый критичный и самый заметный дефект, который вызывает самые большие трудности при использовании игрового продукта. Более того, блокер, как правило, – это такой дефект, который не позволяет нам больше играть, и обойти это препятствие не представляется возможным. Помнишь синий экран смерти в Windows? Вот это как раз пример блокера! Другими примерами могут стать «вечный» фриз, утечка памяти и многие другие неприятные вещи. Но есть и хорошая новость для тестировщика: ты никогда не пропустишь блокер, если увидишь его, это просто нереально. Ты внезапно теряешь контроль над игровым процессом и получаешь его назад только после полной перезагрузки. Хотя и в этой ситуации, если подходить строго, блокеры можно разделить на софтлок (softlock) и хардлок (hardlock).
Софтлок – это случаи, когда игрок, например, постоянно погибает в месте воскрешения или автосохранение игры происходит как раз в момент гибели персонажа. Другими словами, формально игра продолжает работать, но все, что может делать игрок, – бесконечно повторять одни и те же действия без прогресса и возможности откатиться назад.
Хардлок – это ситуация, при которой игра перестает воспринимать любые команды ввода и единственный выход из ситуации – перезагрузка.
Представь, что ты находишься в комнате, в которой нет окон, дверь заперта, а ключа нет: выйти из нее невозможно.
Critical (Критический) – этот баг очень похож на предыдущий. Он тоже может превратить игровой процесс в кошмар и выглядит как начало Армагеддона, но, в отличие от предыдущего дефекта, предполагает некий способ выхода из ситуации. Например, появляющееся каждые пять минут окно с ошибкой, останавливающее игровой процесс, можно закрыть, нажав Alt+F4, и продолжить игру.
В той же комнате, в которой ты оказался в первый раз, кроме запертой двери есть окно, в которое можно с трудом выйти. Люди не должны выходить в окна, но это альтернативный приемлемый выход из ситуации, не так ли?
Major (Значительный). Значительными называются дефекты, которые осложняют использование основных функций игры: движение персонажа, использование необходимых предметов, переходы на другие уровни, получение наград и т. д. Они также могут полностью блокировать второстепенный функционал: выполнение отдельных квестов, способы перемещения по карте, взаимодействие моделей и т. д.
В комнате есть дверь, но она открывается только на такую ширину, что тебе придется выдохнуть весь воздух и снять часть одежды, чтобы протиснуться в проем. Ужасно неудобно, но выйти все же можно.
Minor (Незначительный). Обычно такие баги не относятся к функционалу игры или влияют на него в очень незначительной степени. Тем не менее баг заметен и очевиден для тестировщика и для пользователя. Чаще всего так определяется дефект, который затрудняет нам удобство использования игрового продукта, раздражает игрока или связан с недочетами интерфейса. Очень часто в эту категорию попадают мелкие рендер-баги[15 - Рендеринг – термин в компьютерной графике, обозначающий процесс получения изображения по модели с помощью компьютерной программы.]
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию (https://www.litres.ru/book/aleksandr-torgovkin/testirovanie-videoigr-ili-legkiy-sposob-popast-v-geymd-70895029/) на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
notes
Примечания
1
Saber Interactive – международная компания по разработке и изданию компьютерных игр. Офисы разработки находятся в России, Армении, Испании, Беларуси, Швеции и Португалии. – Здесь и далее прим. авт.
2
Bytex – российская компания, специализирующаяся на тестировании компьютерных игр любого жанра на любых платформах.
3
RSTQB (Russian Software Testing Qualifications Board) – российское представительство открытой международной организации ISTQB, занимающейся развитием тестирования программного обеспечения через обучение и сертификацию.
4
Шутан (от «шутер», англ. shooter) – жанр игры от первого или третьего лица, в котором игровой процесс основан на использовании в сражениях огнестрельного оружия.
5
Баг – жаргонное название дефекта. В индустрии ходит такая легенда о появлении этого термина. В 1945 году при испытании компьютера Mark II случился сбой в работе, вызванный мотыльком, закоротившим собой контакты реле. В журнале была сделана соответствующая запись о первом подтвержденном случае обнаружении бага (жука). Так с тех пор называют любой дефект программного или аппаратного обеспечения.
6
Плейтест (англ. playtest) – метод тестирования игры путем предоставления ее группе представителей целевой аудитории для обнаружения потенциальных дефектов и сбора отзывов.
7
Продукт развивается, и требования могут быстро устаревать. Если требования не актуализируются, то, как правило, использовать их в работе нет никакого смысла. Поэтому одна из важных задач в проекте – поддерживать требования к продукту в актуальном состоянии.
8
ГДД (гейм-дизайн-документ) – детальное описание разрабатываемой компьютерной игры.
9
QA (Quality Assurance) – это любой систематический процесс определения соответствия продукта или услуги определенным требованиям.
10
Краш – полная поломка, аварийный сбой.
11
Тест-кейс – это детально описанный сценарий или инструкция, которая позволяет тестировщикам выполнить определенные шаги для проверки определенной функциональности или поведения программного продукта. Это основной инструмент в процессе тестирования программного обеспечения, включая компьютерные игры.
12
Иногда также называется Repro Frequency.
13
Баг-трекер (англ. bug tracking system, bug-tracker – «система отслеживания ошибок») – прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки и неполадки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий.
14
В некоторых компаниях для определения этого фактора может быть использовано отдельное поле. Оно может так и называться – влияние на пользователя (User effect), в английском варианте еще употребляется User impact, Probability. То есть то, насколько вероятно, что пользователь встретит этот дефект. Сам посуди, если баг возникает при прохождении основного сюжетного квеста в игре, то вероятность его встретить 100 %, а если эта проблема где-то на краю локации в подземельях и туда еще надо добежать, то понятное дело, что не каждый игрок найдет это место, а значит и баг.
15
Рендеринг – термин в компьютерной графике, обозначающий процесс получения изображения по модели с помощью компьютерной программы.