Ситуации, которые могут стать причинами и первопричинами появления дефектов, могут возникать на разных этапах разработки игрового проекта. Чем раньше это происходит, тем существеннее может быть влияние дефекта на развитие проекта. А в некоторых случаях такой дефект может привести к невозможности реализовать проект. На рисунке ниже представлена обобщенная информация о том, насколько критичны и к каким последствиям могут приводить дефекты, возникающие на ранних стадиях проекта.
Ошибки, возникшие на ранних этапах проекта, со временем начинают стоить слишком дорого
I – это идеальный проект, практически отсутствующий в природе. В нем не было допущено ни одной ошибки ни на одном этапе.
II – проект, в котором ошибки допущены только при непосредственной разработке. Говорит о том, что команда программистов была очень слабой. Впрочем, такая ситуация тоже практически невозможна.
III – в этом случае первые ошибки появились на этапе проектирования. Разработка, основанная на ошибочном проекте, ошибочна по своей сути. Нужно исправить ошибки проекта и провести разработку заново.
IV – ошибки начались еще раньше – на этапе формулирования требований. Как видно, сформулировать их не совсем удалось. Поэтому получился неправильный проект, на основе которого был разработан программный продукт с критическими ошибками.
V – на этапе концепции не были выявлены дефекты. Это привело к ошибочным требованиям. Далее количество дефектов росло как снежный ком. Получившийся продукт не соответствовал ожиданиям клиентам и даже его создателей.
VI – самый печальный случай, но, к сожалению, распространенный среди инди-разработчиков. Гипотеза не была протестирована и то, что получилось, в конце оказалось никому не нужно.
2.4. Как снизить риски возникновения дефектов
Поскольку шансы возникновения ситуации, которая может стать причиной дефектов, на ранних стадиях довольно высоки, для снижения этих рисков используются модели разработки, включающие в процесс тестирование практически на самых ранних этапах. Хотя в чистом виде такие модели встречаются довольно редко, часто используются разные их комбинации.
2.4.1. Использование моделей и методологий разработки
В разработке программного обеспечения, в том числе и игрового, традиционно применяются три подхода.
1. Классические модели
2. Гибкие модели[19]
3. Сочетания классической и гибкой моделей
У каждого из подходов, как часто бывает в жизни, есть свои достоинства и недостатки. Давай разберем каждый из них подробнее.
Для начала нужно сказать, что ты, возможно, никогда не увидишь все существующие модели «вживую». Для этого есть масса причин: для применения некоторых необходимы определенные условия, например очень профессиональная, самоорганизующаяся команда «мастеров на все руки» или очень гибкий бюджет. Кроме того, некоторые из этих моделей существуют только в воображении их авторов или никогда не выходили за пределы конкретной компании. Еще одна причина – определенная путаница в головах у некоторых «продюсеров», которые зачастую путают понятия «философия» и «методология». Например, они отождествляют понятия Agile и Scrum, хотя последнее – лишь один из подходов-методологий при использовании гибкой модели.
Поэтому, чтобы понять, где находится место тестировщика в разработке и как его работа снижает риск возникновения дефектов, лучше рассмотреть не конкретные методологии, а, скорее, различные философии в управлении проектами по разработке программного обеспечения.
С точки зрения сути подходов (философии) к управлению проектами их принято разделять на две группы: классические и гибкие. Хотя это весьма условное деление, ведь классическое может быть весьма гибким, а гибкое рано или поздно становится классическим. Тем не менее в таблице ниже приведены существенные отличия этих двух групп.
Приведенных выше отличий вполне достаточно для понимания разницы между этими философиями. Давай посмотрим на конкретные популярные модели разработки, чтобы понять их плюсы и минусы и те возможности, которые помогут тестировщику предотвратить появление ранних дефектов.
Последовательная модель (на примере Waterfall model и V model)
У этой модели есть два свойства: 1) она известна человечеству с древнейших времен. Думаю, что постройка египетских пирамид велась с ее использованием, хотя описана она была только в 1970 году в качестве решения для управления усложняющейся разработки программного обеспечения; и 2) она похожа на водопад или водный каскад, хотя, как ты понимаешь, это сделано специально, чтобы дать ей запоминающееся название. Расположив фазы горизонтально или вертикально, мы не поменяем в этой модели ничего, кроме того, что на водопад она больше похожа не будет.
19
Гибкие модели разработки (Agile) – методологии, основывающиеся на цикличном методе (итерационном подходе). В нем решения разрабатываются на основе анализа требований в результате работы самоорганизующихся кросс-функциональных групп (которые делают однородную творческую работу) при управлении ими комбинированным (либеральным и демократическим) методом.