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

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

אבל מה זה Playwright, למה הוא הפך לכל כך פופולרי, במה הוא שונה מ־Selenium, ואיך מתחילים להשתמש בו בפועל?

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


מה זה Playwright?

Playwright הוא Framework לבדיקות אוטומטיות של אפליקציות ואתרי Web, שפותח במקור על ידי Microsoft.

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

לדוגמה, באמצעות Playwright ניתן לבצע אוטומציה של תרחיש כמו:

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

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

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


למה בכלל צריך Playwright?

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

נניח שיש באתר תהליך הרשמה:

Registration → Login → Profile → Payment

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

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

Playwright מאפשר ליצור בדיקות שניתן להריץ:

  • באופן ידני.
  • באופן אוטומטי.
  • כחלק מ־CI/CD.
  • לפני העלאת גרסה.
  • לאחר Deployment.
  • בלילה באופן מתוזמן.
  • כחלק מ־Regression Testing.

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


איך Playwright עובד?

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

הוא תומך בין היתר בדפדפנים:

  • Chromium
  • Firefox
  • WebKit

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

לדוגמה, תרחיש Login אחד יכול לרוץ על:

Chrome / Chromium

וגם על:

Firefox

וגם על:

Safari / WebKit

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


אילו שפות תכנות נתמכות ב־Playwright?

Playwright מספק תמיכה במספר שפות תכנות מרכזיות.

בין היתר:

  • JavaScript
  • TypeScript
  • Python
  • Java
  • .NET

עבור צוותי QA רבים, TypeScript או JavaScript הם בחירה טבעית, במיוחד כאשר סביבת הפיתוח של הארגון מבוססת על Node.js.

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


Playwright Test

אחד המרכיבים החשובים באקוסיסטם של Playwright הוא Playwright Test.

זהו Test Runner שמאפשר לנהל ולהריץ בדיקות אוטומטיות בצורה מסודרת.

באמצעותו ניתן לבצע פעולות כמו:

  • הרצת בדיקות.
  • חלוקת בדיקות לקבוצות.
  • Assertions.
  • Screenshots.
  • Videos.
  • Trace.
  • Parallel Testing.
  • Retry.
  • ניהול Browser Context.
  • Reports.

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


איך מתקינים Playwright?

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

לדוגמה:

npm init playwright@latest

במהלך ההתקנה ניתן לבחור את שפת התכנות ואת מבנה הפרויקט.

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


בדיקת Playwright ראשונה

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

דוגמה פשוטה ב־Playwright:

import { test, expect } from '@playwright/test';
test('Homepage loads successfully', async ({ page }) => {
await page.goto('https://example.com');
await expect(page).toHaveTitle(/Example/);
});

מה קורה כאן?

test

מגדיר Test חדש.

page

מייצג את עמוד הדפדפן שבו מתבצעת הבדיקה.

page.goto()

פותח URL.

expect()

מבצע Assertion.

toHaveTitle()

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

זהו למעשה Test Case אוטומטי.


דוגמה לבדיקת Login באמצעות Playwright

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

  • שדה Username
  • שדה Password
  • כפתור Login

נוכל ליצור בדיקה לדוגמה:

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

הבדיקה מדמה משתמש אמיתי:

פתיחת Login → הזנת Username → הזנת Password → לחיצה על Login → בדיקה שהגענו ל־Dashboard

זה בדיוק סוג התרחישים שמתאימים מאוד ל־E2E Testing.


מה זה Playwright Locator?

אחד הנושאים החשובים ביותר בלימוד Playwright הוא Locators.

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

לדוגמה:

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

או:

page.getByLabel('Password')

או:

page.getByText('Welcome')

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

בחירת Locator טובה היא קריטית ליציבות הבדיקות.


למה Locators חשובים כל כך?

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

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

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

לדוגמה:

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

מובן יותר וגם יכול להיות יציב יותר מאשר Selector שתלוי במבנה DOM ספציפי.

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

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


מה זה E2E Testing ב־Playwright?

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

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

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

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

Playwright מתאים מאוד לתרחישים כאלה.


אילו בדיקות אפשר לבצע באמצעות Playwright?

Playwright מתאים למגוון רחב של תרחישי בדיקות Web.

1. בדיקות פונקציונליות

לדוגמה:

  • Login.
  • Logout.
  • הרשמה.
  • חיפוש.
  • יצירת משתמש.
  • עריכת פרופיל.
  • מחיקת מידע.

2. בדיקות E2E

