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

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

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

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

מה זה בכלל Playwright?

Playwright הוא Framework לבדיקות אוטומטיות של יישומי Web.

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

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

Playwright: מה זה ואיך משתמשים בו לבדיקות אוטומטיות?.

1. Playwright הוא לא רק כלי ללחיצה על כפתורים

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

למשל:

1. פתח אתר.
2. לחץ על Login.
3. הכנס Username.
4. הכנס Password.
5. לחץ על Login.
6. בדוק שהמשתמש נכנס.

זו בהחלט פעולה שאפשר לבצע עם Playwright, אבל היכולת של הכלי רחבה הרבה יותר.

Playwright יכול לשמש לבדיקות:

• UI
• E2E
• Regression
• Smoke
• Functional Testing
• Cross-browser
• Authentication
• API
• אינטגרציה בין רכיבי מערכת
• תרחישים מורכבים הכוללים מספר עמודים

לכן חשוב לחשוב על Playwright כעל Framework לבדיקות, ולא רק כעל כלי שמבצע פעולות בדפדפן.

2. כדאי להבין מהי בדיקת E2E

לפני שכותבים בדיקה ראשונה, חשוב להבין מהי בכלל בדיקת End-to-End.

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

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

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

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

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

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

3. לא חייבים להיות מפתחים מומחים

כדי להתחיל ללמוד Playwright צריך להבין קוד, אבל לא צריך להיות מפתח Full Stack.

כדאי להכיר לפחות:

• משתנים
• פונקציות
• תנאים
• לולאות
• אובייקטים
• Arrays
• async/await
• עבודה עם קבצים
• מבנה בסיסי של JavaScript או TypeScript

למתחילים רבים, TypeScript או JavaScript יהיו נקודת התחלה טבעית.

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

עדיף ללמוד JavaScript/TypeScript במקביל לבניית בדיקות אמיתיות.

4. async/await הוא מושג שחייבים להבין

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

דוגמה:

await page.goto('https://example.com');
await page.getByRole('button', { name: 'Login' }).click();

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

ב־Playwright תיתקלו ב־await שוב ושוב.

לכן אם אתם מתחילים ללמוד Playwright ולא מבינים מדוע משתמשים ב־async ו־await, כדאי לעצור לרגע וללמוד את הבסיס.

5. Locator הוא אחד המושגים החשובים ביותר

Locator הוא הדרך שבה Playwright מזהה אלמנט בעמוד.

לדוגמה:

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

או:

page.getByLabel('Email')

או:

page.getByText('Welcome')

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

Locator טוב יהיה בדרך כלל:

• ברור
• יציב
• קריא
• קשור למשמעות של האלמנט
• פחות תלוי במבנה HTML שמשתנה

לכן לא כדאי להתחיל כל בדיקה עם XPath ארוך.

6. עדיף לזהות אלמנטים לפי משמעות

נניח שיש כפתור:

<button>Login</button>

במקום לחפש אותו באמצעות XPath מורכב, אפשר להשתמש ב־Locator שמתאר את תפקידו:

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

היתרון הוא לא רק טכני.

הקוד גם הופך להיות הרבה יותר ברור.

מי שקורא את הבדיקה מבין מיד:

חפש כפתור Login ולחץ עליו.

לעומת XPath ארוך שדורש להבין את מבנה ה־DOM.

7. אל תשתמשו ב־sleep כפתרון לכל בעיה

אחת הטעויות הנפוצות באוטומציה היא להוסיף המתנה קבועה:

await page.waitForTimeout(5000);

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

זו בדרך כלל אינה הדרך הנכונה להתמודד עם סנכרון.

למה?

כי לפעמים המערכת מוכנה אחרי שנייה.

לפעמים אחרי שלוש שניות.

ולפעמים אחרי יותר.

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

לדוגמה:

await expect(page.getByText('Welcome')).toBeVisible();

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

8. Playwright כולל מנגנוני Auto-Waiting

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

לכן במקום לכתוב:

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

אפשר בדרך כלל לבצע:

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

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

