Shift-Left-тестирование

Updated Jul 2026

Что такое Shift-Left?

Shift-Left означает перенос тестовых активностей на более ранние этапы жизненного цикла разработки. Вместо обнаружения багов после написания кода -- предотвращать их до написания кода. Чем раньше обнаружен дефект, тем дешевле его исправить.

Традиционный:   Требования → Дизайн → Код → Тест → Деплой
                                                ↑
                                          Тестирование начинается здесь

Shift-Left:      Требования → Дизайн → Код → Деплой
                      ↑              ↑         ↑
                      |              |         |
                   Ревью          Ревью    Юнит-тесты
                   критериев      тестируемости  во время
                   с QA           с QA        разработки

Стоимость позднего обнаружения багов

Стоимость исправления бага растёт экспоненциально с каждым последующим этапом обнаружения:

Отсутствующее правило валидации, обнаруженное при ревью требований, стоит 15 минут на исправление. Та же отсутствующая валидация, обнаруженная в продакшене через уязвимость безопасности, обходится в тысячи долларов и месяцы устранения последствий.

Практические Shift-Left-активности

Ревью требований

QA ревьюирует пользовательские истории до планирования спринта, отмечая неоднозначности и пропущенные граничные случаи.

На что обращать внимание:

• Размытые критерии приёмки («система должна быть быстрой»)
• Отсутствующая обработка ошибок («что происходит, когда API недоступен?»)
• Неопределённые граничные условия («каков максимальный размер файла?»)
• Отсутствующие нефункциональные требования (производительность, доступность, безопасность)
• Конфликтующие требования с существующими фичами

До ревью QA:

«Как пользователь, я хочу загрузить фото профиля.»

После ревью QA (заданные вопросы):

• Какие форматы файлов принимаются?
• Каков максимальный размер файла?
• Что происходит при сбое загрузки?
• Есть ли минимальное разрешение?
• Должна ли фотография быть обрезана до квадрата?
• Что с существующим фото -- сохраняется ли оно при ошибке?

После уточнения:

«Как пользователь, я хочу загрузить фото профиля (JPEG, PNG или WebP, макс 5МБ, мин 100x100px). Система должна обрезать до квадрата, показать превью перед сохранением и отобразить понятное сообщение об ошибке, если файл слишком большой, неправильного формата или слишком маленький. Существующее фото должно сохраняться при сбое загрузки.»

Уточнённая история имеет тестируемые критерии. Оригинал -- нет.

Сессии Three Amigos

Разработчик + QA + Владелец продукта встречаются до начала работы для согласования критериев приёмки. (См. отдельный раздел Three Amigos.)

Разработка через тестирование (TDD)

Разработчики пишут тесты до реализации. Тест определяет ожидаемое поведение, а код пишется для прохождения теста.

1. Написать падающий тест (Red)
2. Написать минимальный код для прохождения (Green)
3. Рефакторить код, сохраняя зелёные тесты (Refactor)

Роль QA в TDD: QA не пишет юнит-тесты (это делают разработчики), но QA может:

• Ревьюировать TDD-тесты для проверки покрытия правильных сценариев
• Предлагать граничные случаи, которые тесты разработчика должны покрывать
• Проверять, что TDD-тесты соответствуют критериям приёмки

Статический анализ

Линтеры, проверщики типов и сканеры безопасности выявляют проблемы до запуска тестов. Эти инструменты обеспечивают немедленную обратную связь в IDE разработчика и в CI-пайплайнах.

Парное тестирование

QA работает в паре с разработчиком во время реализации, выявляя проблемы в реальном времени.

Как работает парное тестирование:

1. Разработчик реализует фичу, QA наблюдает
2. QA задаёт вопросы: «Что будет, если я нажму сюда во время загрузки?» «Что, если это поле пустое?»
3. Разработчик устраняет проблемы немедленно (до коммита)
4. Оба согласовывают, что должны покрывать автоматизированные тесты

Когда парное тестирование наиболее ценно:

• Сложные фичи со множеством граничных случаев
• Фичи со значительными последствиями для безопасности или финансов
• Новые члены команды, изучающие кодовую базу
• Восстановление доверия после серии инцидентов в продакшене

Shift-Left на практике: таймлайн спринта

День 1 (Планирование спринта):
  QA ревьюирует истории, задаёт уточняющие вопросы, определяет зависимости

День 2-3:
  Сессии Three Amigos для высокоприоритетных историй
  QA пишет черновые тест-кейсы из критериев приёмки
  QA готовит тестовые данные и окружение

День 4-7:
  Разработчики реализуют фичи
  QA ревьюирует PR по мере написания кода (не после)
  QA запускает автоматизированные тесты на фича-ветках
  Парное тестирование на сложных фичах

День 8-9:
  Исследовательское тестирование на завершённых фичах
  Полный регрессионный прогон

День 10 (Конец спринта):
  Обзор спринта с метриками качества
  Ретроспектива с инсайтами shift-left

Обратите внимание, что QA активен с первого дня, а не ждёт до 7-го, когда «код готов к тестированию».

Измерение эффективности Shift-Left

Отслеживайте эти метрики для проверки работоспособности shift-left:

Типичное сопротивление и как его преодолеть

Практическое упражнение

1. Выберите 3 истории из следующего спринта и проведите их ревью на тестируемость до планирования
2. Посетите (или организуйте) сессию three amigos для истории с наибольшим риском
3. Напишите тест-кейсы из критериев приёмки до начала разработки
4. Проведите 1 час парного тестирования с разработчиком во время реализации и отметьте, сколько проблем вы обнаружите в реальном времени
5. Измерьте процент дефектов, найденных на каждом этапе (требования, разработка, тестирование, продакшен) за последние 3 спринта