Comments 13
Кажется как что-то ненужное и излишество, но по сути это можно внедрять в проекты, у которых большой бюджет, время и желание сделать все идеально чтобы после не разбираться и платить за тех. долг... Или нет?
Вопрос сразу в духе поста и QA - что такое "читы"?
Читы, это некий функционал, который позволяет ускорить тестирование нового контента. Например чит код на выдачу оружия.
А понятно, это намеренно или нет оставленные пасхалки.
Не обязательно. во всех проектах, над которыми я работал, существовала административная панель, содержащая в себе горячие клавиши, которые позволяли перейти на новую миссию и не проходить всю сюжетную линию. Это я и назвал "читами"
В продуктовую версию, доступную игрокам, этот функционал конечно не попадает.
Как-то сумбурно получилось, вы точно не ChatGPT? :)
О какого рода документации вообще речь? В начале вы говорите о требованиях, то есть о проектной документации. Затем вы упоминаете актуальность и доступность документации для пользователей, то есть теперь говорите о пользовательской документации. Затем речь опять заходит про требования, то есть опять про проектную.
У этих видов документации разные цели и задачи, разная аудитория, по идее ее пишут разные люди и на разных этапах жизненного цикла продукта. Наверное и подходы к тестированию совершенно разные должны быть.
Каким образом читы относятся к разработке доки тоже тема не раскрыта.
вы точно не ChatGPT?
Вроде с утра не был :)
О какого рода документации вообще речь?
Прежде всего речь идет о GDD (Game design document), внутри которых содержатся и требования , и доступность информации для пользователей и что либо еще.
Вы очень классно заметили, что я создал некую собирательную статью с перечнем свойств, которые документ может содержать, а может и нет. Например: "Обучение пользователей" - Если новый функционал не подразумевает обучение пользователей, то QA и не тестирует это свойство у документа, а если обучение нужно, то QA должен убедиться, что в GDD будет описано, как оно будет проходить и тд.
У этих видов документации разные цели и задачи, разная аудитория, по идее ее пишут разные люди и на разных этапах жизненного цикла продукта. Наверное и подходы к тестированию совершенно разные должны быть.
Вы абсолютно правы
Каким образом читы относятся к разработке доки тоже тема не раскрыта.
Попробую раскрыть более детально. Читы, это некие надстройки, которые дополнительно должен учитывать разработчик при создании нового функционала, следовательно на этапе декомпозиции и планирования (следующем то есть) он должен знать весь объем разработки. По этому еще при вычитке GDD стоит фиксировать и читы, так как потом этот объем работ будет сложнее учитывать (и дороже)
Спасибо за развернутый ответ. Я с геймдев-документацией не сталкивался еще, поэтому может быть какой-то специфики не понимаю. Хотя это очень интересно должно быть.
Ваша статья могла бы быть более увлекательной, если бы вы о таких неочевидных и специфичных вещах в ней последовательно написали. Без связующих пояснений цели, задач и процесса разработки документации, статья выглядит как набор случайно взятых фактов и советов. Отсюда впечатление, что статью писал ИИ.
Объясните это предложение, плиз:
Все документы должны находится в полном порядке, по разделах.
В идеале, выстроить хранение документации иерархическим образом, чтобы было прозрачно, где хранится какой документ. Для этого хорошо поможет Confluence например, он как раз обладает необходимым инструментарием. Следовательно QA желательно следить за тем, чтобы каждый документ лежал в соответствующем месте, согласно иерархии хранения
Рассказ о том, как QA решили документацию тестировать