SDLC и STLC: что должен знать QA на интервью

На собеседованиях QA-инженеров вопросы про SDLC и STLC встречаются почти всегда — и именно здесь многие кандидаты проваливаются не потому что не знают аббревиатур, а потому что отвечают шаблонно. Интервьюер слышит "требования, дизайн, разработка, тестирование, деплой" и понимает: человек выучил список, но не понимает, где в этой цепочке стоит QA и зачем вообще нужны две разные модели жизненного цикла.

Хороший ответ про SDLC и STLC — это не перечисление этапов, а объяснение того, как качество встраивается в процесс разработки с самого начала. Это и есть то, что проверяет интервьюер: понимает ли кандидат, что тестирование — не изолированная фаза в конце, а сквозная практика.

В этой статье разберём оба цикла по существу: что происходит на каждом этапе, какова роль QA, чем SDLC отличается от STLC, как выглядят разные модели (Waterfall, V-Model, Agile, Kanban) и что именно спросят на интервью — с развёрнутыми ответами.

1. SDLC — жизненный цикл разработки программного обеспечения

Software Development Life Cycle — это структурированный процесс, описывающий все этапы создания программного продукта: от идеи и сбора требований до вывода из эксплуатации. SDLC даёт командам общий язык и предсказуемость: что делается, в каком порядке, кто отвечает за результат на каждом шаге.

Классическая модель включает шесть фаз.

1.1 Requirements (Сбор требований)

Бизнес-аналитики и менеджеры продукта собирают и документируют требования: что система должна делать (функциональные требования) и при каких ограничениях (нефункциональные: производительность, безопасность, масштабируемость).

Роль QA. Именно здесь начинается shift-left: QA читает требования и ищет противоречия, неоднозначности, пропущенные сценарии. Вопросы вроде "а что происходит, если пользователь нажал кнопку дважды?" или "это требование конфликтует с требованием #34" — дешевле задать сейчас, чем исправлять после разработки. QA начинает набрасывать скелет Requirements Traceability Matrix (RTM).

1.2 System Design (Системное проектирование)

Архитекторы и техлиды переводят требования в архитектурные решения: выбор технологий, схема базы данных, API-контракты, разбиение на модули.

Роль QA. Тест-менеджер или старший QA изучают архитектуру и начинают формировать тест-стратегию: какие виды тестирования нужны (функциональное, интеграционное, нагрузочное), какие риски несёт выбранная архитектура, где нужна особая осторожность. Параллельно готовится Test Plan.

1.3 Implementation (Разработка)

Разработчики пишут код. Этап самый длинный и в классических моделях — изолированный.

Роль QA. QA разрабатывает тест-кейсы на основе утверждённых требований и дизайна (не дожидаясь готового кода), готовит тест-данные, настраивает тестовое окружение. В Agile-командах QA работает бок о бок с разработчиком прямо в спринте.

1.4 Testing (Тестирование)

Готовый продукт (или инкремент) передаётся QA для верификации и валидации.

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

1.5 Deployment (Развёртывание)

Продукт выкатывается в продакшн — поэтапно (canary, blue-green) или сразу.

Роль QA. Smoke-тестирование в продакшн-окружении, мониторинг первых часов после релиза, проверка что всё, что работало на staging, работает и в проде.

1.6 Maintenance (Сопровождение)

Исправление багов, выпуск патчей, работа с техническим долгом, улучшение производительности.

Роль QA. Регрессионное тестирование при каждом патче, анализ дефектов из продакшна, обновление тест-кейсов под изменения функциональности.

---

2. STLC — жизненный цикл тестирования

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

Каждая фаза STLC имеет Entry Criteria (что должно быть готово перед стартом) и Exit Criteria (что должно быть выполнено для завершения).

2.1 Requirement Analysis (Анализ требований)

QA изучает требования и выясняет, что вообще тестируемо, а что нет. Задача — понять продукт глазами тестировщика: какие функции критичны, какие риски несут требования, есть ли технические ограничения для тестирования.

• Entry: требования задокументированы, доступны QA-команде
• Exit: все требования проанализированы, testability оценена, RTM-заготовка создана, вопросы к бизнесу заданы

2.2 Test Planning (Планирование тестирования)

Тест-менеджер или сеньор QA разрабатывает Test Plan: определяет стратегию, scope (что тестируем, что нет), подходы (ручное/автоматизированное тестирование), ресурсы, инструменты, риски и сроки.

• Entry: требования проанализированы, RTM-заготовка готова
• Exit: Test Plan согласован и подписан всеми сторонами

2.3 Test Case Development (Разработка тест-кейсов)

