SDLC vs STLC: понимание процессов разработки и тестирования

TL;DR

• SDLC — фреймворк для всего процесса создания ПО, от концепции до поддержки
• STLC — структурированный подход к тестировочным активностям внутри SDLC
• STLC не отделён от SDLC: он начинается уже на этапе анализа требований
• В Agile оба цикла сжаты в спринты; в Waterfall — последовательные фазы

Время чтения: 12 минут

Согласно глоссарию ISTQB, SDLC определяет полный набор фаз планирования, создания, тестирования и поставки ПО, а STLC описывает последовательность тестировочных активностей внутри этих фаз. На практике они неразделимы: отчёт SmartBear State of Software Quality 2025 показал, что 61% QA-команд по-прежнему рассматривают тестирование как позднюю стадию, а не интегрируют его на всём протяжении SDLC — а это напрямую коррелирует с более высоким дефектным просачиванием и более длинными циклами выпуска. Понимание того, как SDLC и STLC соотносятся друг с другом, — не просто теория: это определяет, как рано ты находишь баги, сколько доработок делает команда и где QA находится в организационной иерархии. В Agile-окружении различие становится ещё важнее: тестировщики, понимающие SDLC, могут аргументированно добиваться shift-left практик, раннего участия в ревью дизайна и полноценного времени на планирование тестов. В этом руководстве мы разберём оба цикла по фазам и сопоставим их с контекстами Waterfall, V-Model, Agile и DevOps.

Что такое SDLC (Software Development Life Cycle) #

SDLC (Software Development Life Cycle) — это структурированный процесс разработки программного обеспечения, который описывает этапы создания ПО от концепции до завершения поддержки.

Зачем нужен SDLC #

1. Структурированность — чёткое понимание, что делать на каждом этапе
2. Предсказуемость — возможность планировать сроки и ресурсы
3. Качество — встроенные механизмы контроля качества на каждом этапе
4. Снижение рисков — раннее выявление проблем
5. Эффективность — оптимизация процессов и минимизация переделок
6. Коммуникация — общий язык для всей команды

Классические этапы SDLC #

Независимо от методологии, SDLC обычно включает следующие фазы (хотя их названия и порядок могут варьироваться):

1. Planning (Планирование) #

Цель: Определить объём проекта, ресурсы, сроки и бюджет.

Основные активности:

• Определение бизнес-целей и требований
• Feasibility study (оценка осуществимости)
• Анализ рисков
• Формирование команды
• Создание project charter
• Оценка стоимости и сроков

Выходные артефакты:

• Project plan
• Resource allocation document
• Risk assessment report
• Budget estimation

Роль QA:

• Участие в оценке рисков
• Планирование тестовых ресурсов
• Оценка тестовых усилий
• Предоставление input по quality requirements

2. Requirements Analysis (Анализ требований) #

Цель: Детальное понимание того, что нужно разработать.

Основные активности:

• Сбор бизнес-требований от stakeholders
• Документирование функциональных требований
• Определение нефункциональных требований (performance, security (как обсуждается в Bug Anatomy: From Discovery to Resolution), usability)
• Создание use cases и user stories
• Приоритизация требований
• Получение approval от stakeholders

Выходные артефакты:

• Business Requirements Document (BRD)
• Software Requirements Specification (SRS)
• Use cases
• User stories
• Acceptance criteria

Роль QA:

• Review требований на полноту, ясность, testability
• Участие в requirement walkthrough
• Создание requirement traceability matrix
• Определение acceptance criteria
• Раннее выявление ambiguity и противоречий

QA вопросы на этом этапе:

• Требования testable?
• Все ли edge cases учтены?
• Есть ли противоречия между требованиями?
• Определены ли nonfunctional (как обсуждается в Dynamic Testing: Testing in Action) requirements?

3. Design (Проектирование) #

Цель: Определить архитектуру системы и дизайн компонентов.

Основные активности:

• High-level design (архитектура системы)
• Low-level design (детальный дизайн компонентов)
• Дизайн базы данных
• UI/UX дизайн
• API design
• Выбор технологического стека
• Design review

Выходные артефакты:

• High-Level Design (HLD) document
• Low-Level Design (LLD) document
• Database (как обсуждается в Continuous Testing in DevOps: Quality Gates and CI/CD Integration) schema
• API specifications
• UI mockups и wireframes
• Architecture diagrams

Роль QA:

