или авторизуйтесь, если у вас он уже есть
1. Разнообразные источники сбоев и шума (некорректные данные, обновления кода исследуемой базы, коллизии многопоточной работы, влияние наблюдателя, ошибки тестирующей оснастки и пр.) влияют на валидность, сроки и стоимость тестов
2. Способы повышения робастности системы тестирования на примере гибридной Python+1С системы, и обратная сторона решений
2.1. Неинвазивность - снимает целые классы проблем, но требует внешнего не-1С-кода движка (который надо поддерживать) и веб-клиента 1С
2.2. "Консультант-френдли" хранение и управление тестом из 1С - возможность сохранять сценарии, доступность создания тестов для не-программистов, но снова необходимость поддерживать движок, и все равно это абстракция, хотя и проще, чем Gherkin
2.3. Распределенные стартеры-агенты - снимаем зависимость от ограничений терминального сервера и RDP-сессии, но надо делать оркестрацию
2.4. Снижение перфекционизма при старте и финише - работа стартует и завершается, но у заказчика появляются вопросы
2.5. Хоткеи и "Умные локаторы" - действия гарантированно выполняются, но распухает глоссарий
2.6. Промежуточный сбор логов - не теряются логи при аварии агентов, но это шум
2.7. Аналоги "Goto" в сценариях - обходим ошибки (в данных, в многопотоке), но "возвращаемся к программированию"
3. Вывод. Учим систему выполнять задачу вопреки обстоятельствам, а не благодаря идеальным условиям