3. SDLC и STLC
🧭 Введение: почему без SDLC/STLC QA работает вслепую
Когда junior QA только начинает, часто кажется, что тестирование это просто «получил задачу -> проверил -> завёл баг». На практике этого недостаточно. Если не понимать, где задача находится в жизненном цикле, легко пропустить риск, проверить не то и дать команде слабый результат.
SDLC и STLC дают QA рабочую карту: что происходит на каждом этапе разработки, когда и как подключается тестирование, какой результат нужно отдать команде.
💡 Совет:
Перед любой проверкой задайте себе вопрос: «На каком этапе SDLC/STLC мы сейчас находимся?»
✅ Вывод:
SDLC и STLC нужны junior QA, чтобы тестировать осознанно, а не хаотично.
⚠️ Проблема -> решение
Без понимания SDLC/STLC команда сталкивается с типичной болью: требования расплывчатые, тестирование позднее, дефекты всплывают перед релизом, а fixes становятся дорогими. QA в такой модели превращается в «пожарного» на финальной прямой.
Решение — встроить тестирование в общий жизненный цикл разработки: QA участвует раньше, критерии приёмки уточняются до кода, риски фиксируются заранее, релизные решения принимаются по фактам.
🟢 Если совсем просто:
SDLC показывает путь продукта, STLC показывает путь тестирования внутри этого пути.
🎯 Как понять, что этап прошёл успешно:
У команды есть понятные этапы, входы/выходы этапов и прогнозируемый результат качества.
🛠️ Чем помогает и как работает
SDLC/STLC помогают синхронизировать QA, Dev, BA и PO вокруг общего процесса качества. Это снижает количество «сюрпризов» в конце спринта и повышает предсказуемость релизов.
Как это работает:
- Шаг 1: Команда фиксирует этап SDLC для задачи (требования, разработка, тестирование, релиз и т.д.).
- Шаг 2: QA определяет текущий этап STLC и ожидаемый артефакт (план, сценарии, отчёт, риск-сводка).
- Шаг 3: QA проверяет, что входные данные этапа готовы (например, есть критерии приёмки).
- Шаг 4: QA выполняет действия этапа и фиксирует результат в понятном формате.
- Шаг 5: Команда принимает решение о переходе на следующий этап на основе фактов.
✅ Вывод:
SDLC/STLC превращают тестирование из «набора действий» в управляемый процесс качества.
🧱 Почему junior не любит SDLC/STLC — и почему это ошибка
У начинающего QA часто возникает сопротивление этой теме. Это нормально: в начале хочется быстрее «тестировать руками», а не разбираться в циклах и этапах.
Что обычно думают junior:
- «Это слишком теоретично».
- «В первый месяц от этого мало пользы».
- «Лучше сразу пойти в execution и искать баги».
Почему это ошибка:
- Без SDLC/STLC QA не видит контекст задачи.
- Без контекста QA задаёт слабые вопросы по требованиям.
- Без этапов QA плохо приоритизирует проверки.
- Без этапов QA даёт размытую релизную оценку.
✅ Вывод:
SDLC/STLC не тормозят практику, а делают её точной и полезной для команды.
📅 Как это помогает каждый день
Эта тема полезна не «когда-нибудь потом», а в ежедневных рабочих задачах.
Практический эффект на каждый день:
- Понял этап -> понял, что именно сейчас от тебя ждут.
- Понял этап -> не начинаешь execution, когда требования ещё сырые.
- Понял этап -> не пропускаешь test design и подготовку данных.
- Понял этап -> можешь объяснить команде, что именно сейчас не готово.
- Понял этап -> увереннее защищаешь релизное решение на фактах.
✅ Вывод:
Понимание SDLC/STLC экономит время, снижает ошибки приоритезации и делает QA-вклад заметным уже с первых месяцев работы.
📚 Ключевые термины (простыми словами)
- SDLC (Software Development Life Cycle, жизненный цикл разработки ПО) — общий путь создания и поддержки продукта.
- STLC (Software Testing Life Cycle, жизненный цикл тестирования) — этапы тестирования внутри разработки.
- Requirement Analysis (анализ требований) — проверка, что требования понятны и тестопригодны.
- Test Planning (планирование тестирования) — определение объёма, рисков, подхода и ресурсов тестирования.
- Test Design (проектирование тестов) — подготовка сценариев, тест-кейсов и тестовых данных.
- Test Execution (выполнение тестов) — запуск проверок и фиксация фактических результатов.
- Test Closure (закрытие тестирования) — итоговый отчёт: что проверено, что найдено, какие риски остались.
1. SDLC: как продукт проходит путь от идеи до поддержки
SDLC это общий контур разработки. Для QA важно понимать не только этап «testing», а весь путь целиком. Тогда проще понимать, где возникают риски и как их предупредить.
🟢 Если совсем просто:
SDLC это дорожная карта жизни фичи.
🎯 Как понять, что этап прошёл успешно:
У каждого этапа есть понятный вход, выход и ответственный результат.
Назначение:
Сделать процесс разработки предсказуемым и управляемым.
Простыми словами:
SDLC показывает, что продукт не появляется «в один шаг»: он проходит серию этапов, на каждом из которых можно потерять качество или укрепить его.
Для новичка:
Если вы знаете этап SDLC, вы понимаете, что именно сейчас важно проверить: требования, реализацию или релизный риск.
Аналогия:
SDLC как строительство дома: сначала проект, потом стройка, потом проверка, потом заселение и обслуживание.
Пример:
Типичный SDLC-поток:1) Requirements2) Design3) Development4) Testing5) Release6) Maintenance🔎 Как это происходит на практике:
- На этапе требований команда договаривается, что именно строит.
- На этапе разработки реализует договорённость.
- На этапе тестирования проверяет соответствие договорённости и реализации.
- На этапе релиза принимает решение по рискам.
Характеристики:
- ✅ SDLC охватывает весь продуктовый цикл.
- ✅ QA участвует не только в «testing», но и в этапах до него.
- ✅ Чем раньше выявлен дефект, тем дешевле исправление.
Когда использовать:
Всегда, когда нужно объяснить контекст задачи и синхронизировать работу ролей в команде.
✅ Вывод:
Понимание SDLC помогает QA видеть корень проблемы, а не только её симптомы.
2. STLC: как QA системно ведёт тестирование
STLC это рабочая схема самого тестирования. Она отвечает на вопрос «что делает QA шаг за шагом». Без STLC тестирование легко становится случайным набором проверок.
🟢 Если совсем просто:
STLC это план работы QA от анализа требований до итогового отчёта.
🎯 Как понять, что этап прошёл успешно:
По каждому этапу STLC есть конкретный артефакт: план, сценарии, результаты и финальный вывод.
Назначение:
Сделать тестирование воспроизводимым и измеримым.
Простыми словами:
STLC задаёт порядок действий QA, чтобы не пропускать важные шаги.
Для новичка:
Если не знаете, с чего начать тестирование, начните с этапов STLC и двигайтесь последовательно.
Аналогия:
STLC как чек-лист пилота перед полётом: порядок действий защищает от критичных пропусков.
Пример:
Типичный STLC-поток:1) Requirement Analysis2) Test Planning3) Test Design4) Environment Setup5) Test Execution6) Test Closure🔎 Как это происходит на практике:
- QA анализирует требования на проверяемость.
- QA планирует объём и риски тестирования.
- QA готовит сценарии и данные.
- QA выполняет проверки и фиксирует дефекты.
- QA закрывает цикл итоговым отчётом и рекомендацией по релизу.
Характеристики:
- ✅ STLC фокусируется на действиях QA.
- ✅ Результаты STLC используются для релизных решений.
- ✅ STLC встроен в SDLC, а не существует отдельно.
Когда использовать:
При планировании тестирования любой новой фичи, регресса и релиза.
✅ Вывод:
STLC делает тестирование процессом, а не набором случайных проверок.
3. Связь SDLC и STLC: где именно QA подключается
Одна из частых ошибок junior: воспринимать SDLC и STLC как «две отдельные теории». На практике STLC это тестовый поток, встроенный в SDLC. QA работает на нескольких этапах SDLC, а не только в конце.
🟢 Если совсем просто:
SDLC это большой путь продукта, STLC это тестовый маршрут внутри него.
🎯 Как понять, что этап прошёл успешно:
Команда понимает, какой этап STLC соответствует текущему этапу SDLC.
Назначение:
Убрать разрыв между разработкой и тестированием.
Простыми словами:
QA должен понимать, что его действия привязаны к общему циклу разработки и влияют на переход между этапами.
Для новичка:
Если вы получили задачу «на тест», сначала уточните: это первый прогон, ретест или релизный прогон. Это разные этапы STLC.
Пример:
Маппинг SDLC -> STLC:Requirements -> Requirement AnalysisDevelopment -> Test Design + Environment SetupTesting -> Test ExecutionRelease -> Test Closure + Risk Summary🔎 Как это происходит на практике:
- Во время refinement QA уже запускает Requirement Analysis.
- Пока Dev пишет код, QA готовит тесты и данные.
- Перед релизом QA даёт тестовый итог и риск-карту.
Характеристики:
- ✅ QA включается раньше этапа выполнения тестов.
- ✅ STLC-артефакты помогают принимать решения по SDLC-этапам.
- ✅ Связка SDLC/STLC снижает late defects.
Когда использовать:
Когда команда хочет уменьшить число дефектов на финальных этапах и ускорить релиз.
✅ Вывод:
Качество растёт, когда SDLC и STLC работают как единая система.
4. Артефакты STLC: что QA должен уметь отдавать команде
Сильный QA отличается не только количеством проверок, но и качеством артефактов. Команда должна получать от QA понятные документы и выводы, с которыми можно работать.
🟢 Если совсем просто:
Артефакты QA это рабочие документы, которые двигают задачу вперёд.
🎯 Как понять, что этап прошёл успешно:
По артефактам QA команда без дополнительных пояснений понимает состояние качества.
Назначение:
Обеспечить прозрачную передачу результата тестирования между ролями.
Простыми словами:
Если QA-результат нельзя быстро понять и применить, он почти бесполезен.
Для новичка:
Не ограничивайтесь фразой «протестировано». Всегда отдавайте структуру: что проверено, что не проверено, какие риски остались.
Пример:
Базовый набор артефактов:- Test Plan- Test Scenarios/Test Cases- Bug Reports- Test Execution Report- Test Summary / Release Recommendation🔎 Как это происходит на практике:
- В начале цикла QA даёт план и scope.
- Во время выполнения QA обновляет статусы и дефекты.
- В конце QA отдаёт summary с рисками и рекомендацией.
Характеристики:
- ✅ Артефакты должны быть воспроизводимыми и короткими.
- ✅ Каждый артефакт должен отвечать на конкретный вопрос команды.
- ✅ Плохой формат артефактов замедляет triage и релизы.
Когда использовать:
Всегда, особенно в задачах с высоким риском: авторизация, оплата, профиль пользователя.
✅ Вывод:
Качественные артефакты STLC ускоряют фиксы и повышают предсказуемость релиза.
🔁 Сравнение: SDLC vs STLC
| Критерий | SDLC | STLC |
|---|---|---|
| Что описывает | Полный цикл разработки продукта | Цикл тестирования |
| Фокус | Бизнес и разработка в целом | Качество и проверка |
| Основной результат | Готовый продукт и его поддержка | Результат тестирования и риск-оценка |
| Кто участвует | Вся команда (BA, Dev, QA, PO, Ops) | В основном QA + тесное взаимодействие с командой |
| Где заканчивается | На поддержке/эволюции продукта | На closure и релизном summary |
✅ Must-Know
- SDLC и STLC не конкурируют: STLC встроен в SDLC.
- QA должен участвовать в задаче до этапа execution, минимум на анализе требований.
- В STLC важны не только тесты, но и артефакты: план, дефекты, итоговый отчёт.
- Воспроизводимость результата QA критична для команды.
- Релизное решение принимается по рискам, а не по количеству найденных багов.
- Отсутствие дефектов в отчёте не равно гарантии «всё идеально».
❌ Частые мифы
❌ Миф:
SDLC это только для менеджеров, QA достаточно знать STLC.
✅ Как правильно:
QA должен понимать оба цикла, потому что тестирование живёт внутри общего процесса разработки.
📎 Почему это важно:
Без контекста SDLC QA легко теряет приоритеты и проверяет не то, что критично для релиза.
❌ Миф:
STLC начинается только после полного завершения разработки.
✅ Как правильно:
STLC стартует с анализа требований и подготовки тестов, а не только с execution.
📎 Почему это важно:
Ранний старт QA снижает late defects и стоимость исправлений.
❌ Миф:
Если все тест-кейсы passed, релиз всегда безопасен.
✅ Как правильно:
Нужно учитывать открытые риски, покрытие сценариев и критичность оставшихся дефектов.
📎 Почему это важно:
Релизный риск может остаться даже при хорошем проценте passed.
❌ Миф:
Главная задача STLC это просто найти как можно больше багов.
✅ Как правильно:
Главная задача STLC — дать команде качественную, применимую оценку состояния продукта.
📎 Почему это важно:
Количество багов без контекста не помогает принимать правильные решения.
❓ Часто спрашивают на собеседованиях
❓ Вопрос: В чём простая разница между SDLC и STLC?
✅ Ответ: SDLC описывает весь цикл разработки продукта, а STLC описывает цикл тестирования внутри этого процесса.
❓ Вопрос: Почему QA должен знать SDLC, если он занимается тестированием?
✅ Ответ: Потому что без понимания общего цикла разработки QA не сможет правильно приоритизировать проверки и риски.
❓ Вопрос: С какого этапа начинается STLC?
✅ Ответ: С анализа требований, когда QA проверяет тестопригодность и уточняет критерии приёмки.
❓ Вопрос: Какие этапы STLC обычно называют базовыми?
✅ Ответ: Requirement Analysis, Test Planning, Test Design, Environment Setup, Test Execution и Test Closure.
❓ Вопрос: Что такое Test Closure и зачем он нужен?
✅ Ответ: Это финальный этап STLC, где QA фиксирует итоги тестирования, открытые риски и релизную рекомендацию.
❓ Вопрос: Можно ли считать релиз безопасным только по числу passed-кейсов?
✅ Ответ: Нет, важны ещё открытые критичные риски, покрытие сценариев и статус дефектов.
❓ Вопрос: Как SDLC/STLC помогают junior QA в ежедневной работе?
✅ Ответ: Они дают понятную структуру действий и помогают не теряться между требованиями, проверками и релизным выводом.
❓ Вопрос: Какая частая ошибка junior в теме SDLC/STLC?
✅ Ответ: Подключаться только на execution и пропускать этапы анализа требований и планирования.
⚠️ Типичные ошибки
Ошибка 1: путать SDLC и STLC как одно и то же
❌ Неправильно:
Говорить, что «SDLC это и есть тестирование».
✅ Правильно:
Разделять: SDLC = весь цикл разработки, STLC = цикл тестирования.
Почему:
Без разделения ролей теряется понимание ответственности и входов/выходов этапов.
Ошибка 2: начинать STLC только с execution
❌ Неправильно:
Ждать готовую фичу и только потом думать о тестировании.
✅ Правильно:
Стартовать с requirement analysis и test planning.
Почему:
Позднее включение QA увеличивает риск критичных дефектов перед релизом.
Ошибка 3: делать план тестирования «для галочки»
❌ Неправильно:
Писать Test Plan без scope, рисков и критериев выхода.
✅ Правильно:
Фиксировать в плане цель, объём, риски, подход и условия завершения тестирования.
Почему:
Без плана тестирование становится хаотичным и трудно прогнозируемым.
Ошибка 4: фокусироваться только на баг-логах
❌ Неправильно:
Передавать команде только список дефектов.
✅ Правильно:
Давать ещё и итоговый риск-свод с релизной рекомендацией.
Почему:
Команда принимает релизное решение по картине рисков, а не по количеству тикетов.
Ошибка 5: не делать test closure
❌ Неправильно:
Закончить execution и не зафиксировать итог.
✅ Правильно:
Всегда делать closure: что проверено, что открыто, что рекомендовано.
Почему:
Без closure теряется прозрачность качества перед релизом.
🧩 Best Practices
- Привязывайте каждую проверку к этапу STLC и бизнес-риску.
- Подключайтесь к задаче до кода: анализируйте требования и критерии.
- Ведите короткий, но живой Test Plan с реальными рисками.
- Делайте баг-репорты воспроизводимыми: environment + steps + expected/actual.
- Завершайте цикл test closure с явной релизной рекомендацией.
- На triage обсуждайте не «кто виноват», а влияние риска на пользователя.
🧭 Заключение
SDLC и STLC это базовая карта работы QA в команде. Она нужна не для теории, а для ежедневной практики: понимать контекст задачи, готовить проверяемые критерии, выполнять проверки по этапам и давать полезный релизный вывод.
Для junior главный ориентир простой: если вы понимаете, где задача в SDLC и какой шаг STLC сейчас выполняете, вы уже работаете как системный QA, а не как «кликер тестов».