• Review design документации
• Проверка testability архитектуры
• Планирование тестовой стратегии
• Проектирование тестового окружения
• Идентификация test data requirements
• Начало создания test plan

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

4. Implementation / Development (Реализация / Разработка) #

Цель: Написание кода согласно дизайну.

Основные активности:

• Написание кода
• Unit testing
• Code review
• Version control (git commits)
• Интеграция компонентов
• Continuous integration

Выходные артефакты:

• Source code
• Unit tests
• Build artifacts
• Technical documentation
• Code review notes

Роль QA:

• Подготовка тестовых данных
• Создание test cases и test scenarios
• Настройка test environments
• Разработка автотестов (если есть automation)
• Ранние smoke tests на dev билдах
• Участие в code reviews (в некоторых командах)

5. Testing (Тестирование) #

Цель: Выявление дефектов и проверка соответствия требованиям.

Основные активности:

• Выполнение различных видов тестирования:
  • Functional testing
  • Integration testing
  • System testing
  • Regression testing
  • Performance testing
  • Security testing
  • Usability testing
• Bug reporting и tracking
• Retesting и regression
• Test reporting

Выходные артефакты:

• Test execution reports
• Bug reports
• Test metrics
• Traceability matrix
• Sign-off для перехода к deployment

Роль QA:

• Основная фаза для QA
• Выполнение всех типов тестирования
• Баг-репортинг и отслеживание
• Координация с разработчиками
• Предоставление quality metrics

6. Deployment / Release (Развертывание / Релиз) #

Цель: Доставка продукта пользователям.

Основные активности:

• Подготовка production environment
• Final smoke testing
• Deployment в production
• Monitoring
• Rollback plan готовность
• Пользовательская документация

Выходные артефакты:

• Released product
• Release notes
• User documentation
• Deployment checklist
• Rollback procedure

Роль QA:

• Final smoke testing перед релизом
• Sanity testing после deployment
• Проверка critical paths в production
• Мониторинг production issues
• Участие в go/no-go decision

7. Maintenance (Поддержка) #

Цель: Исправление багов, обновления, улучшения.

Основные активности:

• Bug fixing
• Performance optimization
• Security patches
• Feature enhancements
• User support
• Monitoring и analytics

Выходные артефакты:

• Hotfixes
• Patch releases
• Updated documentation
• Performance reports

Роль QA:

• Тестирование hotfixes и patches
• Regression testing
• Мониторинг user-reported issues
• Анализ production metrics
• Continuous improvement процессов тестирования

Что такое STLC (Software Testing Life Cycle) #

STLC (Software Testing Life Cycle) — это последовательность шагов, выполняемых в процессе тестирования программного обеспечения. STLC является подмножеством SDLC и фокусируется исключительно на тестировании.

STLC vs SDLC: в чём разница #

Важно: STLC не начинается после завершения SDLC. Тестирование интегрировано во все фазы SDLC.

«Большинство проблем с позиционированием QA, которые я видел, возникают из-за того, что команды воспринимают STLC как нечто, начинающееся после разработки. Как только ты понимаешь, что твой цикл тестирования — это параллельный трек внутри цикла разработки, а не фаза после него, ты получаешь возможность влиять на требования, выявлять риски в дизайне и реально предотвращать дефекты, а не просто находить их.» — Юрий Кан, Senior QA Lead

Фазы STLC #

Для полного понимания того, как тестирование интегрируется на разных этапах, см. наше руководство по уровням тестирования.

Phase 1: Requirement Analysis (Анализ требований) #

Цель: Понять, что будет тестироваться.

Активности:

• Изучение требований (BRD, SRS, user stories)
• Идентификация testable requirements
• Requirement review meetings
• Определение scope тестирования
• Идентификация различных типов тестирования
• Подготовка Requirement Traceability Matrix (RTM)

Entry Criteria:

• Требования документированы
• Доступ к requirements документам
• Stakeholders доступны для clarifications

Exit Criteria:

• RTM создана
• Automation feasibility определена
• Все вопросы по требованиям resolved

Deliverables:

• RTM (Requirement Traceability Matrix)
• Automation feasibility report
• List of questions/clarifications

Phase 2: Test Planning (Планирование тестирования) #

Цель: Определить стратегию и ресурсы для тестирования.

Активности:

• Подготовка Test Plan
• Определение test strategy
• Оценка усилий (effort estimation)
• Выбор инструментов тестирования
• Определение ролей и ответственности
• Risk assessment для тестирования
• Планирование test environment

Entry Criteria:

