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

Понимание жизненных циклов разработки (SDLC) и тестирования (STLC) — фундаментальная компетенция для QA-специалиста. Знание того, как устроены процессы создания ПО, на каких этапах включается тестирование и как разные методологии влияют на работу команды, критично важно для эффективной работы. В этом подробном руководстве мы разберём оба цикла, их взаимосвязь и применение в различных методологиях разработки.

Что такое 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.

Фазы 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 может начинаться раньше
• Исследуйте возможности автоматизации в вашем проекте