Если ты начинающий инди-разработчик, или хочешь узнать о тестировании игр, то эта статья тебе понравится!

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

ТЕСТ-ДИЗАЙН

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

QA-ШАОЛИНЬ

Классы эквивалентности и граничные условия. Это наиболее популярные техники, которые могут применяться одновременно.
Перед тем, как начну подробнее рассказывать про техники, хочу подчеркнуть один очень важный момент. Полностью проверить каждый чих в игре - невозможно. Точнее возможно, но это может занять не один год, а нам ведь нужно уже "вчера" выпустить игру в стор. Правильно? Вот тут нам и приходит на помощь классы эквивалентности и граничные. Они помогают тестеру и инди-разработчику минимизировать количество тестов, чтобы уложиться в адекватные сроки и не пропустить серьезных багов.
Я думаю, что с граничными условиями всё понятно, их я затрагивал в предудщих статьях. А вот, как пользоваться техникой классов эквивалентности, сейчас расскажу:
* определи объект, который хочешь протестировать;
* подумай или посмотри (если тесты у тебя уже есть), какие тесты применимы к этому объекту;
* посмотри, какие из этой массы тестов эквивалентны, т.е. проверяют одно и тоже и скомпонуй их;

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

Пример. Допустим, мы тестим шутер от первого лица. Нам нужно протестировать взаимодействие пули с врагами. Обычно в шутерах тело врага разделено на зоны (голова, туловище, ноги) при попадании в которые наносится разный урон. Это тоже нужно учесть при тесте и желательно уточнить у разработки где находятся эти зоны.
Итак, врагов у нас целая орда. Какие наши действия? Нет, шмалять во всех мы не будем, хоть это и весело.
1) Для начала поделим врагов на классы, как это сделал гейм-дизайнер. Например: Бандит, Мародер, Джаггернаут, Снайпер.
2) Затем найдем одного представителя из каждого класса, и вот теперь уже шмальнем по нему.
2.1) Выстрелим сперва в самый низ ботинка (нижняя граница зоны ног);
2.2) Затем, выстрелим ему прям в ладошку. Можно еще в пряжку ремня (Стык зон туловища и ног);
2.3) Еще дышит? Выстрелим наглецу в шею (Стык зон туловища и головы);
2.4) Ну и контрольный, в самую макушку (Верхняя граница головы);
3) Записать результаты тестирования.

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

Следующая техника - это предугадывание ошибок или тестирование на основе опыта.

Тут всё строится на выявлении особенностей игры и составлении списка потенциальных багов. Например:
1) Многие тестировщики знают, что при подборе аптечек есть вероятность столкнутся с ошибками в игровой логике. Т.е. мы подобрали аптечку, у нас фактически увеличились очки жизни, но на панели здоровья количество очков осталось прежним, или на панели изменилось, а в информации о персонаже нет (если мы тестируем РПГ, к примеру).
2) Анализ спецификации (требований). Т.е. тестировщик, читая требования и основываясь на своем опыте, может предположить, в каких местах разработка вероятнее всего допустит ошибку.
3) Чтение исходного кода. Если комментарии написаны невнятно, или код написан кривовато, то с большой вероятностью, в этом месте вылезут баги. (Этот пункт инди-разработчики делают на автомате. Написал строчку / цикл - проверил).
4) Наблюдение "симптомов" ошибки. Т.е. если моб респаунится в тексутре, то это уже сам по себе баг, т.к. игрок не сможет его убить, но если он респнется в текстуре много раз, то это может привести к снижению производительности игры (к примеру если у нас ММО)

Итак! Предугадывать ошибки можно двумя способами:

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

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

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

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

