בדיקות רגרסיה לקוד שנכתב עם AI: שומרים על כללי הלגאסי

מתחילים בכלל שהעסק מסתמך עליו

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

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

בדיקות רגרסיה (Regression Testing): החריג שנשכח

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

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

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

בודקים את ההתנהגות הישנה בלי לגעת בעבודה חיה

משתמשים בנתוני בדיקה מבודדים ובנקודה שבה אפשר לראות את הפלט הרלוונטי. אם בדיקה הייתה פונה לשירות ניתוב חי, מחליפים אותו בתגובה מבוקרת בסביבת הבדיקות. Fowler מתאר נקודות הפרדה במערכות לגאסי (Legacy Seams) שמאפשרות לשנות התנהגות ולבודד תלויות לצורך בדיקה.

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

AI code review: מבקשים ראיות בהנחיית הסקירה

נותנים לבודק את הדרישה, השינוי בקוד ומקרי הבסיס. שואלים: איזה ענף משנה את ההתנהגות של פנייה דחופה ללא מיקום, איזו בדיקה קיימת מכסה אותו ואיך אפשר לשחזר כשל? דורשים מיקום מדויק בקוד ובדיקה מוצעת, ולא אישור כללי שהקוד נראה טוב.

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

ממזגים שינוי מוגדר ושומרים את הראיות

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

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

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