SDLC и модели разработки

Тема дорожной карты · QA-инженер

Модели SDLC — это структурированные фреймворки, определяющие, как программное обеспечение планируется, проектируется, разрабатывается, тестируется и поддерживается, и выбор модели напрямую влияет на тестовую стратегию и инструментарий QA-команды. Классическая модель Waterfall предполагает отдельную фазу тестирования после завершения разработки, что подходит для проектов с фиксированными требованиями, но задерживает обнаружение дефектов; V-модель сопоставляет каждую фазу разработки с соответствующим уровнем тестирования (юнит, интеграционный, системный, приёмочный), делая QA-активности явными с самого начала. Современные Agile SDLC-модели — Scrum, Kanban, SAFe — встраивают QA в короткие спринты доставки, реализуя практики shift-left, где TDD, BDD с Cucumber и Gherkin, а также автоматизированные CI/CD-пайплайны (Jenkins, GitHub Actions, Docker) обеспечивают непрерывную обратную связь. Понимание моделей SDLC необходимо QA-инженерам, поскольку модель определяет, как структурируются тест-планы, тестовые стратегии и процессы управления дефектами, и как инструменты Selenium, JMeter, Allure и TestRail вписываются в жизненный цикл доставки.

Как это работает

SDLC и модели разработки — это дисциплина поиска дефектов + повышения качества ПО. Активности: анализ требований, планирование тестов, тест-дизайн, исполнение тестов, отчёты о дефектах + трекинг, регрессионное тестирование, верификация релиза. Уровни тестирования: unit (на разработчике), integration (границы компонентов), system (end-to-end), acceptance (user-facing). Современный QA сочетает ручное исследование с автоматическим regression. QA-мышление: каждое предположение подозрительно, у каждого input есть граница.

Когда применять

Встраивайте QA с начала проекта — качество-задним-числом всегда стоит дороже, чем встроенное. Используйте пирамиду тестирования как ориентир: много unit-тестов (быстрые, дешёвые), меньше integration, ещё меньше E2E (медленные, хрупкие). Для ранних стадий exploratory testing находит больше багов, чем сценарная regression — автоматизируйте после стабилизации фичи. ISTQB Foundation даёт общий словарь команде.

Типичные ошибки

Ловушки SDLC и модели разработки: QA как "тыкать кнопки до поломки" вместо анализа рисков + дизайна тестов; гонка за 100% покрытием кода (line coverage не значит behaviour coverage); обвинение QA при production-сбое ("вы должны были поймать" — большинство багов системные, не QA-detectable); незнание доменной области (QA, не понимающий бизнес, пропускает важные баги).

Связанные понятия

Полезные ресурсы

Проверить знания (1)

Загрузка вопросов…