Как построить QA для моей игры?

January 22, 2019

Итак. В чате канала были вопросы насчет того, кто я, собственно, такая и пожалуй, следует коротко сказать об этом.

И снова. Я Ира Куркина, начинала в тестировании локализации "Акеллы" в 2007 году, прошла путь из всяческих издателей и операторов игр на территории России до разработчиков социальных, мобильных и ММО-игр (ряд маленьких, а также крупняки вроде Wargaming).

Затем поняв, что хочу делать только сингл, как и раньше, в СНГ его почти нет, а заграницу еще рано по навыкам, - ушла в IT на три года углублять технические компетенции. Завершив этот путь в Lamoda написанием автотестов и ручканьем мобильного сайта, я вернулась в геймдев делать JRPG Grimshade.

В этой команде я закончила, фактически, будучи руководителем отдела, так что после этого длинного пути I've seen shit и могу вам об этом немного рассказать.

На момент января 2019 я работаю над MANU Videogame maker, игровым движком для не-программистов.

Зачем вам QA

Начнем с самого важного. Зачем вам вообще обеспечение качества и тестирование. Принято считать, что оно не очень нужно. Но далеко не везде, к счастью, а все в меньшей и меньшей распространенности. Потому что результативность QA сложно измерить в деньгах, выставить KPI (найти 1000 багов в квартал?), стабильно отследить отдельно от общего качества разработки в целом.

На самом деле, достаточно оценить отток пользователей на примере аналогичного проекта после critical-бага, а потом потерянные с каждого из них покупки, их ли собственные или хотя бы одного друга, которого они сарафанным радио привели с собой. Умножить это как минимум на десятку, потому что глаз у разработчиков мылится и таких будет немало. И умножить на количество ушедших игроков.

Сравнить со стоимостью полугода обеспечения отдела и, если математика получается в пользу него, он вам нужен.

Если упростить, то отдел QA нужен почти наверняка, если вы вышли из pre-production стадии проекта.

Как надо делать

Часто очень хочется получить четкую инструкцию как вашей команде сделать лучшее тестирование прямо сейчас, здесь и за немного денег. Ожидаемо, такого рецепта у меня нет.

Но есть следующее: Общий план и Варианты.

Взяв первое и рассмотрев второе, изучив свой продукт и спросив команду, попробовав, некое количество раз не преуспев и снова рассмотрев варианты, вы получите свой пайплайн тестирования и главное - эффективного предотвращения багов. Дальше останется только его поддерживать и придумывать, как (еще все сломать) сделать его еще лучше.

Общий план

Начнем с основ. Тестирование принято делить на так называемое "внутреннее" и "внешнее".

Внутреннее тестирование - это, грубо говоря, все, что делает команда разработки без участия QA: юнит-тесты, код-ревью, статический анализ, первичное смоук тестирование или приемка (работает/не работает). Иногда сюда же входят автотесты, но это зависит от организации команды, пайплайна разработки и распределения ролей.

Дальше переходим к внешнему тестированию. Это тот же смоук в расширенном виде (автотесты либо руки), тест-аналитика, приемка от бизнеса (опционально), функциональное тестирование, перформанс/нагрузка.

Особнячком здесь стоит релиз-инжиниринг и билд менеджмент, но давайте представим, что команда классная и у нее есть под это отдельный DevOps.

Ваше тестирование превращается в обеспечение качества тогда, когда все это работает вместе и от спринта к спринту вы ищете методы, как не то чтобы сверять то, что уже получилось с тем, что хотелось. А как сделать так, чтобы багов возникало меньше, а исправления были дешевле.

Что это за слова такие странные я перечислила выше - смоук, тест-аналитика, девопс и прочий зеленый леший, останавливаться отдельно не будем - это легко гуглится. А вот как вам это использовать для своего проекта - в общих чертах расскажу.

Варианты

Рассмотрим случай, где вы приходите в команду, в которой нет QA. Скорее всего, где-то между бизнесом, геймдизайном и артом регулярно ломается коммуникация, что отражается на проекте, и повезло, если PM или линейный продюсер помогает решить это. Если нет - цементом и пластилинчиком будут ваши процессы.

