Как мы тестируем сайт перед запуском: этапы проверки

Как мы тестируем сайт перед запуском

Сайт открывается на компьютере разработчика. Кнопки нажимаются. Формы выглядят нормально.

Значит, можно запускать?

Нет.

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

Поэтому тестирование сайта перед запуском — отдельный этап нашей разработки.

Мы проверяем техническую исправность, адаптивность, основные сценарии взаимодействия и производительность. Часть проверок выполняем вручную, часть автоматизируем.

Но есть ещё одна задача:

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

Разработчик знает, куда нужно нажимать.

Пользователь — нет.

Именно поэтому проверить только то, что сайт «технически работает», недостаточно.

{здесь вставить изображение: схема «Разработка → техническое тестирование → пользовательские сценарии → запуск»}

Весь путь проекта до этого этапа мы описываем в статье «Как мы работаем над сайтом: от интервью до запуска».

Что мы проверяем перед запуском сайта

Проверка начинается с базового вопроса:

работает ли сайт так, как должен?

На практике за этим скрывается несколько разных уровней тестирования.

Мы проверяем:

• отображение сайта на разных размерах экранов;
• работу в браузерах;
• формы;
• интеграции;
• основные пользовательские сценарии;
• accessibility;
• технические ошибки;
• производительность;
• поведение сайта при реальном взаимодействии.

Отдельно используются автоматизированные проверки через Playwright и проверки кода через ESLint.

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

Если сайт должен отправлять заявку — отправляем тестовую заявку.

Если информация должна передаваться во внешнюю систему — проверяем передачу.

Если пользователь должен пройти конкретный сценарий — проходим его.

То есть проверяем не наличие функции, а её фактическую работу.

Адаптивный дизайн нужно не просто нарисовать

На этапе дизайна можно подготовить мобильную, планшетную и десктопную логику.

Но после разработки всё это ещё нужно проверить в работающем интерфейсе.

Мы смотрим, как сайт ведёт себя на разных размерах экранов:

не ломается ли композиция;

не уезжают ли элементы;

не становится ли текст неудобным для чтения;

остаются ли доступными целевые действия;

нормально ли работает навигация;

не появляются ли проблемы в интерфейсе на промежуточных разрешениях.

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

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

Она должна обеспечить нормальную работу интерфейса между ними.

{здесь вставить изображение: один экран сайта на mobile / tablet / desktop}

Проверяем сайт в браузерах

То, что интерфейс правильно работает в одной среде, ещё не гарантирует такое же поведение в другой.

Поэтому перед запуском мы проверяем открытие сайта в браузерах.

Нас интересует не только то, загружается ли страница вообще.

Проверяем отображение интерфейса, работу элементов и основные действия пользователя.

Для бизнеса здесь всё достаточно просто.

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

Он просто видит сломанный сайт.

А значит, техническая проблема подрядчика превращается в проблему компании, чей бренд указан на странице.

Форму недостаточно увидеть — нужно отправить заявку

Один из самых критичных элементов коммерческого сайта — формы.

Контактная форма может идеально выглядеть и при этом не выполнять свою главную функцию.

Поэтому формы мы проверяем вручную тестовыми отправками.

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

То же самое относится к интеграциям.

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

Иначе может получиться особенно неприятная ситуация:

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

С точки зрения владельца сайта такой дефект намного серьёзнее небольшой визуальной ошибки.

Автоматизируем часть проверок через Playwright

Ручное тестирование необходимо, но часть пользовательских сценариев можно проверять автоматически.

В разработке мы используем агентские тесты через Playwright.

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

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

При этом автоматические тесты не отменяют ручное тестирование.

Они решают разные задачи.

Автоматизация хорошо проверяет заранее сформулированный сценарий.

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

Поэтому нам нужны оба подхода.

Проверяем не только интерфейс, но и код

До запуска проходят и технические проверки.

В частности, используем ESLint.

Задача здесь отличается от пользовательского тестирования.

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

Поэтому тестирование сайта не состоит из одного действия «прокликать все страницы».

Это несколько слоёв проверки:

код → интерфейс → функциональность → интеграции → пользовательский сценарий.

Каждый отвечает на свой набор вопросов.

Accessibility — часть проверки интерфейса

Перед запуском мы также смотрим на accessibility.

Сайт должен оставаться понятным и доступным не только в идеальном сценарии, который представлял дизайнер во время создания макета.

При тестировании важно смотреть на интерфейс шире:

можно ли нормально взаимодействовать с его элементами;

понятна ли структура;

не создаёт ли реализация ненужные препятствия для пользователя.

Accessibility поэтому входит в общий этап проверки вместе с адаптивностью и другими техническими параметрами.

