תקופת החגים היא אחת התקופות המאתגרות ביותר עבור צוותי QA.

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

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

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

המטרה היא הרבה יותר פשוטה:

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

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

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

בשגרה, אם מערכת מסוימת לא עובדת, בדרך כלל מישהו יגלה את זה.

בודק נכנס למערכת.

מפתח מנסה לבצע פעולה.

Product מגלה שמשהו לא עובד.

לקוח מדווח.

אבל בתקופת החגים משתנה המשוואה.

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

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

"כמה בדיקות אוטומציה אנחנו יכולים לכתוב?"

ויותר במונחים של:

"איזה דברים אסור לנו לגלות באיחור?"

זו הבחנה חשובה.

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

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

מה כדאי להפוך לאוטומטי?

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

1. Smoke Tests

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

לדוגמה:

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

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

2. בדיקות זמינות

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

אנחנו שואלים שאלה פשוטה:

האם המערכת זמינה?

לדוגמה:

			
פתח אתר
↓
המתן לטעינה
↓
בדוק שהכותרת קיימת
↓
בדוק שאובייקט מרכזי קיים
↓
סגור דפדפן
↓
דווח PASS/FAIL

		

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

3. בדיקות של תהליכים קריטיים

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

לדוגמה:

התחברות
חיפוש
יצירת לקוח
יצירת הזמנה
שליחת טופס
תהליך תשלום
טעינת Dashboard
קריאה ל-API מרכזי

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

המטרה היא Early Warning System.

4. בדיקות API

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

אפשר לבדוק:

HTTP Status
Response Time
שדות חובה
ערכים שחייבים לחזור
Authentication
זמינות Endpoint

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

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

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

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

Playwright

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

אפשר לבצע איתו:

פתיחת Chrome/Chromium
ניווט לכתובת
איתור אובייקט
בדיקת טקסט
בדיקת URL
צילום Screenshot במקרה של כשל
סגירת הדפדפן

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

Selenium

גם Selenium מתאים מאוד למשימה.

אם בארגון כבר קיימת תשתית Selenium, אין סיבה להחליף אותה רק בגלל החגים.

להיפך.

זה הזמן לקחת סקריפט קיים, לפשט אותו ולהפוך אותו ל-Health Check שרץ באופן עצמאי.

GitHub Actions

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

אפשר להחזיק את הסקריפט ב-GitHub ולהגדיר Workflow שמריץ אותו באופן מחזורי.

למשל:

			
כל שעה
↓
GitHub Actions
↓
הרצת Playwright
↓
פתיחת דפדפן
↓
בדיקה
↓
PASS / FAIL
↓
שליחת התראה במקרה של כשל

		

כך לא צריך להשאיר מחשב של בודק דולק במשך כל החג.

Jenkins

אם כבר יש בארגון Jenkins, הוא יכול להיות אפילו פתרון טבעי יותר.

אפשר ליצור Job קטן:

QA Health Check

ולהגדיר:

			
Build periodically
כל שעה

ה-Job מריץ את הסקריפט.

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

אם הוא נכשל – שולחים Notification.

ומה לגבי התראות?

זו נקודה קריטית.

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

לכן לכל בדיקה אוטומטית צריך להגדיר Owner.

לדוגמה:

			
בדיקה: Login Health Check
Owner: דני
תדירות: כל שעה
מערכת: Production
התראה: Email

		

אם דני בחופשה, צריך להגדיר גם Backup Owner.

Email – הפתרון הפשוט ביותר

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

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

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

			
Subject:
[QA ALERT] Production Login Check FAILED
System:
Production
Test:
Login Health Check
Time:
10:00
Error:
Login button was not found
Owner:
QA Team
Environment:
Production

		

מכאן הבודק יכול להתחיל לבדוק את הבעיה.

ומה לגבי SMS?

SMS יכול להיות שימושי מאוד כאשר מדובר בתקלה קריטית.

אבל כאן חשוב להפריד בין "חינמי" לבין "זמין".

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

לכן הייתי מדרג את ההתראות כך:

רמה 1 – Email

לרוב התקלות.

רמה 2 – Teams / Slack

כאשר רוצים שהצוות כולו יראה את התקלה.

רמה 3 – SMS

רק לתקלות Production קריטיות באמת.

כך לא מגיעים למצב שבו הבודק מקבל 30 הודעות SMS ביום בגלל בדיקה לא יציבה.

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

נניח שיש לנו אתר Production:

https://example.com

אנחנו רוצים לבדוק:

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

אפשר לעשות זאת באמצעות Playwright.