Команда пишет тест-кейсы — детальные сценарии проверки функциональности. Параллельно готовятся тест-данные (seed-данные в БД, mock-ответы, файлы для загрузки). Готовые тест-кейсы проходят peer review.

• Entry: Test Plan утверждён, требования не изменились
• Exit: тест-кейсы написаны и прошли ревью, тест-данные готовы, RTM заполнена

2.4 Test Environment Setup (Подготовка окружения)

Разворачивается тестовое окружение: серверы, базы данных, интеграции с внешними сервисами (или их моки), CI/CD-пайплайны. После настройки выполняется smoke-тест окружения — проверяется, что оно вообще работает.

• Entry: тест-кейсы готовы, инфраструктура для окружения доступна
• Exit: окружение поднято, smoke-тест пройден, доступ у всех членов команды есть

2.5 Test Execution (Выполнение тестирования)

Основная фаза: прогон тест-кейсов, логирование результатов, создание баг-репортов на найденные дефекты, ретест исправленных дефектов, регрессионное тестирование.

• Entry: окружение готово, сборка задеплоена, тест-кейсы утверждены
• Exit: все запланированные тест-кейсы выполнены (или обоснованно заблокированы), критических и blocker-дефектов нет, метрики покрытия достигнуты

2.6 Test Closure (Закрытие тестирования)

Финальная фаза: оценка того, что было сделано. Команда составляет Test Closure Report — документ с метриками (сколько тест-кейсов выполнено, сколько дефектов найдено/закрыто/отложено), анализирует процесс, фиксирует lessons learned для следующих проектов.

• Entry: тестирование завершено, релизные критерии выполнены
• Exit: Test Closure Report готов и отправлен стейкхолдерам

---

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

Оба термина часто путают или считают синонимами. На самом деле STLC — подмножество SDLC, сфокусированное исключительно на quality assurance.

Ось сравнения	SDLC	STLC
Область охвата	Весь продукт: от идеи до вывода из эксплуатации	Только тестирование: от анализа требований до Test Closure
Участники	Весь проект: PM, BA, разработчики, QA, DevOps, архитекторы	Преимущественно QA-команда
Цель	Создать рабочий продукт, соответствующий требованиям бизнеса	Верифицировать и валидировать продукт, обеспечить качество
Артефакты	BRD, SRS, архитектурные схемы, код, деплой-конфиги	Test Plan, тест-кейсы, RTM, баг-репорты, Test Closure Report
Продолжительность	Весь срок жизни продукта	Определяется тестовыми активностями в рамках SDLC

Ключевой вывод: QA не просто участвует в STLC — он влияет на весь SDLC, если подключается с первой фазы.

---

4. Модели SDLC и роль QA в каждой

SDLC — это не одна конкретная методология, а класс подходов. Разные модели предполагают разный порядок фаз и разную степень вовлечённости QA.

4.1 Waterfall

Самая классическая модель: фазы идут строго последовательно, каждая завершается до начала следующей. Требования → Дизайн → Разработка → Тестирование → Деплой → Поддержка.

Роль QA в Waterfall — ждать. Тестирование начинается только после того, как разработка полностью завершена. Это означает, что дефекты в требованиях обнаруживаются поздно, их исправление дорого, а давление на QA-команду в конце проекта огромное.

Когда Waterfall имеет смысл: проекты с чёткими, неизменными требованиями (государственные контракты, встроенные системы, hardware-проекты, где изменения физически невозможны после определённой точки).

4.2 V-Model

V-Model — это эволюция Waterfall с одним принципиальным отличием: каждой фазе разработки соответствует зеркальная фаза тестирования.

Требования        ←→  Приёмочное тестирование (UAT)
  Системный дизайн    ←→  Системное тестирование
    Архитектурный дизайн  ←→  Интеграционное тестирование
      Детальный дизайн    ←→  Юнит-тестирование
              Кодирование (вершина V)

Левое плечо V — verification (верификация): делаем ли мы продукт правильно? Правое плечо — validation (валидация): делаем ли мы правильный продукт?

Ключевое преимущество V-Model перед Waterfall: тест-артефакты (тест-кейсы, тест-планы) готовятся параллельно с разработкой, а не после. Это сокращает время между разработкой и тестированием.

4.3 Agile/Scrum

В Agile нет отдельной фазы тестирования — QA встроен в каждый спринт. Команда кросс-функциональная: разработчик, QA, дизайнер работают вместе над одной пользовательской историей.

