azShoo

Давайте будем честными, продукты имеющие реальную продуктовую ценность имеют такое число состояний, что какие-то из них будут всегда сломаны.
Независимо от фреймворков, тестирования и прочего. Баги будут, и чем больше изменений вы вносите - тем больше шансов привнести и баги.

Тем не менее, есть вполне стандартные методы минимизировать эту боль.
Это и практики тестирования (не только силами тестировщиков) и повышение code culture, код ревью, мониторинг состояния продукта, нормальные практики релизов и прочее-прочее-прочее.
Никакого единого способа "всё и сразу починить" нету.

Правило номер 0 гласит:
Если вам нужен совет о том, как применить блокчейн - значит вам не нужен блокчейн.

1) Почитать про теорию тестирования. Вам нужно понять, как происходит процесс тестирования, какая у него цель и пр.
2) Прочитать про основные практики тест-дизайна: Вы должны примерно представлять, какие проверки нужны и в каких случаях.
3) Применить полученные знания в выданному вам продукту и составить условный набор тест-кейсов.

Я бы ожидал от джуниора, что он понимает:
а) Какие проверки необходимо провести для оценки общей работоспособности игры, и что стоит проверять после того, как общая работоспособность проверена.
б) Понимает, какими способами можно свести к минимуму эти самые проверки (применение тест-дизайна на практике).
в) Понимает, что такое приоритеты в тестировании - какие проверки стоит проводить раньше, какие позже.

"Оптимальный" путь зависит многих факторов.
Например, от архитектуры игр: предполагается постоянный коннект клиента с сервером, или можно жить в оффлайне?
Например, от UI и игровой логики: должен ли у пользователя быть постоянный real-time доступ к состоянию таймера восстановления, или оно просто должно тикать где-то в фоне?
Может ли он взаимодействовать с этим таймером (напр. дебаффать других игроков, что бы замедлить восстановление, или задонатить что бы сократить время)

В целом детерминированная по определенным правильнам, регулярно случающаяся активность идеально попадает под Scheduled Job \ Timer внутри игровой логики.
У вас есть момент инициализации таймера, в который вы рассчитываете с какой скоростью и в каком объеме у вас должен происходить "тик" восстановления энергии.
У вас есть момент окончания таймера - объект из буффера кидается в очередь на передачу клиента, обрабатывается клиентом, происходит так.
У вас есть критерии его окончания - пользователь ушел в оффлайн? Грохнули все таймеры для него, например. Или, наоборот, зафризили.

Самое сложное тут - правильно отслеживать состояние таймера и апдейтить его при необходимости.
Для этого надо правильно проработать условия возникновения, истечения и обработки таймеров и сложить их в прозрачное и пригодное для дебаггинга-тестирования хранилище.

Python + Requests

Есть разные уровни тестирования, задействующие API.
Если вы тестируете непосредственно контракт (посылаем такой запрос -> получаем такой ответ), то делать это через UI кажется бессмысленным. Подойдет любой инструмент, позволяющий посылать запросы.
Вариантов много: Postman, RestAssured, а так же любой язык + библиотека для отправки HTTP запросов (напр. Python + Requests \ Java + ApacheHttpClient).
Если вы проверяете интеграцию сервисов (интеграционный тест), то логично проверять что сервис А посылает валидные запросы, а сервис Б их валидно обрабатывает. Т.е. запрос будет происходить от лица сервиса А (изнутри или со стороны его UI - не важно).
Если ваш тест представляет собой end-to-end проверку (т.е. максимально приближенную к продакшену последовательность действий), то тест будет проходить в UI (т.к. это точка взаимодействия пользователя).

Первый вариант проще и быстрее, начинать стоит с него. End-to-end тестами стоит покрывать только основный пользовательские сценарии, т.к. такие проверки обычно долгие и дорогие в разработке и поддержке.

Если мы говорим о подготовке данных для тестирования - то это всё напрямую вытекает из вполне емких принципов тест-дизайна.
Граничные значение, классы эквивалентности, pairwise testing - все это позволяет довольно быстро определить нужные наборы данных для каждого сценария и схлопнуть их до необходимого минимума вариаций.
Дальше уже вопрос выявления сценариев, по которым нужно готовить данные. Тут нужно анализировать систему, составлять тестовую документацию и пр.
В целом, я бы сказал, что пары фундаментальных книг по тест дизайну и тест-анализу поможет понимать, что и на каких данных проверять.
Дальше уже только долгий и кропотливый труд по формированию и синтезу тестовых данных.

