Почему «готово» — не значит «всё сделано»: как проверять цифровые системы, чтобы не потерять бизнес в России

В блоге CMS Magazine вышел разбор о том, как система может показать «готово» даже при отсутствии реального результата. Это не про ошибку — это про то, как проверка может быть обманута. Я считаю, что такие сценарии уже не редкость, а стандарт, если не проверять результаты.

О чём речь и почему я считаю это важным для бизнеса

Речь не о баге, а о логике проверки. Система может вернуть «успешный» ответ, даже если ничего не изменилось. В статье описан случай: запрос на обновление объекта №123 завершился с кодом 200, но проверяли не тот объект. Итог — «готово», хотя ничего не изменилось. Это не техническая ошибка — это отсутствие проверки результата.

Я считаю это важным, потому что в бизнесе цифровые системы — не просто «работают» или «не работают». Они либо ускоряют процессы, либо создают ошибки, которые никто не замечает. Если система говорит «всё сделано», но не проверяет, что именно сделано, она не упрощает работу — она скрывает риски.

Когда вы платите за интеграцию, ИИ или автоматизацию, вы не покупаете статус «готово». Вы покупаете результат. И если проверка не учитывает сам результат, а только статус ответа, вы рискуете получить систему, которая «работает», но ничего не делает.

Как это устроено — что тут вообще происходит

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

В статье приведён пример с пакетным обновлением десяти карточек. Система вернула «успешный» ответ, но два изменения были отклонены из-за отсутствия полей. При этом никто не проверил, какие именно изменились. Итог — «всё выполнено», хотя часть данных не обновилась.

Ещё один пример — проверка по количеству. Система получила только первую страницу каталога из 1000 позиций. Но так как она «получила данные», считается, что всё проверено. А на деле — 90% не проверены. Это не баг, это логика, которая не учитывает масштаб.

Что изменилось на рынке: как делали раньше и как делают сейчас

Раньше проверка была ручной, медленной, но прозрачной. Специалист смотрел, что изменилось, сравнивал, делал отчёт. Сейчас всё быстрее, автоматизированнее — и в этом кроется риск. ИИ и автосистемы ускоряют работу, но при этом могут «забывать» проверять то, что важно.

Раньше проверяли по шагам: что было, что стало, где ошибка. Сейчас — по статусу: «принято», «выполнено», «готово». Это удобно, но опасно. Особенно если проверка не включает проверку результата.

Сейчас рынок перешёл от «сделали что-то» к «сделали то, что нужно». И если система не проверяет, что именно сделано, она не соответствует новой парадигме. Работающий сайт — это не достижение. Он должен зарабатывать, а не просто «работать».

Кому это касается и как понять, что это про ваш проект

Это касается любого, кто использует автоматизацию, интеграции, ИИ или внешних сервисов. Особенно если вы:

— запускаете обновления с помощью API;

— интегрируете 1С, CRM, склад или маркетплейс;

— используете ИИ для генерации контента, настроек, карточек;

— передаёте данные между системами.

Если вы не проверяете, что именно изменилось, а только смотрите, что система «ответила», вы в зоне риска. И если вы видите, что в отчёте написано «всё выполнено», но вы не видите изменений — это тревожный сигнал.

Что с этим делать — порядок действий в общем виде

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

Проверяем три числа: сколько объектов было в задаче, сколько получено, сколько успешно обработано. Если не совпадает — значит, что-то упущено.

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

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

Просим показать реальный результат: не локальный предпросмотр, а публичный URL, не тестовый аккаунт, а рабочий, не квитанцию, а изменённый объект.

Проверка — это не статус, это результат

Мы не проверяем, что система «приняла» запрос. Мы проверяем, что он «изменил» то, что нужно. Это разница между «работает» и «работает правильно».

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

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

Именно так мы работаем: не с «готово», а с «проверено».

Это часть нашей работы — Контроль качества. Автоматическое и ручное тестирование сайтов. Улучшение качества существующих проектов. Контроль качества

Автор: Святослав Семенов из Cetera Labs

Новость для бизнеса в Рязани, Россия