Acceptance-тестирование после правок: как проверить, что не сломалось

Приёмочная проверка после правки занимает 10-20 минут по готовому чек-листу: главная, посадочная страница, форма заявки, оплата, вход в админку и вид на мобильном. Смысл в том, чтобы поймать поломку раньше посетителя, а не через две недели по жалобе.

Самый нелюбимый момент любой правки на сайте: «вроде сделал, а вдруг где-то ещё что-то сломалось». Нашёл одну ошибку, починил, через неделю всплыла вторая, оказалась последствием первого исправления. Через месяц обнаруживается третья, прямо в форме заявки, и лежит так уже две недели.

Лечится один раз и навсегда коротким acceptance-чек-листом, который пробегается после каждой правки. У меня такой чек-лист есть для каждого клиентского сайта, и пробежка занимает 10-20 минут. Ниже разложу, что в нём, как составить свой, и как часть рутины автоматизировать без больших вложений.

Свежая правка на сайте, инспектор сравнивает до и после

Что такое acceptance-тестирование

В мире разработки есть несколько уровней проверки кода:

Unit-тесты маленькие функции тестируются в изоляции.
Integration-тесты проверяется, как функции работают вместе.
End-to-end (E2E) тесты имитируют поведение пользователя на сайте.
Acceptance-тестирование проверка, что бизнес-функциональность сайта работает так, как ожидает заказчик.

Acceptance это самый высокий уровень. Не «корректно ли работает функция X в коде», а «может ли клиент оформить заказ от и до». Не «не выскакивает ли ошибка в консоли», а «выглядит ли страница как должна».

Для маленького сайта на WordPress или Битрикс обычно ничего глубже acceptance не нужно. Unit-тесты вы не пишете (потому что и кода своего у вас минимум). E2E-тестов через Playwright или Cypress тоже обычно нет (или есть на больших проектах). А вот acceptance это база.

Когда обязательно проверять

Список ситуаций, после которых я не выпускаю изменение без проверки.

После любой правки темы или кастомного плагина (свой код).
После обновления любого плагина, который влияет на форму, корзину, авторизацию, кэширование.
После обновления ядра CMS (минорное и мажорное).
После обновления версии PHP или MySQL на хостинге.
После переноса сайта на новый хостинг или новый домен.
После добавления нового плагина (даже если он «не должен ничего трогать»).
После любого вмешательства третьих лиц (поддержка хостера что-то правила, кто-то заходил в админку).
После переключения на новый сертификат SSL или обновления .htaccess.

Иногда правка явно тривиальная (поменял цвет фона), и я ограничиваюсь визуальной проверкой одной страницы. Но даже это проверка, не «отправить и забыть».

Базовый чек-лист на типовом сайте

Шаблон, который я иду по проекту любого клиента. Подстраиваю под специфику, но костяк один и тот же.

Главная страница

Открывается загружается без ошибки 500.
Стили загружены не «голый html».
Шрифты загружены не sans-serif на месте кастомного шрифта.
Hero-блок заголовок, кнопка CTA, изображение на месте.
Меню работает разворачивается на мобильном, ссылки не битые.
Кнопка «связаться» или CTA скроллит/открывает форму.
Footer ссылки на политику, контакты на месте.

Форма заявки

Открывается на странице, в модалке, в футере, везде где должна.
Поля заполняются все обязательные.
Валидация работает при пустом email видна ошибка.
Чекбокс согласия есть и не предзаполнен.
Кнопка отправки отправляет, не перезагружая страницу криво.
«Спасибо» появляется или редирект на страницу-спасибо.
Письмо приходит на email клиента (отправляю реальную тестовую заявку).
Дублируется в Telegram или CRM, если интеграция есть.
Запись в логе на сервере есть (для аудита и 152-ФЗ).

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

Авторизация

Страница /wp-login.php или аналог открывается.
Логин и пароль реальные (не тестовые) пускают.
Двухфакторка запрашивает код.
После входа редирект в админку, не белый экран.
Выход работает.

Корзина (если магазин)