1.2) Денежный тур. В данном методе тестируются основные фичи и внутриигровые объекты, которые активно рекламируются и за которые игрок готов выложить деньги.
1.3) Внеурочный тур. Если игрок свернул/закрыл игру, это еще не означает, что оно прекратило свою работу. Игра может сохранять данные, получать обновление. Суть тура в том, чтобы проверить эти операции.
2) Туры по историческим районам. Исторические районы игры - это старый функционал, унаследованный код или исправление старых багов. Разделяются на:
2.1) Тур по нерекомендуемым местам. Это как зайти в гоп-стоп райончик. Нерекомендуемые места в игре - это места, где часто скапливаются баги. После того, как баги были исправлены, необходимо еще раз пройтись по этому месту.
  2.2) Музейный тур. Это проверка "музейного" кода. Т.е. кода, который давно не менялся. При переносе игры на новую среду, этот участок кода может не работать и ронять нашу игру.  2.3) Тур предыдущей версии. Применяется, когда вырезается какой-то функционал, меняется интерфейс или устраняется баг, который игроки использовали, как фичу.
3) Туры по развлекательным районам. Обычно туристы приходят в развлекательный район, чтобы отдохнуть, а не ради достопримечательностей. В большинстве игр имеются функции, не представляющие значения для бизнеса, но являющиеся приятным дополнением к основному функционалу. Например, функции, позволяющие настроить игру «под себя» или позволяющие «навести красоту»: персонализация, изменение стиля персонажа, иконок и пр. Таким образом, развлекательные туры проверяют второстепенные функции, и то, насколько они правильно и гармонично сочетаются с основными. Разделяются на:
3.1) Тур по тёмным переулкам. Это тур по фичас, которые не востребованы/мало востребованы игроками, т.к. приносят меньшую пользу или вызывают меньший интерес.  3.2) Тур любителя ночной жизни. В данном метода проверяются возможности работы игры без перезагрузки. А ты о чем подумал?
4) Туры по туристическим районам. Быстрый осмотр игры или основных фич. Разделяются на:
4.1) Тур супермодели. Этот тур о внешнем интерфейсе игры. На сколько он красив и привлекателен, насколько правильно используются цвета, нет ли лишних элементов интерфейса, насколько быстрая анимация, соответствует ли интерфейс стандартам и ожиданиям пользователя. Цель тура - сделать так, чтобы игра смотрелось великолепно, как супермодель на подиуме.  4.2.) Тур по шотландским пабам. Не всегда можно узнать об интересных местах из путеводителя. Иногда, для этого нужно заглянуть в паб. Форумы и блоги, в ним узнать много нового об игре. (В основном это касается крупных игр или игр с большой фан базой). Задача тура заключается не только в проверке игры, но и в том, чтобы получше с ней познакомиться, в идеале, путём общения с игроками.
5) Туры по району отелей. Проверяют второстепенный функционал игры. Разделяются на:
5.1) Тур, отмененный из-за дождя. В этом туре проверяется возможность отмены действия игрока всеми способами: кнопкой "отмена", Esc, Alt + F4, отмена каста заклинания движением персонажа вперед/назад/в стороны/прыжком, закрытием игры через диспетчер задач и т.д. При этом важно отметить, возвращается ли игра в начальное состояние, сохраняются ли данные, возможно ли повторить отмененное действие.  5.2) Тур домоседа. Проверка по принципу наименьшего сопротивления, т.е. выполнять в игре только обязательные задания, качать только обязательные характеристики и т.д.
6) Туры по неблагополучным районам (самый веселый). Проверка уязвимых мест в игре, которые часто используют недобросовестные игроки. Разделяются на:
6.1) Тур диверсанта. Тестировщик должен подорвать работу игры всеми возможными способами. Для этого нужно начать выполнить какое-то действие, определить ресурсы, необходимые игре для выполнения этого действия, удалить или ограничить доступ к этим ресурсам, повторить действие. Например, отключить интернет, ограничить размер оперативной памяти, удалить файл, который считывает игра, ограничить права на выполнение операции, запустить игру на проблемном окружении и т.д. Ограничивайся только своей фантазией!  6.2) Антисоциальный тур. В этом туре нужно делать с игрой то, что обычный пользователь не стал бы делать. Т.е. делай все то, что противоречит логике игры.  6.3) Тур невротика. Повторяй одни и те же действия в игре много и часто.

