ایک ویب پر مبنی ڈیزائن ٹول پر اے آئی (AI) سے چلنے والے QA نے رپورٹ کیا کہ "تمام فیچرز کام کر رہے ہیں، پاس (pass)"، لیکن کینوس پر کچھ بھی نظر نہیں آ رہا تھا۔ یہ غلط کامیابی (false pass) ماڈل کے استدلال (reasoning) میں کوئی خرابی نہیں تھی؛ بلکہ یہ اس بات کا نتیجہ تھا کہ براؤزر چھپے ہوئے ٹیبز کو کیسے ہینڈل کرتا ہے اور ٹیسٹ اسکرپٹ نے بصری آؤٹ پٹ (visual output) کے بجائے "صحت" (health) کی پیمائش کیسے کی۔

اے آئی (AI) QA ایجنٹس خالی کینوس کو کیوں نظر انداز کر سکتے ہیں

وہ JavaScript چلاتے ہیں، اسکرین شاٹس لیتے ہیں، اور ماڈل کو یہ اندازہ لگانے دیتے ہیں کہ آیا کوئی فیچر صحیح طریقے سے کام کر رہا ہے۔ عملی طور پر، دو تکنیکی خامیاں بار بار اس وقت "پاس" دکھاتی ہیں جب UI درحقیقت خالی ہو۔

چھپے ہوئے ٹیبز کی تھروٹلنگ (throttling) کی وضاحت

Chrome MCP اکثر مین ونڈو کو دوسرے کاموں کے لیے آزاد رکھنے کے لیے بیک گراؤنڈ ٹیبز میں ٹیسٹ چلاتا ہے۔ جب کسی ٹیب کی document.visibilityState hidden ہو، تو براؤزر رینڈرنگ پائپ لائن کو تھروٹل (throttle) کر دیتا ہے:

  • JavaScript چلتی رہتی ہے، اس لیے کوئی رن ٹائم ایرر (runtime error) ظاہر نہیں ہوتا۔
  • requestAnimationFrame کال بیکس (callbacks) چلنا بند ہو جاتے ہیں، جس سے اینیمیشن فریم کاؤنٹ صفر رہ جاتا ہے۔
  • ٹائمرز بہت کم وقفے سے چلتے ہیں؛ ایک ٹیسٹ جس میں 33ms کے وقفوں کی توقع تھی، اس نے صرف چار وقفے دیکھے۔

اے آئی ایجنٹ صاف ستھرے JS نتائج اور ایک اسکرین شاٹ دیکھتا ہے، اور فرض کر لیتا ہے کہ اینیمیشن نے کام کیا۔ چونکہ رینڈرنگ لوپ نے کبھی پکسلز پیدا نہیں کیے، اس لیے بصری خرابی چھپی رہتی ہے۔

چھپے ہوئے ٹیب کے مسائل کے حل

  • کسی بھی کینوس، اینیمیشن، یا گرافکس کی تصدیق کے لیے ٹیسٹ ٹیب کو نظر آنے والا (visible) رکھیں۔
  • انٹرایکشنز (interactions) صرف تب شروع کریں جب ٹیب فار گراؤنڈ (foreground) میں ہو۔
  • اسکرین شاٹ لینے سے پہلے تھوڑا انتظار (چند سیکنڈ) کریں، تاکہ اس بات کو یقینی بنایا جا سکے کہ فریم بفر (frame buffer) بھر چکا ہو۔
  • اگر چھپا ہوا ٹیب استعمال کرنا ضروری ہو، تو رپورٹ کے شروع میں ایک ڈسکلیمر (disclaimer) شامل کریں جیسے کہ "رینڈرنگ بصری طور پر مشاہدہ نہیں کی گئی"۔

کوڈ کی صحت (Code health) بمقابلہ فیچر کا طرزِ عمل (feature behavior)

زیادہ تر AI QA اسکرپٹس "کوڈ کی صحت" (code health) کا جائزہ لیتے ہیں: وہ اس بات کی تصدیق کرتے ہیں کہ کلک ہینڈلرز (click handlers) منسلک ہیں، کوئی JavaScript exceptions نہیں آئے، اور مطلوبہ لائبریریز لوڈ ہو گئی ہیں۔ یہ اشارے اس بات کا ثبوت ہیں کہ کوڈ چلا ہے، نہ کہ اس بات کا کہ UI مطلوبہ طریقے سے تبدیل ہوا ہے۔ ایک کینوس ایلیمنٹ بنایا جا سکتا ہے، ڈرائنگ روٹین کو کال کیا جا سکتا ہے، اور پھر بھی کچھ بھی رینڈر نہیں ہوگا اگر ڈرائنگ کمانڈز زیرو سائز بفر یا خالی اثاثے (asset) کو نشانہ بنا رہی ہوں۔