• Требования проанализированы
• RTM готова

Exit Criteria:

• Test Plan утверждён
• Effort estimation завершена
• Resources allocated

Deliverables:

• Test Plan document
• Test Strategy document
• Effort estimation document

Test Plan включает:

• Test scope (что тестировать, что не тестировать)
• Test approach (виды тестирования)
• Roles and responsibilities
• Test schedule
• Entry/exit criteria для каждой фазы
• Risk mitigation plan
• Test deliverables

Phase 3: Test Case Development (Разработка тест-кейсов) #

Цель: Создать детальные test cases и test data.

Активности:

• Написание test cases
• Создание test scripts (для automation)
• Review test cases
• Создание/получение test data
• Приоритизация test cases
• Создание traceability между requirements и test cases

Entry Criteria:

• Test plan утверждён
• Требования доступны и stable
• RTM создана

Exit Criteria:

• Все test cases написаны и reviewed
• Test data prepared
• Traceability matrix обновлена

Deliverables:

• Test cases
• Test scripts (для automation)
• Test data
• Updated RTM

Хороший test case включает:

• Test case ID
• Test description
• Preconditions
• Test steps
• Test data
• Expected result
• Actual result (заполняется при выполнении)
• Status
• Priority

Phase 4: Test Environment Setup (Настройка тестового окружения) #

Цель: Подготовить окружение для выполнения тестов.

Активности:

• Настройка test environment (hardware, software, network)
• Подготовка test data в базе данных
• Настройка инструментов тестирования
• Smoke test окружения
• Получение test builds

Entry Criteria:

• Test plan готов
• Test environment design document готов

Exit Criteria:

• Test environment готово
• Smoke test пройден
• Test data загружена

Deliverables:

• Test environment ready для использования
• Smoke test results

Phase 5: Test Execution (Выполнение тестирования) #

Цель: Выполнить test cases и найти дефекты.

Активности:

• Выполнение test cases согласно плану
• Сравнение actual results с expected
• Logging defects для failed tests
• Retesting defects после исправления
• Regression testing
• Обновление test case status
• Test execution tracking

Entry Criteria:

• Test environment готово
• Test cases готовы
• Build готов для тестирования
• Smoke test passed

Exit Criteria:

• Все запланированные test cases выполнены
• Critical и high bugs исправлены и retested
• Regression testing завершено
• Exit criteria из test plan выполнены

Deliverables:

• Test execution reports
• Defect reports
• Updated test cases (если нужно)
• Test logs

Типы тестирования на этой фазе:

• Smoke testing
• Functional testing
• Integration testing
• System testing
• Regression testing
• Exploratory testing
• Non-functional testing (performance, security, usability)

Phase 6: Test Cycle Closure (Завершение цикла тестирования) #

Цель: Оценить completeness тестирования и собрать learnings.

Активности:

• Сбор test artifacts
• Анализ test metrics
• Подготовка test summary report
• Lessons learned встреча
• Идентификация лучших практик
• Архивирование test artifacts

Entry Criteria:

• Test execution завершено
• Все critical bugs закрыты
• Regression testing завершено

Exit Criteria:

• Test closure report готов
• Sign-off от stakeholders получен

Deliverables:

• Test closure report
• Test metrics
• Lessons learned document
• Best practices documentation

Test Metrics включают:

• Total test cases vs. executed
• Pass/Fail percentage
• Defect density
• Defect leakage
• Test coverage
• Test execution velocity

Методологии разработки и место тестирования #

Waterfall Model (Каскадная модель) #

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

Фазы: Requirements → Design → Implementation → Testing → Deployment → Maintenance

Характеристики:

• Строгая последовательность фаз
• Невозможно вернуться к предыдущей фазе
• Тестирование — отдельная фаза после разработки
• Обширная документация
• Фиксированные требования

Место тестирования в Waterfall:

• Testing — отдельная, поздняя фаза
• QA вовлечены в requirement review, но основная работа — после coding
• Длительный тестовый цикл
• Высокий риск нахождения критичных багов на поздних этапах

Плюсы для QA:

• Чёткие требования
• Полная документация
• Достаточно времени для тщательного тестирования
• Легко планировать ресурсы

Минусы для QA:

• Позднее обнаружение дефектов (дорого исправлять)
• Мало гибкости для изменений
• Если пропустили баг, откатывать дорого
• Долгий feedback loop

Когда используется:

• Проекты с чётко определёнными, stable требованиями
• Regulated industries (медицина, финансы)
• Проекты с фиксированным scope и timeline

