כל הבדיקות עברו. המשתמש עדיין לא הצליח לשחק במשחק

"ה-API מחזיר 200 OK!"

עבדתי בעבודה ההנדסית הראשונה שלי וראיתי בעיה משמעותית. המנהלים הבכירים שלי אהבו דאשבורדים. הם אהבו כיסוי קוד גבוה. הם חשבו שאם הבדיקות ירוקות, המוצר עובד.

הם טעו.

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

בניתי דרך למצוא את מבוי הדרכים הללו ב-UX מבלי להריץ את האפליקציה. אני קורא לזה the two-agent static walkthrough. זה משתמש בשני סוכני AI שמתקשרים בלולאה.

  • סוכן A הוא המשתמש. לסוכן הזה יש מטרה ספציפית. הוא עקשן. הוא לא מוותר אחרי טעות אחת. הוא ממשיך לנסות מסלולים שונים.
  • סוכן B הוא האפליקציה. יש לו גישת קריאה לקוד המקור עצמו. הוא עוקב אחר נתיב הקוד של כל פעולת משתמש. הוא מדווח בדיוק מה הקוד עושה. הוא מציין את שם הקובץ ומספר השורה. הוא לא יכול לדמיין דברים שלא קיימים בקוד.

בדקתי את זה על מחולל משחקי מיני מבוסס AI שהיה שבור. הנה מה שקרה:

תור 1: הכפתור נכשל. המשתמש לחץ על "Generate". הקוד שלח את הבקשה ל-endpoint ישן ומת במקום לחדש. הבדיקות עברו כי ה-API הישן עדיין עבד.

תור 2: הריק הבלתי ניתן ללחיצה. המשתמש ניסה ללחוץ על התוצאה. הקוד הציב את הטקסט בתוך תיבה פשוטה ללא click handler. לא קרה כלום.

תור 3: הברכה הכוזבת. המשתמש ניסה לתקן את השגיאה. ה-backend נכשל בגלל ID חסר. המסך הציג הודעת הצלחה ירוקה למרות שהמערכת קרסה.

תור 4: תקווה קטועה. המשתמש ניסה להעתיק את הקוד ידנית. ה-API קטע את הטקסט באמצע. הקוד היה שבור.

המשתמש ויתר.

רוב בדיקות היחידה (unit tests) בודקות רק אם endpoint מחזיר 200. הן לא בודקות אם המשתמש באמת משיג את המטרה שלו.

איך להשתמש בזה:

  • הפכו את סוכן המשתמש לעקשן. באגים אמיתיים מסתתרים מאחורי הטעות הראשונה.
  • הצמידו את סוכן האפליקציה לקוד אמיתי. זה הופך משחק תפקידים לדו"ח באג אמיתי.
  • השתמשו בזה כתוספת לבדיקות שלכם. זה מוצא את הפערים שבהם הלוגיקה שלכם פוגשת את המציאות.

השיטה הזו היא סטטית וזולה. היא רצה עוד לפני שכתבתם אפילו test fixture אחד. היא הופכת את "הקוד עובד" ל"המשתמש מצליח".

מקור: https://dev.to/terum/every-test-passed-the-user-still-couldnt-play-the-game-388o

קהילת למידה אופציונלית: https://t.me/GyaanSetuAi