Тестирование игр *

Равно 15 лет назад состоялся релиз PlayStation Vita. К сожалению, PS Vita не удалось добиться успеха и популяности уровня PSP и почти весь мир забыл про PS Vita. На PlayStation Vita существуют игры, которые больше не выходили нигде. У PlayStation 4 и PlayStation 5 нет никакой поддержки игр PlayStation Vita ни в каком виде (обратная совместимость, эмуляция в PSN как у PSP и PS2). Сегодня в этой статье я узнаю как обстоят дела с эмуляцией PlayStation Vita.

Это была пятница, шесть вечера. Я сидел перед монитором и чувствовал себя следователем, который зашёл в тупик.

Три часа назад я нашёл странное поведение в приложении. Открыл Jira, но пока заполнял поля — мысль ушла. На рабочем столе уже лежало 15 скриншотов с именами вроде «Снимок экрана 154312.png». Я открыл их наугад, но уже не помнил, к какому запросу какой относится.

«Я потерял контекст». Баг есть, даже помню, как воспроизвести. Но чтобы восстановить цепочку «действие → реакция сервера → скриншот → вывод» — нужен ещё час.

Знакомо? Я инженер по тестированию, работаю со сложными продуктовыми сценариями, где один баг тянет за собой цепочку из запросов, скриншотов и логов. И с этим сталкиваюсь регулярно.

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

Меня зовут Александр. Я перепробовал Jira, Confluence, Notion и просто папки на диске. Всё либо медленно, либо хаотично, либо зависит от интернета. Поэтому я собрал свой локальный редактор — под себя, под тестирование. Делюсь историей и кейсом.

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

Playwright или Selenium на Java — что выбрать для автотестов в 2026 году? Разбираю историю инструментов, различия в локаторах, ожиданиях, стабильности, стоимости поддержки и объясняю, в каких сценариях каждый из них лучше.

Инжиниринг качества (Quality Engineering) — это современный подход к созданию надёжных и востребованных продуктов, основанный на проактивных методах, автоматизации и анализе метрик. Он помогает компаниям предотвращать ошибки на ранних этапах и обеспечивать высокий уровень качества на всём жизненном цикле разработки.

Несколько лет назад сеть McDonald проводила промо-акцию, в которой через простую мини-игру можно было выиграть iPhone. Называлась эта игра «FriesHit» и была доступна в мобильном приложении McDonald’s (бельгийская версия). Это просто примитивная тапалка, целью которой являлось занять первую строчку таблицы лидеров, чтобы заполучить заветный iPhone (или Samsung S10, если вы окажетесь на втором месте; но кому он нужен).

Каждый день таблица лидеров аннулировалась, то есть компания ежедневно отдавала iPhone X занявшему первое место (как я понял, это происходило целый месяц). Естественно, в игре есть свой подвох — чтобы набрать победные очки, нужно соревноваться с другими игроками. Хитрость в том, что для покупки жизней в игре вы тратите «баллы лояльности». Кто не знает, эти баллы вам начисляют за покупку товаров в сети (типа потратьте €1 в ресторане McDonald's и получите 10 баллов).

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

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

Матрица трассируемости (RTM) — инструмент, который помогает QA видеть реальное покрытие требований и не тестировать «вслепую».

В статье разберём:
• что такое RTM и зачем она нужна
• какие бывают типы трассируемости
• как выглядит матрица на практике
• типичные ошибки при работе с RTM

примеры таблиц, схемы и чек-лист для QA

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

Статья рассказывает о внедрении автоматизированных тестов для CROSSOUT.

В статье описан процесс создания тестового окружения и обоснован выбор инструментов, которые позволили нам справиться с требованиями проекта.

26 февраля в 21:00 по московскому времени стартовал Server Slam - финальное открытое тестирование нового шутера Marathon от студии Bungie. И, дорогие читатели, это получился натуральный краш-тест всей серверной системы. 143 тысячи игроков в Steam одновременно. Спустя два часа после запуска. В будний день. Думаю, цифра говорит сама за себя.

Студия, которая три десятилетия активно участвует на рынке многопользовательских шутеров. Легендарные создатели саги про похождения Мастера Чифа и Молодого Волка - теперь бросают вызов самим себе. Отказ от привычной формулы кооперативных лутер-шутеров. Полный переход в жанр extraction shooters - эвакуационные шутеры, где смерть означает безвозвратную потерю всего нажитого.

Принцип атомарности (объект или операцию нельзя разделить на части, не нарушив их целостность или смысл) применяется в как в разработке кода ПО, так и в разработке кода автотестов.

И в автотестах Postman он особенно хорош! Давайте разберемся на примерах, почему лучше писать небольшие автотестики, «один тест, одна проверка», чем «много проверок в одном тесте».

Разработчик рассказал о необычной задумке — он решил научить свою собаку создавать игры с помощью инструментов вайб-кодинга. Вот как это было.

Привет! Меня зовут Оля, я работаю в сфере обеспечения качества ПО уже больше 17 лет. За это время я успела поработать в самых разнообразных компаниях по очень разным направлениям: от ПО для автозаправок до финтеха, агротеха и ритейла. Пробовала себя и в ручном, и в автоматизированном тестировании. В итоге лет 10 назад ушла с головой в менеджмент.

И как-то в разговоре с Алиной Илюхиной, автором канала Багов бояться - в прод не ходить, зашла речь про развитие QA в наше непростое время. Алина ставила интересные вопросы и в итоге у нас получилось отличное пятничное чтиво, статья-интервью, которой мы решили поделиться с общественностью, чтобы, как завещал Шрек, не держать в себе.

Начиная писать данную статью, меня не покидало ощущение, что я открываю “Ящик пандоры”. Холивар. Так как ну кто признается, что он плохой проектный менеджер? Кто скажет - я плохо управляю проектами? Ну я же… (дальше сами подставьте необходимый спич:))

