Как снизить риск при внедрении многомерного тестирования в динамическое веб-приложение?

Question

Моя компания сотрудничает с поставщиком многопараметрического тестирования (я пока не могу назвать, какой именно), и меня просят интегрировать их систему в наш ведущий коммерческий сайт B2C.

Обычно слово«интегрировать» - это сверхмощный термин.Однако здесь это означает добавление тега <script> в несколько представлений, а затем выход из цикла с этого момента.Многовариантные эксперименты будут организованы нашим отделом маркетинга (и / или поставщиком).Наша команда разработчиков не будет вовлечена в это и может даже не знать, когда это произойдет.

По сути, мне говорят, что я намеренно добавляю вектор атаки JavaScript-инъекцией в наше ведущее приложение ... и надеюськ лучшему.Мои опасения связаны не столько с вредоносным кодом, сколько с непреднамеренными взломами.Наш CSS и базовый макет страницы уже в беспорядке, и я ожидаю разгораться, когда чей-то многомерный эксперимент взрывает внешний вид домашней страницы и т. Д. Гораздо важнее то, что существует много уродливых AJAX и на стороне сервера.что зависит от предсказуемых элементов HTML, id атрибутов и т. д., и поэтому, если эксперимент слишком сильно изменит элементы HTML, функциональность основной коммерции просто непредсказуемо рухнет.

Мои опасения усиливаютсяотсутствие реальной тестовой среды.Поставщик выполняет фильтрацию, поэтому обрабатываются только вызовы AJAX с нашего производственного URL.Звонки из нашей среды Dev или QA игнорируются.Однако это не то же самое, что наличие тестовой среды.Скорее это означает, что production теперь является нашей тестовой средой для каждого эксперимента.

Принимая во внимание все вышеперечисленное, существуют ли какие-либо методы, позволяющие снизить некоторые из этих рисков? Многофакторное тестирование - это такая новая область, первые несколько страниц поиска в Google состоят из сомнительных консультантов, продающих модные слова ИТ-директорам.Там не так много написано для внутренней технической аудитории, в конечном итоге ответственной за отслеживание риска.Существуют ли какие-либо способы надлежащего обеспечения качества в соответствии с вышеуказанными ограничениями, или просто нет альтернативы, кроме как отодвинуть (*) в таком сценарии?

(*) Примечание: Учитывая политику взаимоотношений с поставщиками, мыпотребуется создать чрезвычайно герметичный корпус для отталкивания, и его можно игнорировать в любом случае.

Answer 1

Вы должны помнить, что многовариантное тестирование - это не тестирование в смысле того, что вы думаете (или не должно быть).Вы не должны тестировать код или контент.Вы проверяете реакцию посетителей на этот контент.

То есть ... контент, который должен быть протестирован вашим поставщиком, все же должен пройти через некоторый процесс обеспечения качества перед его развертыванием на их платформе.Таким образом, это должно указывать на то, что лучший способ снизить риски, о которых вы беспокоитесь, - это ввести себя в цикл тестирования / предварительной версии, чтобы обеспечить безопасность и стабильность их кода до его выхода.Вам не нужно (и не хотите) рассказывать о своих усилиях с помощью полных регрессионных тестов или чего-то подобного.Но вы можете взять на себя инициативу, чтобы установить очень специфический набор тестов для динамического контента, который будет проходить до того, как он перейдет к продукту.

Если поставщик стоит своего веса в [вставьте сюда любой материал], тогда ондолжны были уже учесть это в своих процессах или, по крайней мере, быть в состоянии удовлетворить такой запрос.Это не слишком много, чтобы попросить, чтобы вы получили подпись с высоты птичьего полета до того, как будет введен какой-либо код с риском вторжения.

Или ... получите отказ, подписанный, освобождающий вас от любой ответственности за безопасность или производительность во время вендора.упражнения.:)