BrowserAct-এর স্টিলথ ব্রাউজার একটি বট-ডিটেকশন চেক সফলভাবে পার করেছে, যেখানে Playwright-এর ডিফল্ট হেডলেস রানকে বট হিসেবে চিহ্নিত করা হয়েছিল, যদিও উভয় স্ক্রিপ্টই একই লগইন ফ্লো সম্পন্ন করেছিল। এই পার্থক্যটি দেখায় কেন এমন সাইটগুলোর সাথে ইন্টারঅ্যাক্ট করার জন্য একটি এজেন্ট-ভিত্তিক পদ্ধতি বেশি নিরাপদ হতে পারে যা অটোমেশন প্রতিরোধ করার চেষ্টা করে।

কেন এই পরীক্ষাটি গুরুত্বপূর্ণ

অটোমেশন টুলগুলো টেস্টিং, ডেটা সংগ্রহ এবং অ্যাকাউন্ট ম্যানেজমেন্টের কাজ সহজ করে তোলে। বেশিরভাগ ডেভেলপার Playwright-এর মতো সিলেক্টর-চালিত (selector-driven) ফ্রেমওয়ার্ক ব্যবহার করেন কারণ এগুলো আপনাকে সুনির্দিষ্ট নির্দেশাবলী লিখতে সাহায্য করে—যেমন "এই CSS সিলেক্টরটি দিয়ে বোতামটি ক্লিক করো"—এবং দ্রুত ফলাফল যাচাই করতে পারে। তবে, আধুনিক সাইটগুলোতে এমন স্ক্রিপ্ট থাকে যা হেডলেস ব্রাউজার শনাক্ত করার চেষ্টা করে: যেমন একটি সাধারণ user-agent স্ট্রিং, webdriver প্রপার্টি, অথবা মানুষের মতো ইন্টারঅ্যাকশন প্যাটার্নের অভাব। যখন এই সংকেতগুলো ধরা পড়ে, সাইটটি রিকোয়েস্ট ব্লক করে দেয় অথবা CAPTCHA প্রদর্শন করে, যা কার্যত স্ক্রিপ্টটিকে অকার্যকর করে তোলে।

এজেন্ট ব্রাউজারগুলো আগে থেকে লেখা সিলেক্টরের ওপর নির্ভর না করে একজন মানুষের মতো আচরণ করার চেষ্টা করে। তারা একটি পেজকে অ্যাকশনেবল এলিমেন্টের (actionable elements) একটি সংগ্রহ হিসেবে বিবেচনা করে এবং CSS পাথের পরিবর্তে একটি ইন্টারনাল ইনডেক্সে অবস্থানের ভিত্তিতে এলিমেন্ট নির্বাচন করে। এই পরীক্ষায় একটি JavaScript-রেন্ডার করা লগইন পেজ এবং একটি বট-চেকিং সাইটের ওপর উভয় পদ্ধতির তুলনা করা হয়েছে।

পরীক্ষাটি

আমি দুটি স্ক্রিপ্ট লিখেছিলাম যা একই ধাপ অনুসরণ করেছিল: লগইন পেজ লোড করা, ক্রেডেনশিয়াল (credentials) প্রবেশ করানো, সাবমিট করা এবং ইনভেন্টরি পেজে পৌঁছানো। একটি স্ক্রিপ্টে Playwright-এর ডিফল্ট হেডলেস মোড ব্যবহার করা হয়েছিল; অন্যটিতে BrowserAct-এর স্টিলথ ব্রাউজার ব্যবহার করা হয়েছিল, যা বট ডিটেকশন ট্রিগার করে এমন ফিঙ্গারপ্রিন্টগুলোকে মাস্ক (mask) করে ফেলে।

