Как идёт процесс по Waterfall

Процесс разработки по методологии Waterfall («Водопад»)

Waterfall — это классическая линейно-последовательная методология разработки ПО, где весь процесс разделён на строго определённые этапы, следующие друг за другом без возвратов на предыдущие шаги (в идеальной модели). Каждый этап должен быть полностью завершён до начала следующего, а результаты этапа закрепляются в виде документации.

---

Ключевые фазы процесса

Обычно процесс включает 5-7 основных этапов, которые идут строго один за другим:

1. Сбор и анализ требований (Requirements Gathering & Analysis):

    *   На этом этапе происходит глубокая работа с заказчиком и стейкхолдерами. **Аналитики** и **бизнес-аналитики** выявляют, документируют и согласовывают **все** функциональные и нефункциональные требования к будущему продукту. Цель — создать полный и неизменный спецификационный документ.
    *   **Роль QA:** QA-инженер может участвовать в ревью требований на предмет тестируемости, полноты, непротиворечивости и отсутствия двусмысленностей.

1. Проектирование системы (System Design):

    *   На основе утверждённых требований архитекторы и разработчики создают техническое проектирование системы. Этот этап делится на:
        *   **Высокоуровневое проектирование (High-Level Design):** Архитектура системы, выбор технологий, модульная структура.
        *   **Детальное проектирование (Low-Level Design):** Спецификации для каждого модуля, схемы баз данных, интерфейсы.
    *   **Роль QA:** Начинается работа над **стратегией тестирования** и создаются **макеты тестовых сценариев** на основе архитектурных документов.

1. Реализация (Implementation / Coding):

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

1. Тестирование (Testing):

    *   Это ключевой и, как правило, **самый длительный этап в Waterfall для QA-команды**. После завершения разработки **всё** созданное ПО передаётся тестировщикам.
    *   QA-инженеры выполняют полный цикл тестирования на основе ранее подготовленных артефактов:
        *   **Модульное тестирование** (часто ответственность разработчиков).
        *   **Интеграционное тестирование**.
        *   **Системное тестирование** (функциональное, нефункциональное: нагрузочное, безопасность и т.д.).
        *   **Приёмочное тестирование** (UAT) с участием заказчика.
    *   Все найденные дефекты документируются, передаются на исправление, и после фикса — на ретест. Этап считается завершённым, когда продукт соответствует всем требованиям и достигнут приемлемый уровень качества.

1. Внедрение и сопровождение (Deployment & Maintenance):

    *   Готовый продукт разворачивается на production-окружении и передаётся заказчику/пользователям.
    *   Далее начинается этап **сопровождения**, который может включать исправление критических багов, обнаруженных в реальной эксплуатации, выпуск небольших улучшений или патчей. Любые существенные изменения требуют запуска **нового цикла Waterfall** с самого начала.

graph TD
    A[Сбор и анализ<br>требований] --> B[Проектирование<br>системы]
    B --> C[Реализация / Кодирование]
    C --> D[Тестирование]
    D --> E[Внедрение и<br>сопровождение]

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style D fill:#ccf,stroke:#333,stroke-width:4px

---

Особенности QA в Waterfall с точки зрения инженера

• «Большой взрыв» в тестировании: Тестирование начинается только после полной разработки. Это создаёт огромную нагрузку на QA-команду в конце цикла, когда сроки уже часто «горят».
• Жёсткая документация: Тест-план — это ключевой и обязательный документ. От него зависит вся деятельность QA. Тест-кейсы пишутся максимально подробно, часто вручную, так как они служат не только для проверки, но и как документация на продукт.
• Реактивная, а не превентивная роль: QA-инженер в классическом Waterfall выступает скорее как «приёмщик» и контролёр качества готового кода, а не как активный участник его создания. Основные методики — это сценарное (кейсовое) и документальное тестирование.
• Высокие риски: Если требования были неверно поняты или изменились (что почти неизбежно в реальных проектах), ошибка обнаруживается только на этапе тестирования или внедрения. Её исправление крайне дорого и может потребовать перепроектирования всей системы.
• Отсутствие гибкости: Процесс плохо адаптируется к изменениям. Предполагается, что требования, согласованные на первом этапе, останутся неизменными до конца проекта.

---

Когда Waterfall может быть оправдан для QA?

Несмотря на критику, Waterfall имеет право на жизнь в проектах с:

• Чёткими, фиксированными и неизменными требованиями (например, в оборонной или космической промышленности).
• • Жёсткими регуляторными стандартами, требующими полной документации каждого шага (медицина, фарма, банковские системы).
• Очень маленькими и простыми проектами с понятным результатом.

Вывод: Работа QA в Waterfall — это структурированный, предсказуемый, но часто напряжённый процесс с фокусом на документацию и финальное, объёмное тестирование. Современная тенденция смещается к гибким методологиям (Agile, DevOps), где тестирование интегрировано в цикл разработки на ранних этапах, что делает роль QA более проактивной и эффективной. Однако понимание Waterfall критически важно, так как многие его принципы (планирование, документация) лежат в основе процессов тестирования в любой методологии.