E2E Testing: מה זה בדיקות E2E ואיך מבצעים בדיקות מקצה לקצה?

פורסם ע"יdinraפורסם בUncategorizedתגים: , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

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

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

אבל מה קורה כאשר משתמש אמיתי נכנס למערכת, מתחבר, מבצע פעולה, עובר למסך אחר, המערכת שולחת בקשה לשרת, הנתונים נשמרים, מתבצע חישוב ובסוף המשתמש מקבל את התוצאה שהוא ציפה לה?

כאן נכנסות לתמונה בדיקות E2E – End-to-End Testing.

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

אז מה זה E2E?

E2E הוא קיצור של End-to-End, כלומר "מקצה לקצה".

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

לדוגמה, נניח שיש אתר מסחר.

בדיקה רגילה יכולה לבדוק:

האם כפתור "הוסף לסל" עובד?

בדיקת API יכולה לבדוק:

האם שירות הוספת המוצר לסל מחזיר HTTP 200?

אבל בדיקת E2E תשאל שאלה הרבה יותר רחבה:

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

זה כבר תהליך שלם.

וזה בדיוק הכוח של בדיקות E2E.

למה בכלל צריך בדיקות E2E?

זו אחת השאלות שאני נשאל לא מעט.

אם כבר יש לנו Unit Tests, בדיקות API, בדיקות אינטגרציה ובדיקות UI – למה צריך גם E2E?

התשובה שלי היא פשוטה:

כי משתמש לא משתמש ב-Unit Test.

הוא משתמש במערכת.

מערכת מודרנית יכולה להיות מורכבת מעשרות שירותים, APIs, מסדי נתונים, מערכות צד שלישי, ממשקי משתמש ותהליכים עסקיים.

כל רכיב בפני עצמו יכול לעבוד מצוין.

ועדיין – החיבור ביניהם יכול להיכשל.

לדוגמה:

  1. המשתמש מתחבר.
  2. השרת מאמת את המשתמש.
  3. המערכת שולפת את הנתונים.
  4. API נוסף מחזיר מידע.
  5. המערכת מבצעת חישוב.
  6. הנתונים נשמרים.
  7. המשתמש מקבל הודעת הצלחה.

אם אחד החיבורים בדרך לא עובד, המשתמש חווה תקלה.

בדיקת E2E מנסה לראות את התמונה השלמה.

דוגמה אמיתית לתרחיש E2E

ניקח מערכת בנקאית.

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

במקום לבדוק רק את מסך ההעברה, תרחיש E2E יכול להיות:

שלב 1: כניסה למערכת.

שלב 2: אימות המשתמש.

שלב 3: מעבר לחשבון הבנק.

שלב 4: בחירת "העברה".

שלב 5: הזנת חשבון יעד.

שלב 6: הזנת סכום.

שלב 7: אישור הפעולה.

שלב 8: קבלת אימות.

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

שלב 10: בדיקה שהיתרה עודכנה בהתאם.

שים לב כמה מערכות יכולות להיות מעורבות בתהליך אחד כזה.

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

E2E לעומת בדיקות Unit, API ואינטגרציה

כדי להבין את ההבדל, אפשר לחשוב על מערכת כמו מכונית.

Unit Testing

בודק חלק קטן מאוד.

לדוגמה:

האם פונקציית חישוב המחיר מחזירה את התוצאה הנכונה?

API Testing

בודק את התקשורת בין המערכת לשירות.

לדוגמה:

האם API ליצירת הזמנה מחזיר את ההזמנה שנוצרה?

Integration Testing

בודק האם רכיבים שונים עובדים נכון ביחד.

לדוגמה:

האם מערכת ההזמנות מצליחה להעביר נתונים למערכת התשלומים?

E2E Testing

בודק את התהליך כולו:

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

אין כאן "בדיקה טובה יותר".

אלה שכבות שונות של בדיקות.

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

לא.

אוטומציה היא כלי.

השאלה החשובה היא מה אנחנו בודקים, באיזה שלב ולמה.

