קבעו יעד: בקוד שנכתב ב-AI, שיעור זיהוי המוטציות צריך להיות מעל 65%. מתחת לזה, הבדיקות הן קישוט.
3. בדיקות חוזה בכל גבול של קוד AI
מפתח שכותב שני מודולים זוכר בראש איך הם מתחברים. כש-AI מייצר מודולים מפרומפטים נפרדים, ההקשר הזה פשוט לא קיים.
מה לעשות: הטמיעו בדיקות חוזה (Pact לשירותים, סכמות ייעודיות למודולים פנימיים) בכל נקודה שבה קוד שנכתב ב-AI מדבר עם קוד אחר. אמתו את מבנה הבקשות והתשובות, את החוזה של טיפול בשגיאות ואת הציפיות מהמרת נתונים.
למה זה חשוב: הבאג הנפוץ ביותר שאנחנו רואים בקוד AI לא נמצא בתוך פונקציה אחת. הוא יושב בגבול בין שתי פונקציות שנוצרו בפרומפטים נפרדים. פונקציה A מחזירה null כשיש שגיאה. פונקציה B מניחה ש-A זורקת Exception. כל אחת עובדת לבד. יחד הן נכשלות. חוזים תופסים את אי-ההתאמות האלה.
4. חבילת בדיקות אבטחה לדפוסים של קוד AI
אל תסמכו על סריקת אבטחה כללית בקוד שנכתב ב-AI. בנו שכבת בדיקות נוספת, שמכוונת לפרצות שידוע שקוד AI נוטה אליהן.
מה לבדוק:
- סודות בתוך הקוד: AI מטמיע הרבה פעמים מפתחות API, מחרוזות חיבור ופרטי גישה ישירות בקוד. סרקו לפי דפוסי אנטרופיה ולפי פורמטים מוכרים של סודות.
- אימות קלט: קוד AI בודק קלט לעתים קרובות רק בחלקו. בדקו עם ערכי גבול, מחרוזות זדוניות וטיפוסים לא צפויים.
- בדיקות הרשאה: ודאו שכל נקודת קצה בודקת הרשאות. AI מייצר לפעמים Routes שעובדים, אבל בלי Middleware של הזדהות.
- הזרקת SQL ו-NoSQL: קוד AI בונה שאילתות משרשור מחרוזות יותר מקוד שאנשים כותבים. בדקו עם Payloads של הזרקה.
- בלבול תלויות: AI עלול להפנות לחבילות שלא קיימות, או לשמות של חבילות מתחזות (Typosquatting). אמתו כל תלות.
אנחנו מחזיקים תבנית בדיקות אבטחה ייעודית לקוד AI, עם 47 דפוסי בדיקה שמכוונים בדיוק לבעיות האלה, ומריצים אותה על כל מאגר עם הרבה קוד AI שאנחנו סוקרים. היא מוצאת בממוצע 3 עד 5 בעיות קריטיות.
5. בדיקות ביצועים תחת עומס אמיתי
קוד שנכתב ב-AI עובד הרבה פעמים מצוין בסביבת הפיתוח וב-Staging, ומתחיל לגמגם בהיקפים של Production. הסיבה: AI כותב קוד קריא ונכון בקנה מידה קטן. הוא לא מתכנן ל-10,000 בקשות במקביל.
מלכודות ביצועים נפוצות בקוד AI:
- שאילתות N+1 למסד הנתונים, שמסתתרות בתוך שכבות הפשטה שנראות נקיות
- דליפות זיכרון מ-Closures שמחזיקים משתנים, בלי שה-AI הבין שהם יישארו בחיים
- פעולות סינכרוניות במקומות שצריך אסינכרוניות, עטופות בתחביר async שנראה תקין
- חיבורי HTTP שלא נשמרים ב-Pool ולא עוברים שימוש חוזר
מה לעשות: הריצו בדיקות עומס שמכוונות במיוחד לנקודות קצה שנבנו עם קוד AI. התחילו בפי 2 מתנועת השיא הצפויה. עקבו אחרי הזיכרון, ה-Connection Pools והתפלגות זמני התגובה (p95 ו-p99, לא ממוצעים). קוד AI שמתפקד יפה ב-p50 יכול לקרוס ב-p95.
6. בדקו התנהגות, לא מימוש
בדיקות שנכתבו ב-AI נוטות לבדוק פרטי מימוש במקום התנהגות. הן בודקות מצב פנימי, קריאות למתודות מסוימות או מבנה של אובייקט, במקום תוצאות שאפשר לראות מבחוץ. ככה הבדיקות שבירות, ונותנות תחושה כוזבת של כיסוי.
מה לעשות: עברו על הבדיקות שה-AI כתב, וכתבו מחדש כל בדיקה שבודקת מימוש. בדיקה טובה אומרת: "כשמשתמש שולח כתובת מייל לא תקינה, הטופס מציג הודעת שגיאה." בדיקה גרועה אומרת: "כש-handleSubmit נקראת עם מייל לא תקין, setError נקראת עם 'Invalid email format'." הבדיקה הראשונה שורדת Refactoring. השנייה נשברת בכל פעם שמשנים שם של פונקציה פנימית.
אכפו את זה ב-Code Review: כל בדיקה צריכה להיות ניתנת לתיאור כהתנהגות שהמשתמש רואה.
7. בדיקת עקביות בין פרומפטים
כש-AI כותב קוד על פני כמה פרומפטים (וזה המצב בכל פיצ׳ר שאינו טריוויאלי), נכנס חוסר עקביות. סגנונות שונים של טיפול בשגיאות בין מודולים. מוסכמות שמות שונות. פתרונות שונים לאותה בעיה בקבצים שונים.
מה לעשות: אחרי פיתוח פיצ׳ר בעזרת AI, הריצו סקר עקביות:
- טיפול בשגיאות: כל המודולים עובדים באותה גישה? try/catch, Result Types או קודי שגיאה: ערבוב סגנונות הוא מקור לבאגים.
- מוסכמות לוגים: AI מייצר הרבה פעמים רמות לוג ופורמטים לא עקביים בין מודולים.
- אימות נתונים: ודאו שכללי האימות של אותם שדות זהים בכל מקום שהם מופיעים.
- ניהול State: בקוד React ובפרונטאנד בכלל, AI מערבב הרבה פעמים דפוסי State שונים באותו פיצ׳ר.
השכבה הארגונית
למדו את סוקרי הקוד לזהות דפוסי AI
תרבות ה-Code Review צריכה להשתנות. הסוקרים צריכים להכיר את הדפוסים שבהם AI נוטה לטעות:
- לוגיקה שמטפלת רק במסלול התקין
- דפוסי אבטחה שכל אחד מהם נראה נכון, אבל יחד הם מתנגשים
- בדיקות שבודקות מימוש במקום התנהגות
- טיפול בשגיאות שתופס Exceptions ובולע אותם בשקט
הוסיפו שערי איכות ב-CI/CD
הגדירו את ה-Pipeline כך ש-Commits שמסומנים כקוד AI יפעילו אוטומטית שכבות בדיקה נוספות. זה לא מאט את המפתח, כי הבדיקות רצות במקביל. וכך קוד AI מקבל את הבדיקה שהוא צריך, בלי לסמוך על כך שכל סוקר יזכור.
גייסו ל-QA מהנדסים בכירים
קוד מעידן ה-AI משנה את הפרופיל של צוות ה-QA שאתם צריכים. חמישה בודקים ידניים שמריצים סקריפטי רגרסיה כבר לא מתאימים לעבודה. צוות קטן יותר של מהנדסי QA בכירים מתאים, בתנאי שהם יודעים:
- לשפוט אם קוד שנכתב ב-AI תואם את הכוונה העסקית, מעבר לנכונות הטכנית
- לתכנן ארכיטקטורת בדיקות שיוצאת מהנחה שהקוד ישתנה מהר ובאופן לא צפוי
- להפעיל סוכני בדיקות AI איפה שהם עובדים טוב, ולהשאיר בני אדם איפה שלא
מדדו את איכות קוד ה-AI בנפרד
עקבו אחרי שיעורי באגים, ממצאי אבטחה ותקלות Production בקוד שנכתב ב-AI לעומת קוד שכתבו אנשים. לא כדי להאשים את הכלי. כדי לדעת איפה למקד את משאבי הבדיקות. אם 70% מהבאגים ב-Production מגיעים מ-30% מהקוד, החלק שנכתב ב-AI, ברור לאן צריכה ללכת ההשקעה בבדיקות.
שאלות נפוצות
שווה לסמן קוד שנכתב ב-AI? זה נשמע כמו עוד עבודה.
כן. המידע שווה את 5 השניות לכל Commit. צוותים שעוקבים אחרי קוד AI יכולים למקד את משאבי הבדיקות ולמדוד הבדלי איכות. צוותים שלא עוקבים עובדים בעיניים עצומות מול מקור הבאגים שגדל אצלם הכי מהר.
כדאי לאסור על כלי AI לכתיבת קוד?
לא. שיפור התפוקה אמיתי. אבל כתיבת קוד ב-AI בלי ניהול היא כמו לתת לכל מפתח לשחרר ישירות ל-Production: המהירות מלהיבה עד שמשהו נשבר. הפתרון הוא תהליך, לא איסור.
כלי בדיקות AI יכולים לפתור את הבעיות שכתיבת קוד ב-AI יוצרת?
חלקית. סוכני בדיקות AI טובים בכתיבת מקרי בדיקה, בתחזוקת סקריפטים ובהרחבת הכיסוי. הם חלשים בשיפוט של לוגיקה עסקית, של השלכות אבטחה ושל קוהרנטיות ארכיטקטונית. המודל שעובד: כלי AI בהכוונה של מהנדסי QA בכירים, שיודעים מה "נכון" אומר במוצר שלכם.
כמה בדיקות נוספות צריך קוד שנכתב ב-AI?
תקצבו 30% עד 50% יותר זמן בדיקות לפיצ׳רים עם הרבה קוד AI. ההשקעה הזו מחזירה את עצמה בדרך כלל, כי יש פחות תקלות ב-Production. נשמח לעזור לכם לבנות את תהליך הבדיקות הנכון לפיתוח בעידן ה-AI.
אנחנו צוות קטן. זה לא יותר מדי בשבילנו?
התחילו בצעד 1 (סימון קוד AI) ובצעד 4 (בדיקות אבטחה). לשניהם יש את היחס הטוב ביותר בין השפעה למאמץ. הוסיפו בדיקות מוטציה ובדיקות חוזה ככל שהקוד גדל. גם צוות קטן יכול להריץ סריקת אבטחה בסיסית על כל PR. לצוותים עם משאבים מוגבלים, QA במיקור חוץ יכול לסגור את הפערים.
