יצירה אוטומטית של תרחישי בדיקה ב-AI מתוך סיפורי משתמש ו-API

מדוע תרחישי בדיקה מבוססי AI נתקעים בתיוג ידני

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

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

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

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

מה משתנה אחרי ההטמעה: כיסוי ומהירות הרצות

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

• כיסוי דרישות. כל סיפור עם קריטריוני קבלה נפרש למערך בדיקות: תחת שליטה אוטומטית נמצאים 80–90% מההתנהגות המוצהרת, לעומת 40–50% סלקטיביים במעבר ידני.
• זמן הרצה מלאה. המערך הקריטי נכנס לדקות ומופעל על כל שינוי, המלא — לעשרות דקות הודות לחלוקה לחלקים בלתי תלויים; ההמתנה לחלון הלילה נעלמת.
• מחלקת כשלים שנמנעה. פערים בין חוזה השירות לציפיות של מודולים סמוכים נתפסים לפני היציאה לאוויר: מקור האמת מחזיק OpenAPI, ולא תיאור "לאנשים" שמתפצל מהקוד.
• שימוש חוזר בבדיקות. השלבים מוצאים לספרייה משותפת — תרחיש חדש נבנה מבלוקים מוכנים, ושיעור השלבים בשימוש חוזר גדל משחרור לשחרור.
• עלות תחזוקה. עריכת דרישות מעדכנת את הבדיקות המקושרות, תרחישים לא יציבים מסומנים אוטומטית, וניתוח כשלים שגויים מצטמצם פי כמה.

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

שלוש גישות לתרחישי בדיקה מבוססי AI והמגבלות שלהן

שלוש הגישות נבדלות לא בכלי, אלא במקור האמת לבדיקה. בבדיקות תבניתיות זה שלד מתואר מראש, ביצירה לפי דרישות — טקסט סיפור המשתמש ותיאור ה-API, ובגישה ההיברידית — קריאה אמיתית שתועדה בסביבה.

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

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

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

שלבי הטמעה: מביקורת דרישות ועד מסירה

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

1. ביקורת דרישות. מפרקים סיפורי משתמש, אפיון ואוסף בקשות. מסמנים ניסוחים שמהם לא תצא בדיקה הניתנת לאימות — אותם מחזירים למחברים לפני ההתחלה, אחרת המודל ישלים את החסר ונקבל כיסוי מדומה.
2. סכמת יצירה. מתעדים מה מוגש לכניסה (סיפור, חוזה, נתוני בדיקה) ומה צריך להיות ביציאה: שלבים, תשובות מצופות, ערכים גבוליים, פורמט של תרחישי בדיקה מבוססי AI מוכנים.
3. הגדרת חוקים. תנאים מוקדמים מחייבים, בידוד נתונים בין הרצות, עדיפויות בדיקות, איסור על השוואה לערכים משתנים ועל תלות בזמן הנוכחי.
4. בדיקה בפיילוט. לוקחים כמה שיפורים אמיתיים ובודקים: כמה תרחישים עוברים בלי עריכה, היכן המודל טעה, אילו נתונים חסרו. מתקנים את הסכמה, ולא תרחישים בודדים.
5. הטמעה בתהליך. היצירה מופעלת לפי שינוי בדרישות או בחוזה, התוצאה נכנסת למאגר הבדיקות האוטומטיות; הפער בין דרישות לקוד נראה בניתוח השינויים, ולא אחרי השחרור.
6. מסירה לצוות. מוסרים את הסכמה, מערך החוקים וניתוח שגיאות טיפוסיות, ומלמדים על משימות אמיתיות. מכאן הצוות מוסיף חוקים בעצמו ומנתח תרחישים שנויים במחלוקת.

מה נשאר אצלכם: מערכי בדיקות וחוקים

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

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

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

מקרה בוחן: כיצד צמצמנו הרצות ידניות במוצר חי

המוצר — אזור אישי עם חיוב, תפקידי גישה ועשרה אינטגרציות חיצוניות. הרגרסיה נשענה על הרצות ידניות: 320 תרחישים עברו ב-6–8 שעות לפני שחרור, והמסלולים הקריטיים — תשלום, שחזור גישה, שינוי מסלול — היו מכוסים בכ-40%.

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

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

התרחישים יוצאו לקוד מוכן ב-Playwright — הם חיים באותו מאגר של המוצר ומופעלים בצינור הבנייה בעת מיזוג כל ענף. יום "הרצה" נפרד כבר לא קיים.

מה הראו המדדים

שיעור המסלולים הקריטיים המכוסים עלה מ-40% ל-88%, הרגרסיה המלאה הצטמצמה מ-6–8 שעות ל-45 דקות. הפגמים שהגיעו למשתמשים ירדו מ-11–14 ל-2–3 לספרינט.

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

במה יצירה לפי דרישות נבדלת מתיעוד פעולות

שתי השיטות פותרות אותה משימה — לקבל מערך בדיקות שמורץ בכל שחרור. ההבדל במקור האמת: תיעוד פעולות מתעד את מה שהמערכת עשתה ברגע לחיצת הכפתור, ויצירה לפי דרישות — את מה שהיא מחויבת לעשות לפי סיפור המשתמש וחוזה ה-API.

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

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

מה לעשות אם הדרישות חסרות או סותרות?

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

האם לא נכפיל בדיקות אוטומטיות שכבר קיימות?

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

אילו הרשאות גישה לסביבות נדרשות ומה עם בידוד?

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

נדון במשימה: מה נדרש כדי להתחיל

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

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

מה שמאיץ את הערכת הפרויקט:

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

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