Кто отвечает за качество игр: разработчик или тестировщик
Всем привет! Меня зовут Александр Дончук, я руководитель отдела обеспечения качества студии 4A Games, известной по играм «Метро 2033», «Метро: Луч надежды», «Метро: Исход», ARKTIKA.1. Уже
Сегодня я хотел бы обсудить свой опыт в вопросах обеспечения качества игр и того, чья же это на самом деле зона ответственности и как его (качество) сознательно повысить. Статья будет полезна в первую очередь тем, кто занимается тестированием и обеспечением качества, руководителям проектов, менеджерам, продукт-оунерам. Впрочем, разработчики и просто пытливые умы тоже, вероятно, смогут почерпнуть для себя что-то интересное о разработке игр и процессах, которые помогают повысить их качество.
Почему я выбрал конкретно эту тему? Общаясь с людьми, я часто сталкивался с ошибочным мнением о том, что за качество игры отвечают тестировщики, а если кого-то оно не устраивает, значит, виноват в этом отдел контроля и обеспечения качества. Людям, не разрабатывающим игры (или другие приложения), такое мнение вполне простительно. Но когда я услышал подобные речи из уст опытных разработчиков, то во мне стал пробуждаться праведный гнев. И я недоумевал тем сильнее, чем опытнее был мой так глубоко заблуждающийся собеседник. Итогом моих размышлений стала идея: раз люди не осознают, как создается качество, моя задача — просветить их в этом по мере возможностей.
В статье я постараюсь кратко объяснить суть работы QA и дать определение качеству, расскажу о том, кто же в действительности его создает и как лучше взаимодействовать тестировщикам и разработчикам, чтобы это самое качество неустанно повышать.
Что такое качество
Прежде чем переходить к конкретике, хочется немного потеоретизировать, обозначить понятия, чтобы исключить недопонимание со стороны уважаемых читателей.
Итак, что же такое качество? Хорошо известная всем (я думаю) Международная организация по стандартизации (ISO) имеет целый специальный комитет, определяющий понятие и критерии качества программного обеспечения.
Международный стандарт ISO 8402:1994 гласит: качество программного обеспечения — это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности. Другими словами, это показатель того, насколько хорошо ваше ПО (в нашем случае игра) отвечает явным и неявным требованиям, предъявленным к нему.
Иллюстрации Каталины Маевской
Пойдем дальше. Международный совет по тестированию программного обеспечения (ISTQB), занимающийся экзаменацией и сертификацией тестировщиков, имеет свой глоссарий, в котором также определяется понятие качества. Согласно ему, качество — это степень, в которой ваше ПО обладает требуемой всеми участниками комбинацией свойств.
Одно из важнейших словосочетаний здесь — «всеми участниками». Естественно, конечная цель разработки — предоставить игроку продукт без ошибок. Но чтобы этого достичь, ваша игра должна соответствовать ожиданиям всех участников процесса: разработчиков, тестировщиков, менеджеров, издателей, маркетологов...
Отдельное внимание хочется уделить критериям качества по той же ISO, особенно одному из них. Итак, согласно ISO, существуют такие 6 критериев качества: функциональность, надежность, практичность, эффективность, мобильность, сопровождаемость.
Как вы уже могли догадаться, я хочу остановиться именно на последнем критерии из списка — на сопровождаемости. Если все остальные критерии в той или иной степени отражают ожидания конечного пользователя от игры, то сопровождаемость важна в первую очередь самим разработчикам.
Не изобретаем велосипед, идем к тем же стандартам ISO. ISO 9126 гласит, что сопровождаемость — это 4 основных фактора: удобство для анализа, изменяемость, стабильность, тестопригодность.
И тестопригодность — именно то, чем часто пренебрегают при планировании и разработке фич. Хотя это важнейший фактор, от которого напрямую зависит, насколько хорошо эта фича в итоге будет работать.
Что такое тестопригодность
Это приспособленность игры (или ее части) к обнаружению дефектов и их локализации. Всем известный шуточный закон Мерфи в тестировании работает на сто процентов: если что-то не протестировано, значит, оно сломано. Определение тестопригодности фичи на ранних этапах ее разработки — важнейшая задача QA, выполнение которой способно оградить вас от очень дорогих ошибок.
Смоделируем ситуацию: гейм-дизайнер придумал фичу, а вы в силу каких-то ее особенностей не понимаете, как нормально проверить ее. Например, вы придумываете систему нанесения урона противникам с большим количеством параметров: множество типов патронов, разные типы урона и брони. Дизайнер создает сложную систему, количество вариантов в которой сугубо комбинаторно будет очень большим. Такое проверить уже сложно. Следом добавляется еще какой-то влияющий на урон параметр: перк игрока, зависимость от окружающей среды (например, урон меняется в зависимости от того, где сейчас находится противник). Каждый новый параметр добавляет еще одну степень к количеству возможных вариантов. В такой момент важно спросить у этого разработчика: «А как, по-твоему, мы будем это проверять?» И если он не может дать вразумительного ответа, такую фичу делать нельзя. Она не будет работать сама и будет негативно влиять на качество работы других фич, которые могут с ней пересекаться.
Кто же в действительности отвечает за качество игры
Лично мое мнение (и я надеюсь, что все читатели этой статьи в итоге согласятся с ним): достичь желаемого качества игры возможно только благодаря слаженной работе всей команды. Не только тестировщики, не только разработчики, не только менеджмент — все должны эффективно взаимодействовать ради желаемого результата. Чтобы получить качественную игру по завершении работы над ней, нужно поддерживать ее качество и в процессе ее создания. Одно без другого невозможно.
Звучит достаточно банально: «Чтобы получить качественную игру, просто делайте ее хорошо». К сожалению, в современных движках еще не придумали кнопку «Сделать хорошо» (упущение, конечно, на мой взгляд). Поэтому я хотел бы поделиться набором конкретных советов. Они будут работать вне зависимости от жанра вашей игры, бюджетов, размеров команды и прочих факторов, которые, как многие по неопытности полагают, должны критично влиять на качество игры.
Что делать разработчикам, чтобы повысить качество игры
Первый блок советов касается процессов разработки и самих разработчиков.
1. Каждый разработчик хорошо (скорее всего, лучше всех) знает конкретную часть игры, которой непосредственно занимается. И зачастую он может довольно точно предсказать появление дефекта. Изменив параметры нанесения урона, разработчик может подсказать тестировщикам проверить пробиваемость материалов. Изменив настройки физической капсулы игрока, вполне возможно спрогнозировать застревания в местах, где раньше можно было пролезть. Или, наоборот, можно предсказать, что игрок пройдет туда, куда до этого проходить не должен был.
Это абсолютно здоровая и полезная практика, когда разработчик указывает тестировщику, где, что и как стоит проверить, предполагая, что там может возникнуть ошибка. Или же он может просто рассказать, как лучше протестировать тот или иной функционал. Игры — крайне сложные системы с огромным количеством взаимодействий и возможных пользовательских сценариев. Если разработчик может помочь создать эффективные сценарии тестировщикам, это однозначно стоит делать. Чем быстрее тестировщик найдет дефект, чем быстрее его исправят, тем меньше этот дефект нанесет вреда продукту. Чем дольше ошибка находится в игре, тем она дороже.
2. Code review. Мощнейшая практика для повышения качества вашей игры. Чем качественнее у вас код, тем качественнее в итоге будет ваш продукт. Причем относится это не только к программистам. Дизайнеры пишут скрипты, которые тоже с этой точки зрения можно считать кодом, проводя их review. Как говорится, всего несколько недель регрессии способны заменить часы code review.
3. Smoke test собственных изменений разработчиками. Казалось бы, тестами должны заниматься тестировщики, а не разработчики. Но! Если, например, разработчик отдал код, который не компилируется, или недодал какие-то файлы, в итоге страдает вся компания. Вы не можете работать, это приводит к огромным потерям, которые можно подсчитать даже в денежном выражении. И если с кодом и как минимум его компиляцией все еще довольно просто и на сборку проекта уходит не слишком много времени, то с изменениями, которые вносят гейм-дизайнеры, все намного печальнее. Дизайнер где-то там в середине уровня что-то поменял и сам не проверил, можно ли его банально пройти. В итоге отдается непроходимый контент, тестировщики собирают билд, проводят свой smoke test, берут билд в работу, доходят до сломанного места, где обнаруживается, что билд не проходится. В итоге тратится куча времени, чего можно было бы избежать, если бы дизайнер потратил немного времени на smoke test своих изменений и не отдал такой контент в билд.
4. Разработчики должны участвовать в составлении требований тестировщиками. Безусловно, в идеальной схеме разработчики должны отдавать на тестирование фичи уже с документацией и требованиями к ним. Однако зачастую тестировщикам приходится составлять список требований самостоятельно. И ладно еще, если это происходит на основе актуальной документации. Но если документация неактуальна или ее вообще нет, тестировщик никогда не может быть уверен, что требования, которые он составил на основе своих проверок, верны. А значит, задача разработчика — провести review тестов и указать, что данные проверок валидны и фича должна соответствовать им.
Этот набор не самых трудозатратных рекомендаций (пускай smoke test и code review все же потребуют времени, оно с лихвой компенсируется) позволяет разработчикам повысить качество продукта в любой команде и в любой ситуации.
Что делать тестировщикам, чтобы повысить качество игры
Теперь же перейдем к тестировщикам. Главный вопрос, на который хочется дать ответ в этой статье, — «А повышают ли тестировщики качество игр?». Внимание, сейчас будет спойлер: нет, не повышают.
Тестировщики находят ошибки, которые уже попали в ваш продукт. На момент тестирования игра уже обладает каким-то уровнем качества. Сами тестировщики его повысить не могут. У нас для этого нет ни компетенций, ни полномочий. Тестирование — информационный сервис. Тестировщики — люди, которые рассказывают другим заинтересованным людям правду о вашем продукте. Мы ни в коем случае его не ломаем, как можно часто услышать от тех же разработчиков, мол, «я отдал продукт в тестирование, сейчас тестировщики все сломают». Да не ломаем мы ничего! Оно уже сломано. Как однажды полушутя сказал Джеймс Бах, «максимум, что могут сломать тестировщики, — это ваши мечты о продукте». И это абсолютная правда. Мы не ломаем игры, мы рассказываем разработчикам, где они сломаны. Или не сломаны. Не менее важная часть процесса тестирования — убедиться, что все работает так, как задумывалось.
И вот на основе информации, переданной тестировщиками, разработчики (или менеджмент) принимают решения по поводу исправления дефектов. Именно разработчики создают качество, мы его лишь контролируем.
И что же получается? Тестировщик ни в чем не виноват? Это злые разработчики делают плохие игры?
Это не так. Существует целый ряд проблем, которые могут возникать в процессе тестирования и из-за которых будет страдать качество продукта. Хочу поделиться списком ошибок и их возможных решений, достаточно универсальных для большинства игровых продуктов и студий.
Первая проблема — недостаточная квалификация тестировщиков. Только джуны никогда не смогут добиться желаемого результата — ни в разработке, ни в тестировании. К сожалению, распространено мнение, что тестировщики — самые низкоквалифицированные сотрудники и можно нанять энное количество джунов к концу проекта, чтобы закрыть существующие вопросы тестирования. А не получится — нанять еще джунов. Как в анекдоте про 9 женщин, беременных 1 месяц, это не работает. Множество джунов никогда не заменит одного квалифицированного тестировщика. Естественно, как и в любой другой сфере, джунов надо больше. Задач, не требующих какой-то исключительной компетенции, у вас будет в итоге намного больше. Но квалифицированные QA — всегда основа и опора вашего отдела. Вы должны их нанимать, воспитывать и любить. Как и в любой другой сфере в разработке, вы не сможете обойтись исключительно некомпетентным составом.
Вторая проблема — недостаток тестировщиков. Да, в большинстве своем игры — крайне сложные системы с буквально неограниченным количеством возможных пользовательских сценариев и вариантов взаимодействия различных механик. Именно поэтому полностью покрыть вашу игру проверками даже теоретически невозможно. Не существует какой-то универсальной схемы, по которой можно вычислить необходимое количество тестировщиков для вашего проекта. На это будет влиять слишком много факторов: объем самой игры, количество механик, платформ, даже жанр и линейность игрового процесса. Однако одним из самых адекватных критериев, от которого можно плясать, я считаю количество разработчиков, чью работу вы будете тестировать. Считается, что здравое соотношение — 1 тестировщик на 4 разработчика. И это то количество, к которому имеет смысл стремиться, уже в дальнейшем делая поправки на специфику вашего конкретного продукта.
Третья проблема — несвоевременное тестирование. Причем это касается обеих возможных сторон несвоевременности. Если с проблемой слишком позднего запуска тестирования все довольно очевидно, то о проблеме слишком раннего тестирования я хотел бы поговорить отдельно.
Игры создаются не одномоментно. Наверняка процесс создания вашей игры разбит на этапы и отчетные периоды. Тестировщикам важно осознавать, на каком этапе вы сейчас находитесь, и указывать только релевантные для этого этапа дефекты. Казалось бы, что плохого в том, что вы заранее напишете о найденных багах? Если они касаются фичи в околофинальном состоянии — ничего. Однако, когда тестировщики начинают описывать дефекты низкой важности на этапе условного драфта, это очень вредно для всей разработки. Тестировщики тратят время на поиск, локализацию и занесение ненужных на данном этапе дефектов. В лучшем случае они просто будут висеть мертвым грузом у вас в баг-трекере, и вам придется регрессить их через какое-то время, когда проект выйдет на финальные этапы. В худшем случае неопытный разработчик возьмется их решать. Чинить миноры в драфте — худшее, что можно придумать. Это потеря времени на совершенно никому не нужную работу. Баги коллизии на ранних этапах игры никого не интересуют — там вся геометрия еще 15 раз переделается. Дергающиеся анимации в сценах, которые еще не утверждены и не анимированы на чистовую, чинить нельзя. Старайтесь максимально избегать таких багов, следить за текущим этапом и осознавать требования и ко всему продукту, и конкретно к тестируемой фиче.
В заключение
Так как тестирование — сервис про коммуникации, старайтесь как можно больше коммуницировать. Именно на общении между разработчиками и тестировщиками строится качество вашей игры. Запрашивайте тестирование, пишите отчеты, наращивайте документацию, утверждайте, спорьте, если это нужно. Это и есть наша работа.
Спасибо всем, кто дочитал.