Как это выглядит на практике: QA участвует в груминге и refinement, помогает формулировать acceptance criteria, иногда ведёт сессии Three Amigos (BA + разработчик + QA обсуждают историю с трёх точек зрения). В спринте QA тестирует задачи по мере их готовности, не ждёт конца спринта. Definition of Done включает: код написан, покрыт тестами, тест-кейсы прошли, ревью пройдено.

Регрессия в Agile — непрерывная. Автоматизированные тест-сюиты запускаются в CI на каждый пуш или PR.

4.4 Kanban

Kanban — поток задач без фиксированных итераций. Задачи движутся по колонкам (To Do → In Progress → In Review → Testing → Done), и объём незавершённой работы ограничен WIP-лимитами.

QA в Kanban — это WIP-ограничение на колонке Testing: нельзя брать новые задачи, если предыдущие ещё не протестированы. Это создаёт pull-давление на разработчиков делать меньше работы одновременно.

5. Shift-Left Testing

Shift-Left Testing — один из главных принципов современного QA. Идея проста: сдвинуть тестирование как можно левее по временной шкале SDLC. Не ждать готового кода, а встраивать качество в процесс с самого начала.

За этим принципом стоит экономика дефектов. Исследования (в том числе NIST и IBM) показывают: исправление дефекта на этапе требований обходится в 1 условную единицу, на этапе дизайна — в 5–10, на этапе разработки — в 10–20, после релиза — в 100 и более. Каждый пропущенный этап умножает стоимость.

Практики Shift-Left:

QA на груминге. QA читает пользовательские истории до их попадания в спринт. Задаёт вопросы: "что если поле пустое?", "что произойдёт при одновременных запросах?", "какое поведение ожидается при отсутствии прав?". Ответы фиксируются в acceptance criteria.

Three Amigos. Короткая сессия перед стартом разработки истории: BA объясняет бизнес-ценность, разработчик — техническую реализацию, QA — как это будет тестироваться. Три точки зрения часто обнаруживают противоречия, которые каждый по отдельности не замечал.

Acceptance criteria до разработки. Criteria should be defined before coding starts, not after. Это даёт разработчику чёткую цель и QA — готовые тест-кейсы.

Статический анализ и ревью требований. QA участвует в ревью BRD/SRS так же, как разработчики участвуют в ревью кода. Дефект в документе дешевле найти при чтении, чем при тестировании реализованной функции.

Тест-кейсы раньше кода. В TDD и BDD (Behaviour-Driven Development) тесты пишутся до реализации. QA участвует в написании Gherkin-сценариев (Given/When/Then), которые одновременно служат спецификацией и автотестом.

---

6. Типичные вопросы на интервью

Разберём десять вопросов, которые чаще всего звучат на собеседованиях на позиции QA Engineer и QA Lead. Для каждого — развёрнутый ответ, а не просто определение.

Вопрос 1. Назовите этапы SDLC и STLC

Ответ: SDLC включает шесть фаз: Requirements, System Design, Implementation, Testing, Deployment, Maintenance. STLC — шесть фаз внутри тестирования: Requirement Analysis, Test Planning, Test Case Development, Test Environment Setup, Test Execution, Test Closure. STLC выполняется преимущественно на этапе Testing в SDLC, но в современных командах QA-активности начинаются с первого этапа SDLC.

Вопрос 2. Чем отличается SDLC от STLC?

Ответ: SDLC описывает весь жизненный цикл продукта и охватывает все роли команды. STLC — подмножество SDLC, которое описывает только тестовые активности. Если SDLC отвечает на вопрос "как создать продукт", то STLC — на вопрос "как убедиться, что продукт работает правильно".

Вопрос 3. Что такое V-Model? Чем отличается от Waterfall?

Ответ: V-Model — это модель SDLC, в которой каждой фазе разработки зеркально соответствует фаза тестирования. От Waterfall отличается тем, что тест-артефакты готовятся параллельно с разработкой: когда пишутся требования, одновременно планируется UAT; когда проектируется архитектура — готовятся интеграционные тесты. В Waterfall тестирование начинается только после завершения разработки. Ключевые концепции V-Model: verification (левое плечо, делаем ли мы продукт правильно) и validation (правое плечо, делаем ли мы правильный продукт).

Вопрос 4. На каком этапе SDLC QA должен подключаться?

Ответ: С первого этапа — с Requirements. Это и есть Shift-Left Testing. На этапе требований QA может найти противоречия, пропущенные сценарии, нетестируемые формулировки. На этапе дизайна — оценить архитектурные риски и начать тест-стратегию. Подключаться только на этапе Testing — это антипаттерн, который увеличивает стоимость исправления дефектов и снижает предсказуемость релиза.

Вопрос 5. Что такое Entry и Exit Criteria?

