אתר חדש נראה מצוין.

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

ואז האתר עולה.

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

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

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

בדיקת אתר מקצועית היא הרבה מעבר לזה.

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

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

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

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

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

וזה הבדל גדול.

למה בכלל צריך בדיקות לאתר?

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

לדוגמה:

הדף הראשי עובד.

אבל:

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

מבחינת בעל האתר, אלה לא "באגים קטנים".

כל אחד מהם יכול לעלות כסף.

אילו סוגי בדיקות מבצעים לאתרים?

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

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

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

זו הבדיקה הבסיסית:

האם האתר עושה את מה שהוא אמור לעשות?

לדוגמה:

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

אם יש פעולה באתר – צריך לבדוק אותה.

אבל אני לא מסתפק בתרחיש החיובי.

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

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

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

2. בדיקות UI

כאן בודקים את הממשק עצמו.

לדוגמה:

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

הנקודה החשובה היא שלא צריך לבדוק רק אם האתר "נראה יפה".

צריך לבדוק אם הוא שמיש.

3. בדיקות Responsive

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

אותו אתר צריך לעבוד במגוון גדלי מסך:

• מחשב נייח
• לפטופ
• טאבלט
• טלפון
• מסכים קטנים
• מסכים גדולים

לפעמים אתר שנראה מושלם ב-Chrome על מחשב פשוט נראה אחרת לחלוטין בטלפון.

דוגמאות לתקלות:

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

לכן Mobile Testing הוא לא תוספת נחמדה. הוא חלק מהבדיקה הבסיסית של אתר.

4. בדיקות Cross Browser

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

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

לדוגמה:

• Chrome
• Edge
• Firefox
• Safari

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

הסיבה פשוטה:

דפדפנים שונים יכולים לפרש רכיבי HTML, CSS ו-JavaScript בצורה שונה.

5. בדיקות טפסים

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

במיוחד באתר שמטרתו לייצר לידים.

נניח שיש טופס:

שם + טלפון + אימייל + הודעה

לא מספיק לבדוק שהטופס נשלח.

צריך לבדוק:

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

והנקודה האחרונה חשובה במיוחד.

יכול להיות שהמשתמש רואה:

"הטופס נשלח בהצלחה"

אבל בפועל הליד בכלל לא הגיע ל-CRM.

מבחינת המשתמש הכול תקין.

מבחינת העסק – נוצרה תקלה רצינית.

6. בדיקות חנות אונליין

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

כאן כבר צריך לבדוק תהליך שלם.

לדוגמה:

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

כל אחד מהשלבים יכול להיכשל.

ולכן כאן בדיקות E2E חשובות במיוחד.

7. בדיקות תשלום

אם באתר יש סליקה, זה אזור שאסור להקל בו ראש.

צריך לבדוק:

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

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

8. בדיקות API

אתר מודרני הוא בדרך כלל לא רק Frontend.

מאחוריו יכולים להיות APIs שמבצעים פעולות כמו:

• התחברות
• חיפוש
• שמירת נתונים
• שליפת מוצרים
• תשלומים
• שליחת מידע
• חיבור ל-CRM

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

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

9. בדיקות אינטגרציה

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

נניח שיש באתר טופס לידים:

אתר
 ↓
API
 ↓
CRM
 ↓
Email
 ↓
מערכת Marketing

מה קורה אם ה-API עובד אבל ה-CRM לא מקבל את הליד?

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

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

10. בדיקות ביצועים

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

לדוגמה:

המשתמש לוחץ על מוצר.

מחכה.

מחכה.

ועוד מחכה.

ואז האתר נפתח.

מבחינת QA אולי "הבדיקה עברה".

מבחינת המשתמש – האתר איטי.

בדיקות ביצועים יכולות לבחון:

• זמני טעינה
• זמני תגובה
• עומסים
• מספר משתמשים במקביל
• זמני תגובה של APIs
• ביצועי מסד נתונים
• עומס על השרת
• התנהגות בזמן Peak

11. בדיקות אבטחה

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

לדוגמה:

• הרשאות
• גישה לעמודים מוגנים
• ניהול Session
• Logout
• גישה למידע של משתמש אחר
• קלטים לא תקינים
• חשיפת מידע
• הודעות שגיאה
• העלאת קבצים