Если ты дочитал до этого моменты, то я тебя поздравляю! Теперь ты знаешь техники тест-дизайна: умеешь разбивать тесты на классы эквивалентности, проверять граничные условия и понял, как можно эффективно предугадывать ошибки. Надеюсь это поможет тебе в создании тестов, лично мне эти значения хорошо помогают в работе. В заключении, хочу перечислить характеристики, которыми должен обладать хороший, эффективный тест:
* Тест должен выявлять ошибки;
* Набор тестов не должен быть избыточным;

* Тест должен быть наилучшим в своей категории;
* Тест не должен быть слишком простым или сложным;

* Между тестами не должно быть зависимостей (серьезно, не надо).

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

До встречи! 

Если ты начинающий инди-разработчик, или хочешь узнать о тестировании игр, то эта статья тебе понравится!

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

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

ЦИКЛ ТЕСТИРОВАНИЯ ИГРЫ

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

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

АНАЛИЗ ТРЕБОВАНИЙ. На этом этапе выполняется тестирование требований и уточнение требований. "Как можно тестировать требования?" - спросишь ты. Да очень просто, нужно лишь смотреть, чтобы они отвечали следующим пунктам:

* Завершенность (чтобы не было фраз по типу: "и т.д.", "смотри выше");
* Атомарность (требование должно описывать только одну ситуацию, никаких: "когда игрок лутает врага и судук, или босса, должно открываться окно инвентаря"); 

* Непротиворечивость;

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

* Выполнимость;

* Обязательность (если требование не обязательно, так зачем оно вообще нужно? Явный признак необязательности, наличие пометок "на всякий случай" или же устаревшие требования); 

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

ПЛАНИРОВАНИЕ ТЕСТИРОВАНИЯ. На данном этапе определяются цели тестирования. Составляется тест-план (за частую он есть лишь в голове тестера). Определяется трудоемкость тестирования и составляется расписание, если это необходимо.

РАЗРАБОТКА ТЕСТОВ. Вот тут тебе и пригодятся навыки тест-дизайна и знания тестовых артефактов.

ВЫПОЛНЕНИЕ ТЕСТОВ. Ну тут всё понятно из названия. Плюсом будет лишь заведение баг-репортов в баг-трекер. Если ты инди, то тебе повезло, т.к. баг-репорты заводятся прямиком тебе в голову!

ОЦЕНКА РЕЗУЛЬТАТОВ. Составляется отчет и определяется состояние игры: "готово к релизу", "надо подправить", "что это было???".

КСТАТИ. Если ты хочешь быть настоящим львом в тестировании, то у тебя всегда должен быть особый настрой. Берясь за тестирование, ты должен внушить себе, что перед тобой настолько хреновая игра, что играть в нее просто невозможно. Ведь все мы ищем только то, что хотим. Если ты настроишь себя иначе, мол "Игра просто супер! Надо это лишь доказать", то ты нихрена не найдешь. Инди-разработчикам это бывает очень сложно сделать.

ТЕСТОВЫЕ АРТЕФАКТЫ

Итак, что же нужно, чтобы ловить и уничтожать баги?

(Я использую Excel для создания артефактов, если ты пользуешься другим софтом, то можешь написать об этом в комментариях)

Чек-листы. Это, по сути, список всех объектов и их состояний в игре, которые нужно проверить. Чек-лист нужно иметь даже идни-разработчику (хотя бы упрощенную версию). Зачем? Чтобы было понятнее, приведу аналогию с походом в магазин за покупками. Когда ты / твоя жена / мама предварительно пишет тебе список покупок, то зайдя в магазин, ты купишь всё что нужно. Если у тебя списка не будет, то ты купишь только то, о чем вспомнишь или что понравится.

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

Что должно включаться в тест-кейс (рекомендуемое):

* Номер теста (Нумерация должна быть уникальной, чтобы можно было потом сослаться на этот тест);

* Название (краткое описание);

* Предварительные условия (начальное состояние объекта);

* Шаги тестирования;

* Ожидаемый результат;

* Фактический результат;

* Постусловие (событие, которое возвращает игру в начальное состояние).

Вот пример. Предположим, что по логике игры можно иметь только одну казарму:

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

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

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