בדיקת תהליכים עסקיים מלאים.

לדוגמה:

Login → הזמנה → תשלום → אישור

3. בדיקות Regression

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

4. בדיקות Cross Browser

הרצת בדיקות במספר מנועי דפדפן.

5. בדיקות UI

בדיקת:

  • כפתורים.
  • טפסים.
  • הודעות.
  • תפריטים.
  • טבלאות.
  • ניווט.

6. בדיקות API

Playwright כולל גם יכולות לביצוע בדיקות API, ולכן ניתן לשלב בדיקות API ו־UI באותו פרויקט.


Playwright מול Selenium – מה ההבדל?

זו אחת השאלות הנפוצות ביותר בקרב אנשי QA.

גם Selenium וגם Playwright משמשים לבדיקות אוטומטיות של מערכות Web, אבל הם שונים בארכיטקטורה ובגישה שלהם.

נושאPlaywrightSelenium
Web Testing
Chrome/Chromium
Firefox
WebKitבאמצעות פתרונות אחרים
Auto-waitingתלוי במימוש
Parallel Testing
API Testingבדרך כלל באמצעות כלים נוספים
שפותמספר שפותמספר שפות
קהילה ותיקהחדשה יותרותיקה מאוד
מתאים ל־E2E

חשוב להבין שאין תשובה אחת שמתאימה לכל ארגון.

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

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


מה היתרונות של Playwright?

Auto-Waiting

אחד היתרונות המשמעותיים של Playwright הוא מנגנון ההמתנה האוטומטי.

במקום להוסיף בכל מקום:

wait(5000)

Playwright יודע להמתין לתנאים מסוימים לפני ביצוע הפעולה.

זה יכול להפוך את הבדיקות ליציבות יותר.


תמיכה במספר דפדפנים

אפשר להריץ בדיקות על Chromium, Firefox ו־WebKit.

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


Parallel Testing

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

Playwright מאפשר להריץ בדיקות במקביל ובכך לקצר את זמן הריצה הכולל.


Trace Viewer

אחד הכלים השימושיים ביותר ב־Playwright הוא Trace.

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

זה מסייע מאוד בתהליך Debugging.


Screenshots ו־Videos

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

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


מה החסרונות של Playwright?

למרות היתרונות הרבים, Playwright אינו פתרון מושלם.

1. עדיין צריך ידע בתכנות

Playwright הוא כלי אוטומציה המבוסס על קוד.

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

  • JavaScript / TypeScript
  • Python
  • Git
  • Debugging
  • מבני נתונים
  • Assertions
  • עקרונות Automation

2. תחזוקת אוטומציה

גם בדיקות Playwright דורשות תחזוקה.

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

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

זו נקודה חשובה מאוד.

לא צריך להפוך כל Test Case לאוטומטי.

בדיקות אוטומטיות מתאימות במיוחד לתרחישים:

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

Playwright ו־CI/CD

אחד השימושים החשובים ביותר של Playwright הוא שילוב הבדיקות בתהליך CI/CD.

לדוגמה:

Developer Commit → Build → Deploy → Playwright Tests → Result → Release

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

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

ניתן לשלב Playwright בסביבות וכלים שונים של CI/CD, בהתאם לארכיטקטורה של הארגון.


איך לבנות פרויקט Playwright נכון?

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

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

לדוגמה:

tests/
login.spec.ts
registration.spec.ts
checkout.spec.ts
pages/
LoginPage.ts
DashboardPage.ts
CheckoutPage.ts
utils/
testData.ts
helpers.ts

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

Tests

לבין:

Page Objects

ולבין:

Utilities

וכך קל יותר לתחזק את הפרויקט.


Page Object Model ב־Playwright

אחת השיטות המקובלות לבניית Automation היא Page Object Model – POM.

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

לדוגמה:

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

לאחר מכן ה־Test יכול להשתמש ב־Page Object.

היתרון הוא שהקוד הופך למודולרי וקל יותר לתחזוקה.


Playwright למתחילים – מאיפה להתחיל?

אם אתם אנשי QA שרוצים להיכנס לתחום האוטומציה, הייתי ממליץ לא להתחיל ישר מתרחישים מורכבים.

סדר לימוד יעיל יכול להיות:

שלב 1 – בסיס בתכנות

ללמוד:

  • Variables
  • Conditions
  • Loops
  • Functions
  • Arrays
  • Objects
  • Async/Await

שלב 2 – Git

להכיר:

  • Clone
  • Commit
  • Push
  • Pull
  • Branch
  • Merge

