Случай с Cyberpunk 2077
Если вы – геймер, вы точно слышали о «Cyberpunk 2077» от студии CD Project RED, если нет – то все равно вы должны были хоть что-то слышать об этой игре. По замыслу руководства CD Project RED эта игра должна была стать лучшей компьютерной игрой в истории, событием 2020 года в игровой индустрии, и, учитывая репутацию, которую студия уже успела получить благодаря своему «Ведьмаку», многие искренне верили в ее успех. Игра ждала своего появления аж 8 лет (первый анонс был еще в 2012 году), CD Project RED потратила миллионы долларов на разработку и маркетинг, в проект даже привлекли Киану Ривза, который исполнил одну из ключевых ролей, но что-то пошло не так…
Несмотря на ошеломительный успех первых дней (только на ПК заказали более 4,7 млн. копий), то, что случилось далее геймеры точно не ожидали. На ПК игра идет еще более-менее нормально, но на консолях (кроме новейших) ситуация просто ужасная. Полная заторможенность, огромное количество багов, плохая оптимизация, «разрывы экрана» и другие неожиданности привели к тому, что более 150 миллионов геймеров так и не смогли нормально поиграть в нее.
Многие огорчены и разочарованы, а студия, которая до этого считалась одной из лучших в индустрии терпит репутационные потери. Да, они пообещали в ближайшее время выпустить обновления и патчи, которые должны исправить ситуацию, но общее впечатление уже сложилось, и результат можно описать одним словом – ПРОВАЛ.
Так что же случилось и когда процесс пошел не так? Вот версия главного разработчика Марчина Ивински (Marcin Iwinski):
Главный тестировщик проекта, Стей МакСти выразила мнение, что в этом видео Марчин обвиняет их отдел в провале, поскольку «тестировщики не нашли баги» и руководство приняло поспешное решение выпустить игру.
Мы здесь не будем анализировать причины провала и роль в этом всех его участников, мы лишь хотим показать на примере этого огромного и дорогого проекта, что никакой маркетинг, хайп и промоушн не смогут компенсировать качество продукта, ведь в конечном счете успех определяется комплексом факторов, и качество – важнейший из них. Здесь мы рассмотрим роль технической команды – разработчиков и тестировщиков в обеспечении качества готового продукта.
Как разработчики могут обеспечить качество игры
- Никто лучше разработчика не знает особенности конкретной части игры. Разработчики лучше всех остальных понимают все особенности и нюансы своей игры, и, хотя они конечно же стараются сразу сделать все хорошо, но все же всегда будут «узкие места», в которых могут появиться дефекты, и разработчик точно знает где они. Поэтому подсказать тестировщику на что именно, где и когда обратить особое внимание – хорошая практика для разработчика. На самом деле, тестирование игр – это очень сложный процесс, несмотря на кажущуюся увлекательность. В игре, тем более в такой, как «Cyberpunk 2077» очень много разных взаимодействий и сценариев поведения для игрока. В идеале все их нужно опробовать. В лучшем случае, разработчик помогает тестировщикам создавать сценарии тестирования, если есть такая возможность. Это позволит найти максимально много ошибок на максимально раннем сроке. А это означает, что можно быстро и дешево найти все баги.
- Smoke test своих изменений. Да, тестирование – это работа тестировщиков, а не разработчиков. Но тут есть свои нюансы. Возьмем к примеру такой случай: программист отдает код, который невозможно компилировать, или для этого не хватает определенных файлов, в результате это приводит к остановке потока, простою и денежным потерям. Это только простейший случай, так как на сборку проекта и его компиляцию уйдет не так уж и много времени, но бывают и более сложные ситуации. Например, такая: гейм-дизайнер в одном из уровней меняет какой-то компонент, и не проверяет возможность его прохождения с таким изменением. Появляется потенциальное непроходимое место, тестировщики делают билд, добираются до этого проблемного места и обнаруживают, что его невозможно пройти. Таким образом потрачено время. Но этого можно легко избежать, если внедрить практику smoke test в работе разработчиков.
- Помощь в процессе составления требований для тестировщиков. В идеале схема выглядит так: разработчики передают фичи на тест вместе с документами к ним, но так бывает далеко не всегда, и тестировщикам иногда нужно самим составить список требований. Хуже всего, когда им нужно сделать это на базе неактуальной документации, или, когда ее вообще нет (и так тоже бывает). Таким образом получается, что тестировщик не может полагаться на правильность требований, составленных на его проверках. Поэтому разработчик должен пересматривать тесты и проверять их валидность.
На выполнение этих рекомендаций не потребуется много времени (больше всего займет smoke test, но и это в конечном счете окупится), но их выполнение поможет команде значительно улучшить качество продукта.
Как тестировщики могут обеспечить качество игры
А сейчас давайте рассмотрим роль тестировщиков в обеспечении качества игр. На самом деле, тестировщики не повышают качество игры (сами по себе). Они ищут и находят те ошибки и проблемы, которые уже есть в игре, и исправить их, а значит и повысить качество продукта тестировщики не могут, это не входит в их обязанности. Тестирование – это оценка продукта, несмотря на бытующее среди некоторых разработчиков мнение «тестировщики все ломают», это далеко не так. Тестировщики не придумывают проблем, они уже там есть. Задача этих людей – правильно выявить их. В процессе тестирования могут возникнуть определенные проблемы, и здесь мы опишем наиболее типичные из них.
Проблемы тестирования
- Квалификация специалистов. Бытует мнение, что тестирование – самая неквалифицированная в ИТ работа, поэтому чтобы быстро закрыть этот вопрос, можно просто нанять побольше джуниоров, и они в кратчайший срок смогут прогнать все тесты. Но, на деле, все оказывается не так просто. Пять джуниоров без опыта не заменят одного высококлассного специалиста. Да, джуниоры тоже нужны в проекте, но без опытных тестировщиков никак не обойтись.
- Недостаток времени/тестировщиков. Нужно понимать, что игра — это сложный программный продукт с космическим количество пользовательских сценариев и вариантов взаимодействия. Даже при огромном штате тестировщиков, проверить все не удастся, но с другой стороны, если не уделить этому процессу достаточно внимания, продукт получится сырым и непривлекательным из-за множества ошибок, и сбоев. Поэтому лучший вариант – это разумный баланс между временем и количеством тестировщиков, которых нужно задействовать. В разработке игр за примерный ориентир можно предложить схему соотношения количества разработчиков к тестировщикам 4:1, хотя здесь все зависит от специфики проекта.
- Ранее/позднее тестирование. Вопрос тестирования с опозданием выглядит более-менее ясно – сроки горят (Cyberpunk 2077 – хороший пример), работы выполняются кое-как, в результате продукт выходит сырой. Но есть и другая сторона проблемы – ранее тестирование. Многие команды стремятся максимально сократить время на разработку продукта, и вводят тестировщиков в работу максимально быстро. Что плохого в баге, который найден максимально быстро? Если продукт уже на финишной прямой – отлично! Но если тестировщик находит баг еще в «драфт»-версии, это может негативно сказаться на работе разработчиков. Нет смысла фиксить баги в процессе работы над продуктом, когда все меняется по 10 раз в день. Это – лишнее время и никому не нужные усилия. Поэтому очень важно, чтобы тестировщики правильно понимали, на каком они этапе и свою роль на этом этапе.
Так что, как видите тестирование в играх – это не такой простой процесс, как кажется на первый взгляд. А еще, для нормального выполнения этой работы вам понадобится достаточное количество профессионалов.
Так кто же обеспечивает качество игры
Итак, несмотря на бытующее среди некоторых специалистов мнение, тестировщики не могут сами по себе обеспечить качество игры, да они и не должны этого делать. Разработка ПО и игр в частности – это командная работа и ее успех зависит в первую очередь от слаженной работы всех ее участников. Готовый качественный продукт – это результат общих стараний. Нет смысла обвинять других членов команды, если ваш продукт провалился – в такой ситуации проиграют все. И для того, чтобы команда работала слаженно, каждый ее член должен хорошо понимать, какова его роль и выполнять свою работу так, как нужно. Это относится и к разработчикам, и к тестировщикам.