Коротко: тестировать надо чужими руками: автор знает, куда идти, и потому не видит проблем. Дайте игру другу без объяснений — всё, о чём он спросит, и есть список того, что надо исправить.
Никто не любит тестировать собственную игру. Хочется сразу показать друзьям готовый результат, а не по двадцатому разу проходить тот же уровень в поисках мелкого бага. И именно поэтому тестирование — тот этап, который чаще всего пропускают новички. Зря.
Почему «я проверил и всё работает» почти всегда неправда
Разработчик тестирует свою игру так, как сам привык в неё играть: теми же кнопками, теми же маршрутами, в своём темпе. Реальный игрок сделает что-то, чего автор просто не предусмотрел — нажмёт кнопку раньше, чем она появилась, зайдёт в комнату задом наперёд, попробует запрыгнуть туда, куда «нельзя».
Поэтому тестирование «сам за себя» — это необходимый первый шаг, но недостаточный.
Пять типов ошибок, которые ловит тестирование
- Логические — механика работает не так, как задумано (двери открываются, когда не должны)
- Производительности — игра тормозит при большом количестве объектов на экране
- Интерфейса — кнопка не нажимается на телефоне, хотя отлично работает на компьютере
- Баланса — уровень слишком лёгкий или невозможно сложный
- Крайние случаи — то, что произойдёт, если игрок сделает что-то неожиданное
Как тестировать самому: попытка сломать
Перед тем как звать друзей, автор проходит собственный чек-лист. Он короткий и почти всегда что-то находит.
- Пройти уровень так, как он задуман, — от начала до конца, без остановок.
- Пройти наоборот: зайти с другой стороны, прыгнуть через препятствие, обойти то, что должно было быть обязательным.
- Нажать всё и помногу раз: кнопку дважды подряд, кнопку до того, как она должна была появиться.
- Постоять на месте минуту. Немало скриптов ломается именно тогда, когда ничего не происходит.
- Умереть или проиграть намеренно — и посмотреть, корректно ли игра возвращает к началу.
Для ребёнка это превращается в отдельную игру «сломай своё», и работает она лучше любой лекции о качестве: ломать собственную постройку весело, а результат — тот самый список исправлений.
Тест на телефоне и вдвоём
Две проверки, которые почти всегда пропускают. Первая — другое устройство: в Studio можно сразу посмотреть, как игра выглядит на телефоне, и именно там обычно выясняется, что кнопка не нажимается, а половина текста не влезла.
Вторая — несколько игроков. Studio умеет запускать несколько тестовых игроков одновременно, и это единственный способ увидеть ошибки, которых в одиночку не существует: двое берут один предмет, счёт засчитывается не тому, дверь закрывается перед вторым игроком. Если игра рассчитана на друзей, без этой проверки она к ним не готова.
Почему чужой взгляд важнее собственного
Автор проекта всегда знает, «как правильно» играть. Именно поэтому он не замечает неудобств, которые сразу бросятся в глаза постороннему человеку. Один внешний тестировщик — даже одноклассник, увидевший игру впервые — находит больше проблем за час, чем автор за неделю самостоятельных проверок.
Как просить друга протестировать
Самое главное правило — молчать. Как только автор говорит «тебе надо пойти направо и нажать на синее», проверка закончилась: дальше друг проходит игру по подсказкам, а не по интерфейсу.
Поэтому договариваются заранее: автор сидит рядом и записывает, а не комментирует. Записывать стоит не только слова, но и паузы — место, где игрок остановился и огляделся, почти всегда важнее того, что он потом сказал вслух. И отдельно ценна фраза «а что тут делать?»: каждая такая фраза — это то, что игра не объяснила сама.
Мнение преподавателя
«Я всегда прошу учеников дать поиграть в свою игру кому-то, кто вообще ничего о ней не знает. Реакция бывает болезненной — «а почему тут непонятно, куда идти?» — но именно эта реакция и есть самый ценный фидбек за весь курс», — делится один из наших менторов.
Баг-репорт: как фиксировать найденные проблемы
«Что-то не работает» — не баг-репорт, а пустая трата времени того, кто будет исправлять. Полезный формат простой: что я сделал → что ожидал увидеть → что увидел на самом деле. Даже в формате одного предложения это спасает часы на выяснение, что именно сломалось.
Вторая половина формата — воспроизводимость. Ошибка, которую удаётся повторить намеренно, считай исправлена: осталось найти строку. Ошибка, которая «иногда бывает», может съесть вечер, поэтому первый вопрос к тестировщику всегда один — что именно ты делал за мгновение до того. Если повторить не удаётся, записывают хотя бы обстоятельства: сколько было игроков, на каком устройстве, в какой части уровня.
Что делать со списком: не всё сразу
После первого внешнего теста список обычно пугает — там двадцать пунктов, и хочется бросить всё. Поэтому мы сразу учим делить найденное на три кучки: ломает игру (исправляем сейчас), мешает играть (исправляем до показа), хотелось бы лучше (записываем на потом).
Третья кучка — самая важная для спокойствия: идеи никуда не исчезают, они просто ждут. А ещё именно там со временем обнаруживается половина будущего второго уровня.
Исправил одно — проверь соседнее
Отдельный урок, который дети усваивают на собственном опыте: исправление ломает то, что работало. Подняли скорость персонажа — он начал перепрыгивать стену. Изменили условие выдачи монеты — исчез счёт.
Отсюда простая привычка: после каждого исправления пройти не только сломанное место, но и то, что рядом. Взрослые команды называют это проверкой на регрессию и автоматизируют; на учебном проекте хватает одного прохода уровня целиком.
Когда останавливаться
Противоположная крайность тоже существует: ребёнок бесконечно шлифует уровень и никогда его не показывает, потому что «ещё не идеально». Тестирование здесь превращается в способ отложить самое страшное — момент, когда в игру сыграет кто-то чужой.
Ориентир простой: игру можно показывать, когда её можно пройти от начала до конца и ни одна ошибка не заставляет перезапускать всё сначала. Остальное дорабатывается после — на живых игроках видно значительно больше, чем на двадцатом собственном проходе.
А сколько времени закладывать на тестирование?
Честный ответ — больше, чем кажется сначала. В небольших учебных проектах мы обычно советуем выделять на тестирование как минимум четверть общего времени разработки. Звучит много. На практике это именно то время, которое спасает от стыда на публичном показе. Считать проще не в часах, а в занятиях: на четыре занятия разработки — одно целиком на проверку и исправления, без единой новой возможности.
Тестирование — не наказание за плохо сделанную игру, а обычная часть любой разработки, включая крупные студии. На курсе Roblox Studio мы учим этому отдельно, потому что без этого навыка даже отличная идея теряется в мелких багах. Приходите на пробное занятие — покажем, как это работает на практике.
