מדוע בדיקות e2e מתפרקות על סביבות לא יציבות
הרצת בדיקות e2e נופלת כל פעם מחדש: אותו תרחיש של ביצוע הזמנה היום ירוק, מחר אדום בשלב האישור. את הסיבה מחפשים בלוגים של הבנייה, אבל היא בסביבה — הרצה מקבילה תפסה את אותו חשבון בדיקה, המיגרציה לא החזירה את הסכימה לאחור, התרחיש הקודם השאיר רשומה בסל.
באופן מקומי אותה בדיקה עוברת עשר פעמים ברצף, ולכן לא מצליחים לשחזר את הנפילה. ב-Playwright זה נראה אותו דבר: יש trace, אבל אין אשם.
נפילות שווא של הרצות עולות יותר ממה שנדמה. זמן המשוב על ענף גדל מדקות לשעות, ושיעור הבדיקות הלא יציבות בדוח מגיע לשליש — לפי מדד כזה אי אפשר לשפוט את מוכנות הגרסה. מפתחים מפעילים מחדש בדיקות שנפלו בלי לקרוא אותן, והרגרסיה האמיתית טובעת ברעש.
לאחר מכן נכנסת לפעולה בדיקה ידנית חוזרת לפני השחרור: נתיבים קריטיים עוברים ידנית, הגרסה נדחית, והביטחון לא גדל.
השורש הוא שהסביבה משותפת, והנתונים אינם מבודדים. כל עוד חשבונות הבדיקה, מצב בסיס הנתונים וסדר ההרצות לא מופרדים לסביבות בלתי תלויות, כל שינוי בבדיקות האוטומטיות רק מסווה את הבעיה. בידוד נתוני הסביבה אינו אופטימיזציה אלא תנאי שבלעדיו הבדיקות האוטומטיות כלל לא נותנות אות. נפרט כיצד זה נסגר.
מה משתנה לאחר הטמעת ההרצות בצינור הבנייה
מדדים מרכזיים שמראים שההרצות הוטמעו בצינור ולא מתקיימות כמשימה לילית נפרדת. כל סעיף נבדק לפי לוגים ומדדים, ולא לפי תחושות הצוות.
- זמן הבנייה. מלוא מערך תרחישי הדפדפן מתפרס לזרמים מקבילים לפי קבצי המפרט, חימום הדפדפנים והכנת הנתונים מוצאים מהנתיב הקריטי — ההרצה נכנסת לדקות ולא נמתחת לשעות.
- שיעור נפילות השווא. המתנה לתגובות רשת ולהופעת אלמנטים מחליפה השהיות קבועות, נתוני הבדיקה מבודדים לפי הרצות — המערך מפסיק להבהב בסביבה לא יציבה, ודוח אדום מעיד על פגם אמיתי.
- גילוי מוקדם של פגמים. הבדיקות רצות על כל בקשת מיזוג: קרע בשרשרת «טופס — בקשה — תגובת שירות — רשומה במאגר» נראה לעיני מחבר השינוי, בעוד ההקשר עוד בראשו.
- זמן שחזור הסביבה. הסביבה עולה מאימג' ו-seed תוך דקות, לאחר תקלה ההרצה מתחילה ממצב נקי ולא מתוקנת בידיו של תורן.
- יכולת התבוננות בתוצאה. הדוח שומר וידאו, trace ותמונת מצב בשלב הנפילה — הניתוח אורך דקות במקום התכתבות «אצלי זה לא משוחזר».
- סוג כשל שנעלם. שגיאות אינטגרציה בין שירותים ורגרסיות בתרחישי משתמש נתפסות לפני הפריסה, ולא בפנייה של לקוח.
Playwright ו-Cypress סוגרים את הסעיפים האלה בדרכים שונות: הראשון נוח יותר להרצות מקבילות ולתרחישים עם מספר לשוניות, השני — לצוותים שכבר בנו את עבודתם עליו. בוחרים לפי אופי האפליקציה ולפי אילו מדדים צריך להזיז.
פורמטים של הרצת בדיקות e2e: רגרסיה, עשן, לילה
מצבי ההרצה נבדלים לא במערך הבדיקות אלא במועד ההרצה ובאופי המשוב שהם נותנים. מערך עשן עונה על שאלה אחת — האם האפליקציה חיה לאחר הפריסה. הוא רץ על כל בנייה לענף הראשי, נכנס לדקות ועוצר את הצינור לפני שגרסה שבורה תגיע לסביבה. המחיר של המהירות — כיסוי צר: רגרסיה בתרחישים עמוקים מערך כזה לא יתפוס.
אין טעם להריץ מערך רגרסיה על כל קומיט: הוא נותן תשובה לאחר עשרות דקות, והרצה מקבילה בזרמים מקצרת את הזמן הזה ביחס למספר מכונות הבנייה. הרצת לילה לוקחת על עצמה את מה שיקר להחזיק במעגל המהיר — מלוא המערך, תרחישים ארוכים, בדיקות על מספר סביבות.
| פורמט הבדיקות | מתי מתאים | במה משלמים |
|---|---|---|
| הרצת עשן | כל בנייה, פריסה לסביבה | כיסוי צר, רגרסיה עמוקה לא נתפסת |
| הרצת רגרסיה | ענף שחרור, קבלה | ממושכת, דורשת משאבי מכונות בנייה |
| הרצת לילה | מלוא המערך לפי לוח זמנים | המשוב מגיע רק בבוקר |
| הרצה מקבילה | מערך גדול, מספר סביבות | נדרש בידוד נתונים, אחרת הבדיקות מפריעות זו לזו |
הרצה מקבילה אינה סוג בדיקות נפרד אלא דרך להכניס את הרגרסיה ליום עבודה: שני הכלים תומכים בפיצול המערך לחלקים, אך דורשים בידוד של נתוני הבדיקה וסביבה נפרדת לכל זרם.
תוכנית עבודה — עשן על כל קומיט, רגרסיה על ענף השחרור, לילה לכיסוי מלא; הבחירה בתצורה מסוימת תלויה בכמה זמן הצוות מוכן להמתין לאות.
שלבי ההטמעה: מביקורת הסביבה ועד מסירת הנהלים
את העבודה מובילים בשלבים, וכל אחד מסתיים בארטיפקט שאפשר לבדוק. הסדר אינו מקרי: תחילה מתעדים את המצב בפועל של הסביבות והתרחישים, אחר כך בונים את סכימת הסביבות, ורק לאחר מכן מגדירים את ההרצות — אחרת הבדיקות נופלות על התשתית ולא על הקוד, והאמון במערך אובד תוך שבועות ספורים.
- ביקורת סביבות ותרחישים. עורכים ספירת מלאי של הקונטורים, ההרשאות ונתוני הבדיקה, אוספים מרשם של נתיבי משתמש קריטיים ומסננים את מה שזול יותר לבדוק ברמה נמוכה יותר. בפלט — מפת כיסוי עם פערים ברורים.
- סכימת הסביבות. מפרידים קונטורים לפי ייעוד: היכן רץ המערך המלא, היכן מערך עשן קצר, כיצד מכינים נתונים ומחזירים מצב לאחור בין הרצות. זה מסיר את הסיבה העיקרית לנפילות שווא.
- הגדרת ההרצות. משלבים את המערך על Playwright ו-Cypress בצינור: על שינויים — רשימה מצומצמת לפי האזורים שנפגעו, בלילה — מלא. הדוח מציג לא «נפלו שנים־עשר בדיקות» אלא נתיב ושלב מסוימים.
- ייצוב הנפילות. מנתחים כל בדיקה לא יציבה: המתנות מפורשות במקום השהיות קבועות, בידוד נתונים, חזרה על הבדיקה רק בתקלת תשתית מאושרת. נקודת ייחוס — שיעור הרצות מוצלחות מעל 95%.
- בדיקה על גרסאות אמיתיות. מריצים את המערך במקביל לכמה שחרורים ומצליבים את האותות עם הפגמים בפועל: רואים אם הוא תופס רגרסיות או רק מרעיש.
- מסירת נהלים. מוסרים תיעוד: כיצד להוסיף בדיקה, כיצד לקרוא את הדוח, מי עושה מה בנפילה. מכאן והלאה הצוות מנהל את המערך בעצמו.
ארטיפקטים בפלט: קונפיגורציות, סכימות סביבות, נהלים
מה שנשאר אצל המזמין — לא דוח על העבודות אלא מערכת ארטיפקטים במאגר שלכם: הרצת בדיקות e2e עולה על מכונה נקייה לפי ההוראות, בלי לפנות אלינו.
- קונפיגורציות סביבה — פרופילים מתוקננים של הסביבה ושל סביבת הטרום־פרודקשן: כתובות, פסקי זמן, מערכי חשבונות בדיקה. הסודות נמצאים במאגר הסודות, והחלפת הסביבה נעשית במשתנה הרצה אחד.
- סכימת הסביבה — תרשים קשרים: היכן רצות הרצות הדפדפן, כיצד מתמלאים נתוני הבדיקה, מה דרוש לשחזור הסביבה מאפס.
- כללי גישה לנתונים — אילו חשבונות בשימוש, אילו נתונים סינתטיים, כיצד מבודדים תרחישים כדי שהרצות מקבילות לא ידרסו זו את מצב זו.
- תיעוד ההרצות — כיצד לקרוא את הדוח, היכן ה-traces והצילומים של שלבים שנפלו, כמה זמן נשמרים הארטיפקטים, כיצד להריץ מחדש תרחיש בודד באופן מקומי.
- נוהל שחרור — אילו מערכים חוסמים את הפריסה, אילו אינפורמטיביים, מי ובאיזה מועד מנתח הרצה אדומה.
- נוהל ניתוח נפילות — קריטריון לתרחיש לא יציב והסגר עם טיקט חובה לתיקון, כדי שהרעש לא יסווה פגמים אמיתיים.
- מודולי עזר — סלקטורים, שלבים ופיקסצ'רים משותפים, כדי שהמהנדסים שלכם יוסיפו תרחישים על Playwright או Cypress בלי עזרתנו.
הקבלה פשוטה: מהנדס שלא השתתף בהטמעה מריץ תרחיש לפי ההוראות מהמאגר. אם זה עובד — המערכת מלאה ומכאן פועלת בלעדינו.
מקרה בוחן: זמן בדיקת השחרור הצטמצם פי ארבעה
נקודת ההתחלה
רגרסיה לפני שחרור הורצה ידנית לפי צ'ק־ליסט: שני מהנדסים השקיעו בה יומיים, והפריסה חיכתה לבודקים ולא להפך. כשליש מההרצות האדומות היה שווא — הבדיקה לא חיכתה למוכנות הממשק, וחלק מהבדיקות חלקו ביניהן את אותם נתונים ונפלו בגלל עקבותיו של תרחיש שכן.
המהנדסים בדקו נפילות כאלה שוב ביד, והאמון באוטומציה ירד עד כדי כך שהפסיקו לקרוא דוח אדום עד השחרור עצמו.
מה שינו
כל תרחיש קיבל מערך נתונים משלו וקונטור נקי שעולה לפני ההרצה ונמחק אחריה — אין יותר חפיפות בין בדיקות. את ההמתנות החליפו בתנאי מוכנות מפורשים של האלמנט, ולא בהשהיות קבועות.
הבדיקות הועברו ל-Playwright: ההרצה מתנהלת במקביל בכמה זרמים, תרחיש שנפל מופעל מחדש פעם אחת תוך שמירת וידאו ו-trace. בדיקות שנשארו בכל זאת לא יציבות מסומנות ואינן חוסמות את הפריסה, אך נכנסות לרשימה נפרדת לניתוח.
מדידות לאחר
| מדד | לפני | אחרי |
|---|---|---|
| בדיקת השחרור | יומיים של הרצה ידנית | כ-4 שעות בקונטור אוטומטי |
| נפילות שווא | כשליש מההרצות | פחות מ-5% |
| פגמים שנמצאו לפני הפריסה | כ-6 מתוך 10 | 9 מתוך 10 |
העיקר כאן אינו המהירות כשלעצמה, אלא שהבדיקה הפסיקה להיות צוואר בקבוק: אפשר לפרוס את הגרסה ביום המוכנות, ולא ביום שבו הבודקים יתפנו. נפילות שווא הפסיקו להסוות נפילות אמיתיות — כעת כל דוח אדום מעיד על פגם מסוים שנראה ב-trace, ולא מהווה סיבה להריץ מחדש ולקוות.
מה לעשות אם הבדיקות כבר פרוסות, אך אין בהן אמון
הקונטור פרוס, אבל ההרצה אדומה: מפעילים מחדש בדיקות עד לירוק, לא קוראים נפילות בדוח, ולפני השחרור הבדיקה הידנית נשארת העיקרית. האמון בבדיקות נשבר לא בגלל בחירת הכלי, אלא בגלל היעדר מדדים ובעלים לקונטור.
מתחילים במספרים: שיעור ההרצות הלא יציבות לכל תרחיש, זמן ההרצה המלאה, שיעור הנפילות שהגיעו לפגם אמיתי. משם ממיינים — חלק מהתרחישים להסגר ולתיקון, חלק סוגרים פערים בהמתנות ובבידוד נתוני הבדיקה, כפולים נמחקים.
המעבר לכלי אחר נעשה לפי דומיין ולא כמקשה אחת: תרחישים חדשים נכתבים רק בקונטור החדש, ותיקים מועברים בעת נגיעה בפונקציונליות. קריטריון היציאה — עשר הרצות ירוקות ברצף בלי הפעלות מחדש ונפילה שנקראת כמשימה, ולא כרעש.
שאלות נפוצות על סביבות, נתונים ונפילות שווא
הספקות שעולים לפני ההתחלה נוגעים בדרך כלל לא לכלי עצמו, אלא למחיר החזקתו. להלן תשובות למה שמהנדסים ומנהלי תחום שואלים לרוב לפני שמכניסים הרצת e2e לצינור הבנייה המשותף.
נפילות שווא יערערו את האמון בהרצה — כיצד אתם מתמודדים עם זה?
הסיבה כמעט תמיד אחת: התרחיש ממתין לזמן ולא למצב הממשק. אנחנו מסירים השהיות, קושרים סלקטורים לתכונות יציבות ולא לסימון, ומבודדים את הנתונים של כל הרצה. חזרה על תרחיש שנפל מוגדרת לצורכי אבחון, ולא כדרך «להפוך לירוק» את הבנייה — אחרת השגיאה האמיתית מוסתרת.
האם דרושה סביבה נפרדת או שמספיק קונטור בדיקות משותף?
נדרשת נפרדת: בקונטור משותף ההרצה האוטומטית והרגרסיה הידנית מפריעות זו לזו — הבדיקות משנות נתונים ושוברות זו את מצבה של זו. הסביבה עולה מאותם תיאורי תשתית כמו סביבת העבודה, אך בהיקף קטן יותר, עם תחליפים למערכות חיצוניות.
מאין לקחת נתוני בדיקה?
מכינים אותם לפני התרחיש דרך ממשקי התוכנה של האפליקציה, עם קידומות ייחודיות, ומסירים אותם לאחר ההרצה. כך ההרצות אינן מתנגשות זו בזו, ובסיס הנתונים נשאר במצב צפוי.
האם יהיה צורך לשכתב תרחישים לאחר כל שחרור?
את התרחישים מתארים ברמת פעולות המשתמש והמשמעות העסקית, ולא ברמת מבנה העמודים, ולכן שינוי עיצוב לא שובר אותם. התמיכה מצטמצמת להוספת נתיבים חדשים ולהסרת מיושנים: רגרסיה ידנית נשארת לבדיקות חקריות וויזואליות, ואוטומטית מחזיקה נתיבים קריטיים.
נדון במשימה: מה להכין לקראת תחילת העבודה
את תחילת העבודה מזרזים לא קילובייטים של תיעוד, אלא שלושה דברים: סביבה שבה הבדיקות יכולות לרוץ, רשימת תרחישים שאסור לשבור, ואנשים שמקבלים החלטות. בלעדיהם הצוות יתכתב בשבוע הראשון במקום לכתוב בדיקות. להלן המינימום שמסיר את רוב השאלות בכניסה.
- גישות למאגר ולצינור הבנייה: בהתחלה מספיקות הרשאות קריאה ויכולת להריץ בנייה ידנית.
- סביבת בדיקות עם בסיס נתונים מבודד, חשבונות ותפקידים צפויים, ויכולת להחזיר נתונים למצב ההתחלתי בין הרצות.
- רשימת תרחישים קריטיים — 10–20 נתיבים שכשל בהם עולה ביוקר: התחברות, תשלום, ביצוע הזמנה, הפקת דוחות.
- החלטה בנוגע לשירותים חיצוניים: היכן מחליפים אותם בתחליפים, והיכן דרושה סביבת בדיקה נפרדת של הספק.
- אנשי קשר לצד הלקוח, לצד השרת ולתשתית — אדם אחד שמרכז את ההחלטות ומאשר את הקבלה.
- ארטיפקטים קיימים: בדיקות ישנות, יומני נפילות, דוחות פגמים, תיאור מחזור השחרור וחלונות הפריסה.
מכאן נתאם את הסדר: תחילה מערך בדיקות מהיר על כל מיזוג ענפים, אחר כך הרחבה לרגרסיה מלאה לפי לוח זמנים. תארו את המשימה ושלחו את מה שכבר קיים — נחזור עם הערכה, תוכנית הטמעת בדיקות E2E וגבולות האחריות.