Тем не менее, в рамках цикла статей по управлению рисками в GameDev данную область просто необходимо рассмотреть.

Четкое понимание целей, целевого состояния проекта, продукта, позволяет лучше понять присущие риски. Эффективное управление игровым проектом и присущими рисками, дает конкурентное преимущество тому, кто знает, как управлять и эффективно этим пользуется.

Мы все часто слышали: “Нужно задержаться”, “Нужно выйти в субботу”, “Вся команда пашет, а ты домой собрался”, “У нас дедлайн, нужно сделать и все”, “It is the Crunch time, baby!” и т.д. в подобном ключе. Я сам, бывало, работал и по выходным, и до утра. Иногда это было дико интересно, а иногда у тебя был просто выбор - либо поработать как просят, либо уволиться.

Давайте разберемся, почему так происходит?

Большое количество игровых проектов терпят неудачу. Но что, если это не вопрос удачи, а следствие ошибок управления, рисков, не выявленных во время, или выявленных, но оставленных без должного внимания? Провал игрового проекта — это чаще всего не случайность.

Январские праздники 2026. Я давно думал над тем, а что просиходит в GameDev с рисками? Как происходит управление игровыми проектами? Почему даже у известных тайтлов достаточно часто бывают серьезные проблемы с финансами, сроками, качеством, командой? Я даже не говорю об инди-разработке, о малых студиях. Почему многие игровые проекты проваливаются, а еще о большем количестве проектов, после их выхода, мы даже никогда не узнаем и не вспомним, они исчезают как вспышка метеора на ночном небе...Почему?

Нелегка жизнь геймера! Позволить себе наслаждаться новыми ААА-тайтлами на ультра-настройках могут только зажиточные ПК-бояре. Но и в классику поиграть не так-то просто! Старые игры написаны под старые системы. Их движки не понимают новых технологий, инструкций, заложенных в новые CPU/GPU. Следовательно, приходится танцевать с бубном, чтобы запустить любимый проект из детства. 

Во многом любителям ретро-игр помогают ребята из GOG, которые дают возможность запускать, например, «Героев 2» на современной системе. Но что делать, если в их ассортименте нет нужного вам тайтла? А как быть, если речь идет об играх времен SEGA или PS1?

В данном случае на помощь приходят эмуляторы! В нашем сегодняшнем материале мы решили узнать, как поживают эмуляторы старых приставок в 2026 году. 

Здравствуйте, уважаемые читатели!

Ох, не подумал бы, что буду устанавливать операционную систему Windows 95 в 2025 году, спустя 30 лет с момента её выхода. Но наступило время чудовищных экспериментов, разящих «железку» наповал! Сегодня мы будем мутировать в учебных целях. В качестве мутанта выступит вирус CIH.1003, навеки прожжённый на компакт-диске с игрой — и не вылечить его оттуда, ну вот никак. Мы наглядно увидим запуск заражённой игры, момент заражения, «окирпичивание» материнской платы, последствия и процедуру «лечения».

Данный эксперимент проводится исключительно в познавательных целях — на своём железе, на своём софте, в изолированной от сети среде — и преследует цель показать, как мы выживали в пререлизной заражённой среде «Half-Life: Day One».

Когда я работала техническим писателем в международной команде, bug reports частенько попадались мне на глаза. И довольно быстро стало понятно: 90% багов написаны одними и теми же конструкциями, просто в разном порядке. Ниже - концентрат того, что часто используется в bug reports на английском. Сохраняйте.

За последние годы я получил 9 сертификатов ISTQB.
И если бы в начале пути я знал, сколько денег можно сэкономить, я бы точно принимал другие решения.

Почти все экзамены я сдавал через GASQ из Беларуси — выходило 140–150 евро за экзамен, что уже было дешевле, чем стандартные европейские цены. Но, как оказалось позже, это далеко не минимум.

И вот что интересно: если бы я заранее знал, какие способы экономии реально существуют, я бы точно пересмотрел стратегию сдачи экзаменов и сэкономил бы несколько сотен евро.

В этой статье я собрал все рабочие способы сэкономить на ISTQB, от полностью легальных до пограничных (с честным описанием рисков).

Привет! Меня зовут Артем Русов. Я тестировщик, который любит разрабатывать разные полезные вещи для других тестировщиков.

Каждый год я создаю бесплатный адвент-календарь для QA, содержащий в себе полезные ссылки, материалы, тренажеры, интерактивные игры, связанные с тестированием, от разных авторов.

Решил, что хочу поделиться им с вами. Каждый день в этот пост буду добавлять новую ссылку из него.

Все материалы в подборке бесплатные, без подвоха и помогают в формировании определенных навыков, смежных с работой тестировщика.