Визуальная регрессия: непреднамеренное изменение внешнего вида пользовательского интерфейса (вёрстка, цвета, типографика, отступы, выравнивание), внесённое изменением кода, обновлением зависимости или правкой конфигурации и обнаруживаемое только визуальным сравнением двух состояний интерфейса.
Вот правда, которую многие команды, использующие Cypress, предпочитают не замечать: ваш набор тестов Cypress, каким бы полным он ни был, структурно слеп к целой категории багов. Визуальные регрессии проходят сквозь ваши проверки, как вода через дуршлаг, и не потому, что тесты плохо написаны, а потому, что Cypress просто не создавался, чтобы их находить.
Это не критика Cypress. Это констатация. А разница между констатацией и критикой в том, что констатация требует решения, а не спора.
Все наши сравнения по проверяемым критериям: Альтернативы и сравнения.
Ваш набор Cypress подтверждает, что всё работает, но не что всё хорошо выглядит. Дополните его Delta-QA: сценарии записываются без кода, аккаунт бесплатный, банковская карта не нужна. Попробовать Delta-QA бесплатно →
Cypress: превосходен в своём деле, но отсутствует там, где важна визуальная часть
Cypress совершил революцию во фронтенд-тестировании, когда появился на рынке. Выполнение в браузере, автоматическая перезагрузка, отладка с путешествием во времени, интуитивный API (всё это сделало сквозное тестирование доступным командам, которые считали Selenium средневековым орудием пыток). И в области функционального тестирования Cypress остаётся замечательным инструментом.
Но задайте себе вопрос: когда вы в последний раз писали тест Cypress, проверяющий, что главная страница выглядит правильно? Не что кнопка существует. Не что текст присутствует. А что она выглядит правильно: отступы в порядке, цвета согласованы, вёрстка не сдвинулась ни на пиксель.
Для подавляющего большинства команд ответ «никогда». И не из-за небрежности. А потому что Cypress не сравнивает изображения. Его собственная документация говорит об этом по состоянию на 10/2026: команда cy.screenshot() делает снимок, но не сравнивает его; визуальное тестирование выполняется через плагины или сторонние сервисы.
Слепая зона Cypress: нет встроенного визуального сравнения
Когда вы пишете cy.get('.button').should('be.visible'), вы проверяете, что элемент существует в DOM и не скрыт CSS. Вы не проверяете, что у него правильный цвет. Не проверяете, что он на правильном месте. Не проверяете, что его текст читаем. Не проверяете, что он не перекрывает другой элемент.
Кнопка может быть «видимой» в понимании Cypress (присутствует в DOM, display не равен none, opacity больше 0) и при этом совершенно непригодной визуально. Белый текст на белом фоне. Размер 2 на 2 пикселя. Позиция в 3000 пикселях правее экрана. Cypress скажет, что всё хорошо. Ваш пользователь скажет другое.
Это фундаментальная слепая зона, а не мелкое ограничение. Значительная часть проблем, о которых сообщают пользователи, касается отображения: нечитаемая кнопка, сдвинутая форма, блок, который вылезает за границы. А Cypress в базовой конфигурации не обнаруживает ни одной из них.
Визуальные плагины Cypress: частичное и хрупкое решение
Столкнувшись с этим пробелом, экосистема Cypress породила плагины для визуального тестирования. Самые известные опираются на сторонние сервисы (Percy, Applitools, Happo), которые делают скриншоты и сравнивают их, либо на cypress-image-snapshot для локального сравнения. Если вам нужны подробности по каждому варианту, наше полное руководство по добавлению визуального тестирования в Cypress разбирает эти подходы и их реальные ограничения. Этот путь работает, но с существенными оговорками.
Зависимость от стороннего сервиса. Каждый визуальный плагин для Cypress опирается на внешнюю платформу. Ваши скриншоты отправляются на серверы поставщика, сравниваются там, а результаты возвращаются к вам. Это добавляет задержку в CI-пайплайн, сетевую зависимость и лицензионную стоимость стороннего сервиса поверх стоимости Cypress Cloud, если вы его используете.
Сложность настройки. Чтобы добавить визуальный плагин в Cypress, нужно установить npm-пакет, настроить аутентификацию в стороннем сервисе, изменить существующие тесты, добавив вызовы снимков, управлять API-токенами и обучить команду работе с внешней платформой. Это не непреодолимо, но и не тот опыт «заработает за 5 минут», который обещают маркетинговые страницы.
Двойное сопровождение. Вы поддерживаете две системы: тесты Cypress и конфигурацию визуального плагина. При обновлении Cypress плагин может сломаться. Когда сторонний сервис меняет API, ваши тесты могут упасть. Когда меняется команда, новичков нужно обучать двум инструментам вместо одного.
Ограниченное покрытие. Визуальный плагин, встроенный в Cypress, делает скриншоты во время выполнения функциональных тестов. Это значит, что визуальное покрытие зависит от функционального. Если у вас нет теста Cypress для страницы «Общие условия продажи», то нет и визуального теста для этой страницы. Ваше визуальное покрытие ограничено функциональным, а у них нет причин совпадать.
Delta-QA: визуальное тестирование как самостоятельная дисциплина
Delta-QA исходит из другой философии. Визуальное тестирование не функция, привитая к инструменту функционального тестирования. Это полноценная дисциплина со своими требованиями, своими процессами и своими пользователями.
Независимость от функциональных тестов. Delta-QA записывает ваши сценарии в процессе навигации. Функциональный тест как «транспорт» для снимка страницы не нужен. Ваше визуальное покрытие не зависит от функционального: можно проверять десятки страниц, не написав ни одного теста.
Доступность для не-разработчиков. Кто лучше всех способен судить о визуальном качестве интерфейса? Дизайнеры. Ручные тестировщики. Product owner. А эти люди в большинстве организаций не умеют писать на JavaScript. С Cypress и визуальным плагином они зависят от разработчика, который всё настроит, запустит и интерпретирует тесты. С Delta-QA они самостоятельны. Это различие меняет динамику команды.
Встроенное управление эталонами. Delta-QA включает полный процесс: отчёт, который называет изменившиеся элементы, оценка каждого различия (задуманное или баг), история изменений. Этот процесс продуман для междисциплинарных команд, а не для одиночного разработчика, который делает push и merge в одно утро.
Браузер. Delta-QA воспроизводит ваши сценарии в настоящем браузере, сегодня это Chromium; Firefox и WebKit запланированы. Cypress поддерживает Chrome, Edge и Firefox, а WebKit остаётся экспериментальным.
Структурная проблема плагинов: закон связанного покрытия
Вернёмся к этому пункту, он заслуживает развития. Когда ваш визуальный тест связан с функциональным (как в случае визуальных плагинов Cypress), ваше визуальное покрытие наследует все ограничения вашего функционального покрытия.
Есть тест Cypress для воронки покупки? Визуальное покрытие воронки обеспечено. Нет теста Cypress для страницы FAQ? Нет и визуального покрытия страницы FAQ. Ваш тест Cypress для страницы профиля покрывает случай «авторизованный пользователь с премиум-подпиской»? Для этого случая визуальное покрытие есть, а для «авторизованный пользователь без подписки» или «пользователь с истёкшей подпиской» нет.
У функционального и визуального покрытия разная логика. В функциональном тестировании вы проверяете сценарии: последовательности действий и проверок. В визуальном проверяете состояния: снимки страниц в заданных условиях. Функциональному сценарию из 10 шагов может хватить 2 визуальных проверок (входная страница и страница подтверждения). И наоборот, простая страница без сложной функциональной логики (страница «О нас») может потребовать визуальной проверки на 5 разрешениях и в 3 браузерах.
Связать эти два вида значит заставить одну дисциплину принять покрытие другой. Это всё равно что сказать, что вы осматриваете помещение завода только тогда, когда туда заходит рабочий воспользоваться станком. В дни, когда в этом помещении никто не работает, протечки воды остаются незамеченными.
Cypress лучше справляется с функциональным тестированием
Признаем сильные стороны Cypress, потому что они реальны и значительны.
Опыт разработчика. Cypress создан разработчиками для разработчиков. Интерфейс отладки с путешествием во времени, скорость выполнения, плавный цепочечный API (им приятно пользоваться). Delta-QA не претендует на такой опыт, потому что это не его поле.
Проверка бизнес-логики. Платёжная воронка, которая правильно считает налоги, стоимость доставки и промокоды: это проверяет Cypress, а не Delta-QA. Бизнес-логика невидима визуально, пока не даёт отображаемый результат, да и тогда проверка «показанная сумма правильна» требует знать ожидаемую сумму, а вычислить её может только функциональный тест.
Перехват сети. Cypress умеет перехватывать HTTP-запросы, имитировать ответы сервера, тестировать случаи ошибок. Это мощный инструмент интеграционного фронтенд-тестирования, выходящий далеко за рамки простой проверки интерфейса.
Растущая облачная экосистема. По состоянию на 10/2026 Cypress Cloud предлагает Test Replay для воспроизведения сбоя, UI Coverage, Cypress Accessibility, сгенерированные ИИ сводки сбоев, а команда cy.prompt() превращает шаги на естественном языке в команды Cypress. Ничто из этого не сравнивает внешний вид страницы с эталоном, но инструмент быстро развивается.
Скорость выполнения. Архитектура Cypress, выполняющая тесты в том же процессе, что и приложение, обеспечивает замечательную скорость функциональных тестов. Нет сетевой задержки между тестом и приложением, нет промежуточного протокола WebDriver.
Ваш набор Cypress проверяет логику, но не внешний вид. Закройте этот пробел с Delta-QA: визуальное тестирование без кода, бесплатный аккаунт, банковская карта не нужна. Попробовать Delta-QA бесплатно →
Delta-QA лучше справляется с визуальным тестированием
Быстрое покрытие. Чтобы визуально покрыть основные страницы, нужно столько времени, сколько занимает их обход в Delta-QA. Чтобы получить то же покрытие через плагин Cypress, придётся писать тест для каждой страницы, управлять эталонами и стабилизировать снимки. С одной стороны дни работы, с другой несколько часов навигации.
Процесс утверждения. Когда Delta-QA обнаруживает изменение, ваш дизайнер может оценить его прямо в интерфейсе. Не нужен разработчик, не нужно разбираться в отчёте Cypress. Отчёт говорит на языке людей, оценивающих визуальное качество: какой элемент изменился и как.
Сокращение ложных срабатываний. Визуальные плагины для Cypress часто наследуют ограничения грубого попиксельного сравнения. Другое сглаживание шрифта между двумя запусками? Ложное срабатывание. Каретка курсора в текстовом поле? Ложное срабатывание. Delta-QA сравнивает элементы страницы, а не её пиксели: вариация отрисовки, не меняющая ни цвет, ни размер, ни позицию элемента, не сообщается.
Визуальная история. Delta-QA хранит историю эталонов и оценённых изменений. Можно проследить эволюцию страницы по версиям. С локальным плагином Cypress ваши эталоны это файлы в Git (под версионным контролем, но без интерфейса для просмотра их эволюции).
Типичный сценарий: когда плагина Cypress уже недостаточно
Представим распространённую ситуацию. Ваша команда использует Cypress два года. У вас 300 функциональных тестов. Покрытие хорошее. И вот однажды рефакторинг CSS затрагивает вашу дизайн-систему. Переменная --color-primary меняется. Все тесты Cypress проходят, ни один из них не проверяет цвета. В продакшене на 30 страницах у кнопки действия контраст стал недостаточным для чтения. Поддержка получает 15 обращений за два часа. Исправление выкатывают срочно.
После этого инцидента ваш техлид решает добавить в Cypress визуальный плагин. Установка занимает полдня. Настройка эталонов для 50 критичных страниц занимает день. Первые запуски порождают 47 ложных срабатываний. Разбор ложных срабатываний занимает день. Две недели спустя разработчик обновляет Cypress, и плагин перестаёт быть совместимым. Визуальный набор «временно» отключают. Три месяца спустя он всё ещё отключён.
Этот сценарий не выдуман: это собирательный рассказ из десятков разговоров с QA-командами. Фундаментальная проблема не в плагине. Визуальное тестирование, привитое к инструменту функционального тестирования, никогда не бывает приоритетным. Это всегда «что-то сверх», что делают, когда есть время, то есть никогда.
Delta-QA избегает этой ловушки, потому что визуальное тестирование это смысл существования инструмента, а не необязательное дополнение. Нет функционального набора, который забирает приоритет. Нет более срочной конфигурации, которую нужно поддерживать. Визуальное тестирование это приоритет, и инструмент построен вокруг него.
Выигрышное сочетание: Cypress и Delta-QA
Наша позиция не «откажитесь от Cypress ради Delta-QA». Это было бы абсурдно. Cypress отличный инструмент функционального тестирования. Delta-QA создан для регрессионного тестирования интерфейса. Сочетание двух даёт QA-покрытие, которого ни один не обеспечит в одиночку.
Cypress проверяет, что ваше приложение работает. Пользовательские сценарии, бизнес-логика, интеграции API, случаи ошибок. Это функциональный слой вашего обеспечения качества.
Delta-QA проверяет, что ваше приложение выглядит правильно. Цвета, типографика, отступы, вёрстка. Это визуальный слой вашего обеспечения качества.
У каждого слоя свой ритм. Тесты Cypress работают в вашем пайплайне CI/CD; сценарии Delta-QA воспроизводятся при каждой версии. Каждый смотрит на своё измерение качества инструментами, оптимизированными для него.
Это как иметь и сигнализацию, и камеры наблюдения. Сигнализация обнаруживает проникновение (функциональное: вошёл кто-то, кому не следовало). Камеры показывают, что происходит (визуальное: всё ли выглядит нормально). Вместе они эффективнее, чем по отдельности.
Аргумент «у нас уже есть Cypress, этого достаточно»
Это самое частое возражение. «Мы уже вложились в Cypress, не будем добавлять ещё один инструмент». Аргумент понятный, но ложный. У вас уже есть молоток, но это не делает каждую проблему гвоздём.
Если у вашего приложения есть пользовательский интерфейс (а раз вы читаете эту статью, скорее всего, есть), значительная часть ценности, которую видят пользователи, исходит из внешнего вида этого интерфейса. Не из бизнес-логики под ним, какой бы блестящей она ни была. Пользователь не видит вашу микросервисную архитектуру. Он видит синюю кнопку, выровненную форму, последовательную типографику.
Не тестировать это измерение значит ставить на то, что никто никогда не сломает CSS вашего приложения. Это пари, которое вы проиграете. Вопрос не в том, случится ли, а в том, когда. И когда это произойдёт, цена будет пропорциональна времени, которое регрессия проведёт в продакшене: время, которое сокращается, если обнаружить её до развёртывания.
Сколько времени занимает добавление Delta-QA к существующей настройке Cypress
Если вы уже используете Cypress и хотите добавить Delta-QA, вот что это значит на практике.
Delta-QA работает независимо от Cypress. Менять существующие тесты Cypress не нужно. Устанавливать плагин не нужно. Трогать конфигурацию Cypress не нужно. Оба инструмента сосуществуют без конфликтов, потому что ничего не делят.
Внедрение Delta-QA сводится к тому, чтобы открыть ваш сайт и пройти сценарии, которые нужно покрыть. Первый прогон создаёт эталоны. Это всё: визуальное покрытие активно, независимо от ваших тестов Cypress.
Чтобы пойти дальше в CI, у Delta-QA теперь есть SDK, Vision. Сегодня он поддерживает Playwright, на TypeScript и JavaScript; поддержка Cypress запланирована следом. С Playwright достаточно одной строки на каждую проверяемую страницу: неоценённое различие приводит к падению теста, а в логе CI есть ссылка на отчёт.
FAQ
Добавит ли Cypress когда-нибудь встроенное визуальное тестирование?
Это постоянный вопрос в сообществе Cypress. По состоянию на 10/2026 документация указывает, что Cypress сам не сравнивает изображения, и отсылает к плагинам. Cypress Cloud пополняется (Test Replay, UI Coverage, Accessibility, функции ИИ вроде cy.prompt()), но без визуального сравнения с эталоном. И даже если Cypress это добавит, оно останется связанным с выполнением функциональных тестов: проблема связанного покрытия, описанная выше, сохранится.
Разве визуальных плагинов Cypress не достаточно? Для базового использования они могут выручить. Но они добавляют зависимость от стороннего сервиса (со своей лицензионной стоимостью), связывают визуальное покрытие с функциональным, а их сопровождение это дополнительная нагрузка. Если у вас 10 страниц и разработчик, готовый поддерживать плагин, это может сработать. Если у вас 100 страниц и смешанная QA-команда, ограничения становятся блокирующими.
Может ли Delta-QA обнаружить баги, которые Cypress не находит? Да, по определению. Cypress проверяет программные утверждения: «этот элемент содержит этот текст», «этот URL правильный», «этот запрос вернул 200». Delta-QA проверяет внешний вид: «эта страница выглядит так же, как эталонная версия». Визуальные баги (регрессии CSS, проблемы адаптивности, конфликты z-index, отсутствующие шрифты) невидимы для проверок Cypress, но обнаруживаются Delta-QA.
Замедляет ли Delta-QA пайплайн CI/CD? Ваши сценарии Delta-QA, записанные без кода, не проходят через ваш пайплайн Cypress и его не замедляют. Для интеграции в CI SDK Vision сегодня поддерживает Playwright; Cypress запланирован следом.
Нужно ли выбирать между Cypress Cloud и Delta-QA? Нет. Они служат разным целям. Cypress Cloud оптимизирует ваши функциональные тесты Cypress: параллелизация, воспроизведение сбоев, обнаружение нестабильных тестов, покрытие интерфейса и доступность. Delta-QA покрывает визуальное сравнение с эталоном, которым Cypress Cloud не занимается. Это взаимодополняющие вложения.
Моя QA-команда не техническая. Смогут ли они пользоваться Delta-QA без помощи разработчика? Именно для такого случая Delta-QA и создан. No-code интерфейс позволяет тестировщику QA, дизайнеру или product owner настраивать, запускать и интерпретировать визуальные тесты без каких-либо навыков разработки. Это одно из фундаментальных отличий от плагина Cypress, который требует менять JavaScript-код, чтобы добавить точки визуального снимка.
Можно ли использовать Delta-QA с другим фреймворком, а не Cypress? Да. Сценарии Delta-QA не зависят ни от какого тестового фреймворка: используете ли вы Cypress, Playwright, Selenium, TestCafe или никакого, они работают одинаково. А для команд Playwright SDK Vision позволяет добавить проверку Delta-QA в существующий тест.
Заключение: не заставляйте Cypress нести ношу, которая не его
Cypress замечательный инструмент в том, что он делает. Но требовать от него визуального тестирования (через плагины, хаки или самодельные проверки CSS) значит возлагать на него миссию, для которой он не создавался. Это как нагрузить спринтера рюкзаком в 20 килограммов и удивляться, что он стал медленнее.
Освободите Cypress. Пусть он делает то, что у него получается лучше всего: проверяет, что ваше приложение работает. А визуальное тестирование поручите инструменту, созданному для этого.
Готовы закрыть визуальную слепую зону вашего набора тестов? Запустите первое сравнение с Delta-QA, с бесплатным аккаунтом и без банковской карты. Попробовать Delta-QA бесплатно →