উভয় স্ক্রিপ্টই একটি স্যান্ডবক্স সাইটে অথেন্টিকেশন সম্পন্ন করেছিল, যা প্রমাণ করে যে টুল যাই হোক না কেন মূল লগইন ফ্লো কাজ করে। পার্থক্যটি দেখা দেয় যখন স্ক্রিপ্টগুলো একটি ডেডিকেটেড বট-ডিটেকশন পেজ ভিজিট করে যা একটি JSON ফ্ল্যাগ isBot রিটার্ন করে। Playwright রিপোর্ট করেছে isBot: true, যা পাঁচটি আলাদা ডিটেকশন চেক ট্রিগার করেছে। অন্যদিকে BrowserAct রিটার্ন করেছে isBot: false, যা নির্দেশ করে যে পেজটি এটিকে একজন সাধারণ মানুষের ভিজিটর হিসেবে গণ্য করেছে।

আমি এই পার্থক্যের কারণ হিসেবে দুটি প্রযুক্তিগত দিক খুঁজে পেয়েছি। Playwright-এর ডিফল্ট কনফিগারেশন একটি সাধারণ user-agent স্ট্রিং পাঠায় এবং webdriver ফ্ল্যাগটি উন্মুক্ত রাখে—যা ডিটেকশন স্ক্রিপ্টের জন্য ধরা পড়া খুব সহজ। BrowserAct-এর স্টিলথ মোড user-agent পুনরায় লিখে ফেলে, webdriver প্রপার্টিটি সরিয়ে ফেলে এবং এর ফিঙ্গারপ্রিন্টকে একটি সাধারণ ডেস্কটপ ব্রাউজারের সাথে সামঞ্জস্যপূর্ণ করে তোলে।

অভ্যন্তরীণভাবে টুলগুলোর মধ্যে পার্থক্য

দিক Playwright (ডিফল্ট) BrowserAct (স্টিলথ)
ইন্টারঅ্যাকশন মডেল সিলেক্টর-চালিত, ডিটারমিনিস্টিক (deterministic) এজেন্ট-চালিত, ইনডেক্স-ভিত্তিক
আগে থেকে লেখা সিলেক্টরের প্রয়োজন বাধ্যতামূলক; স্ক্রিপ্টকে অবশ্যই সঠিক DOM স্ট্রাকচার জানতে হবে প্রয়োজন নেই; এজেন্ট রানটাইমে অ্যাকশনেবল এলিমেন্টগুলো খুঁজে নেয়
লেআউট পরিবর্তনের মোকাবিলা সিলেক্টর পরিবর্তন হলে কাজ করা বন্ধ করে দেয় যতক্ষণ এলিমেন্টের অবস্থান ইনডেক্সড তালিকার মধ্যে থাকে, ততক্ষণ কাজ চালিয়ে যায়
বট চেকের সম্মুখীন হওয়া User-agent এবং webdriver অপরিবর্তিত থাকে ফিঙ্গারপ্রিন্টগুলো ইচ্ছাকৃতভাবে মাস্ক করা হয়
সাধারণ ব্যবহারের ক্ষেত্র ইন্টারনাল সাইট, স্থিতিশীল UI, দ্রুত টেস্ট সাইকেল অ্যান্টি-অটোমেশন ব্যবস্থা থাকা পাবলিক সাইট, প্রতিনিয়ত পরিবর্তনশীল পেজ

এই টেবিলটি ব্যবহারিক সুবিধা ও অসুবিধাগুলো তুলে ধরে। যখন আপনি সাইটটি নিয়ন্ত্রণ করেন এবং স্থিতিশীল এলিমেন্ট আইডেন্টিফায়ার নিশ্চিত করতে পারেন, তখন Playwright দারুণ কাজ করে। অন্যদিকে, যখন আপনি পেজের গঠন সম্পর্কে নিশ্চিত হতে পারেন না বা সাইটটি সক্রিয়ভাবে স্ক্রিপ্ট ব্লক করার চেষ্টা করে, তখন একটি এজেন্ট ব্রাউজার বেশি কার্যকর।

কারা উপকৃত এবং কারা ঝুঁকির মুখে

