Введение Я солгал! На этой неделе мы говорим не об аудио, а об обеспечении качества, иначе известном просто как QA!
Извините за пыль, поскольку мы разбираем и настраиваем этот новый дневник разработки немного раньше, чем планировалось.
В конечном итоге у нас будет Аудио-дневник разработчика (с надеждой смотрит на сообщество), но сейчас вы все снова заперты здесь со мной на тему, которую я слишком хорошо знаю: каково это - QA Victoria 3.
Хотя, честно говоря, это отличное введение в то, что такое Q A Victoria 3, или каково это - быть QA в целом.
Поскольку мы находимся в конце конвейера, мы должны быть наиболее адаптируемыми членами команды. Неработающие сборки, задержки, переделки и ошибки слияния - это повседневное явление в нашей профессии.
Даже когда все идет идеально, контроль качества по-прежнему является гонкой со временем или, более конкретно, гонкой тайм-бокса: что наиболее важно протестировать сейчас, а что можно отложить на потом, когда будет время или оно будет более полным - подозреваем ли мы, что грядет очередная переделка рынка, или мы на наконец-то окончательная реализация?
Регулярное сообщение о контроле качества, обычно между нами. Не все можно проверить, это печальный факт.
Игры Paradox уникальны по своей сложности взаимосвязанных механик и систем, что проверить полную функциональность игры и всех ее итераций при каждом изменении невозможно.
Бесконечное количество QA с бесконечным бюджетом и временем все равно не обеспечит продукт почти идеального качества. Это почему?
Хорошо, потому что в этом сценарии узким местом качества был бы не отдел контроля качества, а разработчики по другую сторону исправлений ошибок - тогда ограничивающим фактором была бы их пропускная способность.
Задача QA состоит в том, чтобы тестировать и отрабатывать надлежащим образом, распределяя время для технической обратной связи и баланса игрового процесса на основе графика разработки игры.
И прежде чем мы зайдем слишком далеко, комментарий, который я ожидаю получить больше всего к этому дневнику: “Почему бы вам не использовать [вставить конкретный процесс разработки / тестирования], это решит все ваши проблемы!
” Я хотел бы, чтобы это было правдой, но нет серебряной пули для развития.
Каждая модель разработки и тестирования снижает риск по-своему, но по своей сути определенный риск все же существует, особенно потому, что мы говорим о возможности человеческой ошибки: отсутствующих соединениях или построении поверх системы, которая изначально не была написана с такой точки зрения несколько итераций назад.
Самая закрытая модель разработки, которая не допускает никаких “багов”, также не допускает никакого творчества со стороны разработчиков.
Видеоигры могут быть продуктом для продажи, но они также по своей сути являются искусством, что делает контроль качества и решение их проблем в лучшем случае гораздо более субъективным опытом.
Хитрость заключается в том, чтобы найти систему, которая создает как можно больше гарантий, не полностью ограничивая творческий потенциал команды.
Я отвлекся и остановлюсь на этом, прежде чем перейду к более длинной и широкой боковой ноте. На протяжении всего этого дневника я буду более подробно рассказывать о том, что я имею в виду.
Люди, Процесс, Сроки и продвижение вперед Поскольку мы перешли к более публичной стороне процесса разработки, моя роль в QA изменилась, в то время как мем обо мне как о Руководителе QA остался прежним.
Я получил много вопросов о том, “что именно делает руководитель отдела контроля качества и чем отличалась моя роль менеджера / директора”, поэтому я подумал, что мне потребуется некоторое время, чтобы разъяснить это всем вам, по крайней мере, в общих чертах.
Структура команды по контролю качества: Директор по контролю качества: Представляет интересы команды по контролю качества на уровне руководства студии, гарантируя, что все планы выпуска и разработки учитывают пропускную способность и требования их команды.
Менеджер по контролю качества: Профессионально управляет командой контроля качества, менее вовлеченный в повседневную работу и более вовлеченный в рост и развитие Команды контроля качества как отдельных лиц и надзор за персоналом.
Руководитель отдела контроля качества: Представляет интересы команды контроля качества на уровне руководства проектом, управляет повседневной расстановкой приоритетов и координацией тестировщиков.
QA-тестер (встроенный): Сотрудник студии разработки Paradox, который отвечает за тестирование разработки, проверку исправлений и предоставление обратной связи.
Тестировщик качества (на аутсорсинге): Сотрудник наших Партнеров по аутсорсингу (таких как QLOC), который работает с внутренней командой и помогает в тестировании разработки, проверке исправлений и предоставлении обратной связи.
Сообщество / бета-тестировщик: Участник сообщества Paradox, который в соответствии с NDA получает доступ к незавершенной сборке, чтобы оставлять отзывы и частичные отчеты об ошибках, которые QA позже сопоставит и проверит.
В целом QA - интересная группа людей.
Нужен очень целеустремленный человек, чтобы взглянуть на незаконченный проект и с радостью приступить к работе, не только задокументировать недостатки, но и заглянуть за кулисы, увидеть замысел готового продукта и дать отзыв об этом.
QA, как личность, может посмотреть разработчику в глаза, сказать им, что им нравится функция, а затем отправить им более 20 сообщений о всех проблемах, связанных с ней, без когнитивного диссонанса.
Иногда мы оставляем несколько комментариев о том, как, по нашему мнению, было бы здорово связать это и с другими функциями.
Проверка того, действительно ли проблемы исправлены, всегда является приключением - вы никогда не знаете, какие новые проблемы вы обнаружите. Наша необходимость быть критичными и учитывать точку зрения игрока также приводит к тому, что мы очень прямолинейны, когда нас спрашивают о нашем мнении.
В нашей профессии проблемы с сахарной глазурью приводят только к проблемам в дальнейшем. Трюк, которым я поделюсь на форумах, заключается в следующем - можно быть прямолинейным и не быть придурком.
Запугивание разработчика в качестве QA может решить проблему, но это происходит за счет рабочих отношений.
В моей карьере было много типов QA, и если я осмелюсь поразмыслить об этом - именно QA, который является грубым, но уважительным, добивается большего влияния на игру, чем тот, кто кричит громче всех.
Поскольку разработчики тоже люди, у них есть чувства, и они могут эмоционально реагировать, особенно если вы действуете эмоционально (особенно сердито) по отношению к ним.
Я прошу вас, пожалуйста, помнить об этом, когда мы перейдем к пост-запуску и оперативной поддержке, но я подробнее расскажу об этом позже в этом дневнике разработчика.
Однажды нам сказали, что мы должны подходить к вещам с более позитивной точки зрения. Эта просьба не задержалась надолго.
Я пошутил на стриме, что “Я видел, как команда контроля качества смеялась во время многопользовательского тестирования, и это либо признак того, что все работает, либо все сломано”.
Наша профессия сопряжена со странным чувством юмора, или, может быть, это просто тип людей, которым нравится наша работа - спустя 8 лет я все еще не уверен.
Процесс Я собираюсь подробнее рассказать об общем процессе контроля качества и постараюсь не вдаваться здесь в подробности, иначе это кроличья нора, из которой мне никогда не выбраться.
Что я скажу, так это то, что я говорю о процессах высокого уровня отдела контроля качества в целом по отношению к проекту, о взаимодействии отдела контроля качества друг с другом: Код, Дизайн, Повествовательный контент, VFX, Аудио, UI / UX, Environment Art, Tech Art, 2D Art и различные подкатегории, которые я забыл - у каждой из них есть отдельный процесс, работающий немного по-другому.
Это связано с тем, что все они разрабатываются по-разному и внедряются в разное время игры, и поэтому стандарт контроля качества для одной команды отличается от другой в зависимости от состояния разработки.
QA имеет два типа общего тестирования процесса: Этапное и функциональное.
Этапное тестирование - это то, что понимают большинство людей за пределами отрасли, поскольку оно переводится на слова, которые мы используем - Доказательство концепции, Альфа, Бета-версия, Кандидат на выпуск и т.д.
Все это основные этапы, которые мы используем в процессе разработки.
Намерение состоит в том, чтобы между ними существовала существенная разница в статусе его функций и, что еще более важно, в циклах геймплея и вовлеченности.
Milestone охватывает игру в целом и обычно используется в таких заявлениях, как “это то, что вы ожидаете от альфа-версии” и т.д. Даже во время тестирования функций для контрольных точек.
QA, как и остальная команда, находит способ добавить немного юмора в документацию.
Тестирование функций немного отличается, здесь, в Paradox, мы обычно называем это “тестированием поддержки разработки”, где QA проводит более частичное тестирование отдельных реализаций различных частей игры.
Именно здесь мы следим за тем, чтобы все было объединено правильно, чтобы кодеры случайно не перезаписывали друг друга, и мы больше заботимся о том, чтобы все работало с технической точки зрения, чем с точки зрения всего игрового процесса.
Когда игра находится на ранних стадиях разработки до стадии альфа-тестирования, тестирование функций заменяет этапное тестирование.
Это не значит, что мы не проводим альфа-тесты, но большая часть нашего тестирования связана с техническими аспектами игры, а не с “игрой в целях баланса”.
Причина этого заключается в том, что, хотя игра все еще активно разрабатывается и еще не достигла того рубежа, когда функции с меньшей вероятностью изменятся, тестирование баланса является неэффективным усилием.
У отдела контроля качества ограниченное количество времени и бесконечная череда задач, которые нужно решать, поэтому мы должны быть настолько умными, насколько это возможно.
На раннем этапе команда контроля качества должна признать тот факт, что игра менее отшлифована. Мы находим уникальные способы справиться с этим фактом.
На случай, если вам интересно, вот как выглядит эта улыбка сегодня.
По мере того, как мы продвигаемся дальше по нашим этапам, к бета-версии и кандидатам на выпуск, верно обратное: этапное тестирование заменяет тестирование функций в качестве основного средства сбора данных.
В бета-версии QA все еще может углубляться в функции и тестировать их с технической точки зрения в зависимости от количества изменений, внесенных разработчиком, но чаще всего они будут сосредоточены на том, как эти функции взаимодействуют друг с другом и способствуют ли они значимому и увлекательному игровому процессу.
Наши трудности в этом? Нам нужно выяснить, как ответить на этот вопрос с некоторой определенностью как можно быстрее.
По мере развития игры улучшаются и стандартные процессы контроля качества в отношении того, что стоит прослушивать, а что является приемлемой проблемой, к вашему сведению.
Технические проблемы имеют приоритет на ранних стадиях разработки milestone, в то время как в релиз-кандидате вырезки из бумаги с плохим пользовательским интерфейсом или неверной информацией, предоставляемой игроку, рассматриваются как та же серьезность, что и полностью нарушенная функциональность.
Потому что не имеет значения, работает ли это технически, если игрок не может этого понять. График продвижения вперед (и прощания) Роль QA меняется по мере продвижения проекта.
В начале проекта мы были очень технически настроены и работали над тем, чтобы структура игры была на месте.
По мере продвижения разработки мы все больше фокусируемся на функциях и их ощущениях, а также на всеобъемлющем охвате игры.
По мере продвижения по этапам QA становится представительными экспертами в своей игре.
Дизайнеры могут рассказать вам, как это должно работать, отдел контроля качества расскажет вам, как это работает в настоящее время, и благодаря этим знаниям мы регулярно работаем с сообществом, бета-тестерами и влиятельными лицами, обучая их тому, как все работает на ранних стадиях, и получая их отзывы.
Сообщество - это в значительной степени наши товарищи по оружию в этом начинании, все, о чем сообщается команде Сообщества на наших форумах или в discord, доводится до сведения QA, чтобы убедиться, что мы получили это Jira'd и остальная команда в курсе.
Скоро нас ждет релиз, захватывающее время для всех нас.
Вы все, наконец, овладеете игрой, и команда разработчиков будет сидеть здесь, с нетерпением ожидая услышать ваши отзывы и увидеть, на какие проделки вы все способны.
Сама команда контроля качества будет сидеть здесь и гадать, какие изменения, внесенные нами в последнюю минуту, что сломали и как это проскользнуло сквозь трещины нашего тестирования.
При выпуске и в дальнейшем у нас будет форум об ошибках, где вы сможете сообщить нам о любых обнаруженных вами проблемах, о которых, по вашему мнению, мы не знаем.
И даже если мы знаем об этом, вы можете помочь определить приоритет исправления, но дополнительная информация по этому поводу поступит от руководителя группы контроля качества в связи с выпуском, так что будьте начеку.
И что ж, это краткое изложение процессов контроля качества высокого уровня, вместо того, чтобы говорить о деталях тестирования функций X или о том, сколько jira мы написали, я надеюсь, вам понравится пик за кулисами нашего чувства юмора, разбросанного по всему дневнику разработчиков.
Я предполагаю, что этот дневник разработчика также знаменует собой окончание моих обязанностей в качестве QA в команде.
Теперь я перехожу к другой стороне запросов на слияние… готов взять на себя другого рода ответственность. Будьте добры к моей команде контроля качества в ближайшие недели.
Вы даже не представляете, сколько усилий они вложили в эту игру на протяжении ее разработки - особенно в прошлом году. Я, конечно, люблю, и я очень горжусь ими.
Проект находится в надежных руках. Надеюсь, на следующей неделе у нас будет наш Дневник разработки аудио с Франко, жаль, что на этот раз у меня нет классного сегвея.
0 Комментарии:
оставьте ответ