V-Model (Verification and Validation Model) #

Описание: Расширение Waterfall, где для каждой фазы разработки существует соответствующая фаза тестирования.

Структура:

Requirements ←→ Acceptance Testing
System Design ←→ System Testing
Architecture Design ←→ Integration Testing
Module Design ←→ Unit Testing
      ↓
  Implementation

Характеристики:

• Тестирование планируется параллельно с разработкой
• Для каждого этапа разработки — соответствующий этап тестирования
• Verification (Are we building the product right?) и Validation (Are we building the right product?)
• Тестовые артефакты создаются рано

Место тестирования в V-Model:

• QA вовлечены с самого начала
• Test planning начинается на фазе requirements
• Test case design параллельно с design фазой
• Test execution после implementation

Mapping фаз:

• Requirements Analysis → Acceptance Test Planning
  • User Acceptance Tests (UAT)
  • Business requirement verification
• System Design → System Test Planning
  • End-to-end testing
  • Functional и non-functional testing
• High-Level Design → Integration Test Planning
  • Module interactions testing
  • API testing
• Low-Level Design → Unit Test Planning
  • Individual component testing
  • Developer-driven testing

Плюсы для QA:

• Раннее вовлечение QA
• Дефекты находятся раньше (дешевле исправлять)
• Чёткая корреляция между разработкой и тестированием
• Лучшая test coverage

Минусы для QA:

• Всё ещё негибкая модель
• Трудно адаптироваться к изменениям
• Требует обширной документации

Когда используется:

• Safety-critical systems (automotive, aerospace, medical)
• Проекты с чёткими, stable требованиями
• Regulated industries

Agile Methodology (Гибкая методология) #

Описание: Итеративный и инкрементальный подход, где разработка ведётся короткими циклами (sprints).

Принципы Agile:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Характеристики:

• Короткие итерации (обычно 1-4 недели)
• Continuous feedback
• Self-organizing teams
• Тесная коллаборация
• Адаптация к изменениям

Место тестирования в Agile:

• Testing — непрерывный процесс внутри каждого спринта
• QA — полноценный член команды, а не отдельная фаза
• Тестировщики работают параллельно с разработчиками
• Continuous testing и continuous integration

Agile Testing Quadrants (Brian Marick):

Business-Facing                     Technology-Facing

Q2: Functional Tests         |     Q1: Unit Tests
- Manual/Exploratory         |     - Automated
- User Stories               |     - Component Tests
- Examples/Scenarios         |     - API Tests
Support Programming          |     Support Programming
--------------------------------|---------------------------
Q3: Usability Tests         |     Q4: Performance Tests
- Manual                     |     - Automated
- User Acceptance           |     - Load Tests
- A/B Testing               |     - Security Tests
Critique Product            |     Critique Product

QA в Agile Sprint:

Day 1-2 (Sprint Planning):

• Участие в planning
• Clarification требований
• Estimation testing effort
• Defining acceptance criteria
• Planning testing approach

Day 3-8 (Development + Testing):

• Тестирование готовых user stories
• Exploratory testing
• Regression testing
• Bug reporting и retesting
• Automation test creation/update
• Постоянная коммуникация с devs

Day 9-10 (Sprint End):

• Final regression
• Demo участие
• Retrospective участие
• Test metrics подготовка
• Planning для следующего спринта

Плюсы для QA:

• Раннее и continuous testing
• Быстрый feedback loop
• Defects исправляются в том же sprint
• Тесная коллаборация с командой
• Гибкость и адаптивность

Минусы для QA:

• Меньше документации (может быть unclear)
• Сжатые timelines (давление)
• Нужно быть multitasking (testing + automation + communication)
• Regression может накапливаться
• Требует высокого уровня automation

Agile фреймворки:

Scrum:

• Sprints (обычно 2 недели)
• Roles: Product Owner, Scrum Master, Development Team (включая QA)
• Ceremonies: Sprint Planning, Daily Standup, Sprint Review, Retrospective
• Artifacts: Product Backlog, Sprint Backlog, Increment

Kanban:

• Continuous flow (нет sprints)
• Work In Progress (WIP) limits
• Visual board
• Pull-based system

Когда используется Agile:

• Стартапы и dynamic environments
• Проекты с меняющимися требованиями
• Продукты, требующие быстрого time-to-market
• Web applications, mobile apps

DevOps и Continuous Testing #

DevOps объединяет Development и Operations для ускорения delivery.

