Работал в куа отделе в ИТ, перекатываюсь в гейдевы, однако не знаком с этим направлением.
Интересует специфика баг-репорта в геймдеве. Ссылки приветствуются.
>тут похуисты-наколеночники-бракоделы обитают ващет
Всё так. В основном тут человеки-оркестры, мастера на все руки.
>>843327 (OP)
>специфика баг-репорта в геймдеве
В большой студии галерного класса - что скажут, то и делай.
В маленькой команде друзей-индюков - на что договоритесь.
Помогаешь человеку-оркестру - лучше всего записывай видео.
Но на зряплату тестировщика можешь надеяться только в большой студии.
Вообще, геймдев - не место для хорошего заработка.
Перекат из ИТ в геймдев - как из города в деревню...
>Вообще, геймдев - не место для хорошего заработка.
>Перекат из ИТ в геймдев - как из города в деревню...
Можно поподробнее, уже слышал о таком, но сам видел все в иной перспективе.
Вот допустим есть баг репорт, обычный. Он состоит из:
Название/короткое описание
СТР
Ожидаемый
Фактический результаты
Тестер
Назначено
Билд
Проект
Часть проекта
Спек
Севирити
Прайорити
Приложение
Но это в ИТ проекте. А если тестируешь игру... Там же навернека есть какие то свои различия. Ведь есть много всего что в ИТ не встречается совсем, провал в текстуру, проблемы с движком (которого если ты сайт тестируешь нет впринцыпе а для геймдева обязателен) и много такой специфики... Вот это и интересует, я полагаю там составные части отличаются.
А так, все эти пункты применимы, это же просто бюрократическая часть. Ож/Факт. есть, тестер, назначено есть, проект, билд есть (ты же конкретную версию тестишь), северити, прайорити есть, куда они денутся.
Из специфики
1. Кроме по пунктового тестирования, есть полные прогоны игры, что она проходится от начала до конца. Тут могут быть градации, от "не обращаем внимания на мелкие недочеты и проходим дальше" до "увидев первый баг, закрываем игру, репортим и переходим к другим задачам".
По хорошему еще должны быть всякие тесты установки. Ну там, что игра с нуля на чистую систему ставится, и после удаления ставится, сейвы не херятся, или подгружаются из облака.
2. Тестирование как "соответствие спецификации" - слишком условная вещь при отсутствии полного дизайн документа. Придется полагаться на здравый смысл и игровой опыт. Например ты подходишь к двери, не сказано как она должна открываться, ключом, рычагом. Если в проекте одна дверь открывается если что-то сделать, а вторая если просто к ней подойти, то тут стоит репортить, чтобы узнать какая из них неправильная. В вебе конечно так тоже бывает, у тебя кнопка и ты просто интуитивно думаешь что кнопка работает как кнопка на другом сайте.
3. Многие баги будут плавающими. Десять раз пройдешь уровень, нормально. Один раз чуть криво посмотришь, все зафейлится. Классический пример: "После многочисленных экспериментов выяснилось, что баг проявляется, только если спрыгнуть под определённым углом, да и ещё при этом двигать мышкой." https://habr.com/ru/post/266385/
В принципе регрессии тестировать - по отзывам боль, т.е. кодер думает, просто предполагает, что он пофиксил баг, тестеру надо тестировать этот уровень, для чистоты эксперимента может понадобиться играть с начала без читов, так баг может несколько дней футболиться. Ожидание: уии, целыми днями играть в игрушки. Реальность: неделю дрочить один спидран два раза в день. Или проходить на разных языках одно и то же, в поисках буковки не влезшей в диалог.
4. К блокерам относятся не только краши игры, но и софт локи, когда игру невозможно пройти, если там логика неправильная, нельзя взять ключ нужный дальше, а также визуал если не видно какие-то ключевые части уровня или надписи. Ну то есть все привыкли что на сайтах текст может вылезать или обрезат... но если игрок не узнает текст задания - то упс.
5. Отдельно есть то что у нас называлось сертификация. В общем формальное соответствие правилам сторов, консолей. Сколько времени показывать логотипы, не забыть значки возрастных ограничений, убедиться что кого-то ниггером не назвали. Что кнопки выбор/назад не через жопу назначены, вот это все.
Если еще что вспомню допишу.
>проблемы с движком
>которого если ты сайт тестируешь нет впринцыпе
В вебе "движком" можно считать Wordpress, Drupal и т.п. Да и с серверной стороны движком можно назвать Apache и Node.js. Сейчас мало кто будет писать веб-сайт и веб-сервер с нуля.
>а для геймдева обязателен
Необязателен. Большая студия может делать игру на собственном движке "с нуля". Вообще, "движок" - это условность, просто некий слой абстракции. У игры не всегда есть библиотека или "плеер", которая пишет в консоль "здрасте, я такой-то движок, запускаю такую-то игру".
>>843576
>Реальность: неделю дрочить один спидран два раза в день.
Да уж, после такого играть в игры дома уже не захочется.
>если игрок не узнает текст задания - то упс
Да постоянно встречаю в играх косяки с текстом, что в старых, что в новых. Обычно можно либо догадаться о содержимом текста, либо узнать где-нибудь в гайдах в интернете. Такая проблема, можно сказать, вовсе не проблема, по сравнению с крашами и порчей сейвов. Тем более что ждать помощи от разработчика бесполезно - патчами проблемы с текстом редко исправляют...
Порчи сейвов, наверное, вообще протестировать невозможно на данном этапе программирования, это надо очень какую-то строгую систему типов, инвариантов, состояний с математическими и алгоритмическими гарантиями...
Тексты конечно просачиваются, но у нас бы точно завернули и на внутреннем qa, и на издательском. А, тут еще стоит упомянуть, что надо тестировать на разных разрешениях. Вообще какую-то матрицу устройств составлять, в разных комбинациях видях, дров, операционок. Но это уже не для джунов вкатунов задача.
>У меня валялись тестерские доки с работки, тестпланы, чеклисты. попозже сделаю выжимку.
Спасибо, жду)
О том что нужно будет тестить долго и скучно знаю, интересует именно различия документации.
Вспомнил что начал разгребать эти доки, но забросил, то что успел выложил тут >>863905 →