Жизненный цикл ПО/модели

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

Начнем с определения: жизненный цикл программного обеспечения (Software Development Life Cycle - SDLC) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации; он также включает стадии, через которые проходит продукт.

В жизненном цикле участвуют не только разработчики и тестировщики. Давайте ещё вспомним, какие стадии разработки существуют? Идея, дизайн, анализ бизнес и системных требований, разработка, тестирование, пользование.

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

Самая первая модель, которая была разработана, — водопадная или каскадная. Она является последовательной, в такой модели стадии разработки идут строго друг за другом, после окончания одной стартует следующая, т. е. начинаем вверху водопада и спускаемся по нему дальше. Здесь тестирование начинается в самом конце цикла. Наглядный простой пример для водопадной модели — это организация мероприятия, когда вы заранее согласуете все нюансы с заказчиком и каждый этап подготовки следует за другим. Вы не можете сначала предложить демо-версию мероприятия, а через месяц-два полную и пышную. Или, например, проектирование домов: мы не можем спроектировать один фундамент, не зная какой будем строить дом.

Преимущество такой модели разработки в том, что изначально все участники процесса понимают, что конкретно предстоит разработать, сразу прорабатываются все-все требования. Это значит, что они не изменятся в ходе работы над продуктом, их стабильность тоже является преимуществом модели. Однако в самом начале работы над продуктом, сложно четко сформулировать конкретные требования, поэтому работа над ними занимает достаточно много времени, соответственно, всё это приводит к увеличению времени разработки продукта. Удлиняются также и этапы имплементации и тестирования продукта, т. к. в работу сразу переходит весь продукт, а не его часть. Как следствие, проблемы обнаруживаются на достаточно позднем этапе, и их намного сложнее устранить. При этом такой подход не позволяет динамически вносить какие-то изменения в процесс или в продукт.

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

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

Ещё есть другие модели — гибкие, которые кардинально отличаются от первых двух тем, что по ним продукт строится частями: разработка каждой части является небольшим циклом разработки. Такие модели называются итерационными, инкрементными или спиральными.

Преимущество таких подходов в том, что можно быстрее подать продукт на рынок или заказчикам. Это происходит за счёт того, что большая функциональность продукта делится на части, каждая из которых разрабатывается в очередной итерации, соответственно, первый, наиболее важный кусок продукта, можно отдать раньше.

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

Гибких моделей много, и некоторые выделяют каждый тип, как отдельный. Одним из примеров инкрементной модели разработки является быстрая разработка приложений (Rapid Application Development, RAD). Она устроена так: продукт делится на части, и каждая часть разрабатывается параллельно с другими. Это даёт возможность быстро получить довольно объёмный кусок продукта.

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

Есть ещё спиральная модель, в такой модели продукт строится витками, где для каждого нового витка необходимо просчитать все требования и риски продукта.

Однако самой популярной моделью разработки, которая относится к итеративным, является Agile (эджайл). Точнее это даже не модель, а, скорее, подход к разработке продукта. Agile поддерживает создание бизнес-историй для определения функциональности, требует от заказчика постоянной обратной связи и определения критериев приёмки задачи. Такой подход позволяет создавать тестовые сценарии до начала написания кода и решать, какие из этих тестов должны быть автоматизированы. Более подробно agile и его методологии мы будем разбирать позднее в курсе.

Независимо от выбранной модели существует несколько показателей, которых следует придерживаться при тестировании:

• Каждой активности разработки соответствует своя активность по тестированию. То есть активности при тестировании требований и функционала будут отличаться.
• Анализ и проектирование тестов для конкретного уровня тестирования начинаются на стадии соответствующих активностей разработки.
• Для более качественного тестирования, тестировщики должны участвовать в обсуждениях для определения и уточнения требований и дизайна, а также вовлекаться в рецензирование рабочих продуктов (например, требований, дизайна, пользовательских историй и т. п.), как только будут доступны первые их черновые версии.

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

Кроме того, сами модели жизненного цикла разработки могут сочетаться одна с другой. Например, V-модель может быть использована для разработки и тестирования систем серверного уровня и их интеграции, тогда как методология гибкой разработки может быть использована для разработки и тестирования пользовательского интерфейса (UI User Interface) и функциональности.

Жизненный цикл задачи

Помимо разрабатываемого нами продукта, у других объектов, задач или багов тоже есть жизненный цикл, т. е. стадии, через которые они проходят. Что такое задача (task)? Представьте, что наш большой и сложный продукт — это слон, которого мы едим. Мы не можем съесть его целиком, поэтому мы его делим и едим по частям. Так и продукт разбивается на небольшие задачи, реализуя которые мы получаем конечный продукт.

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

Жизненный цикл задачи — это процесс прохождения определённых стадий от её создания до закрытия. В цикле задачи задействовано несколько отделов в компании: аналитики, дизайн, разработка, тестирование.

Для чего нужен жизненный цикл задаче? Это необходимо для того, чтобы в процессе разработки каждый участник знал, что определённый этап завершён и что должно происходить с задачей после. Если у задачи не проработан цикл, то она может легко потеряться, “зависнуть” на каком либо сотруднике или всё может превратиться в хаос.

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

Постановка / планирование задачи

Как мы ранее говорили, сначала появляется идея, которая решает какие-то проблемы, чаще всего она не описана или описана, но очень грубо.

После чего начинается обсуждение этой идеи, создание документации. При обсуждении может быть задействовано как несколько человек (менеджеры, аналитики), так и вся команда разработки.

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

Исполнение / тестирование

Когда задача подробно описана, она отдаётся на исполнение разработке. Разработка по документации реализует задачу. В это время отдел тестирования может изучать документацию, готовить сценарии, по которым будет выполняться тестирование.

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

Анализ результатов / закрытие

Задача считается выполненной и готовой к выпуску на прод, если она полностью протестирована и все дефекты исправлены.

Здесь мы представили упрощённый цикл для знакомства, для каждой модели разработки ПО цикл задачи может варьироваться. К тому же, задача может “ходить” туда-сюда, например от разработки вернуться назад в аналитику. Это нормально, если обнаруживаются какие-то проблемы, требующие пересмотра требований или дополнительной аналитики.