एक वेब-आधार-डिज़ाइन टूल पर किए गए AI-संचालित QA रन ने “All features working, pass,” की रिपोर्ट दी, फिर भी कैनवास पर कुछ भी दिखाई नहीं दे रहा था। यह गलत 'पास' मॉडल की तर्कशक्ति (reasoning) में कोई खराबी नहीं थी; बल्कि यह इस बात का दुष्प्रभाव था कि ब्राउज़र छिपे हुए टैब (hidden tabs) को कैसे संभालता है और टेस्ट स्क्रिप्ट ने विजुअल आउटपुट के बजाय "हेल्थ" (health) को कैसे मापा।

AI QA एजेंट खाली कैनवास को क्यों मिस कर सकते हैं

वे JavaScript निष्पादित करते हैं, स्क्रीनशॉट लेते हैं, और मॉडल को यह अनुमान लगाने देते हैं कि क्या कोई फीचर सही ढंग से काम कर रहा है। व्यवहार में, दो तकनीकी ब्लाइंड स्पॉट (blind spots) बार-बार तब 'पास' दिखा देते हैं जब UI वास्तव में खाली होता है।

हिडन-टैब थ्रॉटलिंग (Hidden-tab throttling) का स्पष्टीकरण

Chrome MCP अक्सर मुख्य विंडो को अन्य कार्यों के लिए खाली रखने के लिए बैकग्राउंड टैब में टेस्ट चलाता है। जब किसी टैब की document.visibilityState hidden होती है, तो ब्राउज़र रेंडरिंग पाइपलाइन को थ्रॉटल (throttle) कर देता है:

  • JavaScript चलता रहता है, इसलिए कोई रनटाइम एरर (runtime error) दिखाई नहीं देता।
  • requestAnimationFrame कॉल-बैक (callbacks) चलना बंद हो जाते हैं, जिससे एनिमेशन फ्रेम काउंट शून्य पर रह जाता है।
  • टाइमर बहुत कम बार चलते हैं; एक टेस्ट जिसने 33 ms के अंतराल की अपेक्षा की थी, उसने केवल चार ही देखे।

AI एजेंट साफ JS परिणाम और एक स्क्रीनशॉट देखता है, और मान लेता है कि एनिमेशन ने काम किया। क्योंकि रेंडरिंग लूप ने कभी पिक्सेल उत्पन्न ही नहीं किए, इसलिए विजुअल दोष (visual defect) छिपा रहता है।

हिडन-टैब समस्याओं के समाधान

  • किसी भी कैनवास, एनिमेशन, या ग्राफिक्स वेरिफिकेशन के लिए टेस्ट टैब को विज़िबल (visible) रखें।
  • इंटरैक्शन केवल तभी ट्रिगर करें जब टैब फोरग्राउंड (foreground) में हो।
  • स्क्रीनशॉट लेने से पहले एक छोटा इंतज़ार (कुछ सेकंड) डालें, यह सुनिश्चित करने के लिए कि फ्रेम बफ़र (frame buffer) भर गया है।
  • यदि हिडन टैब का उपयोग करना ही पड़े, तो रिपोर्ट की शुरुआत में “rendering not visually observed” जैसा डिस्क्लेमर (disclaimer) जोड़ें।

कोड हेल्थ (Code health) बनाम फीचर व्यवहार (feature behavior)

अधिकांश AI QA स्क्रिप्ट "कोड हेल्थ" का मूल्यांकन करती हैं: वे पुष्टि करती हैं कि क्लिक हैंडलर (click handlers) जुड़े हुए हैं, कोई JavaScript एक्सेप्शन (exception) नहीं आया है, और आवश्यक लाइब्रेरीज़ लोड हो गई हैं। ये संकेत यह साबित करते हैं कि कोड चला है, न कि यह कि UI इच्छानुसार बदला है। एक कैनवास एलिमेंट बनाया जा सकता है, ड्राइंग रूटीन को कॉल किया जा सकता है, और फिर भी कुछ भी रेंडर नहीं हो सकता यदि ड्राइंग कमांड्स किसी ज़ीरो-साइज़ बफ़र या खाली एसेट को लक्षित करते हैं।

