Глеб Михеев в докладе про contract first упомянул, что этот подход позволяет одновременно стартовать работу фронта и бэка, на что получил резонный комментарий из зала, что важней не начать, а закончить вместе. А чтобы закончить вместе, нужно:
а) точнее прогнозировать
б) устранить узкие места

Как уже ранее писал, одним из наиболее узких мест является тестирование, которое, как правило, начинается когда все компоненты системы готовы. И вот тут нам на помощь приходит статегия тестирования Shift-left. Идея простая — мы должны начасть тестировать как можно раньше. В идеально мире даже раньше разработки. Как это так? Ну так же как мы делаем TDD — разработка ещё не началась, а тесты написаны.

Так-то и TDD, и BDD, и линтеры, и статический анализ, и contract-first и автотесты — всё это вписывается в стратегию shift-left. Мы должны отловить максимум возможных проблем до того как код будет финализирован перед релизом.

Какая роль здесь у QA? Заняться тем же BDD. Подключиться на самом раннем этапе к обсуждению с бизнесом, выяснить для чего делаются эти изменения, понять, что они могут затронуть, описать все тестовые сценарии, передать эти знания разработчикам и начать писать автотесты (ну совсем идеальный случай). На стендапах внимательно слушать, что делают разработчики и как продвигается работа, какие в ней есть проблемы, задавать вопросы и просить заранее закрыть проблемные сценарии (список-то уже в задаче).