Тестирование в Инди-Играх. Часть 2.⁠⁠

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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