Комментарии 28
При этом с помощью этого патча нельзя восстановить ранее поверженные файлы сохранения.
Эпическая игра. У неё даже, битые файлы — поверженные в неравном бою с системой хранения. Надо брать.
НЛО прилетело и опубликовало эту надпись здесь
Более того, теперь зачастую быть бета-тестером еще и дороже! Всякие кикстартеры популяризовали схему — больше заплатил, раньше получил игру.
вы уверены насчет схемы кикстартера? обычно там (по крайней мере в тех сборах, где я участвовал) чем раньше поддержишь проект — тем дешевле он обойдется.
Уверен. Доступ к бета версии часто является перком более дорогих комплектов. Вот пример. Beta-backer платит на 66% больше обычного и получает доступ к бете и скин в игре.
Хотя если подумать, это был баг в стиле самого киберпанка-типа не надо заниматься всякой ерундой вместо главного квеста:) Особенно когда у самого персонажа по сюжету встроен глючный чип.
непонятно чем QA занимались. это же стандартный кейс для проверки — нагенерить как можно больше итемов и проверить игру.
Вроде как всю игру тестер не проходит. Тестирует один участок, если все ок, то с помощью читов телепортируется в следующую часть игры. Вот и вышло, что сохранения если и были у тестеров, то явно меньше 8mb.
Тут скорее от постановки задач зависит. Если у тестера где-то в доступной ему документации было упомянуто такое ограничение — то он должен был проверить, а вот если об ограничении знали не только лишь все — то тут вины тестера нет — ибо исчерпывающее тестирование невозможно кроме некоторых тривиальных случаев (точнее потребует бесконечного количества ресурсов)
У тестера есть некий Главный тестер. Который или сам проверяет все необычное что придет в голову или делает тикеты на сотрудников.
Нагенерить миллион объектов и проверить все типовое работает достаточно необычная и одновременно типовая штука чтобы ее проверить. Все же знают этих Плюшкиных.
Нагенерить миллион объектов и проверить все типовое работает достаточно необычная и одновременно типовая штука чтобы ее проверить. Все же знают этих Плюшкиных.
Нагенерить миллион объектов и проверить все типовое работает достаточно необычная и одновременно типовая штука чтобы ее проверить. Все же знают этих Плюшкиных.
Нагенерили миилион объектов, все работает нормально. Нагенерили два миллиона — все работает нормально. Нагенерили три (а комп тестировщика уже издает предсмертные звуки) — все продолжает работать нормально. На каком моменте остановиться?
Минимум 10 раз больше чем можно собрать в игре при всем желании. Это если тестер ленивый.
Гораздо лучше MAX_INT или вообще MAX_LONG. И тикет на разработку. У вас можно получить столько предметов что все ломается. Запилите разумное ограничение.
Гораздо лучше MAX_INT или вообще MAX_LONG. И тикет на разработку. У вас можно получить столько предметов что все ломается. Запилите разумное ограничение.
Минимум 10 раз больше чем можно собрать в игре при всем желании. Это если тестер ленивый.
Это сколько?
Гораздо лучше MAX_INT или вообще MAX_LONG.
Почему именно их? И сколько ресурсов это потребует?
И тикет на разработку. У вас можно получить столько предметов что все ломается. Запилите разумное ограничение.
С этим вообще-то не к разработчику, а к продакт овнеру.
Но в целом — ресурсы тестирования ограничены. Всякие вот такие вот исследовательские проверки могут быть проведены только в случае, если тестирование по требованиям спецификации полностью завершено и задач больше не осталось (т.е. в среднем — никогда).
Это сколько?
Кто ж его знает. Могу предположить что у разработчиков должна быть цифра максимальное число собранных вещей за всю игру. Понятно что оценочная, но какая-то нужна.
Почему именно их? И сколько ресурсов это потребует?
Хорошие константы, почему бы и нет?
Железо на котором работает человек не стоит ничего. Пофиг.
С этим вообще-то не к разработчику, а к продакт овнеру.
Но в целом — ресурсы тестирования ограничены. Всякие вот такие вот исследовательские проверки могут быть проведены только в случае, если тестирование по требованиям спецификации полностью завершено и задач больше не осталось (т.е. в среднем — никогда).
Бага же типичная. Как именно ее править вопрос, но бага это и есть бага. С ней к разработке надо идти. Разработка уже разберется кто будет решать что именно там поправить надо.
Ресурсов нет, в потом эпичный провал на весь мир. Может стоило заранее ресурсы выделить? В том числе вот на такие исследования. Это игра, люди будут там делать все что не запрещенно механикой. И исследовательские проверки имеют смысл, чтобы потом не позориться.
Тестирование без проверки корнер кейсов и не изобретающее эти корнер кейсы по ходу дела не очень полезно.
Ресурсов нет, в потом эпичный провал на весь мир. Может стоило заранее ресурсы выделить? В том числе вот на такие исследования. Это игра, люди будут там делать все что не запрещенно механикой. И исследовательские проверки имеют смысл, чтобы потом не позориться.
Может быть. Вот только при чем тут тестировщики? За выделение ресурсов отвечает только менеджмент.
Тестирование без проверки корнер кейсов и не изобретающее эти корнер кейсы по ходу дела не очень полезно.
Одно дело — проверять граничные значения тогда, когда известны границы, но тут в ветке изначально речь шла про то, что если границы неизвестны, если нет намека на то, что они должны быть — то найти это можно только исследовательским тестированием, а это вопрос ресурсов, которых, как было отмечено выше, обычно не выделяют достаточно. Вообще — тестировщик не должен придумывать граничные условия. Он должен проверять продукт на соответствие спецификации. Он может исследовать и составлять отчет о текущих реальных граничных условиях (нагрузочное или, допустим, стресс-тестирование), но опять же — тут все зависит от выделения ресурсов менеджментом.
Хорошие константы, почему бы и нет?
А потом приходит менеджмент и говорит — что ты херней занимаешься, куча тасок не завершена, а ты пытаешься делать что-то, чего нет в спецификации продукта.
Железо на котором работает человек не стоит ничего. Пофиг.
Скажите это огромному количеству международных компаний, для которых приобрести продукт стоимостью 100 баксов в год на юзера, но при этом повышающее эффективность раза в два — выходом за пределы бюджета.
На самом деле в этом кейсе все просто с точки зрения тестирования когда граница известна — нужно проверить значение непосредственно перед границей и сразу после, всякие MX_INT и MAX_LONG бессмыслены с точки зрения потраченных ресурсов железа. Но вот если в спецификации ничего нет, и нет даже намека что что-то может пойти не так — то тут может помочь только исследовательское нагрузочное тестирование, но если нет убедительных доказательств что что-то может пойти не так — никто не выделит вам ресурсов в виде человеко-часов на проверку, потому что всегда есть дофига более насущных задач.
Да это понятно. Я и говорю что надо всего лишь добавить хотя бы одного более квалифицированного тестировщика с задачей придумывать корнер кейсы, проверять их и писать тестовые сценарии для регрессии. Для него запихнуть MAX_INT во все места куда он запихивается это логичная задача. Типичный корнер кейс.
В итоге такой тестировщик окупится, за счет отсутсвия таких позорных багов. Возвраты, репутация это все безумного дорого.
Такого тестировщика в проекте не было, и в итоге имеем что имеем.
В итоге такой тестировщик окупится, за счет отсутсвия таких позорных багов. Возвраты, репутация это все безумного дорого.
Такого тестировщика в проекте не было, и в итоге имеем что имеем.
добавить хотя бы одного более квалифицированного тестировщика с задачей придумывать корнер кейсы,
Справедливости ради, не факт, что он бы додумался создать 100500 вещей, а потом сохранить и загрузить игру. Может, разработчики даже тестировали создание кучи вещей. Игра не вылетела, вещи в инвентаре были.
Да это понятно. Я и говорю что надо всего лишь добавить хотя бы одного более квалифицированного тестировщика с задачей придумывать корнер кейсы, проверять их и писать тестовые сценарии для регрессии. Для него запихнуть MAX_INT во все места куда он запихивается это логичная задача. Типичный корнер кейс.
Тестировщик пытается создать MAX_INT вещей. В памяти до определенного момента хранится нормально, потом память заканчивается, программа падает задолго до MAX_INT, допустим на 100 тыс. Тестировщик обращается к менеджменту, ему говорят, что это настолько редкий кейс, что ради него никто не будет увеличивать память машины до скажем терабайта, чтобы проверить как она работает с MAX_INT.
Хотя вот допустим другой сценарий. Тестировщику дают достаточно мощную машину, он создает MAX_INT объектов, сохраняет их… и все в порядке, потому скажем при сохранении в инвентаре — они, по сути, записываются парой ключ-значение и занимают минимум места. Ошибка в ограничение 8МБ на сохранение опять упущена.
Как я уже сказал выше — чтобы найти такую ошибку, нужно хотя бы иметь подозрение, что она может существовать. MAX_INT не засунешь во все возможные сценарии, потому что их в таком продукте становится бесконечно много, а проверка основных сценариев — вполне может упустить её. Одно дело, когда есть тестировщик знакомый с проектом и особенно с движком долгое время и тут он может за счет интуиции догадаться, где может возникнуть проблема, а если новый человек, да при наличии довольно скудной документации? Тут уже хватило бы времени проверить то, что известно. Тестирование — процесс, критически зависимый от исходной информации, чем больше информации — тем качественнее будет проведено тестирование.
Вот кстати вы никогда не задумывались о MMORPG? У них есть тестировщики, более того — у них всегда есть возможность провести бета-тест (в отличие от синглплеерных игр, которым критически важно сохранять интиргу сюжета) на десятках тысяч людей. И все равно — при развертывании игры на миллионы — все равно находятся десятки и сотни ранее не замеченных дефектов. Тупо вопрос статистики и ресурсов, потраченных на их обнаружение.
Там 8 мегабайт лимит был. Какие терабайты? Работоспособность с большим количеством предметов никто не проверял вообще.
Тестировщик берет завышенную, но вполне реальную конфигурацию, допустим со 128 гигами оперативки, и смотрит пределы на которых она работает. На этих пределах прогоняются все типовые сценарии. Не прогнать сценарий сохранения-загрузки при тестировании лимитов это недоработка тестировщика.
Большой инвернтарь это настолько банальный сценарий, что про все места даже речи не было. Хотя бы в основные.
Упустили. Много чего упустили. В итоге скандал, ругань, отзывы из сторов и возвраты денег. Я и веду к тому что еще весной стоило подумать и потратиться. Дешевле бы вышло в итоге.
Если брать пседвобесплатные кореские гриндилки, то да. Там всем просто пофиг. Какой-нибудь платный вов выходит во вполне приличном состоянии. Он несравненно лучше Киберпанка протестирован и проверен.
Тестировщик берет завышенную, но вполне реальную конфигурацию, допустим со 128 гигами оперативки, и смотрит пределы на которых она работает. На этих пределах прогоняются все типовые сценарии. Не прогнать сценарий сохранения-загрузки при тестировании лимитов это недоработка тестировщика.
Как я уже сказал выше — чтобы найти такую ошибку, нужно хотя бы иметь подозрение, что она может существовать. MAX_INT не засунешь во все возможные сценарии, потому что их в таком продукте становится бесконечно много
Большой инвернтарь это настолько банальный сценарий, что про все места даже речи не было. Хотя бы в основные.
проверка основных сценариев — вполне может упустить её
Упустили. Много чего упустили. В итоге скандал, ругань, отзывы из сторов и возвраты денег. Я и веду к тому что еще весной стоило подумать и потратиться. Дешевле бы вышло в итоге.
Вот кстати вы никогда не задумывались о MMORPG? У них есть тестировщики, более того — у них всегда есть возможность провести бета-тест (в отличие от синглплеерных игр, которым критически важно сохранять интиргу сюжета) на десятках тысяч людей.
Если брать пседвобесплатные кореские гриндилки, то да. Там всем просто пофиг. Какой-нибудь платный вов выходит во вполне приличном состоянии. Он несравненно лучше Киберпанка протестирован и проверен.
Там 8 мегабайт лимит был. Какие терабайты?
Ну как бы памяти чтобы сохранить состояние и чтобы работать с ним — очень часто заметно совершенно разное количаство. Вас ведь не удивляет, когда веб-страница размерном 5-10мб занимает в памяти 100-200-300 мб?
Работоспособность с большим количеством предметов никто не проверял вообще.
Вы участвовали в разработке/тестировании? Вопрос в том какое именно количество считается большим в самом проекте.
Тестировщик берет завышенную, но вполне реальную конфигурацию, допустим со 128 гигами оперативки, и смотрит пределы на которых она работает.
Кто же ему столько даст? в 99,(9)% случаев ему скажут — типовая конфигурация у пользователя включает 8-16ГБ памяти, тестируйте на таком.
Не прогнать сценарий сохранения-загрузки при тестировании лимитов это недоработка тестировщика.
Чтобы тестировать лимит — нужно для начала знать о его наличии, как я еще в первом сообщении говорил. Проводить нагрузочное тестирование на исследование лимитов без санкции менеджента — тупо никто не выделит времени.
Большой инвернтарь это настолько банальный сценарий, что про все места даже речи не было. Хотя бы в основные.
Ну вот протестировали большой инвентарь с одним максимальным набором предметов, со вторым, с третьим — все нормально. Сколько вариантов наборов предметов нужно тестировать, чтобы убедиться, что всегда будет с ним работать нормально?
Упустили. Много чего упустили. В итоге скандал, ругань, отзывы из сторов и возвраты денег. Я и веду к тому что еще весной стоило подумать и потратиться. Дешевле бы вышло в итоге.
Отзывы и ругань в первую очередь не потому что баги — все же большинство людей понимает, что без багов можно написать только Hello World, да и то не всегда, а потому что они врали о качестве и пользователям и издателям, хотя сами был о многих недоделках прекрасно осведомлены.
Если брать пседвобесплатные кореские гриндилки, то да. Там всем просто пофиг. Какой-нибудь платный вов выходит во вполне приличном состоянии. Он несравненно лучше Киберпанка протестирован и проверен.
Эм… Я вообще-то когда приводил пример ММОРПГ — именно ВоВ и подразумевал. Банально стартовые цепочки кветстов в первый день после аддона могу легко забаговать и ты не можешь никуда продвинуться по ним, потому что последующие не берутся после завершения предыдущей и ты не можешь какое-то время продолжить играть(точнее можешь, но в старом контенте только). Забагованные квесты? Достаточно. Забагованные спеллы? Всенепременно. Забагованные места, в которых ты можешь случайно провалиться и потом не сможешь войти в игру пока тебе через 3 дня не поможет саппорт? Тоже имеем. Что-то из этого фиксится — то что затрагивает огромное количество людей. А всякая побочка или редко встречающиеся кейсы — так и остаются из аддона в аддон глючить.
Ну как бы памяти чтобы сохранить состояние и чтобы работать с ним — очень часто заметно совершенно разное количаство. Вас ведь не удивляет, когда веб-страница размерном 5-10мб занимает в памяти 100-200-300 мб?
8 мегабайт. Даже с коэфициентом 1000 это всего 8 гигабайт. Пользователи легко справились. Это не что-то там заоблачное. Никаких терабайт оперативки не надо.
Вы участвовали в разработке/тестировании? Вопрос в том какое именно количество считается большим в самом проекте.
Какое бы не считалось оно оказалось неправильным. И да это работа тестировщика. Неправильные умолчания на которые пользователь может влиять проверять надо. Чтобы это понять не надо участвовать в проекте.
Да-да вы опять скажете про дешевых индусов тестировщиков которые только по скрипту работать умеют. Я опять скажу что надо нормальных брать. И давать им волю в проверке любых корнер кейсов которые они придумают.
Ну вот протестировали большой инвентарь с одним максимальным набором предметов, со вторым, с третьим — все нормально. Сколько вариантов наборов предметов нужно тестировать, чтобы убедиться, что всегда будет с ним работать нормально?
Я не буду ничего подбирать. Я сделаю типичный фаззинг тест. С разными правильными данными на входе. И пусть поработает. Лимиты подберу так чтобы не падало на машине со 128 гигами оперативки. Если упадет у пользователя с 256 гигами можно отмазаться. И вообще это не стыдно, затронет мизерную часть пользователей.
Эм… Я вообще-то когда приводил пример ММОРПГ — именно ВоВ и подразумевал.
Мы про какие-то разные вов говорим.
Шедоуландс и Киберпанк вышли примерно одновременно. Шедоуландс и изначально нормально работал. А сейчас уже вообще хорошо. Киберпанк все еще плохо.
Разница видна.
8 мегабайт. Даже с коэфициентом 1000 это всего 8 гигабайт. Пользователи легко справились. Это не что-то там заоблачное. Никаких терабайт оперативки не надо.
Попробуйте запустить тот же Скайрим и добавить MAX_INT уникальных объектов в одну сцену или в инвертарь. Впрочем да, тут скорее всего упрется в процессор или видеокарту, чем в память.
Да-да вы опять скажете про дешевых индусов тестировщиков которые только по скрипту работать умеют. Я опять скажу что надо нормальных брать. И давать им волю в проверке любых корнер кейсов которые они придумают.
Где бы еще заказчиков найти которые согласятся любую хотелку тестировщиков оплачивать)
Я не буду ничего подбирать. Я сделаю типичный фаззинг тест. С разными правильными данными на входе. И пусть поработает. Лимиты подберу так чтобы не падало на машине со 128 гигами оперативки. Если упадет у пользователя с 256 гигами можно отмазаться. И вообще это не стыдно, затронет мизерную часть пользователей.
Ну вот прошел этот тест. Не нашел ошибки на сохранение. Что в этом случае будете делать? Кстати, пользователи с 256ГБ машинами тоже будут недовольны, если что — могли бы ведь и для таких машин проверить — они же существуют — значит нужно проверять.
Мы про какие-то разные вов говорим.
Шедоуландс и Киберпанк вышли примерно одновременно. Шедоуландс и изначально нормально работал. А сейчас уже вообще хорошо. Киберпанк все еще плохо.
Разница видна.
Тем не менее глюков на старте было достаточно, несмотря на все ресурсы близзард и бета-тест, вот о чем речь. И что некоторые дефекты с которыми я в ВоВ встречался — тянутся уже по 15 лет и никто их править не собирается.
Кстати можно вспомнить еще одну синглпеерную игру от Близзард в которую первые несколько дней после старта просто невозможно было начать играть:
Warcraft 3 Refunded
и сравните с рейтингом
Cyberpank 2077
смотря на это — мне кажется хайп вокруг багов киберпанка слегка преувеличенным.
Попробуйте запустить тот же Скайрим и добавить MAX_INT уникальных объектов в одну сцену или в инвертарь. Впрочем да, тут скорее всего упрется в процессор или видеокарту, чем в память.
Нормальный результат. Тормозим до неработоспособности. Количество явно нереальное все ок. Дальше уменьшаем до работающего на максимально реалистичном железе и проверяем что все вообще ок.
На сегодня что-то вроде 3090 + 128 гигов оперативки + не помню что там из топовых процов.
Кто еще больше железа поставил и нашел проблему это 0.01% юзеров можно извиниться сказать что массово пользователей не затрагивает и спокойно фиксить. Обходной путь можно предложить сразу, он разумный.
Где бы еще заказчиков найти которые согласятся любую хотелку тестировщиков оплачивать)
В продуктовой разработке это нормально. Полезные для проекта вещи можешь делать. Даже если ты сам их придумал. Оплатят. И еще спасибо скажут (и даже премию дадут), особенно если найдется чего интересного. Проактивность называется.
Если не найдется тоже ок. На выходе получим кучку тестовых сценариев с корнер кейсами и гарантию что все в них работает. Премию может и не дадут, но оплатят точно.
Ну вот прошел этот тест. Не нашел ошибки на сохранение. Что в этом случае будете делать? Кстати, пользователи с 256ГБ машинами тоже будут недовольны, если что — могли бы ведь и для таких машин проверить — они же существуют — значит нужно проверять.
Их слишком мало. Можно некоторое время игнорировать. Волны хейта не будет.
Тем не менее глюков на старте было достаточно, несмотря на все ресурсы близзард и бета-тест, вот о чем речь. И что некоторые дефекты с которыми я в ВоВ встречался — тянутся уже по 15 лет и никто их править не собирается.
На мой вкус у близов багов заметно меньше и исправили их заметно быстрее. Волна хейта и отзывов Киберпанка это подверждает.
Те баги которым 15 лет запихнуты в самый далекий беклог и не будут исправлены никогда. Затрагивает слишком мало пользователей. Разве что какому-то разрабу скучно станет и он вечерком поправит. По личной инициативе.
НЛО прилетело и опубликовало эту надпись здесь
А треск в звуке до сих пор не пофиксили.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Патч 1.06 для Cyberpunk 2077 убирает ограничение на размер файла сохранения в 8 МБ