מה ההבדל בין E2E ידני ל-E2E אוטומטי?

בדיקות E2E יכולות להתבצע ידנית או באמצעות אוטומציה.

בדיקת E2E ידנית

בודק תוכנה מבצע את התהליך בעצמו.

לדוגמה:

כניסה → חיפוש → הוספה לסל → תשלום → קבלת אישור.

היתרון הוא גמישות.

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

בדיקת E2E אוטומטית

כלי אוטומציה מבצע את התהליך במקום הבודק.

למשל:

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

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

איזה כלים משמשים לבדיקות E2E?

יש לא מעט כלים בעולם האוטומציה.

בין השמות שתפגשו:

  • Playwright
  • Selenium
  • Cypress
  • WebdriverIO
  • Robot Framework

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

לפי התיעוד הרשמי, Playwright Test הוא framework לבדיקות End-to-End של אפליקציות Web מודרניות, והוא כולל Test Runner, assertions, isolation, parallelization וכלי עבודה נוספים. הוא תומך ב-Chromium, Firefox ו-WebKit.

למה Playwright מתאים במיוחד ל-E2E?

אחת הסיבות שאני אוהב את הגישה של Playwright היא שהיא מנסה להתקרב להתנהגות של משתמש אמיתי.

לדוגמה, במקום להסתמך בכל מקום על CSS Selector ארוך ושביר, אפשר לעבוד עם locators שמייצגים את האופן שבו המשתמש רואה את המערכת.

Playwright ממליץ להעדיף attributes שפונים להתנהגות ולממשק שהמשתמש רואה, כגון Role או Label, ולא להסתמך יתר על המידה על מבנה ה-DOM או CSS שעלולים להשתנות.

לדוגמה:

await page.getByRole('button', { name: 'Login' }).click();

הרעיון פשוט:

אל תבדוק איך המערכת בנויה מבפנים אם אתה יכול לבדוק מה המשתמש באמת עושה.

דוגמה פשוטה לבדיקת E2E עם Playwright

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

import { test, expect } from '@playwright/test';
test('בדיקת פתיחת האתר', async ({ page }) => {
    await page.goto('https://example.com');
    await expect(page).toHaveTitle(/Example/);
});

זו כמובן דוגמה פשוטה מאוד.

במערכת אמיתית אפשר להמשיך משם לתרחיש שלם:

Login
↓
חיפוש
↓
בחירת מוצר
↓
הוספה לסל
↓
Checkout
↓
תשלום
↓
אישור

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

הטעות הגדולה ביותר בבדיקות E2E

לדעתי זו אחת הנקודות החשובות ביותר.

לא צריך להפוך כל בדיקה ל-E2E.

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

אני מעדיף לחשוב על E2E כמו על בדיקת "בריאות" של המערכת.

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

לדוגמה באתר מסחר:

  • התחברות
  • חיפוש מוצר
  • רכישה
  • ביטול הזמנה

ולא בהכרח צריך לבדוק באמצעות E2E כל וריאציה אפשרית של כל שדה.

את שאר הבדיקות אפשר לבצע ברמות אחרות.

איך בוחרים אילו תרחישים להפוך ל-E2E?

אני ממליץ לשאול חמש שאלות:

1. האם מדובר בתהליך עסקי קריטי?

אם התשובה כן – הוא מועמד טוב.

2. האם התהליך חוזר על עצמו?

אם בודקים אותו שוב ושוב – אוטומציה יכולה להשתלם.

3. האם כשל בתהליך יפגע במשתמש?

ככל שההשפעה גדולה יותר, כך החשיבות עולה.

4. האם התהליך מספיק יציב?

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

5. האם אפשר לבודד את הנתונים?

זה קריטי.

בדיקה שתלויה בנתונים שמשתנים כל הזמן תהיה קשה לתחזוקה.

ומה לגבי בדיקות E2E בסביבת CI/CD?

כאן E2E מתחיל להיות באמת מעניין.