זו אחת הסיבות לכך שבדיקות Playwright יכולות להיות יציבות יותר כאשר כותבים אותן בצורה נכונה.

9. Assertion חשוב לא פחות מהפעולה

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

לדוגמה:

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

כאן ביצענו פעולה.

אבל מה קרה אחריה?

צריך לבדוק:

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

או:

await expect(page.getByText('Welcome')).toBeVisible();

כל בדיקה צריכה לחשוב על שלושה דברים:

Arrange → Act → Assert

כלומר:

1. הכנת המערכת.
2. ביצוע הפעולה.
3. בדיקת התוצאה.

10. Test Runner הוא חלק מרכזי מהעבודה

Playwright מגיע עם סביבת Test Runner שמאפשרת לנהל ולהריץ בדיקות.

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

import { test, expect } from '@playwright/test';
test('login test', async ({ page }) => {
  await page.goto('https://example.com');
  await page.getByLabel('Email').fill('user@example.com');
  await page.getByLabel('Password').fill('password');
  await page.getByRole('button', { name: 'Login' }).click();
  await expect(page).toHaveURL(/dashboard/);
});

ככל שהפרויקט גדל, ה־Test Runner הופך משמעותי יותר ויותר.

הוא מאפשר לארגן בדיקות, להריץ קבוצות בדיקות, לעבוד עם Fixtures, להגדיר Hooks ולשלב את הבדיקות בתהליכי CI/CD.

11. כדאי ללמוד Fixtures מוקדם

Fixture מאפשר להכין סביבת בדיקה בצורה מסודרת ולשתף אותה בין בדיקות.

לדוגמה, Playwright מספק Fixture בשם page.

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

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

בפרויקטים גדולים אפשר ליצור Fixtures מותאמים אישית.

זה עוזר להפוך קוד אוטומציה למודולרי וקל לתחזוקה.

12. Page Object Model יכול לעזור בפרויקטים גדולים

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

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

לדוגמה:

await page.getByLabel('Email').fill(email);
await page.getByLabel('Password').fill(password);
await page.getByRole('button', { name: 'Login' }).click();

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

לדוגמה:

class LoginPage {
  constructor(page) {
    this.page = page;
    this.email = page.getByLabel('Email');
    this.password = page.getByLabel('Password');
    this.loginButton = page.getByRole('button', { name: 'Login' });
  }
  async login(email, password) {
    await this.email.fill(email);
    await this.password.fill(password);
    await this.loginButton.click();
  }
}

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

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

13. אל תכתבו בדיקות תלויות זו בזו

טעות נפוצה היא:

Test 1 → Test 2 → Test 3

כאשר Test 2 יכול לעבור רק אם Test 1 עבר.

זה יוצר בעיה חמורה.

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

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

14. Authentication הוא נושא שכדאי ללמוד מוקדם

במערכות אמיתיות כמעט תמיד יש Login.

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

• איטיות יותר
• מסורבלות יותר
• תלויות יותר במערכת ההתחברות

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

הרעיון הוא:

Login פעם אחת → שמירת מצב → שימוש במצב בבדיקות

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

15. אל תתעלמו מנתוני בדיקה

אוטומציה טובה אינה רק קוד.

צריך גם לחשוב על Test Data.

לדוגמה:

• משתמשים
• סיסמאות
• מוצרים
• הזמנות
• הרשאות
• תאריכים
• נתוני API

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

לכן כבר מההתחלה כדאי לחשוב:

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

16. כדאי להכיר את האפשרות לבצע בדיקות API

Playwright מזוהה בעיקר עם בדיקות UI, אבל אפשר להשתמש בו גם לבדיקות API.

זה מאפשר לשלב בין:

API + UI

לדוגמה:

1. יצירת משתמש באמצעות API.
2. פתיחת האתר.
3. התחברות עם המשתמש.
4. ביצוע פעולה ב־UI.
5. בדיקה באמצעות API שהנתונים נשמרו.

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

אם אתם רוצים להרחיב את הידע שלכם בנושא API Testing, באתר כבר קיים:

