இணைய அடிப்படையிலான ஒரு வடிவமைப்பு கருவியில் (web-based design tool) இயக்கப்பட்ட AI-அடிப்படையிலான QA, "அனைத்து அம்சங்களும் இயங்குகின்றன, வெற்றி (pass)" என்று அறிக்கை அளித்தது, ஆனால் கேன்வாஸில் (canvas) எதுவும் தெரியவில்லை. இந்தத் தவறான 'pass' அறிக்கை மாதிரியின் (model) பகுத்தறிவில் ஏற்பட்ட பிழை அல்ல; மாறாக, பிரவுசர் மறைக்கப்பட்ட டேப்களை (hidden tabs) எவ்வாறு கையாளுகிறது மற்றும் சோதனை ஸ்கிரிப்ட் காட்சி வெளியீட்டிற்குப் பதிலாக "ஆரோக்கியத்தை" (health) எவ்வாறு அளவிடுகிறது என்பதன் பக்கவிளைவே ஆகும்.

ஏன் AI QA ஏஜெண்டுகளால் காலியான கேன்வாஸைக் கண்டறிய முடிவதில்லை

அவை JavaScript-ஐ இயக்கி, ஸ்கிரீன்ஷாட்டுகளைப் பிடித்து, ஒரு அம்சம் சரியாகச் செயல்படுகிறதா என்பதை மாதிரி (model) ஊகிக்கும் வகையில் செயல்படுகின்றன. நடைமுறையில், UI உண்மையில் காலியாக இருக்கும்போது, இரண்டு தொழில்நுட்பக் குறைகள் (blind spots) மீண்டும் மீண்டும் தவறான 'pass' முடிவுகளைத் தருகின்றன.

மறைக்கப்பட்ட டேப் த்ரோட்லிங் (Hidden-tab throttling) விளக்கம்

Chrome MCP பெரும்பாலும் முக்கிய விண்டோவை மற்ற வேலைகளுக்காகத் தயார் நிலையில் வைத்திருக்க, பின்னணி டேப்களில் (background tabs) சோதனைகளை இயக்கும். ஒரு டேப்பின் document.visibilityState hidden நிலையில் இருக்கும்போது, பிரவுசர் அதன் ரெண்டரிங் பைப்லைனைத் (rendering pipeline) தணிக்கிறது (throttles):

  • JavaScript தொடர்ந்து இயங்குவதால், ரன்டைம் பிழைகள் (runtime errors) எதுவும் தோன்றாது.
  • requestAnimationFrame கால்பேக்குகள் (callbacks) இயங்குவது நின்றுவிடும், இதனால் அனிமேஷன் பிரேம் எண்ணிக்கை பூஜ்ஜியமாக இருக்கும்.
  • டைமர்கள் (Timers) மிகக் குறைவாகவே இயங்கும்; 33 ms இடைவெளியை எதிர்பார்த்த ஒரு சோதனை, வெறும் நான்கு இடைவெளிகளை மட்டுமே கவனிக்கும்.

AI ஏஜென்ட் சுத்தமான JS முடிவுகளையும் ஒரு ஸ்கிரீன்ஷாட்டையும் பார்த்து, அனிமேஷன் சரியாக வேலை செய்ததாகக் கருதுகிறது. ரெண்டரிங் லூப் (rendering loop) ஒரு பிக்சலையும் உருவாக்காததால், அந்தத் காட்சிப் பிழை மறைந்தேவிடுகிறது.