שלב 3 – Playwright בסיסי

ללמוד:

  • Installation
  • Browser
  • Page
  • Locator
  • Assertions
  • Tests

שלב 4 – בדיקות מתקדמות

להמשיך ל:

  • Fixtures
  • Hooks
  • Page Objects
  • Test Data
  • Parallel Testing
  • Retry
  • Trace
  • Reports

שלב 5 – CI/CD

לבסוף לשלב את הבדיקות ב־Pipeline.


10 טעויות נפוצות ב־Playwright

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

1. שימוש מוגזם ב־Timeout

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

2. Locators לא יציבים

Selector שתלוי במבנה HTML פנימי עלול להישבר בשינוי קטן.

3. בדיקות גדולות מדי

Test אחד שמבצע 50 פעולות קשה לתחזוקה ול־Debugging.

4. תלות בין Tests

כל Test צריך להיות עצמאי ככל האפשר.

5. שימוש בנתוני Test קבועים

נתונים לא נכונים יכולים לגרום לכישלונות שאינם קשורים למוצר.

6. אוטומציה של כל דבר

לא כל Test Case צריך להפוך לאוטומטי.

7. התעלמות מ־Negative Testing

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

צריך לבדוק גם:

  • סיסמה שגויה.
  • שדה ריק.
  • נתונים לא תקינים.
  • הרשאות.
  • Session שפג.

8. חוסר ב־Reporting

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

9. חוסר תחזוקה

Automation שלא מתחזקים הופכת במהירות ל־Technical Debt.

10. התמקדות בכלי במקום באיכות

Playwright הוא כלי.

הוא לא מחליף חשיבה של QA.


האם Playwright מתאים לכל פרויקט?

לא בהכרח.

לפני שבוחרים Playwright צריך לבדוק:

  • איזה סוג מערכת נבדק?
  • באילו דפדפנים משתמשים?
  • אילו שפות קיימות בארגון?
  • מה ה־CI/CD?
  • כמה בדיקות צפויות להיות?
  • מי מתחזק את האוטומציה?
  • האם יש כבר Framework קיים?
  • האם יש צורך ב־Cross Browser Testing?

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


Playwright ואוטומציה בעולם ה־QA

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

QA מודרני לא צריך רק לדעת:

איך לבצע בדיקה.

הוא צריך לדעת גם:

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

לכן אנשי QA שרוצים להתקדם לכיוון Automation צריכים להכיר לא רק את Playwright, אלא גם:

  • API Testing
  • SQL
  • Git
  • CI/CD
  • בדיקות E2E
  • Performance Testing
  • Docker
  • עקרונות תכנות

Playwright יכול להיות אחד הכלים המרכזיים בארגז הכלים הזה.


שאלות נפוצות על Playwright

מה זה Playwright?

Playwright הוא Framework לבדיקות אוטומטיות של אתרי ואפליקציות Web, המאפשר לבצע פעולות בדפדפן ולבדוק את התוצאה באמצעות קוד.

האם Playwright הוא כלי אוטומציה?

כן. Playwright משמש בעיקר לבדיקות אוטומטיות של מערכות Web, כולל בדיקות E2E, UI ובדיקות נוספות.

האם Playwright מתאים למתחילים?

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

האם Playwright מחליף את Selenium?

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

האם אפשר לבצע בדיקות API עם Playwright?

כן. Playwright כולל יכולות לביצוע בדיקות API ולכן ניתן לשלב בדיקות API ו־UI באותו פרויקט.

באילו דפדפנים Playwright תומך?

Playwright תומך ב־Chromium, Firefox ו־WebKit.

האם אפשר לשלב Playwright ב־CI/CD?

כן. ניתן לשלב בדיקות Playwright ב־Pipelines ולהריץ אותן כחלק מתהליך Build, Deployment ו־Regression.


סיכום: האם כדאי ללמוד Playwright?

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

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

אבל חשוב לזכור:

כלי אוטומציה טוב לא הופך תהליך QA לתהליך טוב באופן אוטומטי.

הערך האמיתי מגיע מהשילוב בין:

ידע ב־QA + חשיבה של בודק + תכנות + אוטומציה + הבנה של המערכת העסקית.

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

אם אתם מתחילים ללמוד Automation, Playwright יכול להיות נקודת פתיחה מצוינת — במיוחד אם המטרה שלכם היא להתקדם מ־Manual QA לכיוון Automation QA.

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

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

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

כתיבת תגובה