Тестирование в Инди-Играх. Часть 2.
Если ты начинающий инди-разработчик, или хочешь узнать о тестировании игр, то эта статья тебе понравится!
Привет, дружище!
Я рад, что тебе понравилась моя предыдущая статья, где мы построили классификацию ошибок и узнали, кто же такие тестировщики на самом деле.
Напоминаю, что статья поделена на несколько частей, и сегодня мы затронем тему создания тестовых артефактов и самоорганизации. Чтобы ни один баг в твоей крутой игре не остался безнаказанным! Я планировал рассказать еще и о Тест-Дизайне, но статья и без того получилась объемная. Поэтому про Тест-Дизайн я в подробностях расскажу в следующей статье. Надеюсь ты простишь меня за это. Поехали!
ЦИКЛ ТЕСТИРОВАНИЯ ИГРЫ
Работа тестировщика не останавливается на монотонном выполнении тест-кейсов. Порой тестеру приходится напрягать мозги не хуже разработчиков. Ведь для введения новой фичи, разработчику может понадобится всего пару часов, а тестировщику весь день, чтобы эту фичу проверить и пустить игру в массы. Поэтому, для успешной работы тестеру необходимо иметь навык самоорганизации, и уметь правильно выстраивать свою работу. А чтобы это делать, нужно иметь представление о цикле тестирования. Вот, кстати, и он...
Скажу сразу, первые два пункта для инди-разработчиков не особо важны, поскольку обычно, тестированием и разработкой занимается один человек. Но если ты вдруг решил стать тестером или уже им являешься, то эта информация будет тебе полезна.
АНАЛИЗ ТРЕБОВАНИЙ. На этом этапе выполняется тестирование требований и уточнение требований. "Как можно тестировать требования?" - спросишь ты. Да очень просто, нужно лишь смотреть, чтобы они отвечали следующим пунктам:
* Завершенность (чтобы не было фраз по типу: "и т.д.", "смотри выше");
* Атомарность (требование должно описывать только одну ситуацию, никаких: "когда игрок лутает врага и судук, или босса, должно открываться окно инвентаря");
* Непротиворечивость;
* Однозначность (явный признак однозначности, это наличие таких слов, как "легко", "как минимум", "эффективно", "своевременно", "быть способным", "нормально", "быстро"... этот список можно продолжать долго. Я надеюсь ты уловил ход моих мыслей)
* Выполнимость;
* Обязательность (если требование не обязательно, так зачем оно вообще нужно? Явный признак необязательности, наличие пометок "на всякий случай" или же устаревшие требования);
* Трассируемость (требования должны быть пронумерованы, с рабочими ссылками).
ПЛАНИРОВАНИЕ ТЕСТИРОВАНИЯ. На данном этапе определяются цели тестирования. Составляется тест-план (за частую он есть лишь в голове тестера). Определяется трудоемкость тестирования и составляется расписание, если это необходимо.
РАЗРАБОТКА ТЕСТОВ. Вот тут тебе и пригодятся навыки тест-дизайна и знания тестовых артефактов.
ВЫПОЛНЕНИЕ ТЕСТОВ. Ну тут всё понятно из названия. Плюсом будет лишь заведение баг-репортов в баг-трекер. Если ты инди, то тебе повезло, т.к. баг-репорты заводятся прямиком тебе в голову!
ОЦЕНКА РЕЗУЛЬТАТОВ. Составляется отчет и определяется состояние игры: "готово к релизу", "надо подправить", "что это было???".
КСТАТИ. Если ты хочешь быть настоящим львом в тестировании, то у тебя всегда должен быть особый настрой. Берясь за тестирование, ты должен внушить себе, что перед тобой настолько хреновая игра, что играть в нее просто невозможно. Ведь все мы ищем только то, что хотим. Если ты настроишь себя иначе, мол "Игра просто супер! Надо это лишь доказать", то ты нихрена не найдешь. Инди-разработчикам это бывает очень сложно сделать.
ТЕСТОВЫЕ АРТЕФАКТЫ
Итак, что же нужно, чтобы ловить и уничтожать баги?
(Я использую Excel для создания артефактов, если ты пользуешься другим софтом, то можешь написать об этом в комментариях)
Чек-листы. Это, по сути, список всех объектов и их состояний в игре, которые нужно проверить. Чек-лист нужно иметь даже идни-разработчику (хотя бы упрощенную версию). Зачем? Чтобы было понятнее, приведу аналогию с походом в магазин за покупками. Когда ты / твоя жена / мама предварительно пишет тебе список покупок, то зайдя в магазин, ты купишь всё что нужно. Если у тебя списка не будет, то ты купишь только то, о чем вспомнишь или что понравится.
Тест-кейсы. Это четное описание проверки элемента или состояния игры. Хорошо составленный тест-кейс может выполнить абсолютно любой человек. Для инди-разработчиков, тест-кейсы полезны тем, что их можно дать другу или девушке, и не тратить время и энергию на тестирование билда. И в тоже время, получить качественный фидбэк.
Что должно включаться в тест-кейс (рекомендуемое):
* Номер теста (Нумерация должна быть уникальной, чтобы можно было потом сослаться на этот тест);
* Название (краткое описание);
* Предварительные условия (начальное состояние объекта);
* Шаги тестирования;
* Ожидаемый результат;
* Фактический результат;
* Постусловие (событие, которое возвращает игру в начальное состояние).
Вот пример. Предположим, что по логике игры можно иметь только одну казарму:
Тест комплект. Это набор тест-кейсов, который относится к одному модулю, билду, функциональности или типу тестирования. Тест комплекты могут быть вложены друг в друга для удобства. Например в тест комплекте "Постройка зданий" будут располагаться тест комплекты "Постройка казармы", "постройка ратуши", "постройка конюшни" и т.д.
Для инди, тест комплекты полезны по той же причине, что и тест-кейсы. Вообще, это мощный инструмент, который позволяет снять с себя большой объем работы и водрузить его на друга. Ему прикольно, а для нас - спасение!
Ну вот и всё на сегодня. Спасибо, что уделил мне свое время! Надеюсь тебе понравилась статья. В следующий раз мы уже точно обсудим Тест дизайн. А дальше, начнем углубляться в методики и стратегии тестирования. Можешь присылать в комментарии или в личку свои варианты тестовых артефактов, ведь мои примеры не являются абсолютом!
Лига Разработчиков Видеоигр
6.6K постов22.1K подписчиков
Правила сообщества
ОБЩИЕ ПРАВИЛА:
- Уважайте чужой труд и используйте конструктивную критику
- Не занимайтесь саморекламой, пишите качественные и интересные посты
- Никакой политики
СТОИТ ПУБЛИКОВАТЬ:
- Посты о Вашей игре с историей её разработки и описанием полученного опыта
- Обучающие материалы, туториалы
- Интервью с опытными разработчиками
- Анонсы бесплатных мероприятий для разработчиков и истории их посещения;
- Ваши работы, если Вы художник/композитор и хотите поделиться ими на безвозмездной основе
НЕ СТОИТ ПУБЛИКОВАТЬ:
- Посты, содержащие только вопрос или просьбу помочь
- Посты, содержащие только идею игры
- Посты, единственная цель которых - набор команды для разработки игры
- Посты, не относящиеся к тематике сообщества
Подобные посты по решению администрации могут быть перемещены из сообщества в общую ленту.
ЗАПРЕЩЕНО:
- Публиковать бессодержательные посты с рекламой Вашего проекта (см. следующий пункт), а также все прочие посты, содержащие рекламу/рекламные интеграции
- Выдавать чужой труд за свой
Подобные посты будут перемещены из сообщества в общую ленту, а их авторы по решению администрации могут быть внесены в игнор-лист сообщества.
О РАЗМЕЩЕНИИ ССЫЛОК:
Ссылка на сторонний ресурс, связанный с игрой, допускается только при следующих условиях:
- Пост должен быть содержательным и интересным для пользователей, нести пользу для сообщества
- Ссылка должна размещаться непосредственно в начале или конце поста и только один раз
- Cсылка размещается в формате: "Страница игры в Steam: URL"