Начать лучше всего с того, как описываются задачи в разработке, потому что задачи уже наверняка есть и делаются и это проще всего улучшить, почти не сходя с места. Что вам нужно, так это настроить поставку четких критериев приемки фич от бизнеса/геймдизайна и добавить к этому пункты, на которые необходимо обратить внимание QA, которые опишет разработчик или заказчик конкретной фичи или задачи. Если этого не будет, требования придется собирать в каждом случае самостоятельно, ломая об это грабли и получая на выходе не то, что хотели на входе. QA нужен, чтобы починить это.

Итого, каждая ваша задача должна выглядеть примерно так:

"Собрать уровень А

Ссылка на диздок или описание дизайна уровня

На что обратить внимание QA: вейпоинты могут ломаться там-то, коллизии едут так-то, персонаж не дружит с прямыми углами на уровне."

Далее вы смотрите, есть ли дизайнерская/бизнес документация и в каком она состоянии. Если документация производится, вам нужна будет тест-аналитика, потому что чем раньше вы будете проверять, все ли в порядке и выявлять ошибки в технических требованиях, тем дешевле обойдутся исправления. Самые дорогие - на последних этапах, когда уже есть и арт, и левелдизайн, и баланс, и код, и все это работает вместе. Куда сложнее будет заменить каждый отдельный элемент, потому что все они крепко связаны друг с другом. Посадите своего самого внимательного и въедливого QA на это дело (или сядьте сами). А если документации нет - запросите у своего продюсера или другого продукт/фича овнера четко описанные задачи и в них проделайте то же самое.

А что, собственно? Посмотрите критическим взглядом на текст документа. Поищите несостыковки. Проверьте, есть ли в нем критерии, по которым будет проводиться приемка задачи - достаточно ли полно описано то, что заказчик ожидает получить на выходе. Затем представьте типичного пользователя будущего продукта, ЦА вашей игры (с вопросом, кто это, можно сходить к маркетологу/продукт овнеру).

Как он будет использовать фичу? Будет ли ему удобно? Если он сделает ошибку, сможет ли отменить изменения? Поймет ли что происходит, нужны ли дополнительные пояснения и так далее. Эвристики юзабилити вам в помощь.

Так, в геймдизайн немного залезли. А здесь этап, когда вы смотрите на проект, а потом на команду программистов. Потом на проект и снова на команду программистов. Внимательно. И вдумчиво рассказываете, что юнит-тесты - это круто, а кодревью им нужно, чтобы не пропадать в чьем-то коде (и своем, написанном две недели назад), писать красиво и больше общаться. Если им еще не рассказали. В ином случае - вам повезло и в Королевстве программирования все уже классно работает.

Инфраструктура. И здесь вы вступаете. Для стабилизации любой минорной или мажорной версии перед релизом игры, приемкой бизнесом или плейтестом вам нужна будет тестовая инфраструктура. Ветки версий и билдов, тестовые стенды, whatever. Возможно, для этого нужно будет реорганизовать инфраструктуру разработки, а потом уже отвести ветки про свои нужды. Поговорите с руководителем разработки, обсудите, что можно сделать.

На выходе вы, например, можете получить одну ветку под разработку и много веток под тестовые билды/релизы. Или множество фича-веток, всегда свежий и более стабильный master и снова релизы. Здесь выбирать вам и команде. Лично я люблю, когда мерж в релизные и тестовые ветки полностью контролирует и делает QA - порядка больше.

И только сейчас мы переходим к функциональному тестированию. Вы поправили инфраструктуру, создали документацию, описали задачи, познакомились с продуктом и командой и теперь, на основе всего этого, вы можете выстроить процесс в таком порядке:

1. Тест-аналитика (концепты, спеки, гдд, задачи)

2. Тестовая документация (чеклисты/кейсы/майндмапы)

3. Функциональное тестирование (приемка, тестирование фич, регресс, смоук).

И только когда все это уже есть, можно перейти к автоматизации тестирования.