Добавление товара счётчик корзины обновляется.
Изменение количества в корзине работает.
Удаление товара работает.
Промокод применяется.
Доставка считается правильно.
Оплата доходит до экрана платёжной системы.
Тестовая оплата проходит (на тестовом ключе ЮКассы или Stripe).
Письмо «спасибо за заказ» приходит покупателю.
Заказ виден в админке.

Поиск (если есть)

По существующему слову возвращает релевантные результаты.
По несуществующему показывает пустую страницу с сообщением.
Сниппеты не пустые.

Блог (если есть)

Список записей на главной блога.
Карточка записи заголовок, дата, тег, превью.
Открытие записи все картинки видны, навигация по записям работает.
RSS-фид выдаёт корректный XML.

Технические страницы

404 страница при несуществующем URL.
Политика конфиденциальности доступна, ссылка из футера работает.
Карта сайта sitemap.xml отдаётся корректно.
robots.txt содержит правильные директивы.

Чек-лист «по железу»

Несколько вещей, которые проверяю после правок инфраструктуры (не самого сайта).

curl -sI https://saitfix.ru/ ожидаемый код 200.
curl -sI https://www.saitfix.ru/ ожидаемый редирект 301 на https://saitfix.ru/.
curl -sI http://saitfix.ru/ ожидаемый редирект 301 на https.
curl -sI https://saitfix.ru/wp-admin/ ожидаемый редирект на login.
Заголовки: Content-Encoding (gzip/br), Cache-Control, X-Frame-Options.
DNS: A-запись, MX, TXT (SPF, DKIM, DMARC). Через dig или nslookup.
SSL: проверка через https://www.ssllabs.com/ssltest/ или openssl s_client -connect saitfix.ru:443.

Кросс-браузерная проверка

Не нужно тестировать все 30 браузеров. Достаточно представительной выборки.

Что я проверяю на каждом крупном релизе:

Chrome desktop (последняя версия).
Safari desktop (на macOS если есть, или через Lambdatest/BrowserStack).
Chrome Android (через DevTools или реальный телефон).
Safari iOS (на реальном iPhone).
Firefox desktop (последняя версия).

Этого достаточно для 95+ процентов трафика. Для оставшихся 5 процентов (старый Edge, экзотика) проверяю по жалобам, если они есть.

Кросс-устройство

В DevTools Chrome есть режим устройства (Ctrl+Shift+M). Я обязательно прохожу по устройствам:

iPhone SE маленький экран, классическая ширина 320-375.
iPhone 13/14 средний размер, 390×844.
Samsung Galaxy S20+ ширина 412, длинная.
iPad портрет 768×1024.
Desktop 1366×768 (минимум) и 1920×1080 (типичный).

На каждом виде проверяю главную, форму заявки, корзину (если есть). Если что-то не помещается, или съезжает, чиним до выпуска.

Автоматизированная часть

Часть проверок я перевёл на автомат через Playwright. Скрипт раз в день проходит по сайту и проверяет:

// playwright-check.spec.js
import { test, expect } from '@playwright/test';

test('главная грузится и форма работает', async ({ page }) => {
    await page.goto('https://saitfix.ru/');
    await expect(page.locator('h1')).toBeVisible();
    await expect(page.locator('button[type="submit"]')).toBeVisible();

    await page.click('a[href="#contact"]');
    await page.fill('input[name="name"]', 'Test User');
    await page.fill('input[name="phone"]', '+71234567890');
    await page.fill('textarea[name="message"]', 'Acceptance test message');
    await page.check('input[name="consent"]');
    // не нажимаем submit, чтобы не засорить продакшн
    await expect(page.locator('button[type="submit"]')).toBeEnabled();
});

test('политика и контакты доступны', async ({ page }) => {
    await page.goto('https://saitfix.ru/privacy/');
    await expect(page.locator('h1')).toContainText('Политика');

    await page.goto('https://saitfix.ru/contacts/');
    await expect(page.locator('a[href^="tel:"]')).toBeVisible();
});

test('форма реально шлёт письмо на тестовом эндпоинте', async ({ request }) => {
    const response = await request.post('https://saitfix.ru/mail-test.php', {
        form: {
            name: 'Acceptance bot',
            phone: '+70001234567',
            message: 'self-check',
            consent: '1'
        }
    });
    expect(response.status()).toBe(200);
});

