На собеседованиях иногда задают вопрос: знакомы ли вы с shift left testing? При этом часто под ним подразумевают именно тестирование требований. В целом я с этим согласен.
Обычный жизненный цикл разработки любят изображать в виде линии. Об этом я рассказывал в видео про жизненный цикл задачи. Сначала появляется идея, потом создаются требования, собираются дизайн и макеты, дальше продукт разрабатывается, тестируется, релизится, и уже после этого им начинают пользоваться реальные пользователи.
Эту линию условно можно разделить на две части. Левая часть находится ближе к требованиям и разработке, а правая часть ближе к релизу и уже работающему продукту.
Отсюда и появляется название shift left. Оно означает, что проверки стараются проводить как можно раньше. Сюда относятся принцип раннего тестирования, тестирование требований, анализ рисков до начала разработки и так далее.
Shift right означает, что качество продолжают проверять уже после релиза, в реальной среде и с реальными пользователями.
В 2020 году появился новый термин shift everywhere. А в 2025 году, благодаря нашему любимому AI, о нем стали говорить все больше и больше.
Я сейчас не буду подробно уходить в обсуждение shift left или shift right. (Об этом можно почитать
тут и
тут) Мы будем говорить именно о shift everywhere, потому что, на мой взгляд, это гораздо ближе к тому, с чем тестировщики работают на самом деле. И, если честно, работали уже достаточно давно, просто об этом почему-то говорится слишком мало.
Shift everywhere testing, по сути, объединяет shift left и shift right, потому что мы проверяем всю нашу линию.
Качество проверяется до разработки, во время разработки, внутри CI/CD, на тестовом окружении, во время релиза, после релиза, во время эксплуатации, при разборе продуктовых инцидентов и так далее.
То есть это уже подход к организации всей работы с качеством.
Концептуально shift left testing концентрируется на раннем обнаружении проблем. Главные вопросы здесь примерно такие:
- понятны ли требования;
- можно ли их протестировать;
- есть ли риски еще до начала разработки;
- не заложили ли мы проблему уже на этапе идеи или проектирования.
Shift everywhere включает все это, но не останавливается после релиза.
Проще говоря, shift left пытается не допустить, чтобы проблемы ушли дальше по процессу. Сам подход появился как раз из-за того, что ошибки и инциденты, найденные на финальной стадии разработки или уже после релиза, обходятся компании очень дорого.
А shift everywhere контролирует качество на протяжении всего процесса и всей жизни продукта.
На мой взгляд, работа тестировщика и то, чему мы учим на своем курсе, концептуально намного ближе именно к shift everywhere. Потому что мы говорим об ответственности за качество на всех этапах.
Но здесь важно понимать, что качество продукта не зависит только от одной роли или одной зоны ответственности. За качество отвечает вся команда, потому что каждый ее участник на это качество влияет.
При этом тестировщик помогает выстроить единую систему работы с качеством и помогает команде этой системы придерживаться.
Но у подхода shift everywhere есть и определенные проблемы.
На практике можно просто получить больше работы и больше хаоса. Проверки вроде бы есть везде, но никто не понимает, какие из них действительно нужны. Где мы реально снижаем риски, а где просто тратим время. Нет приоритетов, нет понятных границ, нет общей системы.
А фраза «мы тестируем на проде» вообще может превратиться в полный маразм, если под ней подразумевается, что нормально выпускать непроверенный продукт и разбираться уже на пользователях.
Можно очень круто рассказывать, что у компании shift everywhere или shift left testing. Но при этом продолжать отдавать тестировщику готовую задачу за день до релиза со словами: «Давай как-нибудь успевай».😡
При этом границы работы и ответственности QA действительно расширяются. Я вижу это и по собеседованиям, и по общему состоянию рынка.
Современному QA нужно знать немного больше, чем условно три-четыре года назад.
Нужно понимать, как появляется задача и как она проходит через разраб
