בדיקות E2E – איך בונים תרחיש בדיקה מקצה לקצה?

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

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

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

מהן בדיקות E2E ולמה הן חשובות?

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

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

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

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

מה בדיקות E2E בודקות בפועל?

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

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

ההבדל בין בדיקות E2E לסוגי בדיקות אחרים

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

הסוגים אינם מתחרים זה בזה. מערכת איכותית זקוקה לשילוב ביניהם.

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

מומלץ לקרוא גם את המדריך בנושא בדיקות API עם Playwright – מדריך מעשי לאוטומציה, שמסביר כיצד לבדוק שירותים וממשקים באמצעות כלי אוטומציה.

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

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

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

1. בחירת תהליך עסקי מרכזי

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

דוגמאות לתהליכים מתאימים:

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

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

2. הגדרת המטרה העסקית

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

לדוגמה, במקום להגדיר מטרה כללית כמו "בדיקת מסך ההזמנה", עדיף לנסח:

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

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

3. זיהוי המערכות המעורבות

יש למפות את הרכיבים שבהם התהליך משתמש.

בתהליך רכישה, למשל, עשויים להשתתף:

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

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

4. הגדרת גבולות הבדיקה

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

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

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

איך כותבים תרחיש בדיקת E2E מקצועי?

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

מומלץ לכלול את המרכיבים הבאים:

דוגמה לתרחיש בדיקה: ביצוע הזמנה באתר מסחר

מזהה: E2E-ORDER-001

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

תנאים מקדימים:

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

צעדי הבדיקה:

קריטריוני הצלחה:

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

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

דוגמה מעשית: בניית בדיקת E2E באמצעות Playwright

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

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

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

import { test, expect } from '@playwright/test';
test('משתמש מתחבר ומשלים תהליך הזמנה', async ({ page }) => {
  // פתיחת האתר
  await page.goto('https://example.com');
  // מעבר למסך ההתחברות
  await page.getByRole('link', {
    name: 'התחברות'
  }).click();
  // הזנת פרטי משתמש
  await page.getByLabel('כתובת דוא"ל').fill(
    'qa-user@example.com'
  );
  await page.getByLabel('סיסמה').fill(
    process.env.TEST_USER_PASSWORD
  );
  // התחברות
  await page.getByRole('button', {
    name: 'כניסה'
  }).click();
  // אימות שהמשתמש התחבר
  await expect(
    page.getByText('החשבון שלי')
  ).toBeVisible();
  // פתיחת מוצר
  await page.getByRole('link', {
    name: 'מוצר לבדיקה'
  }).click();
  // הוספה לעגלה
  await page.getByRole('button', {
    name: 'הוסף לעגלה'
  }).click();
  // בדיקה שהמוצר נוסף
  await expect(
    page.getByText('המוצר נוסף לעגלה')
  ).toBeVisible();
  // מעבר לעגלה
  await page.getByRole('link', {
    name: 'לעגלת הקניות'
  }).click();
  // בדיקה שהמוצר מופיע בעגלה
  await expect(
    page.getByText('מוצר לבדיקה')
  ).toBeVisible();
});

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

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

למה להשתמש ב-getByRole וב-getByLabel?

Playwright מאפשר לאתר רכיבים לפי התפקיד הנגיש שלהם, לפי תוויות ולפי טקסט. במקרים רבים, איתור באמצעות getByRole או getByLabel עדיף על שימוש במיקומי CSS ארוכים או בנתיבי XPath שתלויים במבנה ה-HTML.

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

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

איך מגדירים תוצאות צפויות בצורה נכונה?

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

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

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

ברמת הממשק

• האם הודעת האישור מוצגת?
• האם מספר ההזמנה מופיע?
• האם סכום התשלום נכון?

ברמת השירותים

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

ברמת הנתונים

• האם ההזמנה נשמרה?
• האם פרטי המוצר והכמות נכונים?
• האם הסכום שנשמר תואם לסכום שאושר?

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

בדיקות חיוביות ושליליות בתרחישי E2E

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

תרחיש חיובי

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

התוצאה הצפויה היא השלמת התהליך ללא שגיאה, תוך שמירה נכונה של הנתונים.

תרחיש שלילי: תשלום שנכשל

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

יש לבדוק כי:

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

תרחיש שלילי: מוצר שאזל מהמלאי

משתמש מוסיף מוצר לעגלה, אך המלאי משתנה לפני השלמת הרכישה.

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

תרחיש שלילי: פג תוקף ההתחברות

משתמש משאיר את מסך הקופה פתוח למשך זמן ממושך, וההתחברות שלו פגה.

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

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

טעויות נפוצות בבניית בדיקות E2E

1. תרחיש ארוך מדי

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

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

2. תלות בבדיקות קודמות

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

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

3. שימוש בנתוני בדיקה לא יציבים

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

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

4. המתנה קבועה במקום המתנה לתנאי

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

ב-Playwright עדיף להמתין לתנאי ממשי, למשל:

await expect(
  page.getByText('ההזמנה הושלמה')
).toBeVisible();

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

5. בדיקה של הודעת הצלחה בלבד

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

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

6. התעלמות מתחזוקה

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

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

לקריאה נוספת: מתי לא כדאי לבצע אוטומציה לבדיקות תוכנה?.

איך מצמצמים בדיקות E2E לא יציבות?

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

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

כדי לצמצם את התופעה:

1. השתמשו בנתוני בדיקה ייעודיים וניתנים לשחזור.
2. הימנעו מתלות בסדר הרצת הבדיקות.
3. המתינו לתנאים ולא למשכי זמן שרירותיים.
4. השתמשו באיתורים יציבים של רכיבי הממשק.
5. הפרידו בין כשלים במוצר לבין בעיות בתשתית הבדיקות.
6. תעדו צילומי מסך, עקבות ריצה ולוגים כאשר בדיקה נכשלת.
7. הריצו את הבדיקות בסביבה מבוקרת ככל האפשר.
8. השתמשו ב-retry לצורכי אבחון, ולא כתחליף לתיקון מקור חוסר היציבות.

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

שילוב בדיקות E2E בתהליך CI/CD

בארגונים רבים מריצים בדיקות E2E כחלק מתהליך האינטגרציה והאספקה הרציפה (CI/CD). כך ניתן לזהות בעיות משמעותיות לפני שהגרסה מגיעה לסביבת הייצור.

תהליך אפשרי כולל:

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

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

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

איך מודדים את האיכות של מערך בדיקות E2E?

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

מדדים שימושיים כוללים:

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

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

צ'קליסט לבניית תרחיש E2E

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

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

סיכום: כך בונים בדיקת E2E שמספקת ערך אמיתי

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

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

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

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

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

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