הרצת ה-QA מבוססת ה-AI בכלי עיצוב מבוסס דפדפן דיווחה על “All features working, pass”, אך הקנבס (canvas) לא הציג דבר. ה-"pass" המזויף לא היה תקלה בלוגיקה של המודל; זה היה תוצאה לוואי של האופן שבו הדפדפן מטפל בלשוניות (tabs) מוסתרות וכיצד סקריפט הבדיקה מדד "בריאות" (health) במקום פלט ויזואלי.

מדוע סוכני AI QA עלולים לפספס קנבס ריק

הם מריצים JavaScript, לוכדים צילומי מסך, ומאפשרים למודל להסיק האם תכונה מסוימת התנהגה כראוי. בפועל, שתי "נקודות עיוורות" טכניות מייצרות שוב ושוב תוצאות pass כאשר ממשק המשתמש (UI) ריק למעשה.

הסבר על הגבלת ביצועים (throttling) בלשוניות מוסתרות

Chrome MCP מריץ לעיתים קרובות בדיקות בלשוניות רקע כדי להשאיר את החלון הראשי פנוי לעבודה אחרת. כאשר ה-document.visibilityState של לשונית הוא hidden, הדפדפן מגביל (throttles) את צינור הרינדור (rendering pipeline):

  • JavaScript ממשיך לרוץ, לכן לא מופיעות שגיאות זמן ריצה (runtime errors).
  • ה-callbacks של requestAnimationFrame מפסיקים לרוץ, מה שמשאיר את מונה פריימי האנימציה על אפס.
  • טיימרים פועלים בתדירות נמוכה בהרבה; בדיקה שציפתה למרווחים של 33ms זיהתה רק ארבעה.

סוכן ה-AI רואה תוצאות JS נקיות וצילום מסך, ומניח שהאנימציה עבדה. מכיוון שלולאת הרינדור מעולם לא ייצרה פיקסלים, הפגם הוויזואלי נשאר מוסתר.

פתרונות לבעיות בלשוניות מוסתרות

  • שמרו על לשונית הבדיקה גלויה עבור כל אימות של קנבס, אנימציה או גרפיקה.
  • הפעילו אינטראקציות רק לאחר שהלשונית נמצאת ב-foreground.
  • הכניסו המתנה קצרה (מספר שניות) לפני לכידת צילום המסך, כדי להבטיח שה-frame buffer התמלא.
  • אם חייבים להשתמש בלשונית מוסתרת, הוסיפו לדו"ח הצהרה כגון “rendering not visually observed”.

בריאות הקוד לעומת התנהגות התכונה

רוב סקריפטי ה-AI QA מעריכים "בריאות קוד" (code health): הם מאשרים ש-click handlers מחוברים, שלא נזרקו חריגות (exceptions) של JavaScript, ושהספריות הנדרשות נטענו. אותם אותות מוכיחים שהקוד רץ, אך לא שה-UI השתנה כמצופה. אלמנט קנבס יכול להיווצר, שגרת ציור (drawing routine) יכולה להיות נקראת, ועדיין לא יתרנדר דבר אם פקודות הציור פונות ל-buffer בגודל אפס או לנכס (asset) ריק.

ההבחנה הזו חשובה מכיוון שמסלול קוד "בריא" יכול להסוות היעדר של רכיב ויזואלי (visual artifact).

הוספת בדיקות התנהגות

  1. זהו אלמנטים דינמיים – סרקו את המקור עבור תגיות canvas, שדות file-input, כפתורי הורדה ולולאות אנימציה.
  2. הגדירו תוצאות ניתנות לצפייה – עבור קנבס, דרשו בדיקה ברמת הפיקסל שה-bitmap אינו ריק. עבור קלט קובץ (file input), ודאו שמופיעה תמונת תצוגה מקדימה. עבור הורדה, אשרו שנוצר קובץ במערכת הקבצים. עבור אנימציות, אשרו שמאפיין (property) מנוטר משתנה לאורך זמן.
  3. דווחו על כיסוי – צרפו טבלה לפלט ה-QA המפרטת כל תכונה, את סטטוס בריאות הקוד ואת תוצאת אימות ההתנהגות. כל דבר שחסרה לו בדיקת התנהגות יישאר “unverified” במקום “pass”.

יישום הכלל הזה הפחית באופן דרמטי את ה-false positives בערכת הבדיקות של המחבר, וגם חשף חוסר התאמה ב-CSS שבו גיליון העיצוב הצהיר על צבע אחד אך הפיקסל שרונדר היה שונה.

צעדים מעשיים לבדיקות ויזואליות אמינות

  • הריצו בדיקות בלשונית גלויה בכל פעם שהתכונה כוללת רינדור.
  • המתינו לייצוב ה-UI; השהיה קבועה של מספר שניות לרוב מספיקה, אך גישה חזקה יותר היא לבצע polling עבור קנבס שאינו ריק באמצעות getImageData.
  • הפרידו בין טענות (assertions) של בריאות הקוד לבין טענות ויזואליות בסקריפט הבדיקה; אפשרו למודל ה-AI להעריך כל אחת מהן באופן עצמאי.
  • תעדו את מצב הנראות ואת מוני הפריימים (requestAnimationFrame calls) כחלק מפלט האבחון.
  • תעדו כל הרצה בלשונית מוסתרת שאינה נמנעת עם אזהרות מפורשות, כדי שבודקים בהמשך התהליך יבינו את המגבלה.

מה כדאי לשים לב אליו בהמשך

ככל שכלי QA בסיוע AI מתרבים, על מפתחים להתייחס אליהם כעוזרים ולא כשופטים. מדדי בריאות קוד תמיד יהיו תחליף (proxy) חלקי להתנהגות מול המשתמש. המסקנה היא פשוטה: מודל AI יכול לדווח רק על מה שהוא רואה. אם הדפדפן מעולם לא מצייר (paints) כי הלשונית מוסתרת, או אם סקריפט הבדיקה מעולם לא שאל “did something appear on screen?”, המודל יכריז בשמחה על הצלחה. הוספת דרישת נראות ושלב אימות התנהגות הופכת "pass" מבריק לתוצאה אמינה.