மறைக்கப்பட்ட டேப் சிக்கல்களுக்கான தீர்வுகள்

  • கேன்வாஸ், அனிமேஷன் அல்லது கிராபிக்ஸ் சரிபார்ப்புகளுக்கு சோதனை டேப்பைத் (test tab) தெரியும்படி வைத்திருக்கவும்.
  • டேப் முன்னணியில் (foreground) வந்த பின்னரே தொடர்புகளைத் (interactions) தூண்டவும்.
  • ஸ்கிரீன்ஷாட்டைப் பிடிப்பதற்கு முன் ஒரு சிறிய காத்திருப்பு நேரத்தை (சில வினாடிகள்) சேர்க்கவும், இதன் மூலம் பிரேம் பஃபர் (frame buffer) நிரப்பப்பட்டிருப்பதை உறுதி செய்யலாம்.
  • ஒரு மறைக்கப்பட்ட டேப்பைப் பயன்படுத்த வேண்டிய கட்டாயம் இருந்தால், அறிக்கையின் தொடக்கத்தில் “rendering not visually observed” போன்ற ஒரு எச்சரிக்கையைச் சேர்க்கவும்.

குறியீட்டு ஆரோக்கியம் (Code health) vs அம்சத்தின் செயல்பாடு (Feature behavior)

பெரும்பாலான AI QA ஸ்கிரிப்ட்கள் "குறியீட்டு ஆரோக்கியத்தை" (code health) மதிப்பிடுகின்றன: அவை கிளிக் ஹேண்ட்லர்கள் (click handlers) இணைக்கப்பட்டுள்ளனவா, எந்த JavaScript விதிவிலக்குகளும் (exceptions) ஏற்படவில்லை மற்றும் தேவையான லைப்ரரிகள் (libraries) ஏற்றப்பட்டுள்ளனவா என்பதை உறுதி செய்கின்றன. அந்த சிக்னல்கள் குறியீடு இயங்கியதை மட்டுமே நிரூபிக்கின்றன, UI திட்டமிட்டபடி மாறியதை அல்ல. ஒரு கேன்வாஸ் உறுப்பு (canvas element) உருவாக்கப்படலாம், ஒரு டிராயிங் ரூட்டின் (drawing routine) அழைக்கப்படலாம், ஆனால் டிராயிங் கட்டளைகள் பூஜ்ஜிய அளவு கொண்ட பஃபர் அல்லது காலியான அசெட்டை (asset) இலக்காகக் கொண்டிருந்தால், அது எதையும் காட்டாது.

ஒரு ஆரோக்கியமான குறியீடு பாதை, விடுபட்ட காட்சித் தடையை (visual artifact) மறைக்கக்கூடும் என்பதால் இந்த வேறுபாடு முக்கியமானது.

செயல்பாட்டுச் சரிபார்ப்புகளைச் சேர்த்தல்

  1. இயக்கவியல் கூறுகளைக் கண்டறிதல் (Identify dynamic elements) – கேன்வாஸ் டேக்ஸ் (canvas tags), file-input புலங்கள், டவுன்லோட் பட்டன்கள் மற்றும் அனிமேஷன் லூப்களை மூலக் குறியீட்டில் (source) தேடவும்.
  2. கவனிக்கக்கூடிய முடிவுகளை வரையறுத்தல் (Define observable outcomes) – ஒரு கேன்வாஸிற்கு, பிட்மேப் (bitmap) காலியாக இல்லை என்பதை பிக்சல் அளவில் சரிபார்க்க வேண்டும். ஒரு file input-க்கு, ஒரு முன்னோட்டப் படம் (preview image) தோன்றுகிறதா என்பதை உறுதிப்படுத்தவும். ஒரு டவுன்லோடிற்கு, கோப்பு ஃபைல் சிஸ்டத்தில் உருவாக்கப்பட்டுள்ளதா என்பதை உறுதிப்படுத்தவும். அனிமேஷன்களுக்கு, ஒரு குறிப்பிட்ட பண்பு (property) காலப்போக்கில் மாறுகிறதா என்பதைச் சரிபார்க்கவும்.
  3. மூலப்பொருள் கவரேஜ் (Report coverage) – ஒவ்வொரு அம்சத்தையும், குறியீட்டு ஆரோக்கிய நிலையைத் (code-health status) மற்றும் செயல்பாட்டுச் சரிபார்ப்பு முடிவையும் (behavior verification result) பட்டியலிடும் ஒரு அட்டவணையை QA வெளியீட்டுடன் இணைக்கவும். செயல்பாட்டுச் சரிபார்ப்பு இல்லாத எதுவும் "pass" என்பதற்குப் பதிலாக "unverified" என்று இருக்க வேண்டும்.