यह अंतर महत्वपूर्ण है क्योंकि एक स्वस्थ कोड पाथ (code path) किसी गायब विजुअल आर्टिफैक्ट (visual artifact) को छिपा सकता है।

व्यवहार जांच (behavior checks) जोड़ना

  1. डायनामिक एलिमेंट्स की पहचान करें – सोर्स में canvas टैग, file-input फ़ील्ड, डाउनलोड बटन और एनिमेशन लूप की जांच करें।
  2. अवलोकन योग्य परिणामों को परिभाषित करें – कैनवास के लिए, पिक्सेल-लेवल चेक की आवश्यकता होनी चाहिए कि बिटमैप (bitmap) खाली न हो। फ़ाइल इनपुट के लिए, सत्यापित करें कि प्रीव्यू इमेज दिखाई दे रही है। डाउनलोड के लिए, पुष्टि करें कि फ़ाइल सिस्टम पर फ़ाइल बनाई गई है। एनिमेशन के लिए, यह सुनिश्चित करें (assert) कि एक ट्रैक की गई प्रॉपर्टी समय के साथ बदलती है।
  3. रिपोर्ट कवरेज – QA आउटपुट के साथ एक टेबल जोड़ें जिसमें प्रत्येक फीचर, कोड-हेल्थ स्टेटस और व्यवहार सत्यापन (behavior verification) परिणाम सूचीबद्ध हो। व्यवहार जांच की कमी वाली किसी भी चीज़ को “pass” के बजाय “unverified” माना जाए।

इस नियम को लागू करने से लेखक के टेस्ट सुइट में फॉल्स पॉजिटिव (false positives) में नाटकीय रूप से कमी आई और CSS मिसमैच भी सामने आए, जहाँ स्टाइलशीट ने एक रंग घोषित किया था लेकिन रेंडर किया गया पिक्सेल अलग था।

विश्वसनीय विजुअल टेस्टिंग के लिए व्यावहारिक कदम

  • एक विज़िबल टैब में टेस्ट चलाएं जब भी फीचर में रेंडरिंग शामिल हो।
  • UI के स्थिर होने का इंतज़ार करें; कुछ सेकंड का निश्चित विलंब (delay) अक्सर पर्याप्त होता है, लेकिन एक अधिक मजबूत दृष्टिकोण getImageData का उपयोग करके नॉन-ब्लैंक कैनवास के लिए पोल (poll) करना है।
  • टेस्ट स्क्रिप्ट में कोड-हेल्थ एसर्शन (assertions) को विजुअल एसर्शन से अलग करें; AI मॉडल को प्रत्येक का स्वतंत्र रूप से मूल्यांकन करने दें।
  • डायग्नोस्टिक आउटपुट के हिस्से के रूप में विज़िबिलिटी स्टेट और फ्रेम काउंटर (requestAnimationFrame कॉल) को लॉग करें।
  • किसी भी अपरिहार्य हिडन-टैब रन को स्पष्ट चेतावनियों के साथ दस्तावेज़ित करें ताकि बाद के समीक्षक (reviewers) सीमा को समझ सकें।

आगे क्या ध्यान रखें

जैसे-जैसे AI-सहायता प्राप्त QA टूल्स का प्रसार हो रहा है, डेवलपर्स को उन्हें सहायक (assistants) के रूप में मानना चाहिए, न कि निर्णायक (arbiters) के रूप में। कोड-हेल्थ मेट्रिक्स हमेशा यूजर-फेसिंग व्यवहार के लिए एक अधूरा प्रॉक्सी (proxy) होंगे। निष्कर्ष सरल है: एक AI मॉडल केवल वही रिपोर्ट कर सकता है जो वह देखता है। यदि टैब छिपा होने के कारण ब्राउज़र कभी पेंट नहीं करता है, या यदि टेस्ट स्क्रिप्ट कभी यह नहीं पूछती कि “क्या स्क्रीन पर कुछ दिखाई दिया?”, तो मॉडल खुशी-खुशी सफलता घोषित कर देगा। विज़िबिलिटी की आवश्यकता और व्यवहार-सत्यापन (behavior-verification) चरण जोड़ने से एक दिखावटी 'पास' एक भरोसेमंद परिणाम में बदल जाता है।