Ответ: Entry Criteria — условия, которые должны выполняться перед началом фазы STLC. Например, перед Test Execution: сборка задеплоена в тестовую среду, тест-кейсы прошли ревью, тест-данные подготовлены. Exit Criteria — условия завершения фазы. Например, для Test Execution: не менее 95% тест-кейсов выполнено, нет открытых критических дефектов, метрики покрытия достигнуты. Exit Criteria одной фазы становятся Entry Criteria следующей.

Вопрос 6. Что включает Test Plan?

Ответ: Test Plan — ключевой документ, определяющий стратегию тестирования. Стандарт IEEE 829 определяет такие секции: идентификатор и название, цели тестирования, scope (что в рамках, что за рамками), тест-стратегия и подходы, ресурсы (команда, инструменты, окружение), расписание и milestones, риски и contingency plan, Entry/Exit Criteria, метрики качества. На практике Test Plan может быть легковесным документом или вики-страницей — главное, чтобы команда и стейкхолдеры были выровнены по ожиданиям.

Вопрос 7. Что такое Test Closure Report?

Ответ: Test Closure Report — финальный документ фазы Test Closure, подводящий итоги тестирования. Включает: количество запланированных и выполненных тест-кейсов, статистику дефектов (найдено/исправлено/отложено/отклонено), процент покрытия требований, метрики производительности тест-процесса, отклонения от плана с объяснениями, оценку выполнения Exit Criteria и lessons learned. Адресован тест-менеджеру, PM, стейкхолдерам и служит входным документом для планирования следующего релиза.

Вопрос 8. Как тестирование в Agile отличается от Waterfall?

Ответ: В Waterfall тестирование — отдельная фаза после разработки, QA получает готовый продукт и тестирует его как единое целое. В Agile тестирование непрерывно: QA работает в спринте параллельно с разработчиками, тестирует инкременты по мере готовности, участвует в груминге и планировании. Нет чёткой границы "разработка закончилась — тестирование началось". Автоматизация в Agile — не опция, а необходимость: без неё регрессия на каждом спринте нереалистична.

Вопрос 9. Что такое Shift-Left Testing?

Ответ: Shift-Left Testing — подход, при котором тестовые активности начинаются как можно раньше в SDLC: QA участвует в анализе требований, груминге, Three Amigos, пишет acceptance criteria до старта разработки. Обоснование — экономика дефектов: исправить баг на этапе требований в 10–100 раз дешевле, чем в продакшне. На практике это означает, что QA должен читать PRD и задавать вопросы, а не ждать передачи задачи в тестирование.

Вопрос 10. Как составить RTM (Requirements Traceability Matrix)?

Ответ: RTM — таблица, которая связывает каждое требование с соответствующими тест-кейсами, гарантируя, что каждое требование покрыто тестами. Стандартные столбцы: ID требования, описание требования, ID тест-кейса(ов), статус выполнения тест-кейса, статус дефектов. RTM строится в несколько проходов: на этапе Requirement Analysis создаётся заготовка с требованиями, на Test Case Development добавляются ссылки на тест-кейсы, на Test Execution заполняется статус. RTM используется как инструмент coverage analysis: если строка без тест-кейса — требование не покрыто; если тест-кейс не привязан к требованию — тест избыточный или требование не задокументировано.

---

Итоги

Чтобы уверенно отвечать на вопросы по SDLC и STLC, нужно держать в голове несколько ключевых вещей.

SDLC — это про весь продукт: от требований до вывода из эксплуатации. STLC — это про тестирование внутри SDLC: шесть фаз с Entry/Exit Criteria. Каждая фаза STLC имеет конкретные артефакты и чёткие условия начала и завершения.

Роль QA в SDLC не ограничивается фазой Testing. Shift-Left означает присутствие QA с Requirements: вопросы к требованиям, участие в груминге, формулировка acceptance criteria — всё это QA-работа, которая снижает стоимость дефектов.

Разные модели SDLC предполагают разный режим работы QA. В Waterfall — последовательно, с риском позднего обнаружения дефектов. В V-Model — параллельно с разработкой по зеркальному принципу. В Agile — непрерывно, в составе кросс-функциональной команды.

На интервью ждут не списки этапов, а понимание того, зачем эти этапы существуют и как QA вписывается в каждый из них. Если вы можете объяснить, почему QA должен быть на груминге, что такое Entry/Exit Criteria и чем V-Model лучше Waterfall для тестирования — вы уже в топ-25% кандидатов.

Для закрепления темы советуем также прочитать нашу статью 50 вопросов на QA-интервью — там SDLC и STLC разобраны в контексте других тем тестирования.