1. מהי בדיקת E2E ולמה היא חשובה?

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

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

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

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

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

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

2. מהו Playwright וכיצד הוא עובד?

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

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

איך נראית בדיקה טיפוסית?

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

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

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

אם אתם חדשים בכלי, כדאי להתחיל גם עם מדריך Playwright למתחילים או לקרוא את המאמר Playwright – מה זה ואיך משתמשים בו לבדיקות?.

3. התקנת Playwright והקמת פרויקט

כדי לכתוב בדיקת E2E עם Playwright, נדרשים סביבת Node.js, מנהל חבילות כמו npm ועורך קוד. אפשר להשתמש ב-Visual Studio Code או בעורך אחר שנוח לכם.

שלב ראשון: בדיקת Node.js ו-npm

פתחו את הטרמינל והריצו:

node -v
npm -v

אם שתי הפקודות מחזירות מספרי גרסה, אפשר להמשיך. אם הפקודה אינה מזוהה, התקינו את גרסת Node.js המתאימה לפרויקט מהאתר הרשמי.

שלב שני: יצירת פרויקט Playwright

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

npm init playwright@latest

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

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

שלב שלישי: התקנת הדפדפנים

אם אשף ההתקנה לא התקין את הדפדפנים, או אם נדרשת התקנה מחדש, הריצו:

npx playwright install

במערכות Linux מסוימות, במיוחד בסביבת CI, ייתכן שיהיה צורך גם בהתקנת תלויות מערכת:

npx playwright install --with-deps

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

שלב רביעי: הכרת מבנה הפרויקט

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

my-playwright-project/
├── tests/
│   └── example.spec.js
├── playwright.config.js
├── package.json
└── node_modules/

• tests/ – תיקייה לקובצי הבדיקות.
• example.spec.js – קובץ בדיקה לדוגמה שנוצר באשף.
• playwright.config.js – הגדרות הדפדפנים, זמני ההמתנה, כתובת הבסיס ועוד.
• package.json – הגדרות הפרויקט והפקודות להרצת הבדיקות.

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

4. כתיבת בדיקת E2E ראשונה עם Playwright

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

צרו קובץ בשם home.spec.js בתיקיית tests והכניסו לתוכו את הקוד הבא. החליפו את כתובת האתר ואת הכותרת הצפויה בערכים המתאימים לאתר שבאמת נבדק.

const { test, expect } = require('@playwright/test');

test('homepage loads successfully', async ({ page }) => {
  await page.goto('https://example.com');

  await expect(page).toHaveTitle(/Example Domain/);

  await expect(
    page.getByRole('heading', {
      name: 'Example Domain'
    })
  ).toBeVisible();
});

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

מה עושה כל חלק בקוד?

• require('@playwright/test') – מייבא את כלי הבדיקה ואת פונקציות האימות.
• test(...) – מגדיר מקרה בדיקה חדש עם שם ברור.
• async ({ page }) – מקבל את אובייקט הדף שבו תתבצע הבדיקה.
• page.goto(...) – מנווט לכתובת המבוקשת.
• expect(...).toHaveTitle(...) – מוודא שכותרת הדף תואמת לציפייה.
• getByRole(...) – מאתר כותרת לפי התפקיד הנגיש שלה והשם שלה.
• toBeVisible() – מאמת שהכותרת מוצגת למשתמש.

שימו לב לשימוש ב-await. פעולות רבות ב-Playwright הן אסינכרוניות, ולכן יש להמתין להשלמתן לפני שממשיכים לשלב הבא.

כיצד מריצים את הבדיקה?

כדי להריץ את כל הבדיקות בפרויקט:

npx playwright test

כדי להריץ קובץ מסוים בלבד:

npx playwright test tests/home.spec.js

כדי לראות את הדפדפן בזמן הריצה, השתמשו במצב headed:

npx playwright test tests/home.spec.js --headed

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

5. דוגמה מלאה: כתיבת בדיקת E2E לתהליך התחברות

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

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

הגדרת תרחיש הבדיקה

קוד בדיקת ההתחברות

הקוד הבא הוא תבנית לדוגמה. יש להתאים את כתובת האתר, שמות השדות והכותרת למבנה האמיתי של היישום שלכם.

