Left Shift Testing: как выстроить процесс, чтобы тесты реально помогали

В статье разбираем современный подход к автоматизации тестирования — от требований до продакшена. Как писать автотесты ещё до выката фичи, запускать их в изоляции, работать в одной ветке с разработчиком и ловить баги раньше, чем они попадут на стенд. Реальные практики, понятные схемы и причины, почему "автоматизация после релиза" — путь в никуда.

В этой статье я хочу поделиться взглядом на то, каким может быть оптимальный процесс автоматизации тестирования. Мы разберём, зачем он нужен, почему именно такой подход может считаться эффективным, а также какие плюсы и минусы он несёт. Важной частью статьи станет анализ рисков, к которым может привести нарушение или игнорирование этих процессов. Кроме того, мы ответим на частый вопрос: когда и какие тесты стоит запускать на CI/CD, чтобы это было максимально эффективно и стабильно.

Сразу хочу подчеркнуть: в этой статье мы будем говорить исключительно о концепции процесса, а не о технической реализации. Здесь не будет примеров кода, конфигураций CI/CD, или привязки к конкретным инструментам и фреймворкам. Цель статьи — описать качественную архитектуру процесса автоматизации, которая может быть адаптирована под любой технологический стек.

Ведь в каждой компании свои инструменты, процессы, команды и особенности CI/CD. Универсального "рецепта" не существует — но существует направление движения и принципы, к которым стоит стремиться. Если же вас интересуют технические детали, реализация автотестов или настройка пайплайнов, рекомендую ознакомиться с другими моими статьями:

Также важно отметить, что описанный здесь процесс — это обобщённая концепция. В зависимости от специфики проекта, команды или компании он может меняться. Это не жёсткий шаблон, а скорее ориентир, позволяющий построить стабильную, понятную и эффективную систему автоматизации. Подходите к нему критически и адаптируйте под свои условия — но старайтесь двигаться в этом направлении.

Всё начинается с появления требований — будь то новая функциональность или доработка существующей. На этом этапе ещё нет ни кода, ни тестов — только описание того, что должно быть реализовано. Сейчас мы не будем углубляться в детали того, откуда берутся требования, кто их пишет (аналитики, продакт-менеджеры и т.д.) и как они оформляются. Нас интересует роль инженера по автоматизации тестирования в этом процессе.

На этапе работы с требованиями QA Automation Engineer может и должен подключаться так же, как и другие QA-инженеры. Важные активности на этом этапе:

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

Следующий этап — начало разработки, когда фича официально переходит в статус "In Progress". С точки зрения тестирования это пока "пустая" стадия — функциональность ещё не реализована, и запускать тесты просто не на что. Но несмотря на это, автоматизатор уже может начать работу.

Вот какие задачи стоит выполнять на этом этапе:

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

Важно понимать: не всегда и не везде это возможно. Где-то фича слишком нестабильна, где-то слишком динамичный процесс, а где-то просто нет смысла заранее тратить время. Однако если это возможно — лучше начать подготовку заранее. Это убережёт от ситуаций, когда в продакшн улетает "огромный" pull request с тестами на 1500 строк, написанными в спешке.

После завершения реализации задачи разработчиком наступает момент, когда в игру вступает QA Automation Engineer. Идеальный процесс предполагает, что автотесты пишутся прямо в той же фича-ветке, где была реализована новая функциональность. Это ключевой момент в построении качественного и быстрого процесса автоматизации.

Что делает автоматизатор на этом этапе:

Сегодня поднятие локального окружения, как правило, не вызывает сложностей, особенно если используется docker и docker-compose. Если у проекта ещё нет удобных скриптов для запуска, можно попросить разработчиков — для них это обычно пара часов работы. В качестве моков можно использовать как кастомные решения, так и готовые инструменты вроде WireMock, MockServer, Hoverfly и других.

Цель этого этапа — провести максимально полноценное локальное тестирование фичи без необходимости выкладки на dev-окружение.

Такой подход, когда тестирование выполняется до деплоя, ещё называют Left Shift Testing. Это означает «сдвиг тестирования влево» — к более ранним этапам разработки. У него есть множество преимуществ.

Преимущества Left Shift Testing:

Подход Left Shift Testing требует определённой зрелости процессов и культуры внутри команды, но он кардинально ускоряет разработку, снижает количество дефектов в продакшене и делает автоматизацию частью разработки, а не "прицепом в конце".

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

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

Такие модули можно оформить как:

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

Преимущества подхода:

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

После того как автотесты написаны и фича протестирована локально, переходим к следующему шагу: выгрузка кода в репозиторий и автоматический запуск тестов в CI/CD.

Что происходит на этом этапе:

Такой подход называется изоляционное тестирование (Isolation Testing) — когда тесты запускаются вместе с фичей, в изолированной среде, до попадания кода на общий dev/stage/prod стенд.

Упрощённая коммуникация и быстрая обратная связь:

Лёгкая локализация проблем:

Быстрые и стабильные тесты:

Тесты — часть фичи, а не внешняя сущность:

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

Только после успешного локального тестирования и прохождения изоляционных тестов на CI/CD, фича попадает на общее окружение (Dev / Stable / Staging).

Что происходит на этом этапе:

Важно понимать: цель интеграционных тестов — не протестировать фичу. Эта работа уже сделана ранее — локально, изолированно, в фича-ветке.

Интеграционное тестирование нужно для:

Такой подход позволяет:

На схеме ниже — полный процесс с изоляционными и интеграционными тестами:

На второй схеме — упрощённый процесс, где сразу после деплоя запускаются только интеграционные тесты:

Такой упрощённый вариант можно использовать:

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

Что в таком случае происходит?

Если фича уехала с багами, а тесты пишутся позже, то:

Когда автоматизатор не участвует в процессе разработки:

Если тесты не запускаются в изоляции:

Без изоляционного подхода:

А ведь разработчик — первый человек, кто может быстро починить баг или добавить недостающий идентификатор для UI.

Когда тесты запускаются только на dev/staging/prod окружениях:

Когда тесты часто падают:

Да, абсолютно реально. И если на первый взгляд процесс кажется сложным или даже невозможным — скорее всего, это говорит не о его нереалистичности, а о нехватке практического опыта в автоматизации тестирования, понимании CI/CD, инфраструктуры или построении зрелых инженерных процессов.

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

Он не родился из воздуха. Он появился как ответ на реальные проблемы и боли. И если хочется внедрить по-настоящему устойчивую практику автотестирования — другого пути просто нет.

Можно идти к этому поэтапно, не обязательно внедрять всё сразу. Главное — не останавливаться на "у нас не получится", а разбираться, пробовать, задавать вопросы и расти как инженер.

Современная автоматизация — это не просто "писать тесты", а стать частью процесса разработки. Чем раньше мы встраиваемся в цикл — тем больше пользы приносим.

Изоляционное тестирование — это не про контроль, а про партнёрство:

Это и есть настоящая культура качества. Не отчёты ради галочки. А живая, полезная автоматизация, которая работает на продукт — каждый день.