מערכת AI לאוטומציה של בדיקות תוכנה ו-QA

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

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

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

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

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

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

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

מה נותן המימוש: אפקטים מדידים במחזור השחרור

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

שיעור התקלים שאותרו לפני השחרור

המערכת מתעדפת בדיקות לפי אזורי הקוד שהשתנו והיסטוריית השברים הקודמים, ולכן הרגרסיה רצה לא במלואה אלא בנתיבים שנגעו בהם. שיעור התקלים שנלכדים לפני הריליז עולה מ-60–70% אופייניים ל-90% ומעלה — השגיאות מכובות בשלב הבנייה, ולא בקבלה, שבה התיקון נוגע בריליז שכבר נבנה.

זמן ההרצה ותדירות ההפעלות

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

סוג התקלות שהוסר

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

גישות לאוטומציה של בדיקות: אפשרויות ומגבלות

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

הרצה היברידית: כללים ועוד מודל

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

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

מתי אוטומציות קלאסיות משתלמות יותר

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

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

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

ביקורת ומפת כיסוי

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

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

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

נכסים הנדסיים: קונפיגורציות, סכמות ותקנוני ההרצה

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

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

כללי גישה לנתוני בדיקה

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

תקנון ניתוח נפילות

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

מקרה בוחן: הרגרסיה לפני הריליז הצטמצמה משני ימים לשעה

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

מה היה לפני

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

• הרצה מלאה: יומיים, 3 מהנדסים
• תדירות ההפעלות: פעם בשבוע
• תקלים שהגיעו עד השחרור: כ-30%
• בדיקת תיקונים בין ריליזים: לא הייתה קיימת

מה השתנה אחרי המסירה

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

• רגרסיה מלאה: כשעה
• תדירות ההפעלות: על כל שינוי, למעלה ממאה הרצות בשבוע
• תקלים שהגיעו עד השחרור: בודדים, כ-4%
• עומס: מהנדס אחד לניתוח נפילות במקום שלושה להרצה ידנית

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

במה שונה בדיקה עם מודל מאוטומציות קלאסיות?

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

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

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

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

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

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

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

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

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

אפשר לפרוס הכול במערך סגור?

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

מה יקרה לאוטומציות שכבר נכתבו?

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

מי מתחזק את האוטומציות אחרי המסירה?

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

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

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

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

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