Как снизить риск при внедрении многомерного тестирования в динамическое веб-приложение?
Моя компания сотрудничает с поставщиком многомерного тестирования (я пока не могу назвать, какой именно), и меня просят интегрировать их систему в наш ведущий коммерческий сайт B2C.
Обычно слово "интегрировать" является термином с большой нагрузкой. Тем не менее, здесь это означает, что нужно добавить <script> пометьте несколько видов, а затем выходите из цикла с этого момента. Многовариантные эксперименты будут организованы нашим отделом маркетинга (и / или поставщиком). Наша команда разработчиков не будет вовлечена в это и может даже не знать, когда это произойдет.
По сути, мне говорят, что мы намеренно добавляем вектор атаки с использованием JavaScript-инъекций в наше ведущее приложение... и надеемся на лучшее. Мои опасения связаны не столько с вредоносным кодом, сколько с непреднамеренными взломами. Наш CSS и базовый макет страницы уже в беспорядке, и я ожидаю разгораться, когда чей-то многомерный эксперимент взрывает внешний вид домашней страницы и т. Д. Гораздо важнее то, что существует много уродливых AJAX и серверной части. Cruft, который зависит от предсказуемых элементов HTML, id атрибуты и т. д.... и поэтому, если эксперимент слишком сильно изменит элементы HTML, основные функции коммерции просто будут совершенно непредсказуемыми.
Мои опасения усиливаются из-за отсутствия реальной тестовой среды. Поставщик выполняет фильтрацию, поэтому обрабатываются только вызовы AJAX с нашего производственного URL. Звонки из нашей среды Dev или QA игнорируются. Однако это не то же самое, что наличие тестовой среды. Скорее это означает, что производство теперь является нашей тестовой средой для каждого эксперимента.
Учитывая все вышеперечисленное, существуют ли какие-либо методы, доступные для смягчения некоторых из этих рисков? Многофакторное тестирование - это такая новая область, первые несколько страниц поиска в Google состоят из сомнительных консультантов, продающих модные слова ИТ-директорам. Там не так много написано для внутренней технической аудитории, в конечном итоге ответственной за отслеживание риска. Существуют ли какие-либо способы надлежащего контроля качества при указанных выше ограничениях, или просто нет альтернативы, кроме как отодвинуть (*) в таком сценарии?
(*) Примечание. Учитывая политику взаимоотношений с поставщиками, нам необходимо создать чрезвычайно герметичный вариант для отталкивания, и в любом случае его можно игнорировать.
1 ответ
Вы должны помнить, что многовариантное тестирование - это не тестирование в том смысле, в каком вы думаете (или не должно быть). Вы не должны тестировать код или контент. Вы проверяете реакцию посетителей на этот контент.
Это означает, что контент, который должен быть протестирован вашим поставщиком, должен пройти некоторый процесс обеспечения качества перед его развертыванием на их платформе. Таким образом, это должно указывать на то, что лучший способ уменьшить риски, о которых вы беспокоитесь, - это вовлечь себя в цикл тестирования / подготовки к выпуску, чтобы обеспечить безопасность и стабильность их кода до его выхода. Вам не нужно (и не нужно) откладывать их усилия с помощью полных регрессионных тестов или чего-то в этом роде. Но вы можете взять на себя инициативу, чтобы настроить очень специфический набор тестов для динамического контента, который будет проходить до того, как он перейдет в prod.
Если поставщик стоит своего веса в [вставить любой материал здесь], то он должен был уже учесть это в своих процессах или, по крайней мере, быть в состоянии удовлетворить такой запрос. Это не слишком много, чтобы попросить, чтобы вы получили некоторые с высоты птичьего полета, прежде чем какой-либо код риска проникновения.
Или... получите отказ, подписанный, освобождающий вас от любой ответственности за безопасность или производительность во время учений поставщика.:)