Давайте по порядку.
Да, ISTQB стоит денег, причем даже за "неудачную" попытку его пройти.
Так работает сертификация везде и всегда.
Дискуссиями о том, какую смысловую нагрузку несет получение сертификата идет не один год, единого мнения нет.
Если коротко: хуже от этого никому не будет, хотя рассчитывать, что это даст ощутимый результат - смысла нет.
Что касается работодателей: нужно понимать, что при собеседовании у работодателя стоит цель закрыть определенные задачи за N денег. Если вы смогли его убедить, что можете это сделать - ему будет пофиг на все бумажки. Если не смогли - сертификат тоже вряд ли поможет.
Есть работодатели и ситуации, когда сертификат играет "в плюс" (напр. при подаче документов на релокацию в другую страну любые сертификаты будут дополнительным плюсом в глазах бюрократов из иммиграционной службы).

Ну и последний вопрос: ситуация, когда текущий работодатель оплачивает сертификацию сотруднику - довольно стандартная. В большинстве случаев это делается с условием, что если вы уволитесь раньше, чем через N - вы вернете стоимость сертификации.
Хотя я бы, с точки зрения работодателя, скорее бы отправил человека на курсы, повышающие его скиллы, нежели на сертификацию позволяющую проверить насколько человек ориентируется в профессиональной терминологии (а весь ISTQB это по сути заучивание терминов).

Короткий ответ: Да, тестируется.

Длинный ответ:
Команды, занимающиеся разработкой подобных инструментов - это всегда относительно независимая команда, существующая в своих циклах разработки, релизах и своем окружении.
Тестирование такого продукта может быть завязано на тех "клиентов", которые интегрировали у себя этот продукт (т.е. во время "внутреннего тестирования") учитываются юзкейсы внешних клиентов. Так работает тестирование любого продукта - тебе, прежде всего, необходимо гарантировать работу тех сценариев, которые задействованы твоими пользователями.
Тем не менее, продукт, вероятнее всего, будет тестироваться изолировано от внешних интеграций.

Тут нужно понимать, что конкретно вы хотите проверить.
Если речь о том, как сайт выдерживает параллельную работу 10 тысяч юзеров - вам нужны инструменты нагрузочного тестирования (гуглите Load & Performance testing tools и вперед).
Если речь о том, как сайт работает на бОльших объемах данных (условно - вывести список из 10к заказов вместо 10 штук) -> нужно копать в сторону сидирования данных и вообще их генерации, т.к. по сути вам не нужны "действия пользователей", а нужны только данные в базе (т.е. артефакты этих действий).
Если речь о лайфтайме данных, то тут сложнее. Вы можете сгенерировать данные, якобы созданные 2 месяца назад (условно подменив все необходимые таймстэмпы нужными), но это никак не покажет проблемы. Основная причина багов в "старых" данных - то, что со временем приложение, модель и структура данных меняется, что делает созданные 2 месяца назад данные не полностью корректными с точки зрения текущей системы (если в процессе изменений была нарушена обратная совместимость).
Тут может помочь только:
а) раскатывать кусок старого дампа и проверять на нём.
б) генерировать тестовые данные в старой версии приложения и инъектить их в базу новой версии.
в) использовать дамп с прода, где эти старые данные уже сгенерены пользователями.

При условии, что он не будет течь по памяти - нет.

В требованиях к кандидату это может значить что угодно, в зависимости от фантазии рекрутера.
Мейнстримные языки в автоматизации и разработке в тестировании -> Java, Python, JS (+C# для майкрософт стэка).
Другие языки тоже применяются, но реже.
Какой из них применять - решение команды, в целом особой разницы нет.
Помимо этого может требоваться и работать с БД (писать запросы, в т.ч. SQL), работать с аналитикой (JQL или аналоги, например), писать bash-скрипты для решения определенных задач.

Что имел ввиду конкретный рекрутер - известно только ему, но в целом стэк используемых QA инструментов довольно большой.

Если мы говорим о внутреннем тестировании (т.е. вы тестируете свой продукт) - то у вас есть доступ к задачам\документации\заказчику, исходя из этого вы можете определить где баг, а где фича.
В случае, если мы говорим о внешнем тестировании (вы пытаетесь найти ошибки в чужом продукте) - тут есть очевидный чеклист багов по безопасности и полноте данных, а в случаях стандартных функциональных ошибок - только здравый смысл и хардкор.

Как лучше всего находить:
Почитать про теорию тестирования, практики тест-дизайна и пр. После этого появится примерное понимание того, что и как проверять.

Я правильно понимаю, что вы хотите запилить свой проект, а за это получать стабильную зарплату одной компании, и ещё и долю в другой?
Хорошая попытка.

Делаете в приложении env файл, в env file в качестве хоста прописываете адрес mock_api, в mock_api делаете заглушки для нужных вас тестовых данных.