במקום לחכות שבודק יפעיל את הבדיקות ידנית, אפשר לשלב אותן בתהליך ה-CI/CD.

לדוגמה:

Developer
   ↓
Git Commit
   ↓
Build
   ↓
Unit Tests
   ↓
API / Integration Tests
   ↓
E2E Tests
   ↓
Deploy

Playwright מספק תמיכה בהרצת בדיקות בסביבות CI, כולל תצורות לדוגמה עבור ספקי CI שונים.

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

ומה עושים כשבדיקת E2E נכשלת?

זו נקודה שחשוב מאוד לחשוב עליה מראש.

בדיקה שנכשלה לא תמיד אומרת שהמוצר שבור.

היא יכולה להיכשל בגלל:

  • שינוי UI
  • נתוני בדיקה לא נכונים
  • בעיית סביבה
  • שירות חיצוני שלא זמין
  • Timeout
  • בעיית הרשאות
  • בעיית תשתית
  • שינוי ב-API
  • או באמת באג

לכן יכולת הדיבוג חשובה כמעט כמו עצם הבדיקה.

ב-Playwright, למשל, קיימים Trace Viewer וכלי UI Mode שמאפשרים לחקור את רצף הפעולות, DOM snapshots, network requests ועוד.

בדיקות E2E ו-Flaky Tests

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

פעם היא עוברת.

פעם היא נכשלת.

מריצים שוב – והיא עוברת.

זה מצב מסוכן.

כי בשלב מסוים הצוות מתחיל להתעלם מהבדיקות.

"זה כנראה סתם ה-E2E."

וזה הרגע שבו האוטומציה מאבדת את הערך שלה.

לכן כדאי לבנות בדיקות מבודדות, עם נתונים נשלטים ועם כמה שפחות תלות בבדיקות אחרות. Playwright, למשל, מדגיש Test Isolation כאחד מעקרונות העבודה החשובים שלו.

האם E2E יכול להחליף בודק תוכנה?

ממש לא.

וזו בעיניי נקודה חשובה במיוחד למי שנכנס לעולם ה-QA וחושב שאוטומציה תחליף את הבודקים.

E2E אוטומטי יודע לבצע תרחיש שהגדרנו.

אבל מי מחליט איזה תרחיש בכלל צריך לבדוק?

מי מזהה סיכון עסקי?

מי מבין שמשהו בהתנהגות של המערכת פשוט "לא מרגיש נכון"?

מי מחליט שצריך לבדוק דווקא תרחיש קצה?

מי מחבר בין דרישה עסקית, מערכת, API, נתונים ומשתמש?

כאן עדיין נדרשת חשיבה של בודק.

לכן מבחינתי, בודק טוב בעידן האוטומציה הוא לא מי שיודע רק לבצע Test Case.

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

E2E הוא לא המטרה – הוא אמצעי

אם יש משהו שהייתי רוצה שתיקחו מהמאמר הזה, זה את המשפט הבא:

לא כותבים E2E כדי שיהיו לנו הרבה בדיקות. כותבים E2E כדי להגן על תהליכים עסקיים חשובים.

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

במקום לשאול:

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

אני מעדיף לשאול:

"על אילו תהליכים עסקיים קריטיים אנחנו יודעים לתת ביטחון?"

זו כבר שאלה הרבה יותר מעניינת.

סיכום

אז מה זה E2E?

E2E Testing – End-to-End Testing – הוא סוג של בדיקות שבוחן תהליך שלם במערכת, מתחילתו ועד סופו, מנקודת המבט של התהליך העסקי או המשתמש.

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

כלים כמו Playwright מאפשרים לבנות תרחישי E2E אוטומטיים, להריץ אותם על מספר דפדפנים, לשלב אותם ב-CI/CD ולחקור כשלים באמצעות כלי דיבוג מתקדמים.

אבל מבחינתי, הדבר החשוב ביותר הוא לא הכלי.

הכלי הוא רק הדרך.

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

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

קורס לבדיקות תוכנה מדויק

לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאןרבה יותר מעניינת

כתיבת תגובה