Мы не рассматриваем её как декоративный пункт в отчёте после завершения проекта.

Она относится к качеству самого продукта.

Производительность — пользователь тоже её чувствует

Ещё одна часть тестирования связана со скоростью и производительностью сайта.

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

В наших проектах для оптимизации используются:

• lazy loading;
• CDN;
• оптимизация изображений;
• работа с Core Web Vitals;
• возможности Next.js;
• SSR.

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

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

Если сайт тяжёлый, перегруженный или плохо оптимизированный, это непосредственно влияет на взаимодействие с продуктом.

Поэтому производительность относится к пользовательскому опыту не меньше, чем расположение кнопки или структура страницы.

Технически исправный сайт ещё может быть непонятным

Представим, что мы закончили все технические проверки.

Ошибок нет.

Формы работают.

Интеграции работают.

Адаптив работает.

Можно ли считать тестирование законченным?

Не совсем.

Есть другой класс проблем.

Пользователь может просто не понять интерфейс.

Не увидеть нужное действие.

Перейти не туда.

Искать информацию в неожиданном месте.

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

Технически сайт при этом работает безупречно.

Но бизнес-задачу выполняет хуже.

Именно поэтому часть проверки посвящена пользовательским сценариям.

На тестировании мы стараемся стать «самым тупым пользователем»

Формулировка грубая, но хорошо описывает подход.

Когда команда несколько недель работает над проектом, она слишком хорошо его знает.

Мы знаем, где находится меню.

Знаем, куда ведёт кнопка.

Знаем, какой блок нужно читать следующим.

Знаем логику продукта.

Реальный человек всего этого не знает.

Поэтому во время проверки мы стараемся абстрагироваться от собственного понимания проекта.

Условная установка:

«Действуй как самый тупой пользователь».

Нажимай туда, куда никто не планировал.

Иди по неочевидному пути.

Ищи информацию не там, где дизайнер считает логичным.

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

Попытайся использовать продукт так, будто впервые оказался на сайте и вообще не знаешь, как он устроен.

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

А потом снова возвращаемся к целевой аудитории

Есть и обратный сценарий.

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

На этапе интервью и проектирования мы разбираем сегменты ЦА и их сценарии взаимодействия с продуктом.

На тестировании возвращаемся к этим портретам.

И задаём вопросы:

Как поступил бы представитель этого сегмента?

Достаточно ли ему информации?

Понятно ли предложение?

Закрыты ли его основные вопросы?

Может ли он выполнить нужное действие?

Таким образом, у нас появляются два разных угла проверки.

Первый:

«Что произойдёт, если человек вообще ничего не знает и действует непредсказуемо?»

Второй:

«Что произойдёт, если на сайт пришёл конкретный представитель нашей целевой аудитории со своей задачей?»

Оба нужны.

Мы не называем любую внутреннюю проверку фокус-группой

Формат пользовательского тестирования зависит от проекта.

Иногда сайт тестирует в первую очередь наша команда.

Иногда заказчик подключает собственных сотрудников.

Иногда предоставляет доступ своим клиентам.

Иногда внешних пользователей вообще не подключают.

Это решение во многом зависит от самого заказчика, потому что именно у него есть доступ к существующим клиентам и возможность привлечь их к тестированию.

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

Базово сайт проверяет наша команда.

Если заказчик может и считает полезным привлечь представителей своей аудитории или сотрудников — получаем дополнительный источник обратной связи.

Это нормальная вариативность процесса.

Не каждый сайт требует одинаковой методологии проверки.

Заказчик может подключать к тестированию своих клиентов

У студии есть важное ограничение.

Мы можем изучить аудиторию.

Проанализировать конкурентов.

Разобрать отзывы.

Построить CJM.

Но существующие клиенты бизнеса находятся у заказчика.

Если компания хочет показать проект части своей аудитории до полноценного запуска, именно она может предоставить доступ к таким людям.

Тогда их реакция становится дополнительным материалом для проверки.

Нам важно разделять:

что мы гарантированно делаем внутри своего процесса

и

что возможно сделать дополнительно при участии заказчика.

Внутренняя проверка продукта — наша обязанность.

Привлечение реальных клиентов бизнеса требует участия самого бизнеса.

Почему тестирование начинается намного раньше финального этапа

Формально в нашем процессе есть отдельная стадия «тестирование и демо».

Но качество сайта закладывается раньше.

Если на интервью неправильно поняли аудиторию, техническое тестирование это не исправит.

Если в прототипе заложили неправильный сценарий, Playwright может идеально подтвердить, что неправильный сценарий работает.