Здесь с универсальными рецептами еще сложнее, так как далеко не в каждом проекте автоматизация нужна и рентабельна с точки зрения отношения стоимости ее разработки к стоимости разработки самой игры. Ключевое вопрос здесь - планируете ли вы поддерживать игру после релиза, выпускать к ней DLC или сиквелы, а также портировать на другие платформы. А также, есть ли у нее в принципе фичи, которые поддаются и требуют автоматизации, например основанные на рандоме. Если на все вопросы ответ - "да", вам нужна автоматизация.

Так же хорошая практика - автоматизировать свой регрессионный набор тестов, это удобно и может уменьшить вероятность человеческих ошибок при прогоне.

В плане технических решений, судя по источникам в интернете и личному опыту - все берут за основу то, что предоставляют движки или платформа и дописывают под нужды своего продукта.

Недавно интернет взрывало видео с GDC: в нем tools programmer из Media Molecule рассказывает, какую обвязку из автоматизации и приложений они сделали для своей игры Dreams. При этом конкретно этой задачей у них в команде занимается буквально 2,5 человека (один работает на полставки), но итеративно и решений было испробовано порядочно.

В итоге получился:

1. Autobot. Бот для автоматизации, который умеет воспроизводить "реплеи" и рассылать результаты команде со всей отладочной инфой - от assert'ов до core dump'а и имени программиста, которое он берет из системы контроля версий.

2. Система записи "реплеев". Так как код от версии к версии поддерживается универсальным и портируемым (deterministic), есть возможность сохранять набор состояний (стейтов) игры, от начального до всех последующих - и использовать эти стейты для воспроизведения багов, прикрепляя их ко всем репортам. Собственно, это все, что оставляют в задаче тестировщики, не считая описания.

3. Сохранение координатов игрока и локации. Для арт-отдела, если нужно заменить ассет в каком-то месте на уровне, необходима информация, что это за уровень и где ассет находится.

4. Сама поддержка deterministic-кода. Ее же помогает осуществлять Autobot, репортя ошибки синхронизации.

5. Расширение для Google Chrome, которое умеет очень много всего - от добавления кнопок в Jira до выемки данных пользователя PSN, чтобы кнопкой можно было запустить реплей прямо на девките, общаясь с ним через сервер игры.

6. Кнопка Report a bug с автозаполнением универсальных данных - реплей, ревизия репозитория и так далее. Открывает окно создания задачи в Jira.

7. Программа для отслеживания производительности игры. Состоит из телеметрии и синхронной записи видео. При необходимости можно тыкнуть в точку на итоговом графике перформанса и увидеть на видео, что происходило в этот момент.

Комплексность и сложность, на первый взгляд, просто восхищает и не верится, что так много могла сделать такая маленькая команда.

Ну, а если вы еще не устали и ручки чешутся добавить что-то еще (читайте: решить проблемы дизайнеров с прототипированием и тестированием своих решений) - вам будет полезно настроить CI/CD. Здесь ничего нового - все старый-добрый Jenkins, Bamboo, Teamcity или любое удобное решение для вас.

Есть ряд багов, которые проявляются только в билдах, но не в движке. Поэтому автоматизированная сборка нужна, особенно на этапах, близких к релизам.

И последнее, о чем хочу сказать: телеметрия (или аналитика). Если вы дочитали досюда, скорее всего, это раздел для вас. Задайтесь теми же вопросами насчет вашей игры, что описаны в разделе про автоматизацию. Если решили, что аналитика вам необходима, есть единственное важное правило: начинайте реализацию как можно раньше, скажем, сразу по выходу из pre-production. Иначе нужны будут костыли, в лучшем случае. В худшем - часть проекта или весь проект придется переписывать.

Что отслеживать? Любые показатели, которые считаете важными для вашей игры или ее сиквелов в будущем. Можно вычислить распространенность багов, воронки отвала пользователей, частоту использования фич, популярность веток прохождения и так далее. Поговорите со всеми стейкхолдерами, которые могут быть заинтересованы.

Задача для реализации довольно нудная, но несложная. Самое трудное - это как раз составить требования и разобраться, где и как хранить данные, а также как их группировать для простоты восприятия. Если вы все составили правильно, отложенный эффект будет стоить всех вложений.

That's all, folks!

Спасибо за внимание и классных вам игр.