یہ فرق اہم ہے کیونکہ کوڈ کا ایک صحت مند راستہ بصری خرابی کو چھپا سکتا ہے۔

طرزِ عمل کی جانچ (behavior checks) شامل کرنا

  1. ڈائنامک عناصر کی شناخت کریں – کینوس ٹیگز، فائل-ان پٹ فیلڈز، ڈاؤن لوڈ بٹنوں اور اینیمیشن لوپس کے لیے سورس کو اسکین کریں۔
  2. قابلِ مشاہدہ نتائج کی تعریف کریں – کینوس کے لیے، پکسل لیول پر چیک کریں کہ بٹ میپ (bitmap) خالی نہ ہو۔ فائل ان پٹ کے لیے، تصدیق کریں کہ پری ویو امیج نظر آ رہی ہے۔ ڈاؤن لوڈ کے لیے، تصدیق کریں کہ فائل سسٹم پر فائل بن گئی ہے۔ اینیمیشنز کے لیے، اس بات کا دعویٰ کریں کہ ٹریک شدہ پراپرٹی وقت کے ساتھ تبدیل ہوتی ہے۔
  3. کوریج رپورٹ کریں – QA آؤٹ پٹ کے ساتھ ایک ٹیبل منسلک کریں جس میں ہر فیچر، کوڈ-ہیلتھ اسٹیٹس، اور طرزِ عمل کی تصدیق کا نتیجہ درج ہو۔ جس چیز میں طرزِ عمل کی جانچ کی کمی ہو، اسے "پاس" کے بجائے "غیر تصدیق شدہ" (unverified) قرار دیں۔

اس اصول کو لاگو کرنے سے مصنف کے ٹیسٹ سویٹ میں غلط مثبت (false positives) کے نتائج میں نمایاں کمی آئی اور CSS کے عدم مطابقت کے مسائل بھی سامنے آئے جہاں اسٹائل شیٹ نے ایک رنگ ظاہر کیا لیکن رینڈر شدہ پکسل مختلف تھا۔

قابلِ اعتماد بصری ٹیسٹنگ کے لیے عملی اقدامات

  • ٹیسٹ کو نظر آنے والے ٹیب میں چلائیں جب بھی فیچر میں رینڈرنگ شامل ہو۔
  • UI کے مستحکم ہونے کا انتظار کریں؛ چند سیکنڈ کی مقررہ تاخیر اکثر کافی ہوتی ہے، لیکن ایک زیادہ مضبوط طریقہ getImageData کا استعمال کرتے ہوئے غیر خالی کینوس کے لیے پولنگ (polling) کرنا ہے۔
  • ٹیسٹ اسکرپٹ میں کوڈ-ہیلتھ کے دعووں کو بصری دعووں سے الگ رکھیں؛ اے آئی ماڈل کو ہر ایک کا آزادانہ جائزہ لینے دیں۔
  • تشخیصی آؤٹ پٹ کے حصے کے طور پر ویزیبلٹی اسٹیٹ (visibility state) اور فریم کاؤنٹرز (requestAnimationFrame کالز) کو لاگ کریں۔
  • کسی بھی ناگزیر چھپے ہوئے ٹیب کے رن کو واضح وارننگ کے ساتھ دستاویزی شکل دیں تاکہ بعد میں جائزہ لینے والے اس کی حد کو سمجھ سکیں۔

آگے کیا دیکھنا ہے

جیسے جیسے اے آئی (AI) کی مدد سے چلنے والے QA ٹولز بڑھ رہے ہیں، ڈویلپرز کو انہیں اسسٹنٹ (assistants) کے طور پر دیکھنا چاہیے، نہ کہ حتمی فیصلہ کن (arbiters) کے طور پر۔ کوڈ-ہیلتھ میٹرکس ہمیشہ صارف کے سامنے والے طرزِ عمل کے لیے ایک نامکمل متبادل رہیں گے۔ سبق سادہ ہے: ایک اے آئی ماڈل صرف وہی رپورٹ کر سکتا ہے جو وہ دیکھتا ہے۔ اگر براؤزر کبھی پینٹ نہیں کرتا کیونکہ ٹیب چھپا ہوا ہے، یا اگر ٹیسٹ اسکرپٹ کبھی یہ نہیں پوچھتا کہ "کیا اسکرین پر کچھ ظاہر ہوا؟"، تو ماڈل خوشی خوشی کامیابی کا اعلان کر دے گا۔ ویزیبلٹی کی ضرورت اور طرزِ عمل کی تصدیق کا مرحلہ شامل کرنے سے ایک ظاہری کامیابی ایک قابلِ اعتماد نتیجے میں بدل جاتی ہے۔