מערכת בינה מלאכותית של Self-Healing Tests: תיקון אוטומטי של בדיקות שבורות

Self-Healing Tests: מדוע בדיקות אוטומטיות נכשלות אחרי שחרורים

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

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

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

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

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

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

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

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

זמן ריצה ושיעור תיקונים ידניים

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

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

סוג הכשלים שנעלם לחלוטין

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

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

אפשרויות חיבור: מעגל מלא, שכבת-על, מצב ידני

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

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

מה משתנה בסט הבדיקות הקיים

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

כיצד מטמיעים self-healing tests: שלבי העבודה

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

1. ביקורת הסט. מסמנים בדיקות לפי יציבות: כמה נפילות בתקופה, אילו נגרמו משינויי מארקאפ ואילו מהלוגיקה. בפלט — רשימת מועמדים לתיקון אוטומטי ואלה שאי אפשר לרפא.
2. תכנון כללים. מתארים אילו מאפיינים נחשבים לעוגן, אילו החלפות מותרות, מה נחשב לאי-התאמה. את הכללים מתעדים בטקסט, ולא «לפי סיכום בעל פה».
3. הגדרת סביבה. מחברים את המערכת לריצות, מגדירים שמירת היסטוריית נפילות והרשאות לריפוזיטורי הבדיקות.
4. אימון על היסטוריה. מריצים את הנפילות שנצברו: בודקים כמה המערכת מתקנת נכון והיכן היא מציעה תיקונים שגויים.
5. פיילוט על ריצה חיה. עובדים במצב הצעות בלי יישום אוטומטי, ומשווים כל תיקון למופת.
6. העברה לצוות. מתעדים את הכללים, משאירים נוהל לניתוח מקרים שנויים במחלוקת.

קריטריוני קבלה בכל שלב

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

מי משתתף מצד הלקוח

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

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

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

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

תיעוד והדרכת הצוות

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

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

מקרה בוחן: שיעור התיקונים הידניים בבדיקות ירד פי כמה

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

מה היה צוואר הבקבוק לפני ההתחלה

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

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

כיצד מדדו את התוצאה

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

תיקון אוטומטי (self-healing tests) עובד כך: כשהמארקאפ משתנה, המערכת בוחרת אלמנט מעודכן לפי מכלול סימנים — טקסט, תפקיד, צמתים שכנים — ואז מאשרת את הבחירה בכך שהאלמנט מתנהג כמצופה בתסריט. התאמה שגויה לא עוברת הלאה לבדיקת ההתנהגות, ולכן «תיקונים» שגויים לא מסווים פגמים אמיתיים.

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

תיקון אוטומטי מול הרצה מחדש: מה ההבדל

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

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

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

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

ספקות טכניים: התראות שווא וגבולות

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

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

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

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

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

מה עם החזרה לאחור של תיקון מזיק?

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

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

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

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

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

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

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