वेब-आधारित डिझाइन टूलवर चालवलेल्या AI-चालित QA ने "सर्व वैशिष्ट्ये कार्यरत आहेत, पास" असा अहवाल दिला, तरीही कॅनव्हासवर काहीही दिसत नव्हते. हा चुकीचा 'पास' मॉडेलच्या तर्कशक्तीतील त्रुटी नव्हती; तर ब्राउझरने लपवलेले टॅब (hidden tabs) कसे हाताळले आणि टेस्ट स्क्रिप्टने व्हिज्युअल आउटपुटऐवजी "हेल्थ" (health) कशी मोजली, याचा तो एक परिणाम होता.

AI QA एजंट्स रिकाम्या कॅनव्हासकडे दुर्लक्ष का करू शकतात

ते JavaScript कार्यान्वित करतात, स्क्रीनशॉट घेतात आणि मॉडेलला एखादे वैशिष्ट्य योग्यरित्या काम करत आहे की नाही याचा निष्कर्ष काढू देतात. प्रत्यक्षात, दोन तांत्रिक त्रुटींमुळे (blind spots) UI प्रत्यक्षात रिकामे असतानाही वारंवार 'पास' मिळतात.

लपवलेल्या टॅब थ्रॉटलिंगचे (Hidden-tab throttling) स्पष्टीकरण

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

  • JavaScript चालू राहते, त्यामुळे कोणतेही रनटाइम एरर्स (runtime errors) दिसत नाहीत.
  • requestAnimationFrame कॉल बॅक (callbacks) थांबतात, ज्यामुळे ॲनिमेशन फ्रेमची संख्या शून्य राहते.
  • टाइमर्स खूप कमी वेळा चालतात; ज्या चाचणीत 33 ms च्या अंतराची अपेक्षा होती, तिथे केवळ चार वेळाच ते चालले.

AI एजंटला स्वच्छ JS रिझल्ट्स आणि स्क्रीनशॉट दिसतो आणि तो ॲनिमेशन व्यवस्थित चालले आहे असे गृहीत धरतो. रेंडरिंग लूपमुळे कोणतेही पिक्सेल्स तयार न झाल्यामुळे, तो व्हिज्युअल दोष (visual defect) लपलेला राहतो.

लपवलेल्या टॅबच्या समस्यांसाठी उपाय

  • कोणत्याही कॅनव्हास, ॲनिमेशन किंवा ग्राफिक्स पडताळणीसाठी टेस्ट टॅब दृश्यमान (visible) ठेवा.
  • टॅब फोरग्राउंडमध्ये आल्यानंतरच इंटरॅक्शन्स (interactions) सुरू करा.
  • स्क्रीनशॉट घेण्यापूर्वी थोडी प्रतीक्षा (काही सेकंद) करा, जेणेकरून फ्रेम बफर भरला गेला आहे याची खात्री होईल.
  • जर लपवलेला टॅब वापरणे अनिवार्य असेल, तर अहवालाच्या सुरुवातीला “rendering not visually observed” (रेंडरिंग व्हिज्युअली पाहिले नाही) असा डिस्क्लेमर जोडा.

कोड हेल्थ (Code health) विरुद्ध वैशिष्ट्य वर्तन (feature behavior)

बहुतेक AI QA स्क्रिप्ट्स "कोड हेल्थ" तपासतात: त्या क्लिक हँडलर्स (click handlers) जोडलेले आहेत की नाही, कोणतेही JavaScript एक्सेप्शन्स (exceptions) आले नाहीत आणि आवश्यक लायब्ररी लोड झाल्या आहेत की नाही याची खात्री करतात. हे संकेत कोड चालला आहे हे सिद्ध करतात, परंतु UI इच्छितप्रमाणे बदलला आहे हे नाही. जर ड्रॉइंग कमांड्स शून्य-आकारच्या बफरला किंवा रिकाम्या ॲसेटला लक्ष्य करत असतील, तर कॅनव्हास एलिमेंट तयार होऊन, ड्रॉइंग रूटीन कॉल होऊनही काहीही रेंडर होणार नाही.

हा फरक महत्त्वाचा आहे कारण एक 'हेल्दी' कोड पाथ व्हिज्युअल आर्टिफॅक्टची (visual artifact) अनुपस्थिती लपवू शकतो.