המטרה היא לא "לפרוץ לאתר", אלא לזהות חולשות שעלולות להפוך לבעיה אמיתית.

12. בדיקות נגישות

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

בדיקות נגישות יכולות לכלול בין היתר:

• ניווט באמצעות מקלדת
• Focus
• Labels
• טקסט חלופי לתמונות
• מבנה כותרות
• ניגודיות
• הודעות שגיאה
• שימוש בקוראי מסך

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

היא חלק מאיכות המוצר.

13. בדיקות SEO טכניות כחלק מ-QA

SEO ו-QA הם לא אותו דבר, אבל יש נקודות שבהן הם נפגשים.

לדוגמה:

• קישורים שבורים
• עמודי 404
• Redirects
• Canonical
• robots.txt
• sitemap
• תגיות Title
• Meta Description
• כותרות H1
• תוכן כפול
• בעיות Mobile
• מהירות טעינה

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

14. בדיקות אנליטיקס ומדידה

זו בדיקה שאני ממליץ לא לדלג עליה.

נניח שהאתר מקבל 10,000 מבקרים.

אבל Google Analytics לא מקבל את הנתונים.

או שהאירוע של "Lead" לא מופעל.

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

מבחינת המשתמש האתר עובד.

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

לכן כדאי לבדוק גם:

• Page Views
• Events
• Conversions
• Form Submission
• Ecommerce Events
• UTM
• Tags
• Pixels
• Consent

איך נראה תהליך מקצועי של שירותי בדיקות אתרים?

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

שלב 1 – הבנת האתר

לפני שאני מתחיל ללחוץ על כפתורים, אני רוצה להבין:

• מה האתר עושה?
• מי המשתמשים?
• מה המטרה העסקית?
• מהם התהליכים הקריטיים?
• אילו מערכות מחוברות אליו?
• מה אסור שיישבר?

זה שלב שאנשים לפעמים מדלגים עליו.

לדעתי זו טעות.

שלב 2 – בניית Test Plan

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

לדוגמה:

שלב 3 – בדיקות חיוביות ושליליות

אני תמיד ממליץ לא להסתפק בשאלה:

"האם זה עובד?"

צריך להוסיף:

"מה קורה אם המשתמש עושה משהו שלא ציפינו לו?"

לדוגמה:

אם יש שדה גיל:

חיובי: 35

שלילי:

• ריק
• -5
• 500
• טקסט
• תווים מיוחדים

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

שלב 4 – בדיקות במכשירים ודפדפנים

כאן אנחנו עוברים בין סביבות שונות.

לא רק Desktop.

גם Mobile.

ולא רק דפדפן אחד.

שלב 5 – בדיקות End-to-End

כאן בודקים את התהליכים העסקיים החשובים.

לדוגמה:

משתמש
↓
כניסה
↓
חיפוש
↓
פעולה
↓
API
↓
Database
↓
מערכת חיצונית
↓
תוצאה

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

שלב 6 – פתיחת תקלות

כאשר נמצאת תקלה, חשוב לא רק לכתוב:

"הכפתור לא עובד."

דיווח טוב צריך לכלול:

Title

Environment

Steps to Reproduce

Expected Result

Actual Result

Severity

Priority

Screenshot / Video

Logs, כאשר רלוונטי.

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

Severity מול Priority – לא אותו דבר

זו נקודה חשובה בעולם ה-QA.

Severity

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

Priority

כמה דחוף לטפל בה.

לדוגמה:

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

Severity: Low

אבל Priority: High

כי זה הדבר הראשון שכל לקוח רואה.

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

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

לא צריך לחכות שהאתר יהיה "מוכן לגמרי".

למעשה, עדיף להתחיל מוקדם.

אתר חדש

לפני העלייה לאוויר.

אתר קיים

לפני שינוי משמעותי.

שדרוג מערכת

לפני ואחרי השדרוג.

מעבר שרת

לפני המעבר ואחריו.

שינוי תשלום

לפני העלייה לייצור.

שינוי תשתית

כאשר משתנים APIs, Database או שירותים חיצוניים.

אתר Ecommerce

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

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

התשובה שלי היא:

גם וגם – אבל כל אחד במקום הנכון.

בדיקות ידניות מצוינות כאשר צריך:

• חקירה
• Exploratory Testing
• בדיקות UX
• תרחישים חדשים
• שינויים תכופים