Ключевые практики:

• Continuous Integration (CI)
• Continuous Delivery (CD)
• Infrastructure as Code
• Monitoring and Logging
• Collaboration culture

Место тестирования в DevOps:

Shift-Left Testing — тестирование смещается влево (раньше в SDLC):

• Unit tests пишут разработчики
• API tests автоматизированы
• Integration tests в CI/CD pipeline
• Static code analysis

CI/CD Pipeline с тестированием:

Code Commit → Build → Unit Tests → Integration Tests → Deploy to Staging →
Smoke Tests → Regression Tests → Deploy to Production → Monitoring

Автоматизация в DevOps:

• 70-80% test coverage автоматизация
• Fast feedback (minutes, not hours)
• Tests запускаются на каждый commit
• Failed tests блокируют deployment

QA роль в DevOps:

• Создание и поддержка automated tests
• Настройка CI/CD pipelines для testing
• Monitoring production (observability)
• Performance и security testing
• Exploratory testing для новой функциональности

Выбор методологии: сравнительная таблица #

Best Practices для QA в разных методологиях #

Для любой методологии: #

1. Ранее вовлечение — участвуйте в requirement analysis
2. Requirement review — проверяйте testability требований
3. Test planning — планируйте заранее
4. Risk-based testing — фокусируйтесь на критичных областях
5. Clear communication — четко коммуницируйте статус и риски
6. Metrics tracking — отслеживайте quality metrics
7. Continuous learning — учитесь на ошибках

Специфично для Waterfall/V-Model: #

• Инвестируйте время в подробную документацию
• Comprehensive test coverage planning
• Тщательная requirement analysis
• Формальные sign-offs на каждом этапе

Специфично для Agile/DevOps: #

• Automation first — автоматизируйте всё, что можно
• Continuous testing — тестируйте постоянно, а не в конце
• Shift-left — находите баги как можно раньше
• Collaboration — работайте тесно с devs
• Exploratory testing — не полагайтесь только на scripted tests
• Fast feedback — давайте быструю обратную связь

Заключение #

Понимание SDLC и STLC, а также различных методологий разработки — это не просто теория. Это практическое знание, которое определяет, как вы будете работать каждый день:

Ключевые выводы:

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

2. Методология определяет роль QA. В Waterfall вы тестируете в конце, в Agile — постоянно, в DevOps — автоматизируете и мониторите production.

3. Нет универсального подхода. Waterfall может быть правильным выбором для regulated industries, Agile — для стартапов, V-Model — для critical systems.

4. Раннее вовлечение QA критично важно независимо от методологии. Чем раньше вы находите дефекты, тем дешевле их исправление.

5. Автоматизация — не опция в современном мире, особенно в Agile и DevOps. Manual testing не масштабируется.

6. Адаптация — ключевой навык. Методологии эволюционируют, гибридные подходы (Water-Scrum-Fall, например) существуют. Важно понимать принципы и адаптировать их к контексту команды.

7. Testing — это не фаза, это mindset. Качество — это ответственность всей команды, а не только QA-отдела.

Успешный QA-специалист не только знает теорию SDLC и STLC, но и умеет применять эти знания в реальной работе, адаптируясь к методологии команды и постоянно улучшая процессы тестирования.

Следующие шаги:

• Изучите 7 принципов тестирования по ISTQB для глубокого понимания основ
• Определите, какая методология используется в вашей команде
• Оцените, где тестирование в вашем SDLC может начинаться раньше
• Исследуйте возможности автоматизации в вашем проекте

Официальные ресурсы #

• Глоссарий ISTQB — определения SDLC и STLC
• Программа ISTQB Foundation Level
• SmartBear State of Software Quality 2025
• Стандарт IEEE 829 для документации тестирования

See Also #

• Ad-hoc vs Monkey Testing: понимание хаотичных подходов к тестированию- Верификация vs Валидация: V&V в Тестировании ПО - Создание правильного продукта vs правильное создание продукта: статическое vs…
• Узнайте различия между ad-hoc и monkey testing, когда использовать…
• Критерии входа и выхода в тестировании: когда начинать и заканчивать тестирование - Освойте критерии входа и выхода для определения четких границ фаз…
• Непрерывное Тестирование в DevOps: Quality Gates и Интеграция CI/CD - Интеграция тестирования в DevOps: CI/CD пайплайны, стратегия…
• Dynamic Testing: тестирование в действии - Изучите техники динамического тестирования, где код выполняется…