இந்த விதியைப் பயன்படுத்துவது ஆசிரியரின் சோதனைத் தொகுப்பில் (test suite) தவறான நேர்மறை முடிவுகளை (false positives) பெருமளவு குறைத்தது, மேலும் ஸ்டைல்ஷீட் (stylesheet) ஒரு நிறத்தைக் குறிப்பிட்டாலும், ரெண்டர் செய்யப்பட்ட பிக்சல் வேறுபட்டிருந்த CSS முரண்பாடுகளையும் வெளிப்படுத்தியது.

நம்பகமான காட்சிச் சோதனைக்கான நடைமுறைப் படிகள்

  • சோதனைகளைத் தெரியும்படி இருக்கும் ஒரு டேப்பில் இயக்கவும் whenever the feature involves rendering.
  • UI நிலைபெறக் காத்திருக்கவும்; சில வினாடிகள் நிலையான தாமதம் போதுமானதாக இருக்கலாம், ஆனால் getImageData-வைப் பயன்படுத்தி காலியான கேன்வாஸைக் கண்டறிவது ஒரு சிறந்த அணுகுமுறையாகும்.
  • சோதனை ஸ்கிரிப்ட்டில் குறியீட்டு ஆரோக்கிய உறுதிப்பாடுகளை (code-health assertions) காட்சி உறுதிப்பாடுகளிலிருந்து (visual assertions) பிரிக்கவும்; AI மாதிரியை ஒவ்வொன்றையும் தனித்தனியாக மதிப்பிட அனுமதிக்கவும்.
  • கண்டறியும் வெளியீட்டின் (diagnostic output) ஒரு பகுதியாகத் தெரிவு நிலை (visibility state) மற்றும் பிரேம் கவுண்டர்களை (requestAnimationFrame அழைப்புகள்) பதிவு செய்யவும்.
  • தவிர்க்க முடியாத மறைக்கப்பட்ட டேப் சோதனைகளை, தெளிவான எச்சரிக்கைகளுடன் ஆவணப்படுத்தவும், இதனால் அடுத்தகட்ட ஆய்வாளர்கள் அந்த வரம்பைப் புரிந்துகொள்வார்கள்.

அடுத்து எதைக் கவனிக்க வேண்டும்

AI-உதவி பெறும் QA கருவிகள் பெருகி வரும் நிலையில், டெவலப்பர்கள் அவற்றை உதவியாளர்களாகவே கருத வேண்டும், தீர்ப்பாளர்களாக அல்ல. குறியீட்டு ஆரோக்கிய அளவீடுகள் (Code-health metrics) எப்போதும் பயனர் எதிர்கொள்ளும் செயல்பாட்டிற்கான முழுமையற்ற மாற்று அளவுகோல்களாகவே (proxy) இருக்கும். இதன் கருத்து எளிமையானது: ஒரு AI மாதிரி தான் காண்பதை மட்டுமே அறிக்கையிட முடியும். டேப் மறைக்கப்பட்டிருப்பதால் பிரவுசர் எதையும் வரையவில்லை என்றாலோ, அல்லது "திரையில் ஏதேனும் தோன்றியதா?" என்று சோதனை ஸ்கிரிப்ட் கேட்கவில்லை என்றாலோ, அந்த மாதிரி மகிழ்ச்சியுடன் வெற்றியை அறிவிக்கும். ஒரு தெரிவுத் தேவையை (visibility requirement) மற்றும் செயல்பாட்டுச் சரிபார்ப்புப் படிநிலையைச் சேர்ப்பது, ஒரு மேலோட்டமான 'pass' அறிக்கையை ஒரு நம்பகமான முடிவாக மாற்றும்.