Баги в релизе — не всегда провал тестирования
TL;DR: Игры выходят с багами даже после тестирования, потому что полностью проверить все сочетания действий, платформ, настроек и нагрузок невозможно. Одни дефекты проявляются при редких условиях, другие находят до релиза, но не успевают или сознательно не исправляют к выпуску. Тестирование показывает состояние продукта и оставшиеся риски, разработчики устраняют ошибки, а решение о готовности к релизу принимают ответственные за выпуск.
Игра прошла тестирование и вышла, но сразу после релиза игроки замечают, что персонажи проваливаются под землю, сохранения не загружаются, а сервер предлагает вернуться через пару часов. Если готовая игра работает не как следует, начинает казаться, что тестировщики плохо искали ошибки.
Разумеется, это самые заметные примеры. Реальные дефекты бывают куда менее очевидными, а найденную проблему ещё нужно локализовать, исправить и перепроверить. Между баг-репортом и тем, что увидит игрок, — исправления, новые сборки, повторные проверки и решения о допустимом риске. На выпуск также влияют требования издателя, сроки и другие ограничения разработки. Найти проблему и решить, можно ли выпускать игру с оставшимися дефектами, — не одно и то же.
Шрек не врезался в стену. Можно выпускать?
Представим условный платформер про Шрека: многослойный огр должен пройти по коридору и не застрять в стене. Дошёл один раз — в этих условиях сценарий сработал. Но игрок может свернуть не туда и не так, как предполагал гейм-дизайнер: открыть дверь во время диалога или попытаться войти в стену боком, верхом на осле и в момент автосохранения.
Тестировщик не просто смотрит, запускается ли игра, а специально ищет места, где она может споткнуться. Он меняет условия, проверяет границы, пробует странные и неудобные сценарии — те самые, для которых простого повторного прохождения недостаточно.
Тестирование относится к контролю качества — QC (quality control) — и даёт сведения о продукте. Обеспечение качества — QA (quality assurance) — сосредоточено на процессах, которые помогают предупреждать дефекты и выявлять проблемы раньше. Подробнее — в статье «QA и QC: в чём разница». Итог проверки — не вердикт «игра хороша», а факты о конкретной сборке, платформе и рисках.
Тестирование относится к контролю качества — QC (quality control) — и даёт сведения о продукте. Обеспечение качества — QA (quality assurance) — сосредоточено на процессах, которые помогают предупреждать дефекты и выявлять проблемы раньше. Подробнее — в статье «QA и QC: в чём разница». Итог проверки — не вердикт «игра хороша», а факты о конкретной сборке, платформе и рисках.
Cyberpunk 2077: найденный баг — ещё не исправленный баг
Найт-Сити должен был показать игрокам будущее, но на старте напомнил о вполне земной проблеме: одна игра существует сразу в нескольких версиях, и готовность каждой может оказаться разной. Поэтому Cyberpunk 2077 интересна здесь не как музей мемных багов, а как пример того, что происходит, когда все платформы встречают одну дату релиза в разном состоянии.
В итоге Cyberpunk 2077 вышла 10 декабря 2020 года после трёх переносов. На базовых PlayStation 4 и Xbox One игроки столкнулись с проблемами стабильности и производительности. В разговоре с инвесторами руководство CD Projekt признало, что слишком сосредоточилось на дате, недооценило масштаб проблем старых консолей и проигнорировало сигналы о необходимости дополнительного времени. Компания использовала внутреннее и внешнее тестирование; ограничения пандемии она не назвала основной причиной.
Исправление тоже нужно проверить: убедиться, что исходный сбой устранён, и оценить последствия для других функций. Для поиска нежелательных последствий изменений нужны регрессионные проверки. Если времени на доработку не хватает, нерешённые проблемы остаются частью решения о выпуске.
Найт-Сити продолжили перестраивать и после премьеры. В сентябре 2023 года Update 2.0 переработал многие механики, включая полицию и развитие персонажа. Обновление вышло для PC, PlayStation 5 и Xbox Series X|S, но не для PlayStation 4 и Xbox One. Это продолжение работы над игрой на новых платформах, а не свидетельство исправления прежних консольных версий.
Из этого кейса не следует, что тестировщики просто «пропустили баги». Руководство признало наличие сигналов, на которые не отреагировало вовремя. Обнаружить дефект, исправить его и принять решение о выпуске — три разные задачи.
Найт-Сити продолжили перестраивать и после премьеры. В сентябре 2023 года Update 2.0 переработал многие механики, включая полицию и развитие персонажа. Обновление вышло для PC, PlayStation 5 и Xbox Series X|S, но не для PlayStation 4 и Xbox One. Это продолжение работы над игрой на новых платформах, а не свидетельство исправления прежних консольных версий.
Из этого кейса не следует, что тестировщики просто «пропустили баги». Руководство признало наличие сигналов, на которые не отреагировало вовремя. Обнаружить дефект, исправить его и принять решение о выпуске — три разные задачи.
Популярные способы сломать премьерный релиз
Фраза «игра не работает» может означать сбой игровой логики, нехватку ресурсов устройства или недоступность контента. Для каждого риска нужны свои проверки.
Cities: Skylines II: когда одна ошибка меняет целый город
После страдающего мегаполиса из будущего — в город, который игрок строит сам. В Cyberpunk 2077 мы говорили о различиях между платформами. В Cities: Skylines II другой риск: видимый сбой в одной части города может быть связан с системой, работающей в другой. Казалось бы, тестировщику остаётся убедиться, что дома стоят, машины едут, а жители хотя бы делают вид, что довольны. На практике приходится работать городским детективом.
В Cities: Skylines II взаимосвязаны экономика, логистика, транспорт, коммунальные службы и поведение жителей. В апреле 2024 года Colossal Order и Paradox признали недостатки игры, нереалистичный срок улучшений и преждевременный выпуск дополнения Beach Properties. Тогда консольная версия ещё не достигла требуемой оптимизации. В ответах 2026 года команда упомянула задачи с рендерингом, поиском маршрутов и ограничениями консольной памяти.
После изменения одной формулы нужно проверять, как оно повлияло на компании, маршруты, бюджет и поведение жителей. Исправление в одной системе может вызвать регрессию в соседней. Поэтому готовность отдельного исправления ещё не означает, что связанные системы работают согласованно.
После изменения одной формулы нужно проверять, как оно повлияло на компании, маршруты, бюджет и поведение жителей. Исправление в одной системе может вызвать регрессию в соседней. Поэтому готовность отдельного исправления ещё не означает, что связанные системы работают согласованно.
Овербукинг в Microsoft Flight Simulator 2024: когда в аэропорт пришли все
Microsoft Flight Simulator 2024 хорошо показывает, что до игрового мира ещё нужно добраться. Можно тщательно проверить самолёт, кабину и маршрут, но в день релиза каждый пилот сначала проходит через общую цифровую инфраструктуру. Если она не выдерживает наплыва, самый детальный симулятор превращается в аэропорт, где всё готово к вылету — кроме самого вылета.
На старте игроки столкнулись с долгой загрузкой и пропадающим контентом, включая самолёты. В официальном сообщении от 20 ноября 2024 года команда объяснила: сервер, обрабатывавший запросы данных для карьеры и миссий, оказался тотально перегружен.
Такой риск оценивают нагрузочными испытаниями. Вот ведь незадача: нагрузку проверяли заранее. По словам разработчиков в разборе запуска, серверную часть испытывали на 200 000 смоделированных пользователей. Кроме того, в октябре прошла Technical Alpha для сбора телеметрии онлайн-сервисов. В её заявленную программу входили стриминг контента, аутентификация, режим карьеры, миссии и другие сервисы.
По объяснению команды, на релизе перегрузился кэш, через который сервис получал данные из базы. Разработчики ограничили число одновременных подключений, затем увеличили размер очереди и скорость допуска игроков в пять раз. Примерно через полчаса кэш снова отказал — именно такую последовательность команда описала в видеосообщении о запуске.
Точного числа одновременно подключившихся пользователей в приведённом разборе нет. Поэтому по этим данным нельзя вычислить, во сколько раз спрос превысил тестовую нагрузку. Известно другое: испытания проводили, но, по признанию команды, наплыв игроков оказался недооценён. Иногда проблема не в том, что аэропорт никто не проверял. Просто в день открытия туда пришло больше пассажиров, чем ожидали.
Такой риск оценивают нагрузочными испытаниями. Вот ведь незадача: нагрузку проверяли заранее. По словам разработчиков в разборе запуска, серверную часть испытывали на 200 000 смоделированных пользователей. Кроме того, в октябре прошла Technical Alpha для сбора телеметрии онлайн-сервисов. В её заявленную программу входили стриминг контента, аутентификация, режим карьеры, миссии и другие сервисы.
По объяснению команды, на релизе перегрузился кэш, через который сервис получал данные из базы. Разработчики ограничили число одновременных подключений, затем увеличили размер очереди и скорость допуска игроков в пять раз. Примерно через полчаса кэш снова отказал — именно такую последовательность команда описала в видеосообщении о запуске.
Точного числа одновременно подключившихся пользователей в приведённом разборе нет. Поэтому по этим данным нельзя вычислить, во сколько раз спрос превысил тестовую нагрузку. Известно другое: испытания проводили, но, по признанию команды, наплыв игроков оказался недооценён. Иногда проблема не в том, что аэропорт никто не проверял. Просто в день открытия туда пришло больше пассажиров, чем ожидали.
Шрек снова застрял в стене — но только на конкретной платформе
Одна и та же игра может нормально работать на мощном компьютере, но сломаться на старой консоли. Причина — в разном «железе», версиях системы, настройках графики, управлении и скорости загрузки данных.
Проверить все сочетания устройств, версий системы, настроек и игровых состояний практически невозможно. Поэтому команда выбирает приоритетные конфигурации: популярные устройства, модели с минимально поддерживаемыми характеристиками и условия, в которых ошибка сильнее всего повлияет на игровой опыт. Такой выбор называют риск-ориентированным тестированием: приоритеты определяют с учётом вероятности отказа и тяжести его последствий.
Сначала проверяют запуск игры, сохранения и основные функции, затем проходят критичные игровые сценарии. Команда фиксирует, какие сочетания устройств и сценариев уже покрыты проверками, а какие остаются вне покрытия.
Если ошибка проявляется только на одном устройстве, в баг-репорте указывают версию игры, модель устройства, настройки, точные шаги воспроизведения, ожидаемый и фактический результат. После исправления тот же сценарий проверяют снова и оценивают, не вызвало ли изменение проблем в других сценариях и конфигурациях. Например, Шрек перестал проходить сквозь стену, но теперь застревает в двери.
Если Шрек дошёл до замка на одном девайсе, это подтверждает только выполнение конкретного сценария в проверенной конфигурации. На другой консоли или компьютере стены всё ещё могут оказаться иллюзорнее, чем нужно по гейм-дизайну.
Сначала проверяют запуск игры, сохранения и основные функции, затем проходят критичные игровые сценарии. Команда фиксирует, какие сочетания устройств и сценариев уже покрыты проверками, а какие остаются вне покрытия.
Если ошибка проявляется только на одном устройстве, в баг-репорте указывают версию игры, модель устройства, настройки, точные шаги воспроизведения, ожидаемый и фактический результат. После исправления тот же сценарий проверяют снова и оценивают, не вызвало ли изменение проблем в других сценариях и конфигурациях. Например, Шрек перестал проходить сквозь стену, но теперь застревает в двери.
Если Шрек дошёл до замка на одном девайсе, это подтверждает только выполнение конкретного сценария в проверенной конфигурации. На другой консоли или компьютере стены всё ещё могут оказаться иллюзорнее, чем нужно по гейм-дизайну.
Почему невозможно найти все баги
Варианты множатся с каждым предметом, заданием, устройством и сохранением. Но невозможность проверить всё не означает, что любого объёма тестирования достаточно: команда может неверно выбрать сценарии или не воспроизвести нужные условия.
Хорошее тестирование обычно незаметно
Правило Штирлица — лучше всего запоминается последняя часть разговора. Игроки же запоминают приключение — и то, что ему помешало. Пользовательский опыт виден на экране, а проблемы, найденные и исправленные до релиза, остаются за кадром.
Действительно хорошее тестирование не обещает выпустить игру без единой ошибки. Оно показывает, что проверено, что сломано и чем опасны оставшиеся дефекты. Шрек дошёл до замка, сохранение осталось на месте, нужные файлы загрузились, а сервер выдержал наплыв. Вроде бы ничего особенного не произошло.
Тестирование не заканчивается сразу после релиза: патчи, обновления и дополнительный контент — DLC (downloadable content) — возвращают команду к знакомым сценариям уже с новыми рисками. О том, как сопоставлять результаты проверок после изменений, — в статье о сравнении тестовых запусков.
Именно так качественная работа чаще всего и выглядит. Ну или по крайней мере может выглядеть в идеале — подробнее это описано в другой статье.
Но отсутствие заметных сбоев в нескольких сценариях ещё не даёт ответа, готова ли вся игра к выпуску. Для этого нужны результаты проверок и оценка того, что осталось за их пределами.
Основные риски, критичные функции и платформы, а также критерии готовности к релизу фиксируют в тест-плане. Пирамида тестирования помогает распределить проверки между модульными, интеграционными и сквозными тестами с учётом их стоимости и скорости обратной связи. Но вместе с тем само наличие тестирования ещё не означает достаточного покрытия: команда может неверно выбрать сценарии или не воспроизвести нужные условия.
Покрытие уточняют и по результатам эксплуатации: разбор значимого инцидента помогает определить, какую проверку добавить или изменить. Этот цикл показан в статье «От инцидента в проде до регрессионного теста».
Действительно хорошее тестирование не обещает выпустить игру без единой ошибки. Оно показывает, что проверено, что сломано и чем опасны оставшиеся дефекты. Шрек дошёл до замка, сохранение осталось на месте, нужные файлы загрузились, а сервер выдержал наплыв. Вроде бы ничего особенного не произошло.
Тестирование не заканчивается сразу после релиза: патчи, обновления и дополнительный контент — DLC (downloadable content) — возвращают команду к знакомым сценариям уже с новыми рисками. О том, как сопоставлять результаты проверок после изменений, — в статье о сравнении тестовых запусков.
Именно так качественная работа чаще всего и выглядит. Ну или по крайней мере может выглядеть в идеале — подробнее это описано в другой статье.
Но отсутствие заметных сбоев в нескольких сценариях ещё не даёт ответа, готова ли вся игра к выпуску. Для этого нужны результаты проверок и оценка того, что осталось за их пределами.
Основные риски, критичные функции и платформы, а также критерии готовности к релизу фиксируют в тест-плане. Пирамида тестирования помогает распределить проверки между модульными, интеграционными и сквозными тестами с учётом их стоимости и скорости обратной связи. Но вместе с тем само наличие тестирования ещё не означает достаточного покрытия: команда может неверно выбрать сценарии или не воспроизвести нужные условия.
Покрытие уточняют и по результатам эксплуатации: разбор значимого инцидента помогает определить, какую проверку добавить или изменить. Этот цикл показан в статье «От инцидента в проде до регрессионного теста».
Кто и когда решает, что игру уже можно выпускать
В одном из типичных вариантов инженер по тестированию воспроизводит проблему и оформляет баг-репорт, разработчик устраняет дефект, а QA-лид вместе с командой обобщает результаты и оценивает остаточные риски. Ответственные за релиз сопоставляют эти сведения со сроками и последствиями переноса.
Кто может остановить релиз, определяется процессом команды, а не названием должности. Тестирование показывает, что проверено, что сломано и чем опасны оставшиеся дефекты. Решение о выпуске определяет, с какими рисками команда готова отправить игру к пользователям.
Без этих данных решение пришлось бы принимать почти вслепую. Поэтому данные о сборке, проверках, найденных проблемах и решении о релизе важно связывать между собой, а не собирать из разрозненных сообщений.
В системе управления тестированием ТестОпс такой срез собирается в тестовом запуске: команда видит результаты и добавленные связи с задачами и дефектами. Версия сборки и окружение доступны, если команда внесла или передала эти сведения; состав данных описан в документации запуска. Система сохраняет факты и контекст, чтобы специалисты могли оценить результаты проверок и принять обоснованное решение о релизе.
Кто может остановить релиз, определяется процессом команды, а не названием должности. Тестирование показывает, что проверено, что сломано и чем опасны оставшиеся дефекты. Решение о выпуске определяет, с какими рисками команда готова отправить игру к пользователям.
Без этих данных решение пришлось бы принимать почти вслепую. Поэтому данные о сборке, проверках, найденных проблемах и решении о релизе важно связывать между собой, а не собирать из разрозненных сообщений.
В системе управления тестированием ТестОпс такой срез собирается в тестовом запуске: команда видит результаты и добавленные связи с задачами и дефектами. Версия сборки и окружение доступны, если команда внесла или передала эти сведения; состав данных описан в документации запуска. Система сохраняет факты и контекст, чтобы специалисты могли оценить результаты проверок и принять обоснованное решение о релизе.
