6.2. Процессы разработки программного обеспечения
Процесс разработки программного обеспечения – это совокупность методов, практик и любых действий, которые используют для планирования, создания, тестирования и поддержки программного обеспечения.
Процессы, как и все в мире ИТ, тоже развиваются, часть из них уже почти не применяют, а часть всё ещё популярна. Наиболее востребованными процессами разработки являются Agile методологии, чаще всего это Scrum и Kanban. Однако далеко не все компании и проекты работают именно по этим конкретным Agile процессам и по Agile подходу в принципе. В некоторых случаях такие методологии просто не применимы.
Для вас как QA инженера важно понимать, какому процессу следует ваша команда. Знание особенностей процессов позволяет еще до старта работы понять, какой ответственностью обладают QA инженеры в команде и каков подход к тестированию в целом. Насколько будут четко описаны требования, насколько точно можно будет определять сроки выполнения задач, будут ли поощрять инициативы и инновации. Это даст понимание того, где вы оказались, в настоящих процессах или их имитации, а возможно и в смешанном хаосе.
6.2.1. Waterfall
Waterfall – это строго последовательный процесс разработки, где каждый этап начинается только после полного завершения предыдущего. Водопадная модель хорошо подходит для проектов с четко определенными требованиями и когда изменения в процессе разработки маловероятны. QA инженеры в такой модели участвуют только на одном этапе из семи.
Особенности:
– Последовательность – этапы разработки следуют строго один за другим, без возможности перекрытия и возврата назад.
– Документирование – документация является ключевым компонентом для передачи информации между всеми этапами разработки. Поэтому на каждом этапе требуется довольно подробное документирование.
– Спецификации – все требования к проекту определяют на ранних стадиях, и любые изменения в процессе разработки могут потребовать возвращения к начальным её этапам.
– Легкая визуализация и понимание – структура модели четкая и легко понятна новым участникам команды.
Преимущества:
– Простота управления – четкая простая структура и последовательность этапов делают контроль и управление довольно легкими.
– Предсказуемость бюджета и сроков – этапы и требования максимально прозрачны, что дает возможность хорошо спланировать сроки и бюджеты.
– Обширная документация – после выполнения проекта остается очень подробная и обширная документация, что упрощает дальнейшую поддержку или развитие проекта.
Недостатки:
– Негибкость к изменениям – изменения в требованиях после старта работы над проектом могут оказаться дорогостоящими и сложными в реализации.
– Отсутствие обратной связи от пользователя – до завершения проекта нельзя понять, насколько он будет валидирован конечными пользователями, есть риск заметно не удовлетворить их потребности.
– Риск на поздних этапах – модель не предполагает возврата на предыдущие уровни, а значит, ошибки, обнаруженные на стадии тестирования, могут дорого обойтись.
Этапы:
– Сбор и анализ требований. Цель этого этапа – выявить требования пользователей к будущей системе и впоследствии создать её подробное описание.
– Системное проектирование – на этом этапе определяют архитектуру проекта и высокоуровневые компоненты.
– Детальное проектирование – создание подробных спецификаций на основе требований к каждому компоненту системы.
– Кодирование и разработка – реализация программного обеспечения в соответствии со спецификациями.
– Тестирование – проверка программного обеспечения на соответствие спецификациям и поиск ошибок.
– Развертывание – внедрение системы в prod–окружение.
– Поддержка и обслуживание – поддержка работоспособности разработанного приложения и выполнение обновлений.
6.2.2. Spiral Model
Spiral Model – это подход разработки приложений итерациями, который сочетает в себе элементы Waterfall модели и прототипирования с акцентом на управлении рисками. Спиральная модель предназначена для больших сложных проектов с высокими рисками.
Особенности
– Итеративность – проект разделен на итерации (спирали), каждая из которых состоит из определения целей, анализа рисков, разработки и тестирования.
– Управление рисками – особое внимание уделяют анализу рисков на ранних этапах каждой итерации. Это позволяет предотвратить или минимизировать влияние рисков на проект.
– Гибкость – изменения можно вносить на любом этапе разработки.
– Прототипирование – создание схематичных образов будущих компонентов системы, что сокращает неопределенности и позволяет проверить концепции до их реализации.
Преимущества:
– Эффективное управление рисками – проблемы выявляют на ранних этапах, что снижает риски для проекта.
– Гибкость в изменениях – подход позволяет быстрее и эффективнее адаптироваться под потребности заказчиков.
– Подходит для больших и сложных проектов, где трудно определить все требования заранее.
– Инкрементальная доставка – получая конечный продукт по частям, заказчик может на ранних стадиях проекта использовать их и оценить удовлетворенность.
Недостатки:
– Сложность управления – большое количество этапов и итераций затрудняет управление проектом.
– Высокая стоимость – анализ рисков и прототипирование с каждой итерацией увеличивают стоимость проекта.
– Требуется опыт – сложно качественно руководить проектом без опыта в управлении рисками и проектами.
Этапы на каждой итерации:
– Определение целей – происходит сбор требований и определение целей спирали (инкремента).
– Анализ рисков – выполняется идентификация, анализ и разработка стратегий для минимизации рисков в этой итерации.
– Реализация и тестирование – разработка, а затем тестирование прототипа или части продукта на основе анализа рисков и требований.
– Планирование следующей итерации – оценка результатов текущей итерации и планирование следующих шагов для реализации проекта.
6.2.3. V–Model
V–Model – расширение Waterfall модели с акцентом на важности тестирования в каждом этапе разработки. Модель подходит для проектов, в которых требования ясны с самого начала и маловероятно будут меняться. Наиболее полезна в областях с высокими требованиями к надежности и безопасности, например авиационная и автомобильная промышленности, где тестирование на каждом этапе разработки особенно необходимо.
Особенности:
– Симметричность – каждому этапу разработки на левой стороне «V» соответствует этап тестирования на правой стороне. Это делает модель и ее акцент понятными.
– Раннее включение тестирования – тестирование стартует с ранних этапов разработки.
– Четкая структура – этапы выполняют последовательно с четко определенными входами и выходами.
Преимущества:
– Улучшенное качество – благодаря раннему планированию и включению тестирования, а также четкому соответствию этапам разработки, возможно улучшить качество конечного продукта.
– Ясность процесса – простая и четкая структура, а также соответствие этапов разработки этапам тестирования обеспечивают прозрачность.
– Эффективное выявление ошибок – V–образность модели помогает обнаруживать и устранять ошибки на ранних этапах разработки.
Недостатки:
– Негибкость – после старта проекта данная модель имеет ограниченную гибкость в плане изменения требований.
– Риск пропуска ошибок – пропущенные на этапе разработки ошибки могут остаться незамеченными до соответствующего этапа тестирования.
– Затраты на изменения – внесение изменений после начала процесса тестирования может быть дорогостоящим из–за необходимости возвращаться к предыдущим этапам разработки.
Этапы:
– Определение требований – установление функциональных и нефункциональных требований, которые необходимо реализовать.
– Системное проектирование – определение высокоуровневых абстракций, таких как технологии, которые будут использовать; архитектура системы и ее дизайн.
– Архитектурное проектирование – разработка модулей системы и архитектуры компонентов, включая способы взаимодействия.
– Модульное проектирование – более глубокое и подробное проектирование отдельных модулей системы и компонентов.
– Реализация – разработка системы по созданным ранее абстракциям архитектурного и модульного проектирования.
– Модульное тестирование – проверка того, что отдельные модули соответствуют ранее разработанному дизайну и требованиям.
– Интеграционное тестирование – проверка взаимодействия между компонентами и модулями системы.
– Системное тестирование – проверка системы целиком на соответствие требованиям.
– Приемочное тестирование – включает в себя валидацию готового проекта и проверку готовности для работы с конечными пользователями.
6.2.4. Iterative and Incremental Development
Iterative and Incremental Development включает в себя элементы итеративного и инкрементального подходов. То есть, когда программное обеспечение развивается повторяющимися итерациями (циклами), при этом добавляя каждый раз некоторую часть продукта к имеющейся. Такую модель можно считать довольно сбалансированной. Она позволяет разработке быстрее адаптироваться к меняющимся требованиям, которые в свою очередь имеют некоторую неопределенность.
Особенности:
– Итерации – весь проект делится на определенное множество итераций. Каждая из них по сути мини–проект, в котором есть собственный цикл планирования, анализа, разработки и тестирования.
– Инкременты – каждый инкремент это созданное в ходе итерации улучшение существующего продукта или добавление новой функциональности.
– Гибкость – модель можно считать гибкой, так как она позволяет вносить в проект изменения и корректировки на основе обратной связи от заинтересованных сторон или пользователей.
Преимущества:
– Гибкость к изменениям требований – модель позволяет вносить изменения в требования во время разработки, что увеличивает релевантность конечного продукта.
– Ранняя доставка ценности – каждая итерация создает работающий продукт, а значит, заинтересованные стороны смогут раньше увидеть и оценить результаты разработки и внести изменения в требования.
– Улучшенное управление рисками – при каждой итерации проводят анализ и тестирование, что позволяет идентифицировать и устранять риски на ранних этапах разработки, тем самым сократив расходы на разработку.
– Постепенное улучшение – получение обратной связи после каждой итерации, что дает возможность своевременно улучшать качество продукта.
Недостатки:
– Управление и планирование – это касается по большей части крупных проектов, где сложно дать качественную координацию итераций и инкрементов. Модель требует эффективного планирования и управления.
– Затраты на изменения – несмотря на то, что модель гибка к изменениям, стоит учитывать, что частые изменения требований или их множественное добавление могут увеличить денежные и временные затраты на разработку.
Каждая итерация повторяет одни и те же этапы (цикл разработки), однако модель не имеет строгих этапов, но абстрактно они могут выглядеть так:
– Планирование – определяются цели и задачи для текущей итерации, определяются требования, которые необходимо реализовать и сроки.
– Анализ требований и проектирование – проводится анализ новых требований или изменений в существующих, выполняется проектирование системы для их последующей реализации.
– Реализация – доработка существующей функциональности в продукте или разработка новой.
– Тестирование – проверка созданных в продукте изменений.
– Оценка – демонстрация работы всем заинтересованным сторонам или пользователям с целью получить обратную связь, в ходе которой могут быть собраны новые требования или изменения к существующим.
6.2.5. Agile Software Development
Agile Software Development – представляет собой набор принципов для разработки программного обеспечения, который поддерживает создание продуктов через регулярное, итерационное сотрудничество между самоорганизующимися кросс–функциональными командами. Популярный выбор команд разработки, следующих главной цели Agile – удовлетворение потребности клиента через раннюю и непрерывную поставку ценного программного обеспечения.
Особенности:
– При итерационном и инкрементальном подходе используют короткие итерации (циклы), в результате которых приносится новый инкремент в разрабатываемый продукт. Позволяет быстро адаптироваться к изменениям.
– Сотрудничество с клиентом – в процессе разработки активно участвует заказчик или клиент, что обеспечивает своевременную обратную связь и корректировку требований.
– Работающий продукт – главным приоритетом является доставка работающего программного обеспечения, которое можно регулярно и часто обновлять.
– Гибкость и адаптивность – допустимы изменения в проекте даже на поздних этапах разработки.
Преимущества:
– Улучшенное удовлетворение клиента – постоянная и частая обратная связь даёт больше удовлетворенности в конечном продукте.
– Повышенная адаптивность к изменениям – легкая и очень гибкая способность адаптироваться под новые тренды рынка или требования.
– Более быстрая доставка продукта – короткие итерации обеспечивают более ранний выход на рынок и ускоряют возврат средств.
– Повышение качества продукта – тестирование и оценку проводят в каждой итерации, что помогает обнаруживать и устранять ошибки на ранних стадиях.
Недостатки:
– Трудности с масштабированием – в больших организациях или проектах могут возникать трудности с использованием этой методологии.
– Неопределенность в планировании и бюджете – гибкость вызывает неопределенность сроков и объемов работ, что может вызвать непредвиденное удорожание продукта.
– Требование активного участия клиента – для эффективности требуется активное участие клиента, что не всегда возможно организовать в принципе или организовать качественно.
Этапы:
– Планирование – определение целей и задач для итерации на основе приоритетов и обратной связи от клиента.
– Разработка – в неё входят сразу проектирование, разработка приложения и выполнение тестирования.
– Демонстрация – показ получившегося в ходе итерации инкремента для получения обратной связи и корректировки дальнейших планов.
– Ретроспектива – мероприятие, при котором анализируют прошедшую итерацию. Это позволяет найти новые точки роста или возможностей, а также улучшить существующие процессы.
6.2.6. Extreme Programming
Extreme Programming – это гибкая методология разработки программного обеспечения. Ее цель: адаптируясь к изменениям требований, выпускать качественный продукт. Она основана на высоком уровне коммуникаций, простоте и лучших практиках разработки программного обеспечения.
Особенности:
– Тесное взаимодействие с клиентом – ему позволено активно участвовать в разработке, таким образом улучшая понимание требований и увеличивая удовлетворенность продуктом.
– Итерации – при разработке используют короткие итерации. Это позволяет быстрее адаптироваться к изменениям в требованиях и минимизировать риски выполнения ненужной работы.
– Парное программирование – код пишется в парах, что повышает его качество и упрощает обмен знаниями внутри команды.
– Разработка через тестирование – сначала для новой функциональности пишут тесты, а затем код, который должен их проходить.
– Непрерывная интеграция – разработанный код регулярно интегрируют и тестируют для выявления и устранения ошибок как можно раньше.
– Рефакторинг – регулярное улучшение кода для его упрощения и увеличения читаемости, а также расширяемости.
Преимущества:
– Гибкость к изменениям требований – их можно вносить даже на последних этапах разработки, что делает ее очень гибкой.
– Высокое качество продукта – применяемые эффективные подходы в разработке позволяют сократить ошибки до появления приложения у пользователей и получить качественный продукт.
– Эффективное общение в команде – используемые подходы разработки делают общение в команде достаточно тесным и эффективным.
– Ускорение процесса разработки – за счет непрерывной интеграции и регулярных релизов ускоряется получение обратной связи.
Недостатки:
– Не всегда подходит для больших команд – эффективность таких практик разработки как парное программирование может заметно снизиться в больших командах.
– Необходимость строгой дисциплины – применяемые практики разработки приложений эффективны при их жестком соблюдении, что могут делать не все команды.
– Может оказаться избыточным для небольших проектов – часть практик разработки могут оказаться явно избыточными для простых или довольно краткосрочных проектов.
Этапы:
– Планирование – выбор пользовательских историй для текущей итерации.
– Проектирование – простое верхнеуровневое проектирование изменений в системе.
– Кодирование – разработка пользовательских историй с использованием техник через тестирование, парное программирование и непрерывную интеграцию.
– Тестирование – проверка функционала и изменений автоматизированными тестами.
– Рефакторинг – улучшение существующего кода без изменения его функциональности.
6.2.7. Scrum
Scrum – популярный в разработке программного обеспечения гибкий фреймворк для управления проектами. В его основе итерационно–инкрементальная разработка, где работа над проектом делится на итерации (спринты). Он ориентирован на постоянное улучшение, сотрудничество и подходит для проектов, где необходима быстрая реакция на изменения.
Особенности:
– Роли – все участники команды играют одну из трёх ключевых ролей: Владелец Продукта (Product Owner), Скрам–мастер (Scrum Master) и Команда разработки (Development Team).
– Спринты – работа над проектом делится на итерации с фиксированной длинной (обычно от 2 до 4 недель), в течение спринтов команда создает и доставляет инкременты продукта.
– События Scrum – мероприятия для координации работы команды. Включают ежедневные встречи, планирование, обзор и ретроспективу спринта.
– Артефакты Scrum – важные элементы для достижения глобальных целей. Основные артефакты это Бэклог Продукта, Бэклог Спринта и Инкремент.
Преимущества:
– Гибкость и адаптивность – позволяет быстро и эффективно вносить изменения в продукт на основе обратной связи.
– Повышенная производительность – структура работы четкая, а спринты короткие. Это позволяет командам сосредоточиться на одной или нескольких небольших целях.
– Прозрачность процесса – регулярные встречи и оценки делают работу всех участников команды прозрачной и видимой.
– Ранняя доставка ценности – ценные для пользователя инкременты доставляют часто и в виде работающего продукта.
Недостатки:
– Зависимость от самоорганизации команды – для эффективной работы требуется высокий уровень самодисциплины и самоорганизации всех участников команды, что не всегда легко достижимо.
– Необходимость активного участия владельца продукта – эффективность фреймворка падает, если владелец продукта не уделяет достаточно времени исполнению своей роли.
– Сложность масштабирования – несмотря на существование фреймворков, таких как SAFe, Scrum сложно использовать в больших компаниях или проектах.
Этапы (События Scrum):
– Планирование Спринта – команда выбирает задачи из Бэклога Продукта для включения в Спринт, определяет цель спринта, планирует работу.
– Ежедневные Scrum встречи – короткое собрание участников команды для обсуждения текущего прогресса и планирования работы на следующий день.
– Обзор Спринта – встреча для демонстрации достигнутых за спринт результатов всем заинтересованным сторонам с целью получить обратную связь.
– Ретроспектива Спринта – мероприятие, на котором проводят анализ работы команды в течение спринта, для выявления возможностей улучшения процесса и решения проблем.