Если дизайн не учитывает задачу пользователя, отсутствие ошибок в коде не сделает его автоматически эффективным.

Поэтому этапы связаны между собой.

Сначала мы разбираемся в бизнесе.

Потом проектируем CJM, структуру и CTA.

Защищаем концепцию.

Разрабатываем.

И только после этого можем проверить, совпадает ли реальный продукт с тем, что проектировали.

Почему решения появляются именно в такой последовательности, мы подробнее объясняем в статье «Как мы принимаем и защищаем решения в дизайне сайта».

Правки после тестирования тоже должны иметь причину

Тестирование может выявить проблему.

Тогда решение нужно корректировать.

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

Мы сохраняем тот же принцип, что и при согласовании дизайна:

сначала понимаем проблему, потом выбираем решение.

Если тест показал, что пользователь не понимает следующий шаг, нужно выяснить почему.

Если не сработала интеграция — исправить дефект.

Если представитель аудитории не нашёл важную информацию — пересмотреть конкретный сценарий.

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

Как мы разделяем обычные корректировки и изменение scope проекта, подробно рассказываем в статье «Правки при разработке сайта: почему мы не просто делаем всё, что просит заказчик».

После проверки сайт готовим к production

Когда основные сценарии проверены и обнаруженные проблемы исправлены, проект можно готовить к запуску.

На следующем этапе подключаем и проверяем то, что необходимо для рабочей эксплуатации:

• домен;
• SSL;
• аналитику;
• формы;
• необходимые интеграции;
• базовые SEO-настройки;
• favicon;
• другие согласованные элементы проекта.

Яндекс Метрика подключается как базовый инструмент аналитики, а цели, события, call tracking и email tracking используются по необходимости и по договорённости с заказчиком.

CRM также не появляется автоматически на каждом проекте.

Если она уже используется и интеграция предусмотрена — подключаем сайт к нужному процессу.

Если CRM в компании нет, сама разработка сайта не означает её автоматическое внедрение.

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

Запуск не доказывает, что сайт будет приносить продажи сам по себе

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

Но мы не обещаем клиенту:

«Мы всё протестировали, поэтому теперь сайт гарантированно принесёт сто заявок».

Так не работает.

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

Наша задача на этапе разработки — создать и проверить качественный инструмент.

Если после запуска сайт остаётся у нас на сопровождении, появляется следующий источник данных — реальное поведение пользователей.

И уже на его основе можно работать над CRO и дальнейшей оптимизацией конверсии.

Именно поэтому сайт для бизнеса — это больше, чем совокупность дизайна и кода.

Эту мысль отдельно раскрываем в последней статье нашего цикла — «Что на самом деле покупает бизнес, заказывая сайт у студии».

Почему тестирование — это часть отношения к клиенту

Заказчик не обязан самостоятельно искать сломанные формы после публикации.

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

Не должен использовать собственных клиентов как бесплатных QA-инженеров для поиска очевидных технических ошибок.

До передачи проекта наша задача — самим проверить то, что можем проверить.

И сообщить о проблемах, если они обнаружились.

Мы предпочитаем найти дефект до запуска и потратить время на исправление, чем передать формально «готовый» сайт и выяснять проблему уже после обращения клиента заказчика.

Для нас бережное отношение к бизнесу клиента выглядит в том числе именно так.

Не обещанием, что ошибок невозможно допустить.

А процессом, который помогает находить их раньше.

Сайт должен быть готов не к презентации, а к использованию

Есть большая разница между красивым макетом и продуктом, который можно отдать реальному пользователю.

Поэтому перед запуском мы задаём не только вопрос:

«Выглядит ли всё как в дизайне?»

Но и:

«Работает ли это?»

«Можно ли пройти все основные сценарии?»

«Доходит ли заявка?»

«Нормально ли сайт ведёт себя на разных экранах?»

«Достаточно ли быстро загружается?»

«Поймёт ли человек, что ему нужно сделать?»

Только после этого проект имеет смысл выпускать в production.

Потому что конечный результат нашей работы — не Figma и не репозиторий.

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

Есть задача по сайту? Начнём с понимания того, что нужно проверить

Тестирование не добавляется к проекту в самом конце как формальность.

Оно зависит от того, какую задачу решает продукт, какие сценарии в нём существуют и с какими системами он взаимодействует.

Поэтому всё начинается значительно раньше — с интервью о бизнесе.

Мы выясняем, что сайт должен делать, проектируем пользовательские сценарии, реализуем их, а затем проверяем перед запуском.

{здесь вставить CTA}

Обсудить разработку сайта с Sadovnikov.digital

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

[Записаться на интервью]