הסקריפט

			
const { chromium } = require('playwright');
(async () => {
    const browser = await chromium.launch({
        headless: true
    });
    const page = await browser.newPage();
    try {
        console.log('Opening production site...');
        await page.goto('https://example.com', {
            waitUntil: 'domcontentloaded',
            timeout: 30000
        });
        console.log('Page loaded');
        // בדיקה שהאובייקט המרכזי קיים
        await page.locator('#main-content').waitFor({
            state: 'visible',
            timeout: 10000
        });
        console.log('Main object exists');
        console.log('TEST PASSED');
        await browser.close();
        process.exit(0);
    } catch (error) {
        console.error('TEST FAILED');
        console.error(error);
        await page.screenshot({
            path: 'failure.png',
            fullPage: true
        });
        await browser.close();
        process.exit(1);
    }
})();

		

כמובן שבמערכת אמיתית צריך להחליף את:

https://example.com

ואת:

#main-content

בכתובת וב-Selector הרלוונטיים למערכת שלכם.

למה חשוב להשתמש ב-Exit Code?

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

כאשר הסקריפט מסתיים עם:

process.exit(0);

המשמעות היא:

הבדיקה הצליחה.

כאשר הוא מסתיים עם:

process.exit(1);

המשמעות היא:

הבדיקה נכשלה.

מערכות כמו Jenkins או GitHub Actions יכולות לזהות את ה-Failure הזה ולהפעיל אוטומטית את מנגנון ההתראה.

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

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

PASS או FAIL.

מערכת ה-CI/CD מטפלת בשאר.

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

ב-GitHub Actions אפשר להשתמש ב-Schedule.

לדוגמה:

			
name: Production QA Health Check
on:
  schedule:
    - cron: '0 * * * *'
  workflow_dispatch:
jobs:
  qa-health-check:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright
        run: npx playwright install --with-deps chromium
      - name: Run QA Health Check
        run: node health-check.js

		

המשמעות של:

0 * * * *

היא למעשה הרצה בתחילת כל שעה.

כך מתקבל:

			
00 → בדיקה
00 → בדיקה
00 → בדיקה
00 → בדיקה
...

		

והכול באופן אוטומטי.

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

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

נניח שבשעה 14:00 הבדיקה הצליחה.

בשעה 15:00:

			
Browser opened
↓
Website loaded
↓
#main-content
↓
NOT FOUND
↓
FAIL

		

ה-Workflow נכשל.

עכשיו אפשר לחבר אליו מערכת Notification.

למשל:

			
GitHub Actions
       ↓
   Test FAILED
       ↓
 Notification
       ↓
Email / Teams / Slack / SMS
       ↓
QA Owner

		

אפשר גם לשלוח Screenshot

זו אחת התוספות שאני ממליץ עליה במיוחד.

במקום לקבל:

Test failed.

מקבלים:

			
Test failed.
URL:
Production
Error:
#main-content was not found
Time:
15:00
Screenshot:
failure.png

		

זה משנה לחלוטין את זמן התגובה של הבודק.

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

ומה אם אנחנו רוצים פתרון אפילו יותר פשוט?

לא תמיד צריך Playwright.

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

למשל:

			
GET /login
↓
HTTP 200
↓
PASS

		

או:

			
GET /api/health
↓
HTTP 200
↓
JSON תקין
↓
PASS

		

זה מהיר יותר, קל יותר לתחזוקה, ופחות רגיש לשינויים ב-UI.

לכן הייתי משתמש בכלל הבא:

אם אפשר לבדוק באמצעות API – בדקו באמצעות API.
אם חייבים לבדוק את ה-UI – השתמשו ב-Playwright/Selenium.

פתרון חינמי נוסף: Cron

אם יש לכם Linux Server שכבר קיים בארגון, אפשר אפילו לא להשתמש ב-GitHub Actions.

אפשר להגדיר Cron:

0 * * * * node /opt/qa/health-check.js

והשרת יריץ את הבדיקה בכל שעה.

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

ומה עם Uptime Monitoring?

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

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

האם האתר זמין?

אבל כאן צריך להיזהר.

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

אתר יכול להחזיר:

HTTP 200

ועדיין להיות שבור לחלוטין מבחינת המשתמש.

לכן יש הבדל בין:

Uptime Monitoring

לבין:

Synthetic Testing

בבדיקת Synthetic אנחנו למעשה מדמים משתמש:

			
Open Browser
↓
Go to Website
↓
Find Object
↓
Click
↓
Validate
↓
Close Browser

		

וזה כבר הרבה יותר קרוב לבדיקת QA אמיתית.

המלצה שלי לתקופת החגים: לבנות "Holiday QA Watch"

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

לדוגמה:

בדיקה 1 – זמינות

כל 15 דקות.

Website → HTTP Check

