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

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

Сегодня я предлагаю вам взглянуть на любопытный продукт — операционную систему, основанную на Linux Debian и имеющую громкое название «Lindows OS», далее — Lindows. Речь пойдёт об операционной системе, которая вынудила корпорацию Microsoft выкупить себе столь созвучное наименование.

Официальная цель создания программного продукта с названием Lindows — обеспечить запуск Windows- и Linux-приложений в среде Linux. А что, так можно было, что ли? Это не просто круто, а неимоверно свежо (речь идёт о 2001 годе). В данном проекте было организовано подобие онлайн-магазина приложений, а ещё бонусом предполагается стабильность работы Linux. В таком случае приобретение Windows — под вопросом.

В дальнейшем «Lindows OS» переименовалась в «Linspire OS», и проект просуществовал аж до 2008 года — это около 7 лет с момента создания.

Поставим-ка мы эту операционную систему, посмотрим, на чём она построена и как планировалось обеспечить обещанную работоспособность.

Я работаю программистом уже более 8 лет, и, признаюсь, никогда не понимал, как на самом деле устроены компьютеры. Поэтому я решил попробовать изучить их работу путём эмуляции. Извините, Бен Итер, я пока не собираюсь ничего создавать.

Перевод статьи из GameDiscoverCo: Разбор (с цифрами и графиками) эксперимента по запуску инди-игры SuperWEIRD на itch.io. Пошаговое описание того, что конкретно делали разработчики с поисковыми алгоритмами, анализом влияния тегов на охваты и итоговые цифры по скачиваниям, браузерным сессиям и конверсиям в Steam вишлисты.

Redis всё чаще встречается в вакансиях для QA, и понимание его работы становится полезным навыком для тестировщика.

В статье простым языком объясняется, что такое Redis, где он используется, чем отличается от реляционных баз данных и почему он работает быстрее SQL.

Также разбираются практические случаи применения Redis в тестировании: проверка данных, ускорение тестов, подготовка нужного состояния системы и отладка.

Подойдёт для подготовки к собеседованиям и для работы на реальных проектах.

Равно 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 году.