Александр Торговкин
Тестирование видеоигр, или Легкий способ попасть в геймдев
III – в этом случае первые ошибки появились на этапе проектирования. Разработка, основанная на ошибочном проекте, ошибочна по своей сути. Нужно исправить ошибки проекта и провести разработку заново.
IV – ошибки начались еще раньше – на этапе формулирования требований. Как видно, сформулировать их не совсем удалось. Поэтому получился неправильный проект, на основе которого был разработан программный продукт с критическими ошибками.
V – на этапе концепции не были выявлены дефекты. Это привело к ошибочным требованиям. Далее количество дефектов росло как снежный ком. Получившийся продукт не соответствовал ожиданиям клиентам и даже его создателей.
VI – самый печальный случай, но, к сожалению, распространенный среди инди-разработчиков. Гипотеза не была протестирована и то, что получилось, в конце оказалось никому не нужно.
2.4. Как снизить риски возникновения дефектов
Поскольку шансы возникновения ситуации, которая может стать причиной дефектов, на ранних стадиях довольно высоки, для снижения этих рисков используются модели разработки, включающие в процесс тестирование практически на самых ранних этапах. Хотя в чистом виде такие модели встречаются довольно редко, часто используются разные их комбинации.
2.4.1. Использование моделей и методологий разработки
В разработке программного обеспечения, в том числе и игрового, традиционно применяются три подхода.
1. Классические модели
2. Гибкие модели[19]
3. Сочетания классической и гибкой моделей
У каждого из подходов, как часто бывает в жизни, есть свои достоинства и недостатки. Давай разберем каждый из них подробнее.
Для начала нужно сказать, что ты, возможно, никогда не увидишь все существующие модели «вживую». Для этого есть масса причин: для применения некоторых необходимы определенные условия, например очень профессиональная, самоорганизующаяся команда «мастеров на все руки» или очень гибкий бюджет. Кроме того, некоторые из этих моделей существуют только в воображении их авторов или никогда не выходили за пределы конкретной компании. Еще одна причина – определенная путаница в головах у некоторых «продюсеров», которые зачастую путают понятия «философия» и «методология». Например, они отождествляют понятия Agile и Scrum, хотя последнее – лишь один из подходов-методологий при использовании гибкой модели.
Поэтому, чтобы понять, где находится место тестировщика в разработке и как его работа снижает риск возникновения дефектов, лучше рассмотреть не конкретные методологии, а, скорее, различные философии в управлении проектами по разработке программного обеспечения.
С точки зрения сути подходов (философии) к управлению проектами их принято разделять на две группы: классические и гибкие. Хотя это весьма условное деление, ведь классическое может быть весьма гибким, а гибкое рано или поздно становится классическим. Тем не менее в таблице ниже приведены существенные отличия этих двух групп.
Приведенных выше отличий вполне достаточно для понимания разницы между этими философиями. Давай посмотрим на конкретные популярные модели разработки, чтобы понять их плюсы и минусы и те возможности, которые помогут тестировщику предотвратить появление ранних дефектов.
Последовательная модель (на примере Waterfall model и V model)
У этой модели есть два свойства: 1) она известна человечеству с древнейших времен. Думаю, что постройка египетских пирамид велась с ее использованием, хотя описана она была только в 1970 году в качестве решения для управления усложняющейся разработки программного обеспечения; и 2) она похожа на водопад или водный каскад, хотя, как ты понимаешь, это сделано специально, чтобы дать ей запоминающееся название. Расположив фазы горизонтально или вертикально, мы не поменяем в этой модели ничего, кроме того, что на водопад она больше похожа не будет.
Модель предполагает, что разработка будет состоять из определенных фаз, результат каждой из которой будет необходим для начала следующей.
Обрати внимание на то, что в этой модели довольно долгий подготовительный период. Менеджеры тщательно планируют работу по проекту и готовят всю необходимую документацию. По сути, сначала создается идеальный план выполнения работ с распределением всех ресурсов на выполнение конкретных задач для достижения целей фазы, а также просчитываются потенциальные риски и способы управления ими. После того как подготовительные этапы завершены, команда приступает к работе, а менеджер сравнивает реальный прогресс работы по проекту с тем идеальным планом, который был создан до этого, и принимает меры, если между ними возникают расхождения.
Использование этой модели предполагает знание ее плюсов и минусов.
Водопадная модель
Несомненный ее плюс – тщательное планирование и документирование работ до начала реализации. С самого начала понятно, какие работы нам следует выполнить для достижения результата и сколько они будут стоить. Кроме того, тщательно разработанная документация позволяет новым членам команды существенно быстрее присоединиться к работе. Вдобавок эта модель выглядит очень естественной и интуитивно понятной, что делает ее довольно легкой для менеджмента.
Однако это, как ни парадоксально, может оказаться одним из главных минусов. Очень сильная зависимость от опыта одного менеджера проекта, по плану которого команда будет работать, значительно повышает риск неудачи. Например, если компетенций и знаний «матчасти» менеджера не хватит, мы обязательно столкнемся с трудностями при реализации проекта. Отчасти эту проблему можно решить тщательной проверкой плана работы и проектной части командой специалистов продюсерской группы и оперативное внесение в них необходимых изменений.
Другой минус использования «водопадной» модели – высокая цена ранних ошибок. Другими словами, если на этапе тестирования ты обнаружишь дефект, связанный с проектированием, то все работы по разработке, вероятно, придется выполнять заново, поскольку функционал был разработан на ошибочных требованиях. Я говорил о таких ситуациях выше. Как же с ними можно бороться?
Например, использовать другую классическую модель – V-модель, усовершенствованнный «водопад». От предыдущей она отличается тем, что каждая фаза проекта совмещена с тщательным тестированием продукта этой фазы. Эта модель идеально иллюстрирует принцип раннего тестирования, который, помимо прочего, позволяет нам существенно экономить время и деньги. Возможно, авторы этой модели придали ей сходство с литерой V, которую часто изображают для обозначения победы (англ. Victory).
V-модель
Таким образом, тестирование с самых ранних этапов позволяет нам избежать концептуальных ошибок, которые сложно исправлять впоследствии, и контролировать проект и его бюджет на всех этапах реализации.
Казалось бы, невозможно придумать ничего лучше для реализации практически любого проекта; недаром эта модель – федеральный стандарт разработки ПО. Но и она не лишена недостатков. Например, мы не можем оперативно внести изменения, без которых проект рискует потерпеть неудачу (добавить или изменить функционал). Кроме того, модель не предполагает глубокого анализа рисков.
Зато углубленное изучение всевозможных рисков предполагается в следующей из рассматриваемых моделей – спиральной.
Спиральная модель (Spiral Model)
Спиральная модель
Спиральная модель – это концептуальный подход, в котором предполагается глубокий анализ разнообразных рисков.
Разработка продукта на каждой стадии (витке спирали) разработки программного обеспечения проходит всегда по четырем этапам.
1. Определение целей
2. Оценка рисков
3. Разработка и тестирование
4. Планирование
Так эта модель становится больше похожа на итеративную, хотя в ней нет четких временных ограничений этапов. И именно это обстоятельство – ее главный минус. Без введения временных ограничений для каждой стадии может быть довольно сложно определять время перехода от одного этапа к другому. Ну, и, как ты понимаешь, чтобы использовать эту модель, нужно быть экспертом в области управления рисками.
В спиральной модели нет фиксированных этапов – например, разработки спецификации или проектирования. Она может включать в себя любые другие модели разработки. Например, на одном витке спирали может использоваться прототипирование для более четкого определения требований, а на следующем витке может применяться каскадная модель.
Совершенно противоположный по идеологии подход к разработке принято называть гибким (Agile). Считается, что он изначально появился как ответ на невозможность использования «водопадной» модели в сложных творческих проектах по разработке ПО. Один из центральных постулатов Манифеста Agile, на положениях которого основана вся философия гибкой разработки проектов, таков: изменения в проекте допустимы на любой стадии реализации. Для менеджеров – приверженцев классического подхода, как ты понимаешь, это делает управление проектом похожим на ад: все бюджетирование «идет лесом», сроки реализации проекта туманны, требования неясны. Но, если вдуматься, это и есть признаки типичного проекта по разработке видеоигры. Отчасти это и делает применение «гибких» методик в сфере разработки игр весьма распространенным.
Суть гибкого подхода – использование достаточно коротких итераций разработки в ответ на вводимые изменения в требованиях.
Почти полное отсутствие плана разработки в этом случае компенсируется постоянными взаимодействием с заинтересованными лицами проекта (например, с заказчиком) и обратной связью от них, что довольно сильно снижает продуктовые и проектные риски. А отсутствие изначальных принятых и согласованных требований позволяет вносить в проект изменения и постоянно экспериментировать.
Основные недостатки этого подхода – все, что связано с довольно сложным взаимодействием в ходе работы над проектом, соблюдением принципов методологии и планированием ресурсов.
Гибкая модель (на примере Scrum)
Когда речь заходит о гибких методологиях, практически у 90 % менеджеров в голове возникает одно слово – Scrum. Это одна из наиболее популярных итерационных моделей разработки ПО, относящихся к Agile. Методология хорошо задокументирована, и ты легко найдешь подробный материал для ознакомления. Я лишь кратко постараюсь осветить основные положения и процессы.
Основных ролей в Scrum три.
1. Владелец продукта (Product owner)
2. Команда разработки (Development team)
3. Scrum-мастер (Scrum master)
Владелец продукта (ВП) – это заказчик или представитель заказчика. Он обладает техническими знаниями в такой мере, чтобы формулировать требования к разрабатываемому продукту. Владелец продукта отвечает за формирование видения (vision) продукта и принятие окончательных решений. Инструмент ВП – Журнал Продукта (Product Backlog), который используется для записи требований к продукту в порядке их приоритета. В этом же журнале прописываются критерии готовности реализации требований (Definition of Done).
Роль Scrum-мастера отличается от менеджера продукта; это, скорее, капитан команды (кстати, термин scrum был заимствован из регби, где им обозначают схватку команд при розыгрыше мяча). Его основная задача – обеспечить выполнение требований методологии и постоянный ритм работы, а также уберечь команду от внешних мешающих работе воздействий. При этом он также разработчик и выполняет задачи по реализации проекта.
Команда разработки (КР) состоит из специалистов, задача которых – реализация задач по проекту и разработка финального продукта. Согласно идеологии Scrum к команде предъявляются следующие требования.
1. Команда должна быть способна к самоорганизации (и это понятно, ведь начальника в виде менеджера проекта или продюсера над ними нет).
2. Специалисты должны обладать всеми необходимыми навыками для реализации продукта, то есть команда должна быть многофункциональной.
3. Ответственность за выполненную и невыполненную работу несет вся команда, а не индивидуальные члены.
При этом рекомендуемый размер команды – 7 ± 2 человека. Считается, что у команды большего размера неизбежно возникнут сложности с коммуникацией. Если же размер команды меньше, то она может не обладать всеми необходимыми компетенциями для реализации проекта.
Инструмент команды – Журнал Спринта (Sprint Backlog), в котором требования ВП преобразуются в конкретные задачи.
Итерация (стадия, временной отрезок), в рамках которой производится разработка продукта в Scrum, называется спринтом (Sprint). Спринт обычно составляет 1‒4 недели (40‒160 рабочих часов), и его продолжительность неизменна на всем протяжении разработки. Изменение продолжительности спринтов неизбежно приводит к потере командой рабочего ритма и снижению эффективности ее работы. Каждый спринт должен заканчиваться новой версией продукта (инкремент).
Итерация в Scrum
Спринт начинается с планирования, в ходе которого команда должна найти ответы на два вопроса: 1) какой объем работы можно выполнить в предстоящем спринте и 2) как она будет выполняться.
После обсуждения требований с владельцем продукта команда декомпозирует требования в конкретные задачи для реализации этих требований. Эти задачи составляют содержимое Журнала Спринта. Затем создается план, чтобы все задачи были выполнены до конца спринта.
В течение спринта команда собирается на ежедневные «летучки»-совещания (Daily scrum), чтобы обсудить текущие проблемы.
Спринт завершается Обзором Спринта (Sprint Review), в рамках которого Владелец продукта предъявляет инкремент, то есть новый билд продукта с разработанным в рамках спринта функционалом.
После этого команда проводит Ретроспективу Спринта (Sprint Retrospective). На ней определяются области работы, требующие улучшений.
Такой порядок повторяется в конце каждого спринта.
Один из важнейших показателей при использовании Scrum – ритм работы команды, то есть скорость, с которой выполняются задачи без перенапряжения сил. Для поддержания рабочего ритма важно:
1. обеспечить фокус команды на задачах проекта без отвлечения на посторонние задачи;
2. правильно оценивать время выполнения задачи;
3. отслеживать прогресс по спринтам.
Для оценки времени на выполнение задачи ты можешь использовать любой из методов, изложенных в параграфе «Планирование ресурсов». А для отслеживания прогресса по спринтам неплохо подходит диаграмма сгорания (Burndown chart). Она сравнивает планируемую скорость работы команды с реальной.
Особенность Scrum – упор на самоорганизующуюся, многофункциональную команду. Это позволяет снизить затраты на координацию и управление, но может привести к повышению затрат на отбор персонала, его мотивацию и обучение.
Пример диаграммы сгорания
Кроме того, несмотря на кажущуюся простоту, Scrum часто используют неправильно. Для таких случаев существует даже особое понятие – Ограниченный Scrum (ScrumBut); это использование лишь части принципов Scrum. Такой подход приводит к существенному ухудшению производительности по сравнению даже с отсутствием методологии. Классические примеры ScrumBut:
1. отсутствие критериев готовности (Definition of Done);
2. неодинаковая длительность спринтов;
3. длительность спринта более 4 недель;
4. проведение «летучек» (Daily Scrum) не каждый день;
5. отсутствие ретроспектив и т. д.
Чтобы компенсировать недостатки разных подходов и усилить их достоинства, часто предпринимаются попытки создания различных гибридных методологий, которые могут удачно использоваться в игровой разработке.
Один из примеров такого подхода – использование V-модели для создания прототипа игры с последующим переходом к Scrum для цикличного наращивания функционала и развития проекта. В этом случае роль группы обеспечения качества возрастает: тестирование проводится с самого начала проекта и далее тестируется результат каждой итерации (спринта).
Использование гибких подходов в разработке накладывает на работу тестировщика дополнительную ответственность, связанную с достаточно сжатыми сроками итераций, в рамках которых разработчикам нужно не только нарастить функционал приложения, но и постараться исправить наиболее серьезные дефекты. В этих обстоятельствах тестировщику нужно уметь правильно не только определить критичность дефекта, но и правильно его приоритизировать, то есть определить сроки его исправления.
2.4.2. Использование ветвления (Branching)
Разработка в разных ветках (branching) – это методология, которая позволяет команде разработчиков работать над различными версиями кода в отдельных ветках, которые могут быть слиты в основную (main branch) после того, как функциональность будет разработана и протестирована. Это позволяет разработчикам изолировать свои изменения от других членов команды, ускорить процесс разработки и снизить вероятность конфликтов в коде.
Ветки могут создаваться для различных целей.
1. Разработка новой функциональности. Когда нужно добавить новую функциональность в приложение, команда может создать отдельную ветку, чтобы не влиять на основной код и тестировать новый функционал отдельно.
2. Исправление ошибок. Когда возникает ошибка в коде, команда может создать отдельную ветку, чтобы исправить ошибку и протестировать исправление, не затрагивая основной код.
3. Стабилизация результата. Когда стабильно работающий билд продукта отправляется заказчику или просто сохраняется как резервная копия для возможности возврата к ней в будущем. При этом работа над продуктом продолжается в основной ветке.
4. Тестирование и эксперименты. Когда нужно протестировать какую-то идею или провести эксперимент, команда может создать отдельную ветку, чтобы проверить идею и не повлиять на основной код.
После того как изменения в ветке были протестированы и одобрены, они могут быть слиты в основную ветку. Это может происходить постоянно или периодически в зависимости от выбранной командой методологии разработки.
Разработка в разных ветках – стандартная практика в большинстве команд разработки, особенно с большим количеством разработчиков. Это позволяет ускорить процесс разработки, улучшить качество кода и снизить вероятность конфликтов в коде.
Пример ветвления при разработке
Ниже приведены некоторые преимущества и недостатки ветвления в разработке программного обеспечения.
Преимущества
• Изоляция изменений. Каждая ветка – это изолированная линия разработки, что позволяет разработчикам работать над изменениями без влияния на другие части кода. Это позволяет снизить количество конфликтов при слиянии изменений в основную ветку.
• Параллельная разработка. Можно работать над разными частями приложения одновременно, что ускоряет процесс разработки.
• Управление версиями. Каждая ветка может быть отдельно версионирована, что упрощает управление версиями приложения.
• Исправление ошибок. Исправления могут быть быстро внесены в отдельную ветку, чтобы избежать проблем с нестабильностью основной.
Недостатки
• Увеличивает сложность управления кодом, поскольку каждая ветка может иметь свои особенности и уникальные изменения.
• Увеличивает необходимость в тестировании и интеграции каждой ветки перед ее объединением с основной веткой.
• Может привести к проблемам слияния веток, если различные члены команды вносят изменения в одни и те же файлы.
Для управления процессом ветвления важно иметь хорошо определенные правила и процессы для управления ветками, а также использовать инструменты для контроля версий, такие как Git, чтобы управлять и сливать ветки.
2.4.3. Взаимодействие тестировщика с заинтересованными лицами
В своей работе тестировщик вступает в общение с большим количеством людей. Все, кто имеет интерес к тестированию и его результатам, а также качеству разрабатываемой системы, называются заинтересованными лицами тестирования. Поскольку они изменяются в зависимости от проекта, продукта, организации и других особенностей, это могут быть следующие роли.
• Разработчики обеспечивают реализацию тестируемого программного обеспечения, получают результаты тестирования и должны принимать меры на основе этих результатов, например исправлять найденные дефекты.
• Системные архитекторы и дизайнеры проектируют программное обеспечение, получают результаты тестирования и принимают меры на их основе.
Менеджеры проекта несут ответственность за управление проектами, соблюдая баланс между показателями качества, сроками, ресурсами и бюджетом. Они часто сотрудничают с руководителем тестирования при планировании и управлении.
• Маркетолог- и бизнес-аналитики определяют функции и уровень качества реализуемой функциональности. Они также часто участвуют в определении необходимого тестового покрытия, анализе результатов тестирования и принятии основанных на них решений.
• Сотрудники технической поддержки, поддержки клиентов поддерживают пользователей и клиентов, которые получают пользу от функций и качества поставляемого игрового ПО.
• Прямые и косвенные пользователи напрямую используют игру (то есть они конечные пользователи).
• Руководители высшего звена, менеджеры продукта и спонсоры проекта участвуют в определении необходимого тестового покрытия, анализе результатов тестирования и принятии основанных на них решений.
Без правильного определения заинтересованных лиц тестирования в конкретном проекте и без установки рабочих взаимоотношений с ними процесс тестирования не будет эффективным и результативным.
Другими словами, в процессе тестирования нужно точно знать, с кем общаться, на какую тему, какие вопросы должны обсуждаться в каждом случае и каких целей мы этим пытаемся достичь. Мнение заинтересованных лиц должно учитываться на разных этапах для достижения результатов этих этапов. Например, на этапе планирования определение и оценка рисков должна включать представителей всех групп заинтересованных лиц продукта и проекта, хотя иногда одни заинтересованные лица выступают в качестве заместителей других (высокорейтинговые игроки могут выступить заместителями всех потенциальных игроков). А во время завершения тестирования должны быть оценены показатели и критерии успеха, которые имеют отношение к ожиданиям заинтересованных лиц тестирования с точки зрения качества. Только когда тестирование удовлетворяет этим потребностям и ожиданиям, команда тестирования может утверждать, что действительно была эффективной.
Коммуникация между тестировщиками и другими заинтересованными лицами должна быть профессиональной, объективной и эффективной, чтобы создать и поддерживать уважение к команде тестирования. Если тестировщика просят предоставить обратную связь о результатах работы других членов проектной команды (например, разработчиков), необходимо быть дипломатичным и максимально объективным. Цель коммуникации – достичь целей тестирования и улучшить качество продуктов и процессов, используемых для создания этих продуктов.
Важно предоставить такую информацию о состоянии проекта на соответствующем уровне детализации (например, менеджеры обычно хотят видеть тенденции, связанные с дефектами, а не отдельные дефекты) и так, чтобы ее было легко правильно понять (например, в виде простых диаграмм и графиков).
Независимо от направления сообщения (передается ли информация высшему руководству или отправляется в отдел технической поддержки пользователей) применяются одни и те же правила: коммуникация должна быть подходящей для целевой аудитории, сообщение должно быть отправлено эффективно и его понимание должно быть подтверждено.
Тестировщик должен уверенно владеть различными средствами коммуникации. Информация передается по электронной почте, в мессенджерах, в устной форме, на официальных или неофициальных заседаниях, в официальных или неофициальных отчетах и с использованием инструментов управления тестированием, таких как баг-трекеры.
Специалист по тестированию должен уметь подготовить отличную документацию. Именно она будет характеризовать организацию, которая обеспечивает качество продукта.
Пример предоставления информации о дефектах
Сергей Унгер, QA-менеджер Bytex
QA – это про общение. Много общения. Рядовые QA обычно взаимодействуют со своим непосредственным руководителем – лидом (QA Project Lead) и с разработчиками (кодерами, левел-дизайнерами, UI/UX-программистами и т. д.) через системы отслеживания ошибок (баг-трекеры) или напрямую через мессенджеры/почту/звонки. Бывают случаи, когда рядовые QA тоже находятся в прямом контакте с продюсерами, но обычно в этом нет острой необходимости.
Если ты лид (или тест-менеджер), основное общение происходит на соответствующем уровне – с продюсерами, лидами и менеджерами других отделов, работающих над проектом. Лиды есть практически у всех рядовых сотрудников, у программистов, у дизайнеров и т. д. Это основное ответственное лицо, отвечающее за работу команды. А продюсер (или project manager) выполняет роль связующего звена всех работающих над проектом отделов. В игровой индустрии все подозрительно схоже с кинематографом…