در این نوشته سعی میشود برای سیستم های شامل a/b تست معماری ارائه شود که تا حد خوبی دغدغه های ذینفعان و توسعه دهندگان این سیستم ها را کاهش دهد. طبیعی است که موارد استفاده a/b تست در سیستم و اپلیکیشن ها با توجه به نیازمندی ها بسیار متنوع است و امکان اینکه یک نسخه واحد برای معماری همه آن ها در نظر گرفت، شاید ممکن نباشد اما در این مقاله سعی شده با استفاده از مطالعه و تجربه افراد مختلف نیازمندی های پر تکرار و غالب در این تست را جمع آوری و بر اساس آن ها راه کاری ارائه شود.
در فضای پر رقابت امروزی داشتن بازخورد کاربر و تجربه آن نسبت به هر تغییر یا ویژگی جدید برای تصمیم گیری درست نسبت به تغییر، ماندگاری یا حذف استراتژی کنونی بسیار مهم است همچنین امروزه ایده های (بعضا مشترک) زیادی به سرعت توسط شرکت های مختلف توسعه داده میشود که اهمیت اینکه بین این ایده ها کدام یک بهترین نتیجه را به همراه خواهد داشت و به چه شکل متناسب با نیازمندی های ما باید در سیستم ماندگار شود بسیار زیاد است. بنابراین برای اینکه بهترین تصمیم گیری را داشته باشیم خوب است همیشه بتوانیم بازخورد کاربر را داشته باشیم و امکان مقایسه بین حالت های مختلف پیاده سازی یک نیازمندی را (که تا حد امکان به جز تفاوت در موارد از پیش تعیین شده و توافق شده، در شرایط یکسان توسط کاربر تجربه شده باشند) داشته باشیم.
این تست برای این است که شما تاثیر تغییر یا افزودن یک ویژگی مشخص را در دو استراتژی و طراحی جدا، از تحلیل روی بازخورد مشتری یا اطلاعات دریافتی از کاربر مشخص کنید و بوسیله ی این نتیجه گیری و مقایسه بهترین تصمیم را برای ماندگاری یکی از روش ها بگیرید.
معمولا افراد وقتی برای بار اول در مورد a/b تست جست و جو میکنند مقالات سعی میکنند با ترکیبی از تست قناری و یک مثال در مورد تغییر یک قسمت از فرانت اپلیکیشن (مثلا تغییر رنگ یا تعویض مکان یک button)این تست را توضیح دهند، همچنین نمونه های کمی از تجربه شرکت های بزرگ در زمینه به کار گیری این نوع تست وجود دارد. در این نوشته سعی شده است تمرکز بیشتری روی موارد کاربرد این نوع تست در نیازمندی های دیگر به خصوص در سمت بک اند (به طور مثال استفاده از مدل های AI یا یک provider خارجی) شود.
این مشکلات برای سیستم هایی که همواره در حال توسعه و اجرای سناریو های مختلف a/b تست هستند پیش می آید و اگر سیستم کوچکی وجود دارد یا تعداد بسیار محدود a/b تست با سناریو های مشابه در آن صورت با این دست مشکلات مواجه نخواهد شد.
همان طور که گفته شد امروزه این نوع تست بسیار پر کاربرد هستند و نیازمندی های جدید از سمت cator های مختلف(تیم مارکتینگ، فنی و ....) برای اجرای a/b تست را میتوان به دو دسته کلی زیر تقسیم کرد:
موضوع مهم توانایی سیستم برای پذیرش تعداد بالای این تست ها با سناریو های متفاوت است که حتما باید در طراحی معماری آن مواردی در نظر گرفته شود در غیر این صورت سیستم توانایی پیاده سازی این نوع تست ها را نخواهد داشت.
معماری این سیستم ها برای اینکه بتوانند نیازمندی های مطرح شده از سمت actor های مختلف برای اجرای سناریو های متفاوت تست را در کمترین زمان ممکن پاسخگو باشند (اهمیت زمان در بسیاری موارد به دلیل فضای رقابتی بین شرکت های مختلف است) باید شامل یک سری ویژگی ها باشند که در قسمت زیر به تفکیک نام برده شده اند:
انعطاف پذیری سیستم برای پیاده سازی سناریو های تست و نیازمندی ها مرتبط با آن به نوعی که روند معمول توسعه و نگهداری سیستم را با مشکل مواجه نکند(زیرا همان گونه که گفته شد در مورد سیستم های بزرگ با تعداد اجرای بالای سناریو های a/b تست صحبت میکنیم). در بسیاری از سناریو های تکراری ایجاد روند اتوماتیک برای اجرای a/b تست ضروری است زیرا در غیر اینصورت علاوه بر کند شدن روند اجرای تست تیم توسعه و فنی درگیر فرایند های تکراری میشود.
استفاده از معماری میکروسرویس برای پاسخگویی به موارد ذکر شده و maintainable بودن توصیه میشود زیرا با جداسازی منطقی بخش های مختلف سیستم در سرویس های مشخص به راحتی میتوان با توجه به تعریف، سطح (نزدیکی به بیزینیس لاجیک) و پیچیدگی آن a/b تست های مرتبط با هر کدام از سرویس ها را مشخص کرد. به عنوان مثال سرویس مرتبط با پرداخت و سرویس نمایش موجودی و تراکنش ها ی کاربر در معماری میکروسرویس به صورت دو سرویس جداگانه هستند که سناریو های a/b تست متفاوتی هم دارند (برای سرویس پرداخت استفاده از درگاه های پرداخت مختلف و برای سرویس نمایش تغییر فرمت و رنگ های نمایش و ...). بنابراین با تفکیک سرویس ها علاوه بر جداسازی دغدغه ها و نیازمندی ها بین سرویس ها و تیم های جداگانه میتوان طراحی و راه حل های اختصاصی برای هر یک از سرویس ها متناسب با وظیفه و کارکرد آن ها داشت، این کار روند خودکار سازی سناریو های تکراری a/b تست را هم بسیار راحت تر میکند،به عنوان مثال سرویس های یکسان صرفا با کانفیگ های مختلف در production بالا بیایند که باعث میشود عملکرد مورد نیاز برای a/b تست را داشته باشند.
با توجه به اینکه b/a تست ها در بازه زمانی خاصی اجرا میشوند و نتایج بازخورد کاربر یا به طور کلی تغییرات در بازه خاصی برای مقایسه و اعتبار سنجی تست انتخاب میشوند در صورتی که سیستم در این بازه زمانی در دسترس نباشد یا عملکرد درست خود را از دست بدهد میتوان گفت سیستم قابلیت اجرای این نوع از تست ها را ندارد.
فیدبک یا رفتار کاربر در a/b تست ذخیره میشود تا بوسیله تحلیل روی این داده ها و مقایسه گروه های مختلف وضعیت تاثیر تغییرات جدید و مقایسه بین عملکرد گروه های مختلف صورت بگیرد, بنابراین اجرای a/b تست ها برای همه گروه ها باید با شرایط درست و یکسانی اجرا شود. اگر تفاوتی در اجرای تست گروه ها به دلیل خطاها، در دسترس نبودن سرویس یا مشکل در بخشی از امکانات و ابزار های مورد نیاز آن ها باشد دیگر داده های جمع آوری شده در زمان a/b تست قابل استناد نیستد.
با توجه به اینکه در b/a تست گروه های مختلف تست بوجود می آید که رفتار های های متفاوت دارند و در مواردی نیازمند منابع اضافه (ذخیره داده های مربوط به ورودی و خروجی قسمت یا قسمت های مورد تست، تغییر مدل AI که نیاز به داده بیشتری برای predict کردن دارد،اضافه کردن سرویس جدید و افزایش تعداد connection های بین سرویس ها و ...) در سرویس ها یا ابزار های مورد استفاده خود هستند باید توجه داشت performance سیستم تحت تاثیر قرار نگیرد.
البته باید درنظر گرفت منظور از performance در اینجا performance ویژگی های مورد تست نیست و performane موارد a و b در a/b تست میتواند در تحلیل نهایی تاثیر گذار باشد(مثلا performance دو الگوریتم برای محاسبات مالی) ، یعنی مثلا با افزایش منابع یکی از موارد a یا b (به صورتی که بیشتر از نیازمندی منطقی آن ها باشد) در a/b تست باعث نابرابری در شرایط تست آن ها شویم و در نهایت با توجه به نادرستی داده های تست دچار نتیجه گیری اشتباهی شویم.
استفاده از ابزار های مناسب (مثلا دیتابیس، cache و ...) با نیازمندی های تست نیز در performance تاثیر گذار است (مثلا استریم داده ها در kafka و ذخیره آن ها در فرمت مناسب در دیتابیس nosql یا sql)
در مواردی زیادی از سناریو های a/b تست شاهد ایجاد نیازمندی جدیدی هستیم، که در بسیاری از این موارد باید سرویس و ساختار فعلی ما بدون تاثیرات منفی (هزینه زمان و منابع زیاد، تغییرات زیاد ساختاری و ...) قابلیت رشد داشته باشد. به طور مثال قابلیت پردازش داده های بیشتر، قابلیت پاسخ به درخواست های بیشتر، توانایی scale شدن متناسب با حجم پردازش یا تعداد درخواست ها و ... همچنین باید ابزار های وابسته به سرویس ها یا ماژول هم scalable باشند. به طور مثال فضای ذخیره سازی داده ها یا استریم های مورد استفاده باید قابلیت دریافت حجم بیشتری از داده ها را در زمان تست داشته باشند.
اهمیت وجود مانیتورینگ برای سیستم های نرم افزاری بسیار مهم است و از کاربرد های آن میتوان به شناسایی رفتار سیستم در بازه های مختلف زمانی، دلیل رفتار های غیر معمول، وضعیت منابع، گزارش گیری و... را نام برد. تمامی موارد نام برده شده در اجرای تست و تحلیل آن بسیار مهم است. اگر در بازه زمانی تست مشکلی ایجاد شود با سرعت بالایی قابل شناسایی و علت یابی است، همچنین تاثیر تغییرات جدید مورد تست در رفتار سیستم یا سرویس های مختلف مرتبط با آن قابل شناسایی است. زمان تحلیل ممکن است بوسیله monitoring بتوان دلایلی برای برخی تفاوت ها و مشکلات بیان کرد، به طور مثال ممکن است در یک سناریو تست، response time در گروه تست provider جدید بسیار بالا باشد ولی مشکلی از سمت provider نباشد بلکه دیتابیس مورد استفاده یا سرویس دیگر که در فرایند ایجاد response حضور دارند کند شده باشند یا تعداد خطاهای آن ها بالا رفته باشد، که با بررسی مانیتورینگ های مربوطه میتوان به راحتی علت را یافت و در مواردی به راه حل رسید (مثلا تغییر بازه زمانی اجرای a/b تست و انتفال آن به ساعات با ترافیک ورودی کمتر).
همانطور که قبلا اشاره شد قسمت مهمی از فرآیند a/b تست زمان تحلیل آن است. باید در سیستم و سرویس لاگ های مناسب همراه داده های مهم و ضروری وجود داشته باشد تا امکان trace کردن سناریو ها و خطاها وجود داشته باشد. در صورت نبود این امکان یا پیاده سازی نشدن دقیق و درست آن تحلیل مشکلات بوجود آمده در زمان اجرای تست یا تحلیل خروجی آن بسیار دشوار و حتی در مواردی غیر ممکن میشود. در مواردی ممکن است با وجود در نظر گرفتن تمامی شرایط و نکات مربوط به پیاده سازی و اجرای تست خطا یا مشکالتی در حین اجرا مشخص شود که به دلایل خارجی باشد (مشکالت سرور, اینترنت یا دیتابیس و ...) که برای تشخیص درست، به موقع و تصحیح یا گزارش دقیق آن نیازمند ثبت وقایع در سیستم هستیم. داده های موجود در log management میتواند در نتیجه نهایی تست هم تاثیر گذار باشد و یا حتی قسمتی از داده های لازم برای تحلیل به حساب بیایند. به طور مثال فرض کنید در تستی نتیجه تحلیل دو گروه شباهت زیادی دارد و تغییری در رفتار کاربران ایجاد نشده ولی تغییر جدید، درصد خطاهای موجود در سیستم را کاهش داده که میتواند باعث برتری ویژگی جدید شود. استفاده از ابزار مناسب که دارای داشبورد user friendly و امکانات جست و جو و گزارش گیری باشد بسیار مهم است
ضرورت وجود داکیومنت برای سیستم هایی که ساختار اجرای a/b تست ها را دارند و این نوع تست ها در آن ها به دفعات اجرا میشود بالا است. باید نوع جدا سازی،دلایل و طراحی component و module ها مشخص و وجود داشته باشد و actor های مرتبط با آن ها (اینکه تست نیازمندی تیم های مختلف مانند مارکتینگ،فنی و ... باشد) بوسیله نمودار های use case digram قابل تشخیص باشد. در این صورت علاوه بر این که نیروهای جدید شرکت به راحتی با قسمت های مختلف سیستم و عملکرد آن ها آشنا میشوند، تشخیص نوع نیازمندی های جدید (به کدام بخش سیستم مربوط میشود) برای اجرای تست و تکراری بودن سناریو یا جدید بودن آن برایشان آسان میشود و جلوی دوباره کاری های احتمالی با وجود نیرو های جدید گرفته میشود. همچنین به دلیل وجود دلایل طراحی سیستم در صورت برخورد با نیازمندی جدید که نیاز به تعریف فرایند جدید تست و اجرا دارد به راحتی و در زمان کمتری امکان پیشنهاد راه حل جدید وجود خواهد داشت. همچنین فرایند automate کردن تست ها برای تیم فنی با وجود document های به روز بسیار دقیق تر و راحت تر انجام خواهد شد.
همانطور که در مقدمه نیز اشاره شد این pattern با توجه به دغدغه ها و نیازمندی های پر تکرار و مشترک طراحی در نموونه های a/b تست طراحی شده است و امکان تغییر آن متناسب به نیازمندی ها به خصوص وجود دارد.
اجرای یک a/b تست معمولا نیازمد این هستیم که یک بخش و منطق مشخص و به خصوص در سیستم را به روش دیگر یا به نوع دیگری استفاده کنیم و سپس روی نتایج به کارگیری آن ها در بازه مشخص تحلیل کنیم.
حال هر چه این بخش مورد نظر برای تغییر دارای وابستگی های کمتر (مستقل تر) و پیچیدگی کمتری باشد کار راحت تری از نظر حجم تغییرات و سهولت پیاده سازی و تغییرات برای اجرای تست داریم. بنابراین اگر با سیستمی رو به رو هستید که کوچک است و وابستگی ها (بین سرویس ها یا ماژول ها) و پیچیدگی های کمی دارد شاید بهتر است تغییری ایجاد نکرد زیرا ممکن است صرفا پیچیدگی به پیاده سازی و معماری اضافه شود.
این پیشنهاد به دو بخش تقسیم میشود که شامل بخش ها و اعمال مورد نیاز برای قبل از اجرا ی a/b تست (پذیرش a/b تست) و اجرای آن است (که بوسیله آن کار خودکار سازی این تست ها ممکن میشود) البته همانطور که گفته شد تمرکز بیشتر سمت نیازمندی های سمت بک اند است.
زمانی که task یک a/b تست جدید مطرح میشود معمولا actor های آن ها اگر از سمت تیم فنی نباشد جزییاتی فنی در مورد اجرای آن نادیده گرفته میشود(مثلا منابع اضافه مورد نیاز، dependency ها پکیج های جدید یا تغییر ورژن آن ها و ....) زیرا آن ها دیدی نسبت به این جزییات ندارند و نباید هم داشته باشند و این تیم فنی است که باید همیشه نسبت به تغییرات جدید و قسمت های فنی آن آگاهی داشته باشد و اگر این تغییرات نیازمند آمادگی (مثلا خرید سخت افزار، آپدیت ورژن نرم افزاری، تعیین پکیج جدید و ...) هستند آن ها را در نظر بگیرد و اگر باعث ایجاد خرابی و مشکلات (افزایش باگ ها و هزینه ها و ...) میشود آن ها را اطلاع رسانی کند در غیر این صورت اجرای a/b تست های زیاد بدون پیش بینی های گفته شده باعث مختل شدن روند کار معمولی سیستم میشود و به نوعی کل بیزینس را تهدید میکند که این بر خلاف فلسفه این تست است.
البته باید توجه داشت اگر سناریو های a/b تست منطقی و در چهارچوب همیشگی و توافق شده مطرح شوند ولی سیستم و نرم افزار ما توانایی پیاده سازی آن را نداشته باشد یا با هزینه زیاد این کار را بکنند مشکل از معماری و طراحی سیستم است و باید تغییر بکند.
به همین خاطر همیشه باید وضعیت فعلی سیستم از لحاظ منابع مورد استفاده (و حداکثر منابع موجود)، پکیج ها و dependency ها و ... را داشته باشیم و در صورت مطرح شدن سناریو جدید ابتدا نیازمندی ها، تغییرات و کانفیگ های سیستم را بررسی کنیم سپس به سمت اجرای تست برویم زیرا این کار روند اجرای آن را ساده تر میکند و جلوی خرابی و دوباره کاری ها را میگیرد.
به طور مثال فرض کنید در یک سیستم یک سرویس پیش بینی وضعیت آب و هوا را میکند، که این سرویس از یک provider خارجی به نام گوگل استفاده میکند، حالا از سمت یک تیم (به جز تیم فنی) در خواست استفاده از یک provider دیگر به نام X مطرح میشود (به دلیل قیمت کمتر آن نسبت به گوگل) که برای اطمینان از علکرد درست آن و بد تر نکردن تجربه کاربر ها باید روی این دو مورد a/b تست انجام شود.ابتدا باید مواردی مثل response time این provider با توجه به در خواست های اپلیکیشن ما (استفاده از load test) بررسی شود یا تعداد exception های آن زیرا ممکن است این provider با استاندارد های سیستم و بیزینس ما نخواند و اصلا نیازمند اجرای a/b تست برای آن نباشیم.همچنین در این حالت باید در این سرویس برای پرسیدن پیش بینی آب و هوایی چند برابر I/o مصرف شود (از دو provider نتایج گرفته شود و با وضعیت آب و هوایی واقعی آن روز مقایسه شود، برای ذخیره نتایج در دیتابیس و ...)، این مورد نباید response time ، performance و به طور کلی روند کار طبیعی سیستم را دچار مشکل کند. به همین دلیل تیم فنی باید قبل از اجرای a/b تست منابع مورد نیاز (دیتابیس، I/O و ...) را در نظر بگیرد.
بنابراین باید در documentation های خود همواره وضعیت نهایی سیستم از لحاظ کانفیگ ها، resource ها، حجم درخواست ها، استاندارد های خودمان برای حداکثر response time و exception rate و ... را داشته باشیم و به روز نگه داریم، همچنین قابلیت انجام مواردی مثل load test و تست های مورد نیاز دیگر را بر روی سرویس داشته باشیم.
در این بخش در مورد نکاتی گفته میشود که روند اجرا و خودکار سازی a/b تست ها را ساده مکیند برای این کار همانطور که قبلا هم گفته شد داشتن معماری میکروسرویس تا حدی خوبی لازم است.
برای طراحی این pattern ابتدا فرایند a/b تست را به سه بخش سناریو، موجودیت تست و کانفیگ های تست تقسیم میکنیم، ابتدا هر بخش و استفاده آن را توضیح میدهیم و در آخر آن ها را ترکیب و نحوه کمک کردن وجود آن ها در معماری نرم افزار سیستم های شامل a/b تست را ذکر میکنیم.
سناریو تست: سناریو تست شامل طراحی کلی تست است یعنی تست باید شامل چه موجودت های تستی باشد (مورد a و b) ، نیاز به تقسیم ترافیک دارد و اگر آره بر چه اساسی (مثلا یوزر آیدی های زوج برای موجودیت a و یوزر آیدی فرد برای موجودیت b)، استریم و ذخیره نتایج (schema، نوع دیتابیس و اطلاعات لازم) برای تحلیل، نوع تفکیک موجودیت ها برای تست (جداسازی بر اساس سرویس یا بر اساس لاجیک)، بازه زمانی اجرای تست، کاربران تحت تاثیر (منطقه جغرافیایی و ...) و. موارد دیگری که همه برای اجرای صحیح a/b تست نیازمند مشخص شدن هستند.
موجودیت تست: موارد مورد تست (a و b) در یک سناریو a/b تست، که میتواند شامل تغییرات جدید برای ایجاد یک موجودیت تست، نیازمندی های موجودیت جدید (منابع، ابزار، پکیج ها و ورژن آن ها و ...)، سرویس های تحت تاثیر (مجموعه از سرویس ها برای ایجاد یک موجودیت تست مورد نیاز است یا سرویس هایی که با اجرای a/b تست درگیر میشوند)، موجودیت های تست تکراری و جدید (موجودیت های پیاده سازی شده که میتوانند مجدد استفاده شوند یا موجودیت جدید که نیاز به پیاده سازی دارند)
کانفیگ های تست: فلگ ها و تنظیماتی که مشخص کننده عملکرد سناریو تست است که در فرایند خودکار سازی وجود آن ها بسیار لازم است.این کانفیگ ها میتوانند شامل مواردی مثل موجودیت های مورد استفاده در تست (موجودیت های پیاده سازی شده که امکان انتخاب را بدهد)، نحوه تقسیم ترافیک بین موجودیت های تست (مثلا بر اساس یوزر آیدی یا منطقه جغرافیایی)، مدت زمان اجرای تست یا بازه زمانی آن، استریم و ذخیره نتایج داده ها.
سناریو های تست بسته به کانفیگ های تست که بر اساس طراحی و نیازمندی های تست از بین موجودیت های تست برای اجرای سناریو انتخاب میکند همچنین آن ها را با توجه به طراحی فراخونی (مثلا فراخوانی به صورت هم زمان یا بر اساس ترافیک تفسیم شده و ورودی و ...) میکند.
در واقع سناریو تست چگونگی مقدار دهی کانفیگ ها استفاده از موجودیت های تست را مشخص میکند. حال اگر معماری سیستم به صورت میکروسرویس باشد و قسمت های مختلف سیستم با توجه وظایف و موضوع آن ها به درستی تفکیک شده باشد ایجاد این pattern در آن ها به سادگی بیشتری انجام میشود زیرا این سرویس ها تا حد ممکن به صورت مستقل هستند (تیم های مجزا روی آن ها کار میکنند) و برای ایجاد یک موجودیت تست یا اجرای سناریو های a/b تست با حداقل تغییرات و در کمترین زمان بدون تاثیرات منفی (بر روی سرویس های نا مرتبط) میتوان این کار را صورت داد.
در واقع در این حالت با توجه به سناریو تست و نحوه استفاده از موجودیت های تست میتوان به شکل های مختلفی موجودیت های مختلف تست را ایجاد کرد.مثلا صرفا با توجه کانفیگ های تست سرویس ها را به نوعی deploy کرد که عملکرد مورد انتظار موجودیت تست را دشته باشند (مثلا کانفیگ استفاده از یک provider یا دانلود یک مدل AI متناسب با موجودیت تست) که این حالت میتواند کار اجرای تست را بسیار راحت کند اما در صورتی که موجودیت های مختلف در سرویس پیاده سازی شده باشند برای استفاده از آن ها بهتر است منطقی وجود داشته باشد که بر اساس ورودی هایش از موجودیت های مختلف استفاده کند (مثلا بر اساس ورودی یوزر آیدی یکی از حالت های نمایش را انتخاب کند).
در این حالت زمانی که باید یک a/b تست اجرا شود ابتدا باید مشخص شود این سناریو تکراری است یا خیر که بر اساس اینکه نیازمندی تکراری است یا نه، موجودیت های تست تکراری است یا خیر، کانفیگ های موجود کافی است یا خیر و ... میتوان این مورد را تشخیص داد، حال اگر سناریو تکراری است که میتوان این مورد را دوباره بدون هزینه پیاده سازی اجرا کرد البته باید همیشه توجه داشت نتایج تست را متناسب با نیازمندی ها و چک کردن با actor ها یا data analyst ذخیره کرد زیرا اگر ساختار نتایج به صورت ناقص (بدون فیلد های مورد نیاز در schema) ذخیره شود امکان تحلیل روی آن ها از دست میرود، در غیر اینصورت باید قسمت های جدید و غیر تکراری را مشخص کرد که در این حالت بیشترین هزینه مربوط به پیاده سازی موجودیت جدید است البته در این حالت اگر به خوبی لاجیک های کد تفکیک شده باشد و تا حد ممکن ارتباطات آن ها به صورت بهینه تعریف شده باشد این تغییرات زمان و هزینه زیادی را از تیم فنی نخواهد گرفت. در نهایت با ایجاد تغییرات مورد نیاز میتوان تست را اجرا کرد.
با توجه به مواردی که گفته شد این کار به راحتی صورت خواهد گرفت و actor هایی که نیازمندی های یک a/b تست را مطرح میکنند میتوانند به وسیله یک واسط کاربری که امکان تغییرات بر روی کانفیگ های سناریو های تست را میدهد این کار را انجام دهند. البته برای این کار نیاز به استفاده از ابزار های درست و مناسب (یا حتی هماهنگی و دریافت مجوز از تیم های فنی نیز ممکن است باشد) است اما با ایجاد فرایند آن دوباره کاری ها برای اجرای a/b تست ها و هزینه های این چنینی در تیم فنی کم یا صفر میشود.