const { test, expect } = require('@playwright/test');

test('user can log in successfully', async ({ page }) => {
  await page.goto('https://your-app.example/login');

  await page.getByLabel('Email').fill(
    process.env.E2E_EMAIL
  );

  await page.getByLabel('Password').fill(
    process.env.E2E_PASSWORD
  );

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

  await expect(page).toHaveURL(
    /dashboard/
  );

  await expect(
    page.getByRole('heading', {
      name: 'Dashboard'
    })
  ).toBeVisible();
});

חשוב: זו תבנית לימודית ולא בדיקה שאפשר להריץ ללא התאמות. הדוגמה מניחה שהאתר משתמש בתוויות Email ו-Password, בכפתור Log in ובכותרת Dashboard. אם השמות שונים, יש להתאים את מאתרי האלמנטים. כמו כן, יש להגדיר את משתני הסביבה E2E_EMAIL ו-E2E_PASSWORD לפני הריצה.

מדוע בחרנו ב-getByLabel?

השימוש ב-getByLabel() מאפשר לאתר שדה קלט לפי התווית המקושרת אליו. זו בדרך כלל בחירה טובה יותר ממיקום האלמנט לפי המבנה הפנימי של ה-HTML, משום שהיא קרובה לאופן שבו משתמשים מבינים את הטופס.

אם שדות הקלט אינם מקושרים לתוויות נגישות, מומלץ לשפר את הממשק. במקרים מסוימים אפשר להשתמש ב-getByPlaceholder(), ב-getByRole() או במאפיין בדיקה ייעודי כמו data-testid.

איך מגדירים פרטי התחברות בצורה בטוחה?

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

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

const { test, expect } = require('@playwright/test');

test('user can log in successfully', async ({ page }) => {
  const email = process.env.E2E_EMAIL;
  const password = process.env.E2E_PASSWORD;

  if (!email || !password) {
    throw new Error(
      'E2E_EMAIL and E2E_PASSWORD must be configured'
    );
  }

  await page.goto('https://your-app.example/login');

  await page.getByLabel('Email').fill(email);
  await page.getByLabel('Password').fill(password);

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

  await expect(page).toHaveURL(/dashboard/);
});

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

בדיקת התחברות שנכשלה

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

const { test, expect } = require('@playwright/test');

test('invalid credentials show an error', async ({ page }) => {
  await page.goto('https://your-app.example/login');

  await page.getByLabel('Email').fill(
    'invalid-user@example.com'
  );

  await page.getByLabel('Password').fill(
    'incorrect-password'
  );

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

  await expect(
    page.getByRole('alert')
  ).toBeVisible();
});

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

6. בדיקת טופס ושליחת נתונים

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

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

const { test, expect } = require('@playwright/test');

test('contact form can be submitted', async ({ page }) => {
  await page.goto('https://your-app.example/contact');

  await page.getByLabel('Name').fill('QA Test User');

  await page.getByLabel('Email').fill(
    'qa-test@example.com'
  );

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

  await expect(
    page.getByRole('status')
  ).toContainText('Thank you');
});

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

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

7. איך בוחרים אלמנטים בצורה נכונה ב-Playwright?

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

שיטות נפוצות לאיתור אלמנטים

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

למה לא להשתמש תמיד ב-CSS Selector?

אפשר לאתר אלמנטים גם באמצעות CSS:

await page.locator('#submit-button').click();

await page.locator('.login-form input[type="email"]').fill(
  'qa-test@example.com'
);

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

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

8. Assertions – כיצד מאמתים את תוצאות הבדיקה?

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

ב-Playwright נהוג להשתמש ב-expect ובמאמתים כמו:

await expect(page).toHaveURL(/dashboard/);

await expect(page).toHaveTitle(/Dashboard/);

await expect(
  page.getByRole('button', { name: 'Save' })
).toBeVisible();

await expect(
  page.getByRole('button', { name: 'Save' })
).toBeEnabled();

await expect(
  page.getByText('Changes saved')
).toBeVisible();

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

מהו Auto-Waiting ולמה הוא חשוב?

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

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

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

9. המתנות, יציבות ופתרון תקלות

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