בדיקה 2 – Smoke

כל שעה.

			
Open Browser
→ Login
→ Check Main Object
→ Close

בדיקה 3 – API

כל שעה.

			
API
→ Status
→ Response
→ Required Fields

בדיקה 4 – תהליך עסקי קריטי

כל 4 שעות.

			
Login
→ Search
→ Action
→ Validate

אל תיצרו מאות בדיקות

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

אין צורך לקחת עכשיו את כל Regression Suite ולהפוך אותה לאוטומטית.

להיפך.

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

המטרה היא לא:

100% Automation.

המטרה היא:

100% Visibility על הדברים הקריטיים.

אם יש לכם 20 מערכות Production, אולי מספיק להתחיל מ-20 בדיקות Health Check.

אחת לכל מערכת קריטית.

הגדירו Owner לכל אוטומציה

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

טבלה פשוטה יכולה להספיק:

בדיקה	מערכת	תדירות	Owner	Backup	התראה
Login	Production	כל שעה	דני	רונית	Email
API Health	Production	כל שעה	רונית	יוסי	Teams
Search	Production	כל 2 שעות	יוסי	דני	Email
Payment	Production	כל שעה	דנה	רונית	SMS

זה חשוב במיוחד בחגים.

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

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

גם זו מלכודת.

נניח שהבדיקה נכשלה פעם אחת בגלל Network Timeout.

אם בכל פעם שולחים SMS, הבודק מקבל:

			
00 FAIL
00 FAIL
00 FAIL
00 FAIL

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

עדיף להגדיר מנגנון פשוט:

			
Failure #1
↓
Retry
↓
Failure #2
↓
Retry
↓
Failure #3
↓
ALERT

		

או:

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

כך מקטינים False Positives.

ומה הייתי עושה כבר עכשיו, לפני החגים?

אם הייתי צריך להכין צוות QA לחג בתוך יום-יומיים, הייתי עובד בסדר הבא:

שלב 1 – רשימת מערכות

לרשום את כל מערכות ה-Production הקריטיות.

שלב 2 – בחירת Smoke אחד לכל מערכת

לא עשרה.

אחד.

התרחיש שמוכיח שהמערכת חיה.

שלב 3 – אוטומציה מהירה

להשתמש במה שכבר קיים:

Playwright
Selenium
Postman/Newman
Python
JavaScript
Jenkins
GitHub Actions
Cron

שלב 4 – הרצה מחזורית

להתחיל מכל שעה.

שלב 5 – התראה

להגדיר:

			
FAIL
→ Email

ואם המערכת קריטית:

			
FAIL
→ Email
→ Teams/Slack
→ SMS

שלב 6 – Screenshot

בכל כשל UI.

שלב 7 – Owner

לכל סקריפט Owner ו-Backup.

והנקודה החשובה ביותר מבחינתי

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

היא יכולה להיות דווקא הזדמנות טובה לבנות מנגנון קטן של QA אוטונומי.

לא מערכת ענקית.

לא פרויקט של חצי שנה.

לא מאות Test Cases.

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

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

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

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

זו שכבת הגנה על ה-Production.

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

Playwright + GitHub Actions + בדיקת Smoke כל שעה + Screenshot בכשל + Email ל-Owner.

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

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

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

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

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

מה כדאי להפוך לאוטומטי?

1. Smoke Tests

2. בדיקות זמינות

3. בדיקות של תהליכים קריטיים

4. בדיקות API

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

Playwright

Selenium

GitHub Actions

Jenkins

ומה לגבי התראות?

Email – הפתרון הפשוט ביותר

ומה לגבי SMS?

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

הסקריפט

למה חשוב להשתמש ב-Exit Code?

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

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

אפשר גם לשלוח Screenshot

ומה אם אנחנו רוצים פתרון אפילו יותר פשוט?

פתרון חינמי נוסף: Cron

ומה עם Uptime Monitoring?

המלצה שלי לתקופת החגים: לבנות "Holiday QA Watch"

בדיקה 1 – זמינות

בדיקה 2 – Smoke

בדיקה 3 – API

בדיקה 4 – תהליך עסקי קריטי

אל תיצרו מאות בדיקות

הגדירו Owner לכל אוטומציה

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

ומה הייתי עושה כבר עכשיו, לפני החגים?

שלב 1 – רשימת מערכות

שלב 2 – בחירת Smoke אחד לכל מערכת

שלב 3 – אוטומציה מהירה

שלב 4 – הרצה מחזורית

שלב 5 – התראה

שלב 6 – Screenshot

שלב 7 – Owner

והנקודה החשובה ביותר מבחינתי

שתף

קשור

כתיבת תגובה לבטל