اجرای QA مبتنی بر هوش مصنوعی روی یک ابزار طراحی تحت وب گزارش داد: «همه ویژگی‌ها کار می‌کنند، تایید شد»، اما بوم (canvas) چیزی را نمایش نمی‌داد. این تایید کاذب، ناشی از نقص در استدلال مدل نبود؛ بلکه پیامد نحوه مدیریت تب‌های مخفی توسط مرورگر و نحوه اندازه‌گیری «سلامت» توسط اسکریپت تست به جای خروجی بصری بود.

چرا عوامل QA هوش مصنوعی ممکن است بوم خالی را نادیده بگیرند

آن‌ها جاوااسکریپت را اجرا می‌کنند، اسکرین‌شات می‌گیرند و اجازه می‌دهند مدل استنباط کند که آیا یک ویژگی به درستی عمل کرده است یا خیر. در عمل، دو نقطه کور فنی مکرراً زمانی که رابط کاربری (UI) در واقع خالی است، گزارش موفقیت صادر می‌کنند.

توضیح محدودسازی (throttling) در تب‌های مخفی

Chrome MCP اغلب تست‌ها را در تب‌های پس‌زمینه اجرا می‌کند تا پنجره اصلی برای سایر کارها آزاد بماند. وقتی وضعیت document.visibilityState یک تب در حالت hidden باشد، مرورگر خط لوله رندرینگ را محدود می‌کند:

  • جاوااسکریپت همچنان اجرا می‌شود، بنابراین خطای زمان اجرا (runtime error) ظاهر نمی‌شود.
  • فراخوانی‌های requestAnimationFrame متوقف می‌شوند و تعداد فریم‌های انیمیشن روی صفر باقی می‌ماند.
  • تایمرها بسیار کمتر اجرا می‌شوند؛ آزمایشی که انتظار فواصل ۳۳ میلی‌ثانیه‌ای را داشت، تنها چهار مورد را مشاهده کرد.

عامل هوش مصنوعی نتایج تمیز JS و یک اسکرین‌شات را می‌بیند و فرض می‌کند انیمیشن کار کرده است. از آنجایی که حلقه رندرینگ هرگز پیکسلی تولید نکرده است، نقص بصری پنهان می‌ماند.

راهکارهای رفع مشکلات تب‌های مخفی

  • برای هرگونه تایید بوم، انیمیشن یا گرافیک، تب تست را در حالت قابل مشاهده نگه دارید.
  • تعاملات را تنها پس از قرار گرفتن تب در حالت پیش‌زمینه (foreground) اجرا کنید.
  • قبل از گرفتن اسکرین‌شات، یک انتظار کوتاه (چند ثانیه) قرار دهید تا اطمینان حاصل شود که بافر فریم پر شده است.
  • اگر مجبور به استفاده از تب مخفی هستید، در ابتدای گزارش یک سلب مسئولیت مانند «رندرینگ به صورت بصری مشاهده نشد» اضافه کنید.

سلامت کد در مقابل رفتار ویژگی

بیشتر اسکریپت‌های QA هوش مصنوعی «سلامت کد» را ارزیابی می‌کنند: آن‌ها تایید می‌کنند که هندلرهای کلیک متصل هستند، هیچ استثنای (exception) جاوااسکریپتی رخ نداده و کتابخانه‌های مورد نیاز بارگذاری شده‌اند. این سیگنال‌ها ثابت می‌کنند که کد اجرا شده است، نه اینکه رابط کاربری طبق انتظار تغییر کرده باشد. یک المان canvas می‌تواند ایجاد شود، یک روتین ترسیم فراخوانی شود، اما اگر دستورات ترسیم یک بافر با اندازه صفر یا یک دارایی (asset) خالی را هدف قرار دهند، باز هم چیزی رندر نشود.

این تمایز مهم است زیرا یک مسیر کد سالم می‌تواند یک نقص بصری مفقود شده را پنهان کند.

افزودن بررسی‌های رفتاری

  1. شناسایی عناصر پویا – سورس کد را برای تگ‌های canvas، فیلدهای file-input، دکمه‌های دانلود و حلقه‌های انیمیشن اسکن کنید.
  2. تعریف نتایج قابل مشاهده – برای یک canvas، یک بررسی در سطح پیکسل را الزامی کنید که نشان دهد bitmap خالی نیست. برای یک ورودی فایل، تایید کنید که تصویر پیش‌نمایش ظاهر می‌شود. برای دانلود، تایید کنید که فایلی در سیستم فایل ایجاد شده است. برای انیمیشن‌ها، تأکید کنید که یک ویژگی ردیابی‌شده در طول زمان تغییر می‌کند.
  3. گزارش پوشش (coverage) – یک جدول به خروجی QA اضافه کنید که هر ویژگی، وضعیت سلامت کد و نتیجه تایید رفتار را لیست کند. هر چیزی که فاقد بررسی رفتاری باشد، به جای «pass»، به عنوان «unverified» (تایید نشده) باقی می‌ماند.

اعمال این قانون، موارد مثبت کاذب (false positives) را در مجموعه تست نویسنده به شدت کاهش داد و همچنین عدم تطابق‌های CSS را در جایی که استایل‌شیت یک رنگ را اعلام می‌کرد اما پیکسل رندر شده متفاوت بود، آشکار کرد.

مراحل عملی برای تست بصری قابل اعتماد

  • تست‌ها را در یک تب قابل مشاهده اجرا کنید، هر زمان که ویژگی شامل رندرینگ باشد.
  • منتظر بمانید تا رابط کاربری مستقر شود؛ یک تأخیر ثابت چند ثانیه‌ای اغلب کافی است، اما یک رویکرد قوی‌تر، پیمایش (poll) برای یک canvas غیرخالی با استفاده از getImageData است.
  • تاییدهای سلامت کد را از تاییدهای بصری جدا کنید در اسکریپت تست؛ اجازه دهید مدل هوش مصنوعی هر کدام را به طور مستقل ارزیابی کند.
  • وضعیت نمایش (visibility state) و شمارنده‌های فریم (requestAnimationFrame calls) را به عنوان بخشی از خروجی تشخیصی ثبت کنید.
  • هرگونه اجرای اجتناب‌ناپذیر در تب مخفی را مستند کنید با هشدارهای صریح، تا بازبین‌های بعدی محدودیت را درک کنند.

آنچه باید در آینده زیر نظر داشته باشید

با گسترش ابزارهای QA به کمک هوش مصنوعی، توسعه‌دهندگان باید با آن‌ها به عنوان دستیار برخورد کنند، نه داور نهایی. معیارهای سلامت کد همیشه یک جایگزین ناقص برای رفتار کاربرمحور خواهند بود. نکته اصلی ساده است: یک مدل هوش مصنوعی فقط می‌تواند آنچه را که می‌بیند گزارش کند. اگر مرورگر به دلیل مخفی بودن تب هرگز چیزی را ترسیم نکند، یا اگر اسکریپت تست هرگز نپرسد «آیا چیزی روی صفحه ظاهر شد؟»، مدل با خوشحالی موفقیت را اعلام خواهد کرد. افزودن یک الزام نمایش و یک مرحله تایید رفتار، یک تایید براق را به یک نتیجه قابل اعتماد تبدیل می‌کند.