Что такое SDLC?
Жизненный цикл разработки ПО (SDLC) — это фреймворк, определяющий процесс планирования, создания, тестирования и развёртывания ПО. Разные модели SDLC описывают разные подходы к организации этих активностей.
Понимание моделей SDLC необходимо тестировщикам, потому что ваш подход к тестированию определяется моделью разработки, которой следует ваша команда. Тестирование в Waterfall-проекте принципиально отличается от тестирования в Agile-проекте.
В этом уроке мы рассмотрим старейшую и наиболее структурированную модель SDLC: Waterfall.
Модель Waterfall
Модель Waterfall впервые описана Уинстоном Ройсом в 1970 году (хотя, по иронии, Ройс представил её как пример ущербного подхода). Несмотря на это, она стала доминирующей методологией на десятилетия.
Waterfall — последовательная, линейная модель. Каждая фаза должна быть полностью завершена до начала следующей. Как вода, падающая каскадом, прогресс течёт в одном направлении — вниз.
Что строить] --> D[Проектирование
Как строить] D --> I[Реализация
Строительство] I --> T[Тестирование
Проверка работоспособности] T --> Dep[Развёртывание
Выпуск] Dep --> M[Сопровождение
Поддержка] style R fill:#3b82f6,color:#fff style D fill:#6366f1,color:#fff style I fill:#8b5cf6,color:#fff style T fill:#a855f7,color:#fff style Dep fill:#d946ef,color:#fff style M fill:#ec4899,color:#fff
Шесть фаз
1. Требования
Проект начинается со сбора и документирования всех требований. Бизнес-аналитики, продакт-менеджеры и заинтересованные стороны определяют, что должна делать система. Результат — детальная спецификация требований (SRS).
Участие QA: Тестировщики проверяют требования на тестируемость, полноту, непротиворечивость и двусмысленность. Начинают писать тест-планы.
2. Проектирование
Архитекторы и старшие разработчики проектируют систему на основе требований. Включает архитектуру, схемы БД, контракты API, UI-вайрфреймы и выбор технологий.
Участие QA: Тестировщики проверяют проектную документацию и начинают разработку тест-кейсов. Тест-архитекторы планируют тестовую среду.
3. Реализация (кодирование)
Разработчики пишут код по спецификации проектирования. Обычно это самая длинная фаза. Формальное тестирование зарезервировано для следующей фазы.
Участие QA: Ограниченное. Тестировщики финализируют тест-кейсы, готовят тестовые данные и настраивают среды.
4. Тестирование
После завершения реализации система передаётся команде тестирования. Тестировщики выполняют тест-кейсы, проводят интеграционное и системное тестирование, сообщают о дефектах. Разработчики исправляют баги, тестировщики перепроверяют.
Участие QA: Основная активная фаза QA-команды. Выполняются все запланированные тесты, регистрируются дефекты, готовится итоговый отчёт.
5. Развёртывание
После завершения тестирования продукт разворачивается в продакшене. Может включать приёмочное тестирование (UAT).
Участие QA: Smoke-тестирование в продакшене, мониторинг проблем.
6. Сопровождение
После развёртывания команда обеспечивает поддержку — исправляет баги от пользователей, выпускает патчи и иногда добавляет функциональность.
Участие QA: Регрессионное тестирование для каждого релиза, проверка исправлений.
Преимущества Waterfall
Чёткая структура и вехи. Каждая фаза имеет определённые поставки и критерии выхода. Руководство легко отслеживает прогресс.
Полная документация. Waterfall создаёт детальную документацию на каждом этапе. Ценно для compliance, адаптации новых сотрудников и долгосрочного сопровождения.
Предсказуемые сроки и бюджеты. Поскольку все требования определены заранее, легче оценивать затраты и сроки.
Хорошо работает для регулируемых отраслей. Медицинские устройства (FDA), авиация (DO-178C), оборонка и государственные контракты часто требуют трассируемости, которую Waterfall обеспечивает естественно.
Прост для понимания и управления. Линейная природа делает Waterfall интуитивным.
Недостатки Waterfall
Позднее тестирование. Главная проблема для QA: тестирование происходит в конце. Фундаментальные ошибки проектирования обнаруживаются поздно, когда их исправление крайне дорого.
Отсутствие работающего ПО до поздних этапов. Заинтересованные стороны не видят работающий продукт до фазы тестирования или развёртывания.
Плохая работа с изменениями. Waterfall предполагает, что требования полны и стабильны с самого начала. В реальности потребности бизнеса меняются.
Интеграция «большим взрывом». Все компоненты интегрируются сразу в фазе тестирования, что затрудняет изоляцию проблем.
Высокий риск. Критическая ошибка в требованиях, не обнаруженная до тестирования, может потребовать значительной переработки всего проекта.
Как тестирование вписывается в Waterfall
| Фаза | Активность QA | Поставка |
|---|---|---|
| Требования | Ревью требований, написание тест-плана | Тест-план |
| Проектирование | Ревью дизайна, проектирование тест-кейсов | Тест-кейсы |
| Реализация | Подготовка среды, финализация тестовых данных | Среда, данные |
| Тестирование | Выполнение тестов, отчёты о дефектах, ретест | Отчёт о выполнении, дефекты |
| Развёртывание | Smoke-тестирование, поддержка UAT | Отчёт о верификации |
| Сопровождение | Регрессионное тестирование | Отчёт о регрессии |
Сжатие фазы тестирования
Известная проблема Waterfall: фаза тестирования сжимается. Разработка затягивается (почти всегда), но дедлайн развёртывания остаётся фиксированным. Результат: фаза тестирования — изначально запланированная на 4 недели — сжимается до 2.
Это давление приводит к:
- Сниженному покрытию тестами
- Приоритизации только happy-path
- Пропуску нефункционального тестирования (производительность, безопасность)
- Переработкам тестировщиков
- Откладыванию багов вместо исправления
Этот паттерн — одна из главных мотиваций перехода к итеративным и Agile-моделям.
Когда Waterfall работает хорошо
Несмотря на ограничения, Waterfall подходит в определённых контекстах:
- Проекты регуляторного соответствия, где документация и трассируемость обязательны
- Интеграция железа и ПО, где компоненты имеют длительные сроки производства
- Хорошо изученные домены со стабильными, документированными требованиями
- Контракты с фиксированной ценой, где объём должен быть определён до разработки
- Небольшие проекты с ясными, простыми требованиями
Упражнение: определите проблемы Waterfall
Прочитайте кейс и определите минимум 5 проблем, вызванных использованием Waterfall:
Кейс: система управления пациентами в больнице
Больница заключила контракт на разработку системы управления пациентами по модели Waterfall:
- Месяц 1-2: Требования собраны от администраторов (врачи и медсёстры не участвовали)
- Месяц 3-4: Система спроектирована с desktop-first интерфейсом
- Месяц 5-8: Разработка завершена
- Месяц 9-10: Начато тестирование — найдено 47 критических багов, включая экраны, требующие 25+ кликов для типичных задач
- Месяц 10: Администраторы впервые увидели систему и запросили 30+ изменений
- Месяц 11: Дедлайн. Система развёрнута с известными дефектами. Медсёстры отказались использовать, заявив, что бумага быстрее.
Подсказка
Учтите: вовлечение стейкхолдеров, качество требований, позднюю обратную связь, время тестирования и принятие пользователями.Решение
Неполное вовлечение стейкхолдеров: Опрошены только администраторы. Врачи и медсёстры — основные пользователи — исключены. Это практически гарантировало несоответствие потребностям.
Отсутствие ранней валидации: Прототипы не показывались реальным пользователям до месяца 10. Десять месяцев работы на основе допущений.
Позднее тестирование обнаружило фундаментальные проблемы: 47 критических багов и 25+ кликов указывают на проблемы уровня дизайна. Найдены слишком поздно.
Изменения требований были неизбежны, но не запланированы: 30+ запрошенных изменений на месяце 10 были предсказуемы.
Сжатие фазы тестирования: Фаза сжата при приближении дедлайна, что привело к выпуску с известными дефектами.
Отсутствие итеративной обратной связи: Рабочий прототип на месяце 4 обнаружил бы проблемы на 6 месяцев раньше.
Неверное допущение desktop-first: Медперсонал перемещается между постами. Desktop-first подход, вероятно, был ошибочным, но это допущение было заложено на этапе проектирования.
Итеративный подход обнаружил бы большинство проблем в первые 2-3 месяца.
Профессиональные советы
Совет 1: Даже в Waterfall настаивайте на ранних активностях тестирования. Вы не можете контролировать модель SDLC, но можете продвигать ревью требований, ревью дизайна и раннее прототипирование.
Совет 2: Документируйте всё — это сила Waterfall. В Waterfall полная документация — не накладные расходы, а преимущество. Пишите тщательные тест-планы, детальные тест-кейсы и полные отчёты о дефектах.
Совет 3: Отстаивайте время на тестирование в плане проекта. На Waterfall-проекте боритесь за достаточное время тестирования на этапе планирования. После фиксации расписания именно фаза тестирования будет сжата.
Ключевые выводы
- Waterfall — последовательная модель SDLC, где каждая фаза должна завершиться до начала следующей
- Шесть фаз: Требования, Проектирование, Реализация, Тестирование, Развёртывание, Сопровождение
- Тестирование сконцентрировано в выделенной фазе после реализации — главная слабость для QA
- Waterfall хорош для регулируемых отраслей, фиксированных контрактов и проектов со стабильными требованиями
- Фаза тестирования рутинно сжимается при задержках разработки
- Несмотря на ограничения, принципы Waterfall (документация, трассируемость) ценны даже в Agile