QA перед сдачей

Каждый проект до сдачи проходит проверку с нулевым порогом отказов.

Site Checker — внутренний QA-плагин, который мы разработали и поддерживаем самостоятельно. Он запускается на каждом WordPress-проекте — ребилде, новой разработке, доработке темы, обновлении дизайна, редизайне — до того, как агентство-партнёр или конечный клиент увидит работу. Ничто не уходит в боевую среду с открытой ошибкой Site Checker.

  • 5категорий проверок
  • Каждыйпроект, любое окружение
  • 7+точек адаптации захватывается на страницу

Первый получатель отчёта — мы сами. Мы запускаем Site Checker на каждом сайте — не потому что агентство-партнёр просит, а потому что предпочитаем находить свои ошибки сами, а не ждать, когда их найдёт клиент. К тому моменту, когда работа доходит до вашего QA, наш барьер перед сдачей уже закрыт. Что бы ваше агентство ни нашло после сдачи — это наши правки, не ваши.

Что проверяет

Пять категорий. Каждая страница сайта, каждое окружение.

Категории упрощены для публичной страницы; внутренняя таксономия более детализирована. Каждая выдаёт структурированный статус ошибка / предупреждение / успех по известному набору ожидаемых состояний.

  • КАТЕГОРИЯ 01

    Базовые настройки WordPress

    Версия WordPress актуальна; флаг индексирования поисковыми системами соответствует окружению (разработка / тестовая среда / боевая среда); заголовок сайта настроен; нет оставшихся демо- или тестовых аккаунтов; отладочное логирование и вывод ошибок не открывают базу данных в публичных ответах.

  • КАТЕГОРИЯ 02

    Контент и SEO-разметка

    Каждая страница имеет уникальные мета-заголовки и описания в пределах допустимой длины; один H1 на страницу с чистой иерархией H2/H3; нет «Hello World», lorem ipsum и стандартного образцового контента WordPress; sitemap.xml существует, проверен и содержит ожидаемые URL.

  • КАТЕГОРИЯ 03

    URL структура

    Слаги в нижнем регистре, через дефис, без ID записей и параметров запроса, без посторонних не-латинских символов.

  • КАТЕГОРИЯ 04

    Контакты и интеграции

    Телефонные номера на сайте соответствуют утверждённому списку (нет оставшихся тестовых заглушек); ссылки на адреса ведут в правильное место на карте; заголовки страниц следуют согласованному стилю написания.

  • КАТЕГОРИЯ 05

    Паритет ребилдаТолько для ребилдов

    Исходный сайт сканируется и снимается снимок до начала работ. Site Checker сравнивает ребилд с этим снимком — отсутствующий контент, битые внутренние ссылки, структурное расхождение — и фиксирует каждое расхождение как ошибку. Неактивен при новых разработках; активен при ребилдах, где есть исходный сайт для сравнения.

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

Здесь всплывают дефекты, видимые только на адаптивных размерах, а не в задаче об ошибке от агентства после сдачи: переполняющийся текст, сломанные пропорции hero-блока, схлопывание навигации, позиционирование модальных окон, sticky-заголовки, перекрывающие контент на узких экранах. Мы ловим их на барьере, на каждой странице, на каждом сданном разрешении.

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

Барьер с нулевым порогом отказов

На каждом WordPress-проекте, который мы ведём сегодня, ни одна сдача не уходит с открытой ошибкой Site Checker.

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

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

Каждый кейс в разделе /work/ содержит раздел «Операционная целостность на момент сдачи» — специфичная для проекта запись о том, что прошло этот барьер до сдачи работы.

Если ваше агентство хочет увидеть сам отчёт — структурированный результат по каждой категории с временными метками — мы экспортируем его по запросу. Отчёт легко переслать дальше: без внутренних комментариев, без ссылок на исходный код, без упоминания агентства-партнёра. White-label — в его основе.

Каждая выпущенная версия тегируется; каждый запуск фиксирует, какая версия дала результат, — поэтому отчёт шестимесячной давности можно воспроизвести или сравнить с текущим запуском.

Плагин внутренний — не в каталоге WordPress.org. Текущая версия, кодовая база и набор правил по каждой проверке доступны для изучения по запросу. Если ваше агентство рассматривает нас как white-label партнёра и хочет разобраться в QA-слое до согласования объёма — мы готовы к такому разговору.

Есть проект, которому нужна сдача с нулевыми ошибками?

Пришлите Figma, URL или ТЗ. В течение 24 часов ответим с фиксированной оценкой часов и датой. Запуск Site Checker — часть каждого проекта: не дополнение, не отдельная строка, просто так работа уходит из наших рук.

Прокрутить вверх