Дисклеймер: всё что написано в этой статье, не претендует на чистую правду в первой инстанции, это просто мои мысли, которые посетили мой разбитый кофеином мозг в 3 часа ночи.

Привет, Хабр! Позволю себе написать немного предыстории о том, как я пришёл к написанию этой публикации:
Я уже около четырёх месяцев работаю в крупной IT компании как Junior тестировщик.
Проект, на котором я работаю, существует с незапамятных времён, с тех периодов развития рунета, когда слово документация ещё не было в обиходе у программистов той эпохи.
Благодаря такой особенности, тестировать не то чтобы легко, часто, на подготовку тестовых данных уходит по несколько часов, а само тестирование может занять целый день. Всё из‑за того, что единственно верный способ проверки приложения при отсутствии документации, по моему мнению — исследовательское тестирование, которое очень пригождается, когда из документации только одна небольшая задача из трекера, закрытая больше 8 лет назад.

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

А есть обратный пример? Как тестирование помогает в гейм‑дизайне?
Конечно, есть.
Можно вспомнить про техники тест‑дизайна, а именно: анализ граничных значений и таблица принятия решений.
Вот пример техники анализа граничных значений:
Задача: Нужно понять сколько атака врага должна наносить игроку урона

Решение:
Можно вспомнить про метод баланса, который использовал Сид Мейер при создании своих игр.
В чём его суть: берётся случайное значение, если оно слишком большое — делим его на два, если слишком маленькое — умножаем на два, повторяем пока не найдём подходящее число. Ну чем не анализ граничных значений?
Смотрим границу -> используем -> анализируем -> увеличиваем или уменьшаем -> повторяем если есть такая надобность.

С таблицей принятия решений, я думаю, сталкивались многие, но вот пример:
Задача: продумать как искуственный интеллект врагов будет реагировать на действия игрока
Решение:
Придумываем ситуации взаимодействия игрока с врагами → составляем табличку действий игрока и ответа противников на эти действия

Пример таблицы принятия решений из Google картинок

Исследовательское тестирование без документации — это как пройти старый квест без подсказок. А балансировка врага методом Сида Мейра, тот же анализ граничных значений только в другой обёртке.

Тестирование и гейм‑дизайн — это одно и то же любопытство. Просто в одном случае мы ищем баги в чужом коде, а в другом — в своих собственных правилах.

Спасибо за прочтение!

P. S. Будет приятно увидеть похожие примеры в комментариях, обязательно всё прочитаю!

Как навыки гейм-дизайна помогают мне в работе тестировщиком