אוטומציה מצוינת כאשר מדובר ב:

• Regression
• תהליכים חוזרים
• תרחישים יציבים
• בדיקות E2E
• בדיקות API
• בדיקות שרצות ב-CI/CD

כלי כמו Playwright, למשל, מאפשר לבנות בדיקות End-to-End אוטומטיות לאפליקציות Web ולשלב אותן בתהליכי CI.

הנקודה החשובה היא לא לבחור בין Manual ל-Automation כאילו אחד מהם צריך לנצח.

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

כמה בדיקות באמת צריך לאתר?

אין מספר קסם.

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

• חנות Ecommerce
• מערכת פיננסית
• פורטל לקוחות
• מערכת ביטוח
• אתר עם אלפי משתמשים
• מערכת עם תשלומים

לכן אני מעדיף לחשוב על Risk-Based Testing.

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

מה יקרה אם טופס הלידים לא יעבוד?

מה יקרה אם משתמש יראה מידע של משתמש אחר?

מה יקרה אם נתונים לא יעברו ל-CRM?

מה יקרה אם האתר יהיה איטי ביום שבו נכנסים אליו אלפי משתמשים?

ככל שהסיכון גבוה יותר – כך הבדיקה צריכה לקבל עדיפות גבוהה יותר.

Checklist: בדיקת אתר לפני העלייה לאוויר

לפני Launch, זו רשימת בדיקה טובה להתחלה:

פונקציונליות

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

Mobile

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

Browsers

☐ Chrome
☐ Edge
☐ Firefox
☐ Safari

Ecommerce

☐ מוצר
☐ סל
☐ קופון
☐ Checkout
☐ תשלום
☐ אישור הזמנה

Performance

☐ זמני טעינה
☐ זמני API
☐ עומס
☐ תמונות
☐ JavaScript

SEO

☐ Title
☐ H1
☐ Meta Description
☐ Sitemap
☐ Robots
☐ Redirects
☐ 404

Analytics

☐ Page View
☐ Events
☐ Conversions
☐ Forms
☐ Ecommerce

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

זו שאלה שמופיעה כמעט בכל פרויקט.

אבל אין מחיר אחיד.

העלות תלויה בין היתר ב:

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

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

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

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

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

"בדקנו והכול בסדר."

אני מעדיף לקבל תמונת מצב ברורה.

לדוגמה:

סה"כ תרחישים: 150

עברו: 137

נכשלו: 13

Critical: 1

High: 3

Medium: 6

Low: 3

וכמובן פירוט של התקלות.

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

האם אנחנו מוכנים לעלות לאוויר?

ומה אם אין תקציב לצוות QA שלם?

זו המציאות בהרבה עסקים.

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

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

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

כלומר:

1. מזהים את התהליכים הקריטיים.
2. בודקים את המקומות שבהם כשל יעלה הכי הרבה כסף.
3. בודקים Mobile.
4. בודקים טפסים.
5. בודקים תשלום אם קיים.
6. בודקים אינטגרציות.
7. בודקים תרחישי E2E מרכזיים.
8. ורק לאחר מכן מרחיבים את הכיסוי.

לפעמים בדיקה ממוקדת של 30 תרחישים נכונים שווה יותר ממאות Test Cases שלא נבחרו בצורה נכונה.

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

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

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

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

הוא לא יודע איזה Database נמצא מאחוריו.

הוא לא יודע איזה Framework פועל באתר.

הוא פשוט רוצה:

להיכנס → למצוא → להבין → לבצע פעולה → לקבל תוצאה.

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

לסיכום: אתר טוב הוא לא רק אתר שנראה טוב

בעיניי, אתר מקצועי צריך לעבור הרבה יותר מבדיקת "האם הוא נראה יפה".

צריך לבדוק:

האם הוא עובד?

האם הוא עובד במובייל?

האם הוא עובד בדפדפנים שונים?

האם הטפסים עובדים?

האם התשלום עובד?

האם המידע מגיע למערכות האחרות?

האם האתר עומד בעומס?

האם המשתמש יכול להשלים את התהליך?

האם הנתונים שנאספים נכונים?

והכי חשוב – מה קורה כאשר המשתמש עושה משהו שלא תכננו?

זו בדיוק המהות של שירותי בדיקות אתרים.

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

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

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

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

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

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

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