2026-10-26
Прогон — не просто этап тестирования. Это момент истины: когда код встречается с реальными условиями, а теория сталкивается с нагрузкой, ошибками ввода и непредсказуемым поведением пользователя. Мы проводим десятки прогонов ежемесячно — не в изолированных средах, а в условиях, максимально приближенных к эксплуатации наших инженерных решений: от управления логистикой поставок оцинкованных C-профилей до автоматизации расчётов несущей способности стальных каркасов. Именно здесь выявляются неочевидные сбои: например, когда API модуля подбора профнастила корректно обрабатывает 100 запросов в минуту, но «падает» при 101-м из-за утечки памяти в цикле проверки толщины цинкового покрытия.
Прогон — это запуск программного обеспечения в целостной конфигурации с реальными или смоделированными данными, целями и ограничениями. Он отличается от unit-теста тем, что проверяет взаимодействие компонентов: как модуль расчёта нагрузок на Z-профиль передаёт параметры в модуль подбора крепежа, как система учёта складских остатков цветного профлиста синхронизируется с CRM-системой партнёра в Минске. Мы видели, как 97 % unit-тестов проходят успешно, но при первом же прогоне с образцами данных заказчика (с 128 типами зданий для животноводства и 47 вариантами климатических зон) возникает ошибка сериализации в JSON-экспорте технических паспортов. Прогон вскрывает именно такие «стыковые» проблемы — там, где границы модулей пересекаются с человеческими шаблонами работы.
Наши инженеры выделяют три обязательных фазы — и отказались от двух «традиционных», но бесполезных:
Мы исключили «предварительный прогон» и «финальный прогон» — они создают иллюзию контроля. Реальный прогон должен быть единственным, но исчерпывающим.
Некоторые считают: если прогон прошёл — система готова. Но мы столкнулись с ситуацией, когда прогон на 1500 строках входных данных завершился успешно, а при первой же поставке партии оцинкованных профилей в Ростовскую область (где требовалось динамическое пересчитывание веса с учётом влажности воздуха и температуры стали) система выдала расхождение в 4,7 %. Причина — в жёсткой привязке к стандартному значению плотности цинка, без учёта отклонений в 0,3 %, допустимых по ГОСТ 14918-80. Прогон не имитировал реальные условия измерения на складе. Вывод: данные для прогона должны включать не только «норму», но и граничные значения из технических регламентов и полевых измерений.
Для нас прогон — это не задача QA-инженера, а совместная работа: проектировщик указывает критические точки нагрузки, логист предоставляет реальные временные рамки доставки, монтажник описывает частые ошибки при сборке узлов крепления. Такой подход позволил сократить количество доработок после внедрения ПО для подбора модульных зданий на 63 %. Прогон перестаёт быть «проверкой на работоспособность» и становится «диалогом между цифровой моделью и физическим миром». Именно поэтому каждый успешный прогон заканчивается не отчётом, а совместным анализом: что в реальности работает иначе, чем в модели — и как это изменить в следующей версии. Это не тестирование. Это сопоставление цифрового решения с требованиями стальных конструкций, которые стоят на земле — и будут стоять ещё 50 лет.
