פרויקט Playwright לתיק עבודות: קטן, אמין וקל להסבר

מה הפרויקט צריך להוכיח?

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

• האם הוא יודע לבחור מה חשוב לבדוק ולא רק להקליט לחיצות?
• האם הוא מבין Web, API, נתונים ואימות תוצאה?
• האם הבדיקות עצמאיות וניתנות להרצה חוזרת?
• האם כישלון משאיר report או trace שאפשר לחקור?
• האם הוא יכול להסביר את הקוד ואת המגבלות בלי להסתתר מאחורי כלי או AI?

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

בחירת מוצר והיקף

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

דוגמת היקף לפרויקט מסחר

הגדרת Done לפרויקט

• 6 עד 12 בדיקות שעוברות מקומית וב־CI.
• לפחות בדיקת API אחת שמכינה או מאמתת נתונים.
• שימוש ב־locators שפונים להתנהגות שהמשתמש רואה.
• נתונים עצמאיים ואיפוס מצב בין בדיקות.
• HTML report ו־trace בכישלון הראשון.
• README עם מטרה, סיכונים, התקנה, הרצה ומגבלות.

מבנה פרויקט שאפשר להבין במהירות

qa-playwright-portfolio/
  tests/
    auth.spec.ts
    checkout.spec.ts
    api-products.spec.ts
  fixtures/
    test-data.ts
  pages/
    checkout.page.ts
  playwright.config.ts
  package.json
  README.md
  .github/workflows/playwright.yml

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

התחלה ב־TypeScript

npm init playwright@latest
npx playwright test
npx playwright show-report

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

בדיקת UI עם locator יציב

import { test, expect } from '@playwright/test';

test('signed-in user can add a product to the cart', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('qa@example.com');
  await page.getByLabel('Password').fill('Example123!');
  await page.getByRole('button', { name: 'Sign in' }).click();

  await page.getByRole('link', { name: 'Products' }).click();
  const product = page.getByRole('article').filter({ hasText: 'QA Handbook' });
  await product.getByRole('button', { name: 'Add to cart' }).click();

  await expect(page.getByTestId('cart-count')).toHaveText('1');
});

הבדיקה משתמשת ב־role, label וטקסט שהמשתמש רואה. היא אינה תלויה בשרשרת CSS ארוכה. Playwright מבצע בדיקות actionability לפני פעולה, וה־assertion מנסה שוב עד שהתנאי מתקיים או שנגמר הזמן.

בדיקת API של תרחיש שלילי

import { test, expect } from '@playwright/test';

test('API rejects an order with a negative quantity', async ({ request }) => {
  const response = await request.post('/api/orders', {
    data: { productId: 'qa-handbook', quantity: -1 }
  });

  expect(response.status()).toBe(400);
  expect(await response.json()).toMatchObject({
    error: 'INVALID_QUANTITY'
  });
});

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

עצמאות ונתוני בדיקה

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

הרצה ב־CI וחקירת כשלים

הוסיפו workflow שמתקין dependencies ודפדפנים, מריץ את הבדיקות ושומר report. אל תציגו badge ירוק אם ה־workflow עצמו אינו יציב.

name: Playwright Tests
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test --project=chromium
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 7

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

Trace Viewer מאפשר לראות timeline, DOM snapshots, network ופעולות. לפרויקט קטן הגדירו trace על retry ראשון. Screenshot עוזר להבין מצב מסך, אבל trace בדרך כלל מספק חקירה מלאה יותר. Video שימושי במקרים מסוימים אך מגדיל את משקל ה־artifacts.

מה לא לעשות כדי "לתקן" flakiness

• לא להוסיף wait קבוע של כמה שניות לכל פעולה.
• לא להפעיל retries רבים עד שהבדיקה עוברת.
• לא לבחור nth locator רק כדי לעקוף התאמה כפולה.
• לא לשתף משתמש או סל קניות בין בדיקות שרצות במקביל.
• לא להסתיר כישלון באמצעות assertion חלש.

README שמספר את הסיפור המקצועי

ה־README צריך לאפשר למראיין להבין את הפרויקט בתוך שתי דקות:

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

איך להציג את הפרויקט בראיון

התחילו מהבעיה ולא מהכלי: "בחרתי תהליך הזמנה כי תקלה בו גורמת לנזק כספי. כיסיתי את המסלול המרכזי ב־UI ואת validation והכפילויות ב־API. הכנתי נתונים לכל בדיקה בנפרד ושמרתי trace בכישלון". לאחר מכן פתחו בדיקה אחת והסבירו locator, assertion ודרך החקירה.

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

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

שאלות נפוצות

מקורות רשמיים

• Playwright: Best Practices
• Playwright: Locators
• Playwright: Trace Viewer