מדוע E2E smoke tests נופלים בפרודקשן
E2E smoke tests מורצים לאחר כל ריליס, כדי לקבל בתוך דקות תשובה: תרחישי המפתח — התחברות, ביצוע הזמנה, תשלום — חיים.
בפרודקשן ההרצה נופלת לא בגלל פגם בקוד, אלא בגלל הסביבה: חשבון בדיקה נתקל במגבלת בקשות, שער תשלומים חיצוני מגיב אחרת מאשר בסביבת הבדיקות, וההמתנה לאלמנט מבוססת על השהיה קבועה שלא מספיקה בעומס אמיתי. בסופו של דבר אות אדום בערוץ התורנות מופיע בתדירות גבוהה בהרבה מתקלה אמיתית.
המחיר — אובדן האמון בבדיקה. כאשר רוב הנפילות שגויות, התורן מפסיק לנתח כל הרצה: תחילה מסתכל «בעין», אחר כך פשוט מריץ מחדש את הסט, ובהמשך מתעלם. ברגע זה רגרסיה לאחר ריליס — שלב תשלום שבור, בלוק אימות שהתנתק — עוברת לפרוד בלי ששמים לב, ונודע עליה מפניות המשתמשים ולא מהמוניטורינג. את החזרה לאחור מכינים ידנית, וההשבתה נמדדת בשעות.
בדיקות ידניות אינן סוגרות את הפער הזה. צ'קליסט לפני ריליס גדל יחד עם המוצר: תחילה עשרה תרחישים, אחר כך שלושים, ובכל זאת הוא מכסה רק את מה שהספיקו לעבור ידנית. צווארי הבקבוק של מחזור הריליס נמצאים לא בבנייה, אלא באימות הידני — הוא תופס יותר ויותר זמן ואינו נותן ערבויות.
השורש הוא בבדיקות התלויות בנתוני בדיקה משותפים ובשירותים חיצוניים, בלי ציפיות מצב מפורשות. אנחנו בונים סט על Playwright עם בידוד נתונים וסביבה נפרדת לאינטגרציות — נפרט בהמשך כיצד זה נסגר.
מה נותנת בדיקה סדירה של תרחישי המפתח לאחר ריליס
E2E smoke tests הם סט קצר של 10–20 תרחישים שעוברים את המסלול הקריטי של האפליקציה: אימות, ביצוע הזמנה, תשלום, מסירת נתונים מ-API. הסט מורץ לאחר כל דיפלוי, ולא פעם ביממה, ולכן את התקלה רואים באותו ריליס שהביא אותה.
זמן גילוי התקלה — דקות במקום שעות
כל עוד אדם מריץ את הבדיקות, בין הריליס לאות הראשון עוברות שעות, ולפעמים עד הבוקר שלמחרת. הרצה אוטומטית מחזירה תוצאה בתוך דקות ספורות, וההתראה נשלחת לתורן לפני שהמשתמשים כותבים על הבעיה. את האירוע מנתחים לפי לוגים טריים, ולא לפי שחזור האירועים.
השבתה קצרה יותר — פחות הפסדים
עלות ההשבתה נקבעת לא לפי עצם הנפילה, אלא לפי מספר הפעולות שלא נכנסו לתוכה. אם התקלה נסגרת בחלון של חמש דקות במקום חלון לילי, היקף ההזמנות והפניות שאבדו מצטמצם פי כמה. במקביל יורד העומס על התמיכה: במקום זרם פניות מלקוחות, הצוות עובד עם אות אוטומטי אחד.
נעלם סוג התקלות שבדיקות יחידה אינן תופסות
סט ה-smoke חושף את מה שאינו משוחזר לוקאלית: קונפיגורציית סביבה שהתפרקה, מסד נתונים לא זמין, שירות חיצוני שהתנתק, מיגרציה שלא הוחלה. אלה תקלות ברמת חיבור השירותים, והן נתפסות באופן עקבי רק בסביבה החיה.
הבדיקות לאחר ריליס מורצות מעצמן
ההרצה מוטמעת בצנרת הדיפלוי: הבנייה נבנית, האפליקציה נפרסת, הסט עולה בלי מעורבות אדם. כשתרחיש נופל, השחרור נעצר או חוזר לגרסה הקודמת — התורן מקבל עובדה מוגמרת, ולא שאלה «מה קרה».
השוואה בין גישות לבדיקות smoke של פרודקשן
את הגישה בוחרים לפי סוג התקלה שצריך לתפוס ולפי מהירות התגובה. צ'קליסט ידני סוגר את הקבלה לאחר הדיפלוי, אך אינו נותן היסטוריה ושותק בין ריליסים.
בדיקות סינתטיות עוברות את המסלולים הקריטיים לפי לוח זמנים ומעלות התראה תוך דקות; נתוני סשנים אמיתיים נותנים חתך על כל בסיס המשתמשים, אך רק לאחר שחלק מהאנשים לא הצליחו לשלם על הזמנה.
בפועל משלבים בין האפשרויות: הסינתטיקה תופסת תקלה מפורשת, ריליס קנרי מגביל את רדיוס הפגיעה לחלק מהתעבורה עם חזרה אוטומטית, וניתוח הסשנים מדייק היכן בדיוק נמצאת הירידה בביצועים. להלן — הגבולות של כל גישה והתנאים שבהם היא משתלמת.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| צ'קליסט ידני | דיפלויים חד-פעמיים, מחזור ריליס נדיר, אין עדיין בדיקות אוטומטיות | שותק בין בדיקות, תלוי במבצע, אין היסטוריית הרצות |
| מוניטורינג חיצוני של זמינות | צריך לדעת שהשירות מגיב ושהתעודות לא פגו | מסתכל על קוד התגובה ולא על התרחיש: עמוד ריק או טופס שבור יישארו בלי ששמים לב |
| בדיקות E2E smoke סינתטיות | יש רשימת מסלולים קריטיים: התחברות, תשלום, מסירת נתונים | דורשות תחזוקה של סלקטורים, חשבונות בדיקה ונתוני בדיקה נקיים; ענפים נדירים נשארים מחוץ לכיסוי |
| ריליס קנרי | דיפלויים תכופים, יש מדד הצלחה ושליטה בשיעור התעבורה | נדרשים חזרה אוטומטית וסף שגיאות; ירידת ביצועים מושהית הרצה כזו לא תתפוס |
| מוניטורינג של משתמשים אמיתיים | נדרשת תמונה על כל בסיס המשתמשים ומכשירים שונים | ריאקטיבי: האות מגיע לאחר תקלה אצל אנשים, הרבה רעש מהסביבות שלהם |
שלבי ההטמעה: מהאודיט ועד המסירה
ההטמעה מתנהלת בשלבים, וכל שלב נסגר בארטיפקט: רשימת תרחישים, קונפיגורציית הרצה, נוהל לתורן. הסדר נבנה כך שהבדיקות יתחילו לתפוס רגרסיה עוד לפני המעבר לסביבת העבודה.
- אודיט תרחישים. עורכים מלאי של המסלולים הקריטיים: כניסה לאזור האישי, ביצוע הזמנה, החלפות עם שירותים חיצוניים. לסט לוקחים את מה שנפילתו שווה לאירוע, ולא קוסמטיקה בעמוד.
- תרשים ההרצה. קובעים מה נחשב לנפילה: קוד תגובה, תוכן העמוד, זמן תגובה. מכינים נתוני בדיקה כדי שההרצה לא תפריע למשתמשים אמיתיים ולא תקלקל את הסטטיסטיקה.
- הגדרת הרצה לפי טריגר. ללוח הזמנים מוסיפים הרצות אירועיות: הרצה לאחר דיפלוי ולפי אות מוניטורינג. התוצאות נשלחות לערוץ ההתראות המשותף, לצד שאר אותות המוניטורינג.
- בדיקת ספים. מכוונים את הרגישות: כמה התראות שווא אנחנו סובלים, איזו השהיית תגובה נחשבת תקינה. את הסף שבו התורן מפסיק לפתוח התראות — בודקים מחדש.
- ייצוב. ההרצות הראשונות נותנות רעש: שירותים חיצוניים לא יציבים, נתונים צפים. מתקנים את הסיבה, ולא מכבים את התרחיש.
- מסירת הנוהל. מוסרים תיעוד, הוראה «מה לעשות כשנופל» ותרשים אסקלציה. בהמשך צוות הלקוח מוסיף תרחישים בעצמו.
לאחר המסירה הבדיקות חיות בעצמן: מספיק להוסיף תרחיש חדש לסט המשותף.
חבילת המסירה: קונפיגורציות, תרשיםים, נוהלים
המוניטורינג של סביבת הייצור נשען לא על הבדיקות עצמן, אלא על ההסכמות סביבן. חבילת e2e smoke tests נמסרת יחד עם תיאור כיצד לשנות אותה, להרחיב ולנתח נפילות. כל הארטיפקטים נמצאים במאגר הפרויקט ומנוהלים בגרסאות יחד עם הקוד — בעת החלפת קבלן או הרכב הצוות אין צורך לשחזר דבר מהזיכרון.
- קונפיגורציות הבדיקות — סביבות, חשבונות בדיקה, מערכי נתונים, זמני המתנה (timeouts) לשלבים, סף ההפעלה ורשימת נמעני ההתראות. משתנות בלי לערוך את קוד התרחישים.
- תרשימי התרחישים — מפת המסלולים הקריטיים: כניסה, חיפוש, ביצוע הזמנה, תשלום, אזור אישי. עבור כל שלב מצוינת התוצאה הצפויה והסימן שלפיו השלב נחשב לנפול.
- מדיניות גישה — חשבונות שירות עם הרשאות מינימליות, מאגר סודות נפרד, נוהל רוטציה של מפתחות ואיסור שימוש בנתוני משתמשים אמיתיים.
- נוהל תגובה לתקלה — רמות קריטיות, מי הראשון שלוקח את ההתראה, תוך כמה זמן מגיב, מתי מצטרפת הפיתוח וכיצד להבדיל בין התראת שווא לירידת ביצועים אמיתית.
- הוראות תחזוקה — כיצד להוסיף תרחיש, היכן לערוך את הקונפיגורציה, כיצד להריץ את הסט כולו לפני הדיפלוי.
- דיווח — פורמט תוצאות ההרצה, היסטוריית ההרצות, חתך לפי זמן תגובה ושיעור הבדיקות היציבות בתקופה.
- מסירה והדרכה — סקירה עם צוות התורנות, מעבר משותף על האירועים הראשונים, מענה על תרחישים שנויים במחלוקת.
מקרה בוחן: קיצרנו את זמן גילוי התקלה לאחר ריליס
הלקוח — שירות עם אזור אישי, תשלום וייצוא מסמכים, ריליסים יוצאים שלוש-ארבע פעמים בשבוע. לפני הדיפלוי רצו בדיקות אוטומטיות, אך לאחר הדיפלוי איש לא אימת שהמסלולים הקריטיים חיים.
את הרגרסיה בביצוע ההזמנה גילו מפניות לתמיכה — לאחר כמה שעות, כשחלק מההזמנות כבר לא עברו, והסיבה הייתה בשינוי שנעשה לאחרונה בקונפיגורציית חישוב המשלוח.
מה שינו
בנינו סט e2e smoke tests על Playwright: כניסה, חיפוש, סל, תשלום, אזור אישי, ייצוא מסמכים — רק אותם תרחישים שנפילתם משמעה אובדן הזמנות ופניות. הסט מורץ בסביבת הבדיקות לפני הדיפלוי ומיד אחריו בכתובת הפרודקשן, ובהמשך — לפי לוח זמנים כל 15 דקות.
כשנופל, נשלח לערוץ התורנות אות עם השלב שבו הכול נשבר, וטрейс: את האבחנה קוראים בדקה, בלי שחזור ידני. את היציבות נתנו בידוד נתוני בדיקה, סלקטורים עמידים וחזרה רק על שגיאות רשת — אחרת התורן מפסיק להאמין לאותות.
מה התוצאה
החציון של זמן גילוי התקלה ירד מ-4–6 שעות ל-4 דקות, כ-90% מהתקלות נתפסות לפני הפנייה הראשונה של המשתמש. מספר הפגמים שהוחמצו — בודדים ברבעון במקום עשרות: תיקונים בהול מפונים על ידי התוכנית הרגילה. שיעור הריליסים שאחריהם נדרשה חזרה לאחור ירד מבערך אחד מחמישה לאחד מעשרים.
את התראות השווא אנחנו מחזיקים מתחת ל-5%, ולכן אותות ליליים אינם מתעלמים. האמון בריליסים חזר: הדיפלויים שוב מתבצעים מדי יום, השחרור בימי שישי הפסיק להיות סיכון נפרד, ומהנדס התורנות מקבל את שלב התרחיש ואת הטрейс במקום הודעה «האתר לא עובד».
במה נבדלות בדיקות סינתטיות ממוניטורינג משתמשים?
ההבדל מתחיל במי שיוזם את הבדיקה. מוניטורינג סינתטי הוא רובוט שעובר לפי לוח זמנים תרחיש שהוגדר מראש בסביבה חיצונית ויודע את התוצאה הצפויה של כל שלב. מוניטורינג משתמשים עובד הפוך: הנתונים נאספים מסשנים אמיתיים — דפדפנים חיים, מכשירים, רשתות ומסלולים שאנשים באמת עוברים.
בזכות זה הסינתטיקה נותנת דיוק גבוה של אותות: נפילה פירושה חד-משמעית נפילה, ההתראה נשלחת לתורן בלי צבירת סטטיסטיקה ובלי כיול ספים. הבדיקה נעשית מבחוץ, ולכן התקלה נראית לפני שהלקוח הראשון כותב עליה. המחיר — הכיסוי של התרחישים הוא בדיוק מה שתיארנו: מסלול שלא נכנס לסט אינו נבדק כלל.
מוניטורינג של משתמשים אמיתיים עונה על שאלה אחרת — מה קורה באמת. הוא מציג את שיעור הסשנים המוצלחים, את זמן התגובה במסלולים מסוימים ואת השלב שבו אנשים נושרים, למשל בתשלום.
אבל האות מאחר: על הבעיה אנחנו לומדים לאחר שהיא פגעה בקונים, ואת הרעש ממכשירים איטיים ומתוספים של צד שלישי יש לסנן בעזרת נפח הנתונים.
לכן הגישות אינן מחליפות זו את זו. בדיקות סינתטיות משמשות התראה מוקדמת על אי-זמינות ורגרסיות במסלולים קריטיים, ונתוני סשנים אמיתיים — מקור אמת ורמז אילו תרחישים להוסיף לכיסוי.
כך סט בדיקות ה-smoke מקצה לקצה (E2E smoke tests) נשאר חי: נוספה אינטגרציה חדשה או השתנה מסלול — הבדיקה מתעדכנת יחד איתו, ולא אחרי האירוע.
שאלות טכניות נפוצות וספקות בנוגע לבדיקות
הבדיקות מוטמעות בסביבה הקיימת ואינן מחליפות אותה, ולכן הספקות נוגעים בדרך כלל לתאימות, הרשאות ולמחיר של התראות שווא. להלן — מה שצף לרוב בשלב הדיון על המשימה.
יש לנו לגאסי בלי בדיקות אוטומטיות — האם הבדיקות בכלל ישתרשו?
כן. בדיקות smoke עובדות מבחוץ, דרך ממשקים אמיתיים: אין צורך בגישה לקוד המקור ולמודולים הפנימיים. מתחילים ב-5–7 מסלולים קריטיים — כניסה, ביצוע הזמנה, תשלום, מסירת נתונים — ומרחיבים את הסט במקומות שבהם תנאי הסף יציבים.
איך זה משתלב עם CI/CD והאם זה לא יחסום את הדיפלוי בגלל שטויות?
הבדיקות רצות בשתי סביבות. בבנייה — סט קצר על סטנד הבדיקות, הוא עוצר את הדיפלוי כשנופל. בפרודקשן — אותו סט לפי לוח זמנים ומיד לאחר הריליס, אבל עם התראה: כשל בתשלום או בכניסה מעלה אזעקה, אי-התאמה בקידוד נשלחת כמשימה.
התראות שווא — כמה זמן יגזול הניתוח?
מטפלים בזה באמצעות הסיבות: המתנה לפי תנאי במקום השהיה קבועה, בידוד נתוני בדיקה לכל הרצה, חזרה אוטומטית אחת על בדיקה שנפלה עם הקלטת וידאו ויומן רשת. סט יציב נותן שברי אחוזים של התראות שווא; כל מה שמעל לכך אנחנו מנתחים כפגם של הבדיקה עצמה, ולא כרעש.
מה עם הרשאות הגישה לפרודקשן ואבטחה?
חשבונות שירות נפרדים עם הרשאות מינימליות, ובמקומות האפשריים — קריאה בלבד. הסודות נמצאים במאגר מאובטח של סביבת הבנייה ואינם נכנסים לדוחות. תשלומים נבדקים במצב הבדיקה של הספק, רשומות בדיקה מסומנות בסימן שירות ונמחקות לפי לוח זמנים.
נדבר על המשימה: כיצד להתכונן להתחלה
E2E smoke-тесты בפרודקשן משתלמים כשהם מורצים מהיום הראשון ומכסים בדיוק את המסלולים שבהם השחרור נשבר לרוב. לכן אנחנו מתחילים בניתוח המשימה: בודקים מה כבר קיים בפרויקט, אילו תרחישים קריטיים וכיצד נשלטת כעת איכות הריליס. בסיום חוזרים עם הערכה ותוכנית — הרכב הבדיקות, סדר העבודה ונקודות החיבור לסביבה שלכם.
מה נדרש לקראת ההתחלה:
- רשימת המסלולים הקריטיים: כניסה והרשמה, תשלום, ביצוע הזמנה, אזור אישי — מה שנבדק בכל שחרור.
- נתוני בסיס לבדיקות: חשבונות בדיקה עם התפקידים הנדרשים, נתונים על הזמנות, גישות לשירותים חיצוניים במצב בדיקה.
- גישה לסביבה שמשכפלת את הפרודקשן בהגדרות ובגרסאות הרכיבים — אחרת הבדיקה עוברת והבעיה נשארת.
- כללי ההרצה: לאחר כל בנייה, לפי לוח זמנים או ידנית לפני השחרור — בוחרים יחד.
- אחראי מצדכם, שיאשר את התרחישים ויקבל את דוח התוצאות.
- הערכה ותוכנית: שלבים, עדיפות הבדיקות, סדר הרחבת הסט בלי לשכתב את מה שכבר מוכן.
הסט הראשון סוגר את התרחישים העיקריים ונותן אות חד-משמעי: השחרור בטוח או שיש רגרסיה עם מקום כשל מדויק. השלב הבא — תארו את המשימה: מהו המוצר, אילו תרחישים קריטיים ומה כואב בריליסים. נחזור עם הערכה ותוכנית ונציע תאריך התחלה.
