Сайт запущен, но заказы не доходят до CRM, мобильная версия ломается, а часть обещанных функций отсутствует. Разработчик отвечает, что всё сделано по техническому заданию. В такой ситуации полезнее начать не с формулировки «сайт не работает», а с конкретных требований, версии проекта и воспроизводимых проверок.

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

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

1. Определите, о каком результате вы спорите

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

Запишите адрес сайта, спорную дату или период, название этапа и перечень переданных материалов. Отдельно отметьте, кто и когда менял проект после передачи: подрядчик, штатный администратор, другая студия. Если это неизвестно, так и укажите — не превращайте предположение в факт.

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

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

2. Переведите претензии в проверяемые требования

Удобный рабочий формат — таблица «требование → проверка → результат». Для каждой претензии нужны ссылка на основание, последовательность действий и наблюдаемое отличие.

Требование Как проверить Что зафиксировать
Заявка передаётся в CRM Отправить согласованную тестовую заявку и проверить запись Время, идентификатор, ответ сайта, результат в CRM
Фильтр учитывает два параметра Выбрать определённые значения на известном наборе товаров Параметры, исходные данные, фактическую выдачу
Есть мобильный макет формы Открыть форму на согласованной ширине экрана Размер окна, браузер, перекрытия и доступность полей
Предусмотрен импорт каталога Загрузить подготовленный тестовый файл Версию файла, журнал импорта, пропуски и ошибки

Фраза «удобный интерфейс» допускает разные трактовки. Условие «после отправки формы появляется номер заявки» проверяется значительно точнее. Если критерий в документах не определён, это отдельное ограничение исследования, а не повод задним числом объявлять собственное ожидание согласованным требованием.

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

3. Сохраните состояние до исправлений

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

У копии должны быть понятны происхождение, время получения, состав и ответственный за передачу. Полезно вести опись файлов и контрольных сумм. Контрольная сумма помогает сравнивать полученные копии, но сама по себе не устанавливает автора файла или момент его создания: криптографическое хеширование вычисляет значение из содержимого. Как устроен digest — MDN.

Если разработка велась в Git, запросите историю репозитория и идентификатор исследуемого коммита. При этом Git-архив не равен полной копии работающего сайта. Официальная документация отдельно предупреждает: git bundle сохраняет выбранную историю и ссылки, но не всё локальное состояние, включая рабочие файлы вне этой истории и конфигурацию репозитория. Базу данных, пользовательские загрузки и окружение надо учитывать отдельно. Документация git bundle.

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

4. Зафиксируйте ошибку так, чтобы её можно было повторить

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

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

Для проблем с интеграциями специалисту может понадобиться журнал сетевых запросов HAR. Chrome DevTools умеет сохранять такой журнал; вариант sanitized исключает некоторые чувствительные заголовки. Однако это не повод считать любой экспорт безопасным: содержимое запросов и ответов всё равно стоит проверить перед передачей. Сохранение HAR в Chrome DevTools.

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

5. Не путайте замер скорости с выводом о качестве всей работы

«Вчера было 92 балла, сегодня 58» — повод разобраться, но не самостоятельный вывод о виновнике. Lighthouse зависит от условий запуска: устройства, сети, расширений браузера и изменяющегося содержимого страницы. Разработчики инструмента рекомендуют учитывать разброс результатов. Оценка производительности Lighthouse.

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

Учитывайте кеширование: повторное открытие может использовать ранее сохранённые ресурсы, а не заново получать всё с сервера. Браузерный кеш — лишь один из возможных уровней; между пользователем и приложением могут работать промежуточные кеши. Обзор HTTP-кеширования — MDN.

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

6. Сформулируйте вопросы в пределах технического исследования

Хороший вопрос связывает объект, критерий и проверяемый факт. Например:

  1. Какие функции из перечисленных пунктов ТЗ реализованы в переданной версии?
  2. Воспроизводится ли указанная ошибка при описанных условиях?
  3. Какие технические различия имеются между двумя представленными версиями?
  4. На каком этапе передачи данных возникает обнаруженный сбой интеграции?
  5. Достаточны ли представленные исходники и инструкции для воспроизведения сборки?
  6. Какие материалы отсутствуют для ответа на оставшиеся вопросы?

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

7. Пример: форма показывает успех, а заявки нет

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

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

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

Чек-лист перед обращением

  • Сформулированы спорный этап, версия и дата.
  • Собраны ТЗ, макеты и согласованные изменения.
  • Требования отделены от пожеланий по улучшению.
  • Есть перечень дефектов с шагами воспроизведения.
  • Сохранена доступная копия до исправлений.
  • Описаны источник материалов и последующие изменения.
  • Уточнены доступы к коду, серверу, базе и интеграциям.
  • Согласован безопасный способ передачи данных.

Не обязательно иметь весь список уже на первом разговоре. Достаточно описать предмет спора и перечислить доступные материалы: после этого можно определить объём проверки и то, чего не хватает.

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

Можно исследовать сайт без исходного кода?

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

Что делать, если подрядчик уже исправил дефект?

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

Достаточно ли одного скриншота?

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

Нужен ли доступ администратора?

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

Чем экспертиза отличается от обычного аудита сайта?

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

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