একটি ওয়েব-ভিত্তিক ডিজাইন টুলে চালানো AI-চালিত QA রিপোর্ট করেছিল “All features working, pass,” অথচ ক্যানভাসে কিছুই দেখা যাচ্ছিল না। এই ভুল 'পাস' রিপোর্টটি মডেলের যুক্তির কোনো ত্রুটি ছিল না; এটি ছিল ব্রাউজার কীভাবে হিডেন (hidden) ট্যাবগুলো হ্যান্ডেল করে এবং টেস্ট স্ক্রিপ্ট কীভাবে ভিজ্যুয়াল আউটপুটের পরিবর্তে "health" পরিমাপ করে তার একটি পার্শ্বপ্রতিক্রিয়া।
কেন AI QA এজেন্টরা একটি খালি ক্যানভাস মিস করতে পারে
তারা JavaScript এক্সিকিউট করে, স্ক্রিনশট ক্যাপচার করে এবং মডেলটিকে সিদ্ধান্ত নিতে দেয় যে কোনো ফিচার সঠিকভাবে কাজ করেছে কি না। বাস্তবে, দুটি প্রযুক্তিগত সীমাবদ্ধতা (blind spots) বারবার 'পাস' রিপোর্ট দেয় যখন UI আসলে খালি থাকে।
হিডেন-ট্যাব থ্রটলিং (Hidden-tab throttling) ব্যাখ্যা
Chrome MCP প্রায়শই মেইন উইন্ডোটি অন্য কাজের জন্য খালি রাখতে ব্যাকগ্রাউন্ড ট্যাবে টেস্ট চালায়। যখন একটি ট্যাবের document.visibilityState hidden থাকে, তখন ব্রাউজার রেন্ডারিং পাইপলাইনকে থ্রটল (throttle) করে দেয়:
- JavaScript চলতে থাকে, তাই কোনো রানটাইম এরর (runtime error) দেখা যায় না।
requestAnimationFrameকলব্যাকগুলো আসা বন্ধ হয়ে যায়, ফলে অ্যানিমেশন ফ্রেম কাউন্ট শূন্য হয়ে থাকে।- টাইমারগুলো অনেক কম সময় অন্তর কাজ করে; একটি টেস্ট যা 33 ms ইন্টারভালের প্রত্যাশা করেছিল, তা মাত্র চারটি ইন্টারভ্যাল দেখতে পায়।
AI এজেন্ট পরিষ্কার JS রেজাল্ট এবং একটি স্ক্রিনশট দেখে এবং ধরে নেয় যে অ্যানিমেশনটি কাজ করেছে। যেহেতু রেন্ডারিং লুপ কখনোই পিক্সেল তৈরি করতে পারেনি, তাই ভিজ্যুয়াল ত্রুটিটি লুকিয়ে থাকে।
হিডেন-ট্যাব সমস্যার সমাধান
- যেকোনো ক্যানভাস, অ্যানিমেশন বা গ্রাফিক্স ভেরিফিকেশনের জন্য টেস্ট ট্যাবটি দৃশ্যমান (visible) রাখুন।
- ট্যাবটি ফোরগ্রাউন্ডে আসার পরেই কেবল ইন্টারঅ্যাকশন শুরু করুন।
- স্ক্রিনশট নেওয়ার আগে একটি ছোট বিরতি (কয়েক সেকেন্ড) দিন, যাতে নিশ্চিত হওয়া যায় যে ফ্রেম বাফার (frame buffer) পূর্ণ হয়েছে।
- যদি একটি হিডেন ট্যাব ব্যবহার করতেই হয়, তবে রিপোর্টের শুরুতে “rendering not visually observed” এর মতো একটি ডিসক্লেইমার যুক্ত করুন।
Code health বনাম ফিচারের আচরণ
বেশিরভাগ AI QA স্ক্রিপ্ট "code health" মূল্যায়ন করে: তারা নিশ্চিত করে যে ক্লিক হ্যান্ডলারগুলো সঠিকভাবে যুক্ত আছে, কোনো JavaScript exception আসেনি এবং প্রয়োজনীয় লাইব্রেরিগুলো লোড হয়েছে। এই সংকেতগুলো প্রমাণ করে যে কোডটি চলেছে, কিন্তু UI যেভাবে হওয়ার কথা ছিল সেভাবে পরিবর্তিত হয়েছে কি না তা প্রমাণ করে না। একটি ক্যানভাস এলিমেন্ট তৈরি করা হতে পারে, একটি ড্রয়িং রুটিন কল করা হতে পারে, কিন্তু ড্রয়িং কমান্ডগুলো যদি একটি জিরো-সাইজ বাফার বা খালি অ্যাসেটের লক্ষ্য করে, তবে সেটি কিছুই রেন্ডার করবে না।
এই পার্থক্যটি গুরুত্বপূর্ণ কারণ একটি স্বাস্থ্যকর কোড পাথ (healthy code path) একটি অনুপস্থিত ভিজ্যুয়াল আর্টিফ্যাক্টকে (visual artifact) ঢেকে রাখতে পারে।
বিহেভিয়ার চেক (behavior checks) যোগ করা
- ডায়নামিক এলিমেন্ট শনাক্ত করুন – সোর্স কোডে ক্যানভাস ট্যাগ, file-input ফিল্ড, ডাউনলোড বাটন এবং অ্যানিমেশন লুপ খুঁজুন।
- পর্যবেক্ষণযোগ্য ফলাফল নির্ধারণ করুন – একটি ক্যানভাসের জন্য, বিটম্যাপটি খালি নয় কি না তা পিক্সেল-লেভেলে চেক করার প্রয়োজনীয়তা রাখুন। একটি file input-এর জন্য, প্রিভিউ ইমেজ দেখা যাচ্ছে কি না তা যাচাই করুন। ডাউনলোডের জন্য, ফাইল সিস্টেমের ওপর একটি ফাইল তৈরি হয়েছে কি না তা নিশ্চিত করুন। অ্যানিমেশনের জন্য, একটি ট্র্যাক করা প্রপার্টি সময়ের সাথে পরিবর্তিত হচ্ছে কি না তা অ্যাসার্ট (assert) করুন।
- রিপোর্ট কভারেজ – QA আউটপুটে একটি টেবিল যুক্ত করুন যেখানে প্রতিটি ফিচার, কোড-হেলথ স্ট্যাটাস এবং বিহেভিয়ার ভেরিফিকেশন রেজাল্ট তালিকাভুক্ত থাকবে। যেগুলোতে বিহেভিয়ার চেক নেই, সেগুলোকে “pass” না বলে “unverified” হিসেবে রাখুন।
এই নিয়মটি প্রয়োগ করার ফলে লেখকের টেস্ট সুইটে ফলস পজিটিভ (false positives) নাটকীয়ভাবে কমে গেছে এবং সিএসএস (CSS) মিসম্যাচগুলোও ধরা পড়েছে, যেখানে স্টাইলশিটে একটি রঙের কথা বলা থাকলেও রেন্ডার করা পিক্সেলটি ভিন্ন ছিল।
নির্ভরযোগ্য ভিজ্যুয়াল টেস্টিংয়ের জন্য ব্যবহারিক পদক্ষেপ
- একটি দৃশ্যমান ট্যাবে টেস্ট চালান যখনই ফিচারের মধ্যে রেন্ডারিং জড়িত থাকে।
- UI স্থিতিশীল হওয়ার জন্য অপেক্ষা করুন; কয়েক সেকেন্ডের একটি নির্দিষ্ট বিলম্ব প্রায়শই যথেষ্ট হয়, তবে আরও শক্তিশালী পদ্ধতি হলো
getImageDataব্যবহার করে একটি খালি নয় এমন ক্যানভাসের জন্য পোল (poll) করা। - টেস্ট স্ক্রিপ্টে code-health অ্যাসারশন থেকে ভিজ্যুয়াল অ্যাসারশন আলাদা করুন; AI মডেলকে প্রতিটি স্বাধীনভাবে মূল্যায়ন করতে দিন।
- ডায়াগনস্টিক আউটপুটের অংশ হিসেবে visibility state এবং ফ্রেম কাউন্টার (
requestAnimationFrameকল) লগ করুন। - কোনো অনিবার্য হিডেন-ট্যাব রান হলে তা স্পষ্ট সতর্কবার্তার মাধ্যমে ডকুমেন্ট করুন, যাতে পরবর্তী রিভিউয়াররা সীমাবদ্ধতাগুলো বুঝতে পারেন।
পরবর্তীতে যা খেয়াল রাখতে হবে
যেহেতু AI-সহায়তা প্রাপ্ত QA টুলগুলোর প্রসার ঘটছে, ডেভেলপারদের অবশ্যই সেগুলোকে সহকারী হিসেবে বিবেচনা করতে হবে, বিচারক হিসেবে নয়। Code-health মেট্রিক্স সবসময়ই ইউজার-ফেসড (user-facing) আচরণের একটি অসম্পূর্ণ বিকল্প হিসেবে কাজ করবে। মূল কথাটি সহজ: একটি AI মডেল কেবল সেটুকুই রিপোর্ট করতে পারে যা সে দেখে। যদি ট্যাবটি হিডেন থাকার কারণে ব্রাউজার কখনোই পেইন্ট (paint) না করে, অথবা যদি টেস্ট স্ক্রিপ্ট কখনো না জিজ্ঞেস করে যে “স্ক্রিনে কি কিছু দেখা যাচ্ছে?”, তবে মডেলটি সানন্দে সাফল্য ঘোষণা করবে। একটি ভিজিবিলিটি রিকয়ারমেন্ট এবং একটি বিহেভিয়ার-ভেরিফিকেশন ধাপ যোগ করলে একটি আপাত 'পাস' একটি নির্ভরযোগ্য ফলাফলে পরিণত হবে।