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

Question

Моя компания занимается многовариантным тестированием (я пока не могу раскрыть, какой именно), и меня попросят интегрировать свою систему в наш флагманский сайт B2C commerce.

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

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

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

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

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

Answer 1

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

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

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

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