Согласен, для небольших команд дополнительные затраты без жестких требований со стороны регулятора могут быть избыточны. В статье я как раз делаю акцент на тех, кто перерос "ручной" режим и хочет выстроить IT-инфраструктуру под свои бизнес-процессы (в т.ч. с заделом на будущее). Использование специализированных сервисов как раз решает упомянутую вами проблему скорости: вместо того чтобы в критический момент собирать цепочку подписей вручную, процесс автоматизируется. Это вопрос выбора между экономией на софте и экономией времени сотрудников.
Бесплатные инструменты (типа МAX, Госключ, базовый VipNet) — это отличный "аварийный" вариант для разовой подачи. Их всегда будут предлагать, чтобы снизить порог входа. Но профессиональное ПО — это не "гемор", а стандартизация, принятая в крупном промышленном и гражданском проектировании, где важно качество архива, а не просто факт успешной загрузки файла на портал сегодня утром.
Добрый день! По данному вопросу лучше направить официальный запрос в ГГЭ (по ипользуемому формату подписи на определенный вид документации). Техподдержка, скорее всего, подтвердит лишь техническую возможность работы с форматом, но не возьмет на себя ответственность за прогнозирование сроков хранения документации. Сейчас требования ГГЭ могут носить рекомендательный характер, но важно учитывать критический нюанс: обычная подпись (CAdES-BES) перестает проходить автоматическую проверку сразу после истечения срока действия сертификата. Поскольку проектная документация должна быть валидной годами, использование форматов с меткой времени (TSP) и данными об отзыве (OCSP/CRL) — это единственный способ обеспечить долгосрочную юридическую значимость. В статье я разобрал оба варианта, чтобы подсветить эти риски.
Да, он определенно лучше, (например, по скорости) если нужно тестировать веб-приложения. Но и там возникают проблемы, например, при составлении тестов на взаимодействие с файловой системой (на JS делать это проблематично). Appium все-таки затачивался для тестирования мобильных приложений нативных, гибридных, и как необходимость, веб-приложений. Поэтому мы целенаправленно провели разделение проектов и под каждый выбрали подходящий фреймворк.
Добрый день. Мы уже используем playwright для тестирования веб-сервисов (задействуем typescript(js)) и Desktop приложений. Для мобильных решили попробовать что-то другое, чтобы было с чем сравнить и не зацикливаться только на одном решении.
Согласен, для небольших команд дополнительные затраты без жестких требований со стороны регулятора могут быть избыточны. В статье я как раз делаю акцент на тех, кто перерос "ручной" режим и хочет выстроить IT-инфраструктуру под свои бизнес-процессы (в т.ч. с заделом на будущее). Использование специализированных сервисов как раз решает упомянутую вами проблему скорости: вместо того чтобы в критический момент собирать цепочку подписей вручную, процесс автоматизируется. Это вопрос выбора между экономией на софте и экономией времени сотрудников.
Бесплатные инструменты (типа МAX, Госключ, базовый VipNet) — это отличный "аварийный" вариант для разовой подачи. Их всегда будут предлагать, чтобы снизить порог входа. Но профессиональное ПО — это не "гемор", а стандартизация, принятая в крупном промышленном и гражданском проектировании, где важно качество архива, а не просто факт успешной загрузки файла на портал сегодня утром.
Добрый день! По данному вопросу лучше направить официальный запрос в ГГЭ (по ипользуемому формату подписи на определенный вид документации). Техподдержка, скорее всего, подтвердит лишь техническую возможность работы с форматом, но не возьмет на себя ответственность за прогнозирование сроков хранения документации. Сейчас требования ГГЭ могут носить рекомендательный характер, но важно учитывать критический нюанс: обычная подпись (CAdES-BES) перестает проходить автоматическую проверку сразу после истечения срока действия сертификата. Поскольку проектная документация должна быть валидной годами, использование форматов с меткой времени (TSP) и данными об отзыве (OCSP/CRL) — это единственный способ обеспечить долгосрочную юридическую значимость. В статье я разобрал оба варианта, чтобы подсветить эти риски.
Да, он определенно лучше, (например, по скорости) если нужно тестировать веб-приложения. Но и там возникают проблемы, например, при составлении тестов на взаимодействие с файловой системой (на JS делать это проблематично). Appium все-таки затачивался для тестирования мобильных приложений нативных, гибридных, и как необходимость, веб-приложений. Поэтому мы целенаправленно провели разделение проектов и под каждый выбрали подходящий фреймворк.
Добрый день. Мы уже используем playwright для тестирования веб-сервисов (задействуем typescript(js)) и Desktop приложений. Для мобильных решили попробовать что-то другое, чтобы было с чем сравнить и не зацикливаться только на одном решении.