वर्तन तपासणी (behavior checks) जोडणे

  1. डायनॅमिक एलिमेंट्स ओळखा – सोर्समध्ये कॅनव्हास टॅग्स, फाईल-इनपुट फील्ड्स, डाउनलोड बटणे आणि ॲनिमेशन लूप्स स्कॅन करा.
  2. निरीक्षणक्षम परिणाम (observable outcomes) परिभाषित करा – कॅनव्हाससाठी, बिटमॅप रिकामी नाही याची पिक्सेल-पातळीवर तपासणी करा. फाईल इनपुटसाठी, प्रिव्ह्यू इमेज दिसते की नाही याची खात्री करा. डाउनलोडसाठी, फाईल सिस्टमवर फाईल तयार झाली आहे की नाही याची पुष्टी करा. ॲनिमेशनसाठी, एखादा ट्रॅक केलेला गुणधर्म (property) वेळेनुसार बदलतो की नाही याची खात्री करा.
  3. रिपोर्ट कव्हरेज – QA आउटपुटमध्ये प्रत्येक वैशिष्ट्य, कोड-हेल्थ स्टेटस आणि वर्तन पडताळणी निकाल दर्शवणारा तक्ता जोडा. ज्यामध्ये वर्तन तपासणी नाही, त्याला "pass" ऐवजी "unverified" (पडताळणी न केलेले) असे ठेवा.

हा नियम लागू केल्यामुळे लेखकाच्या टेस्ट सुईटमधील 'फॉल्स पॉझिटिव्ह' (false positives) मध्ये मोठी घट झाली आणि CSS विसंगती देखील समोर आल्या, जिथे स्टाईलशीटने एक रंग घोषित केला होता परंतु रेंडर झालेला पिक्सेल वेगळा होता.

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

  • चाचण्या नेहमी दृश्यमान (visible) टॅबमध्ये चालवा जेव्हा वैशिष्ट्यामध्ये रेंडरिंगचा समावेश असतो.
  • UI स्थिर होईपर्यंत प्रतीक्षा करा; काही सेकंदांचा ठराविक विलंब अनेकदा पुरेसा असतो, परंतु getImageData वापरून रिकाम्या नसलेल्या कॅनव्हाससाठी पोलिंग (polling) करणे हा अधिक मजबूत दृष्टिकोन आहे.
  • टेस्ट स्क्रिप्टमध्ये कोड-हेल्थ अ‍ॅसर्शन (assertions) आणि व्हिज्युअल अ‍ॅसर्शन वेगळे करा; AI मॉडेलला प्रत्येक गोष्ट स्वतंत्रपणे मूल्यमापन करू द्या.
  • डायग्नोस्टिक आउटपुटचा भाग म्हणून व्हिजिबिलिटी स्टेट आणि फ्रेम काउंटर्स (requestAnimationFrame कॉल्स) लॉग करा.
  • अनिवार्य असलेल्या लपवलेल्या टॅबच्या रनसाठी स्पष्ट चेतावणीसह दस्तऐवजीकरण करा, जेणेकरून पुढील रिव्ह्यूअर्सना (reviewers) मर्यादा समजतील.

पुढे काय लक्षात ठेवावे

जसजसे AI-सहाय्यित QA टूल्स वाढत आहेत, तसे डेव्हलपर्सनी त्यांना सहाय्यक (assistants) म्हणून मानले पाहिजे, निर्णयकार (arbiters) म्हणून नाही. कोड-हेल्थ मेट्रिक्स हे युजर-फेसिंग वर्तनासाठी नेहमीच अपूर्ण पर्याय असतील. याचा मुख्य निष्कर्ष साधा आहे: AI मॉडेल फक्त तेच रिपोर्ट करू शकते जे ते पाहते. जर टॅब लपवलेला असल्यामुळे ब्राउझरने काहीही पेंट केले नाही, किंवा जर टेस्ट स्क्रिप्टने "स्क्रीनवर काहीतरी दिसले का?" असे विचारले नाही, तर मॉडेल आनंदाने यश घोषित करेल. व्हिजिबिलिटीची आवश्यकता आणि वर्तन-पडताळणीची पायरी जोडल्यामुळे, केवळ वरवरचा 'पास' मिळण्याऐवजी एक विश्वासार्ह निकाल मिळतो.