যারা নিজেদের অ্যাপ্লিকেশনের জন্য রিগ্রেশন স্যুট (regression suites) তৈরি করছেন, তারা Playwright ব্যবহার করে খরচ কম এবং টেস্টের গতি বেশি রাখতে পারেন। এর ডিটারমিনিস্টিক প্রকৃতি সরাসরি কোড রিগ্রেশনের দিকে ব্যর্থতাগুলো নির্দেশ করে এবং অতিরিক্ত স্টিলথ লেয়ার না থাকায় জটিলতাও কম থাকে।

বিপরীতে, যে দলগুলো ডেটা স্ক্র্যাপ করে, অ্যাকাউন্ট তৈরি অটোমেট করে বা প্রতিযোগীদের সাইট মনিটর করে, তারা প্রায়শmış বাধার সম্মুখীন হয় কারণ টার্গেট পেজগুলো ঘন ঘন পরিবর্তিত হয় বা সেখানে আক্রমণাত্মক বট ডিটেকশন ব্যবস্থা থাকে। সেই পরিস্থিতিতে, একটি এজেন্ট ব্রাউজার সরাসরি "you are a bot" নামক বাধার সম্মুখীন না হয়ে প্রয়োজনীয় ডেটা সংগ্রহ চালিয়ে যেতে পারে।

"এটি কাজ করেছে" এর লুকানো খরচ

আমি সতর্ক করছি যে একটি সফল এক্সিট কোড (exit code) মানেই এই নয় যে অটোমেশনটি ঠিক যেভাবে করার কথা ছিল সেভাবেই কাজ করেছে। Playwright রান-এর ক্ষেত্রে, স্ক্রিপ্টটি কোনো এরর ছাড়াই শেষ হয়েছিল, তবুও পেজটি রিকোয়েস্টটিকে বট হিসেবে গণ্য করেছিল। এর ফলাফল ছিল একটি লুকানো ব্যর্থতা: পরবর্তী ধাপগুলো (downstream steps) যা শুধুমাত্র মানুষের তৈরি কন্টেন্টের ওপর নির্ভর করে, সেগুলো কখনোই প্রত্যাশিত ডেটা পায়নি।

এই ধরণের নীরব ব্যর্থতাগুলো শনাক্ত করতে, প্রতিটি রান-এর পরে পেজের প্রমাণগুলো পরীক্ষা করুন: স্ক্রল পজিশন, ডকুমেন্ট হাইট এবং নেটওয়ার্ক কল। যদি DOM দেখতে একজন মানুষের দেখা অবস্থার চেয়ে ভিন্ন হয়, অথবা নেটওয়ার্ক ট্রাফিকের মধ্যে ভেরিফিকেশন চ্যালেঞ্জের দিকে অপ্রত্যাশিত রিডাইরেক্ট অন্তর্ভুক্ত থাকে, তবে সম্ভবত অটোমেশনটি তার লক্ষ্য পূরণে ব্যর্থ হয়েছে।

সারকথা

আপনি যদি সাইটটির মালিক হন এবং স্টেবল সিলেক্টর ব্যবহার করে স্ক্রিপ্ট করতে পারেন, তবে Playwright-ই হবে সবচেয়ে বাস্তবসম্মত পছন্দ—যা দ্রুত, সাশ্রয়ী এবং CI pipelines-এ ইন্টিগ্রেট করা সহজ। যখন আপনি অজানা লেআউট, আক্রমণাত্মক অ্যান্টি-অটোমেশন ডিফেন্স বা ঘন ঘন UI পরিবর্তনের সম্মুখীন হন, তখন BrowserAct-এর মতো একটি এজেন্ট ব্রাউজার আরও স্থিতিস্থাপক সমাধান প্রদান করে। একটি সফল রান-কে অন্ধভাবে বিশ্বাস করবেন না; পেজটি একজন মানুষের মতো আচরণ করছে কি না তা যাচাই করুন এবং আপনার টার্গেট সাইটের রিস্ক প্রোফাইলের সাথে সামঞ্জস্যপূর্ণ টুলটি বেছে নিন।