Ошибку исправили — и на этом обычно всё заканчивается. Открыли страницу, она загрузилась, значит, работает. Через неделю ошибка возвращается, а вместе с ней и вопрос: что вообще проверяли в прошлый раз? Исправление ошибки — это не «кнопка нажата, экран не белый». Это подтверждение, что причина устранена, а не замаскирована, и что вместе с ней ничего не сломалось. Разберём, как проверять именно это.
Сначала отделите симптом от причины
Самая частая ловушка — принять исчезновение симптома за исправление. Белый экран пропал — значит, починили. Форма снова отправляется — значит, всё хорошо. Но симптом может уйти по случайной причине: кэш обновился, плагин перезагрузился, сервер перезапустился. А причина осталась и вернётся при первом удобном случае.
Поэтому перед проверкой нужно знать, что именно было причиной. Не «ошибка в плагине», а в каком плагине, в какой строке, из-за чего. Если разработчик не может объяснить причину — это первый повод не принимать результат. Не из недоверия, а потому что без причины нельзя проверить, что она больше не проявляется.
Полезный вопрос разработчику звучит так: «Что именно сломалось и почему?» Хороший ответ содержит конкретику. Плохой — «ну, там конфликт был, мы поправили».
Проверьте, что ошибка не воспроизводится там, где была
Вернитесь к тому же сценарию, при котором ошибка возникала. Те же действия, та же страница, тот же браузер и устройство. Если ошибка была на телефоне — проверяйте на телефоне. Если в Safari — в Safari. Если при отправке формы с пустым полем — отправляйте именно так.
И проверьте несколько раз, а не один. Некоторые ошибки проявляются нестабильно: через раз, при определённой нагрузке, после определённого действия. Однократная проверка может случайно попасть в «удачный» момент и создать ложное впечатление, что всё в порядке.
Хорошая практика — прогнать сценарий трижды: сразу после исправления, через несколько часов и на следующий день. Именно повторная проверка отсекает исправления, которые держатся до первого обновления кэша или перезапуска.
Проверьте соседние сценарии
Любое исправление — это изменение в коде, а изменения редко бывают изолированными. Кнопка, которую чинили, могла потянуть за собой форму. Плагин, который обновили, мог задеть вывод на другой странице. Поэтому после проверки самой ошибки пройдитесь по тому, что рядом.
Если чинили отправку заявки — проверьте, что письмо приходит, заявка сохраняется и попадает туда, куда должна. Если чинили корзину — пройдите оформление заказа целиком, включая оплату и письмо о заказе. Если чинили вёрстку — проверьте соседние блоки и мобильную версию.
Составьте для себя короткий список «что ещё могло задеть» под каждый тип исправления. Это занимает пару минут и ловит большинство побочных эффектов.
Посмотрите на результат глазами пользователя
Бывает, что технически всё исправлено, но пользоваться стало неудобно. Форма отправляется, но сообщение об успехе появляется где-то внизу, и человек его не видит. Ошибка исчезла, но теперь кнопка неактивна без объяснений, и непонятно, что делать. Плагин обновили, и он работает, но интерфейс изменился до неузнаваемости.
Пройдите сценарий так, как его пройдёт обычный посетитель — без знания, где что лежит. Понятно ли, что произошло? Видно ли, что делать дальше? Если да, исправление можно считать полноценным. Если нет — это уже не баг, а недоработка, и её стоит обсудить отдельно, пока контекст свежий.
Проверьте условия, при которых было плохо
Ошибки любят определённые условия. Медленный интернет, мобильное устройство, авторизованный пользователь, полная корзина, конкретный браузер. Если ошибка проявлялась при одном из них, проверять нужно именно в этих условиях, а не в идеальных.
- Тот же браузер и устройство, где была ошибка.
- Мобильная версия, если ошибка связана с вёрсткой или формами.
- Медленное соединение, если дело было в таймаутах или загрузке.
- Состояние авторизации — вход в аккаунт меняет поведение многих страниц.
- Кэш очищен, и страница открыта заново, а не из памяти браузера.
Последний пункт особенно важен. Старые файлы в кэше могут скрывать исправление или, наоборот, создавать видимость ошибки, которой уже нет. Проверяйте в режиме инкогнито или с очищенным кэшем — иначе вы смотрите не на результат, а на прошлое.
Убедитесь, что ошибка не вернётся
Самый обидный вариант — исправление работает день, а потом всё возвращается. Причины бывают разные: обновление плагина, сброс настроек, кэш, конфликт с другим кодом, откат бэкапа. Спросите разработчика, что сделано, чтобы проблема не повторилась.
Иногда ответ простой: «это была ошибка в коде, теперь её нет». Иногда — честнее и полезнее: «мы поправили, но при следующем обновлении плагина это может снова сломаться, следите». Второй ответ не идеален, но он хотя бы даёт вам понимание риска.
Если проблема была системной — например, в настройках сервера или в конфликте двух плагинов, — стоит договориться о периодической проверке. Раз в месяц пробежаться по сценарию дешевле, чем узнать о возврате ошибки от клиента.
Зафиксируйте результат
Через месяц вы вряд ли вспомните детали. Поэтому короткая запись — что сломалось, в чём была причина, что сделали, как проверили — помогает и вам, и следующему подрядчику. Особенно если сайт ведут несколько человек.
Хорошо, если у ошибки есть номер или ссылка в трекере задач, а в задаче — комментарий о результате проверки. Это не бюрократия, а способ не наступать на те же грабли дважды. И заодно — понятный ответ на вопрос «а мы это уже чинили?».
Красные флаги
- Разработчик не может объяснить, в чём была причина.
- Ошибка воспроизводится при повторной проверке через день.
- Исправление работает только в одном браузере или на одном устройстве.
- Вместе с ошибкой сломалась соседняя функция, и об этом не предупредили.
- Проверяли только на тестовых данных, а не на реальных.
- Вам предлагают «закрыть задачу, потом разберёмся».
- Нет записи о том, что и как исправляли.
Один пункт — повод задать вопрос. Несколько — повод не принимать результат и обсудить его спокойно, но твёрдо.
Что в итоге
Проверка исправления — это не «открыл и всё работает», а подтверждение, что причина устранена, соседние сценарии целы, а ошибка не вернётся. Сценарий, условия, повторная проверка и запись результата — этого обычно достаточно, чтобы не чинить одно и то же дважды. И чтобы не узнать о возврате ошибки от раздражённого клиента.
Мы обычно принимаем исправления вместе с клиентом: показываем, что изменилось, проходим сценарии и объясняем, что проверять в следующий раз. Иногда за этим стоит одна строчка кода, иногда — пересборка целого блока, и в обоих случаях важно, чтобы результат был понятен не только разработчику. Напишите или оставьте заявку — поможем разобраться, что происходит с сайтом, и скажем, какие исправления стоит принять, а какие — отправить на доработку.