הימנעו מהשהיות קבועות

קוד כזה אינו מומלץ כפתרון ברירת מחדל:

await page.waitForTimeout(5000);

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

עדיף להמתין לתנאי מוגדר:

await expect(
  page.getByRole('status')
).toContainText('Saved');

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

המתנה לתגובת API

כאשר צריך לאמת פעולה שמבצעת בקשת רשת, ניתן להמתין לתגובה המתאימה במקביל לפעולת המשתמש:

const { test, expect } = require('@playwright/test');

test('saving a record returns success', async ({ page }) => {
  await page.goto('https://your-app.example/records/new');

  await page.getByLabel('Name').fill('QA Record');

  const responsePromise = page.waitForResponse(response =>
    response.url().includes('/api/records') &&
    response.request().method() === 'POST'
  );

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

  const response = await responsePromise;

  expect(response.ok()).toBeTruthy();

  await expect(
    page.getByRole('status')
  ).toContainText('Saved');
});

גם כאן נדרשת התאמה למערכת הנבדקת. הכתובת /api/records והודעת Saved הן דוגמאות בלבד. אם המערכת מבצעת כמה בקשות לאותו נתיב, כדאי להוסיף תנאים מזהים נוספים כדי להמתין לתגובה הנכונה. יש להימנע מהמתנה לתגובה שלא יכולה להתרחש, למשל אם שמירת הנתונים מתבצעת ללא בקשת POST.

מה עושים כשהבדיקה נכשלת לסירוגין?

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

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

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

10. שילוב בדיקות API בתהליך E2E

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

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

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

למידע נוסף, קראו את המדריך בדיקות API עם Playwright – מדריך מעשי.

11. הרצת בדיקות, דוחות ודיבוג

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

פקודות שימושיות

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

הגדרת דוח HTML ו-Trace

אפשר להגדיר ב-playwright.config.js יצירת דוח HTML ושמירת Trace בעת כישלון. לדוגמה, בקובץ CommonJS:

// playwright.config.js
const { defineConfig } = require('@playwright/test');

module.exports = defineConfig({
  testDir: './tests',

  reporter: [
    ['list'],
    ['html', { open: 'never' }]
  ],

  use: {
    trace: 'retain-on-failure'
  }
});

ההגדרה retain-on-failure שומרת עקבות ריצה עבור בדיקות שנכשלו, בהתאם להתנהגות של מנגנון ה-retries והגדרות הפרויקט. יש להתאים את מדיניות השמירה לצורכי הדיבוג, לאבטחת המידע ולנפח התוצרים.

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

12. טעויות נפוצות ושיטות עבודה מומלצות

טעות ראשונה: בדיקה שמוודאת רק שהדף נפתח

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

טעות שנייה: שימוש בהמתנות קבועות בכל שלב

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

טעות שלישית: תלות בסדר ההרצה

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

טעות רביעית: בדיקות שמבצעות פעולות אמיתיות בסביבת ייצור

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

טעות חמישית: בדיקה אחת גדולה מדי

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

טעות שישית: שימוש ב-retries במקום תיקון הבעיה

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

טעות שביעית: בחירת יותר מדי תרחישי E2E

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

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

13. צ'קליסט לבדיקת E2E איכותית

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

14. איך משלבים בדיקות E2E בתהליך העבודה של צוות QA?

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

1. בחירת תהליכים קריטיים: התחילו מהתחברות, הרשמה, תשלום או תהליך עסקי מרכזי אחר.
2. הרצה מקומית: ודאו שהבדיקות יציבות ושאפשר להבין כישלון בלי לנחש מה קרה.
3. הרצה אוטומטית: שלבו את הבדיקות בתהליך CI, למשל לאחר שינויי קוד או לפני פריסה.
4. ניתוח תוצאות: הפרידו בין תקלה במוצר, בעיית סביבה, בעיית נתונים ובדיקה לא יציבה.
5. תחזוקה שוטפת: עדכנו מאתרים ותרחישים כאשר דרישות המוצר משתנות, תוך שמירה על המטרה העסקית.

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

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

15. שאלות נפוצות על כתיבת בדיקות E2E עם Playwright