Скрипт стоит на отдельной VPS, гоняется по cron каждые 6 часов. При падении пишет в Telegram. Стоимость хостинга 200 рублей в месяц, время на разработку 4-6 часов один раз. На хорошем клиентском проекте окупает себя за один пропущенный инцидент.

Что делать, если что-то сломалось

Если acceptance-тест поймал поломку, действуем по протоколу.

Откатить правку. Если изменения в Git, git revert. Если правка была через FTP, восстанавливаем из бэкапа.
Зафиксировать в журнале: что, когда, какая правка вызвала.
Воспроизвести в локальной staging-среде.
Найти причину. Иногда конфликт плагинов, иногда баг в новой версии, иногда наша ошибка.
Исправить на staging.
Перепроверить acceptance-чек-лист.
Накатить на боевой.
Перепроверить ещё раз на боевом.

Этот процесс кажется длинным, но в реальности занимает 30-90 минут на средний инцидент. И сохраняет от ситуации «разбираемся неделю».

Сколько это занимает на практике

Для типового сайта:

Полный acceptance-чек-лист 15-25 минут на ручную проверку.
Автоматизированная часть 0 минут (запускается сама в фоне).
Кросс-браузерная проверка 10-15 минут на крупном релизе.
Кросс-устройственная проверка 10 минут.

Суммарно после большого релиза 45-50 минут. После мелкой правки 5-10 минут (только пострадавший блок).

Для контекста: один пропущенный инцидент с формой заявки, которая не работала неделю, это 30-50 пропущенных заявок. Цена «бесплатной» экономии на тестировании.

Чек-лист с шагами проверки в виде блок-схемы

Чек-лист на старт

Если вы хотите завести у себя acceptance-тестирование с нуля.

Список критических функций сайта. У сайта услуг это: главная, форма, политика, телефон. У магазина: главная, карточка товара, корзина, оформление, оплата.
Чек-лист в Notion, Google Doc, простом markdown-файле. По строчке на функцию.
Регламент в каких ситуациях запускается чек-лист. Пишем рядом с регламентом обновлений.
Один реальный прогон перед первым релизом. Засекаем время.
Автоматизация по мере боли. Что часто ломается переводим в Playwright.

Через 2-3 месяца у вас будет работающая система, в которой регрессии случаются, но ловятся в течение часа.

Кто должен это делать

Распределение ответственности.

Подрядчик-разработчик. Тестирует код перед коммитом. Прогоняет acceptance перед релизом.

Я как абонентский сопровождающий. Прогоняю acceptance после любой своей правки. Прогоняю автоматически по расписанию между правками.

Владелец сайта. После моих правок может прогнать свой собственный мини-чек-лист (просто посмотреть, что главное на месте). Это страховка, не основная мера. Не должен делать каждый раз, но не должен и пропускать релизы.

Куда дальше

Связанные материалы: Регламент работ по сайту, SLA для маленького сайта, Обновление WordPress без поломок.

Если на вашем сайте acceptance не делается никогда (и поэтому регулярно что-то ломается, а вы узнаёте об этом от клиентов), у меня в годовом и месячном тарифе абонентского обслуживания базовый чек-лист и автоматический Playwright-прогон входят по умолчанию. Заявка через форму на главной.

Частые вопросы

Что проверять после правок на сайте

Главную, страницу услуги или товара, отправку формы заявки, оплату, вход в админку и вёрстку на телефоне. На типовом сайте такая пробежка занимает 10-20 минут и закрывает большую часть рисков.

Зачем чек-лист, если правка мелкая

Потому что ломается обычно не то, что правили. Одно исправление тянет за собой второе, а третье всплывает через месяц в форме заявки, про которую никто не вспомнил.

Какие браузеры и устройства проверять

Те, что есть в статистике сайта. Обычно три-четыре браузера дают 95 процентов трафика, остальное экзотика, которую разбирают по факту жалобы.

Что имеет смысл автоматизировать

Регулярную проверку доступности и отправки формы по расписанию. Скрипт закрывает самое дорогое и работает круглосуточно, а ручной чек-лист остаётся для проверки после правок.

Acceptance-тестирование после правок: как проверить, что не сломалось

Что такое acceptance-тестирование

Когда обязательно проверять