Что такое подход shift left в тестировании и как он применяется?

Что проверяют

Видите ли вы тестирование как часть разработки, а не как этап после кода. Для QA это вопрос про зрелость: кандидат, который двигает проверки влево, участвует в требованиях и в проектировании, а не ждёт готовую сборку.

Как отвечать

Shift left это перенос проверок ближе к началу жизненного цикла, чтобы дефект ловился там, где он ещё дёшев: в формулировке требования, а не в проде.

Что за этим стоит на практике:

• разбор требований и критериев приёмки до оценки задачи, совместный разбор примеров с аналитиком и разработчиком;
• тест-дизайн до написания кода: сценарии и тестовые данные готовы к моменту, когда задачу берут в работу;
• статический анализ, типы и линтеры в конвейере, проверки на этапе сборки;
• модульные и компонентные тесты пишут разработчики, QA помогает закрыть риски, а не дублирует их руками;
• контрактные тесты между сервисами вместо ожидания общего интеграционного стенда;
• прогон набора на каждое изменение, а не раз в спринт.

Сильный ответ добавляет обратную сторону: сдвиг влево не отменяет проверок справа. Мониторинг, алерты, постепенная раскатка и проверки на проде ловят то, что на стенде не воспроизводится в принципе.

Где спотыкаются

Сводят подход к автоматизации. Автотесты это следствие, а начинается сдвиг с того, что тестировщик читает требование и задаёт неудобный вопрос до того, как написана первая строка кода.

Обещают сокращение сроков как автоматический эффект. Раннее подключение сначала добавляет работы команде, выигрыш приходит позже и виден по числу дефектов, найденных после релиза, а не по скорости спринта.

Двигают влево всё подряд, включая нагрузочные и исследовательские проверки на неготовой системе. Часть проверок бессмысленна без собранного продукта, и настаивать на них рано значит жечь время команды и терять доверие к самой идее.