המדריך המקיף לבדיקות API: כל מה שבודק תוכנה צריך לדעת.

17. Debugging הוא חלק מהמקצוע

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

יכול להיות ש:

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

לכן צריך ללמוד Debugging.

ב־Playwright כדאי להכיר כלים כמו:

• Trace Viewer
• Screenshots
• Video
• Logs
• Inspector
• HTML Reports

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

18. בדיקות צריכות להיות יציבות ולא רק "לעבור"

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

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

• היום
• מחר
• על מחשב אחר
• בדפדפן אחר
• ב־CI
• כאשר המערכת מעט איטית יותר

בדיקה שנכשלת באופן אקראי נקראת לעיתים Flaky Test.

Flaky Tests הם אחת הבעיות הגדולות בפרויקטי אוטומציה.

לכן אל תשאלו רק:

האם הבדיקה עברה?

שאלו:

האם אני סומך עליה?

19. Playwright ו־Selenium אינם אותו דבר

אם אתם מגיעים מעולם Selenium, חשוב להבין ש־Playwright מציע גישה שונה במובנים רבים.

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

אם אתם מתלבטים במה ללמוד, מומלץ לקרוא גם:

Playwright מול Selenium: מה עדיף לבדיקות אוטומציה ב־2026?.

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

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

20. אל תתחילו ממאות בדיקות – התחילו נכון

זו אולי העצה החשובה ביותר למתחילים.

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

עדיף להתחיל מתרחיש אחד משמעותי.

לדוגמה:

בדיקת Login

test('successful login', async ({ page }) => {
  await page.goto('https://example.com/login');
  await page.getByLabel('Email').fill('user@example.com');
  await page.getByLabel('Password').fill('password');
  await page.getByRole('button', { name: 'Login' }).click();
  await expect(page).toHaveURL(/dashboard/);
});

לאחר מכן אפשר להוסיף:

• Login כושל
• סיסמה שגויה
• משתמש לא קיים
• Logout
• הרשאות
• Session timeout
• Forgot Password

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

20 הדברים החשובים בקיצור

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

1. Playwright הוא Framework לבדיקות Web.
2. חשוב להבין מהי בדיקת E2E.
3. כדאי להכיר JavaScript או TypeScript.
4. חייבים להבין async/await.
5. Locator הוא בסיס מרכזי באוטומציה.
6. עדיף Locators יציבים וברורים.
7. לא כדאי להשתמש ב־sleep כפתרון קבוע.
8. כדאי לנצל Auto-Waiting.
9. כל בדיקה צריכה לכלול Assertion משמעותי.
10. צריך להכיר את Test Runner.
11. Fixtures חשובים לפרויקטים גדולים.
12. Page Object יכול לשפר תחזוקה.
13. בדיקות צריכות להיות עצמאיות ככל האפשר.
14. Authentication הוא נושא מרכזי.
15. Test Data דורש תכנון.
16. Playwright יכול לשמש גם לבדיקות API.
17. Debugging הוא חלק בלתי נפרד מהעבודה.
18. יציבות חשובה יותר ממספר הבדיקות.
19. כדאי להבין את ההבדלים מול Selenium.
20. מתחילים מתרחיש קטן ובונים בהדרגה.

מה כדאי ללמוד אחרי המאמר הזה?

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

סדר לימוד הגיוני יכול להיות:

שלב 1 – להבין את Playwright

התחילו עם:

Playwright: מה זה ואיך משתמשים בו לבדיקות אוטומטיות?.

שלב 2 – לכתוב בדיקה ראשונה

עברו ל:

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

שלב 3 – להבין את האלטרנטיבות

לאחר מכן קראו:

Playwright מול Selenium: מה עדיף לבדיקות אוטומציה ב־2026?.

לסיכום

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

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

מתחילים צריכים להתמקד פחות בכמות הקוד ויותר בהבנה של העקרונות: Locators, Assertions, Waiting, Fixtures, Authentication, Test Data, Debugging ועצמאות בין בדיקות.

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

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

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

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

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

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