בדיקות תוכנה – המדריך המלא לסוגי בדיקות, שיטות וכלים

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

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

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

תוכן העניינים

• מה זה בדיקות תוכנה?
• למה צריך לבצע בדיקות תוכנה?
• איך נראה תהליך בדיקות תוכנה?
• סוגי בדיקות תוכנה
• בדיקות תוכנה ידניות
• בדיקות תוכנה אוטומטיות
• בדיקות פונקציונליות
• בדיקות אינטגרציה
• בדיקות E2E
• בדיקות API
• בדיקות רגרסיה
• בדיקות ביצועים ועומסים
• בדיקות יחידה
• בדיקות קבלה
• בדיקות במערכות SAP
• מהו Test Case?
• איך מדווחים על באג?
• כלים לבדיקות תוכנה ואוטומציה
• בדיקות ידניות מול בדיקות אוטומטיות
• איך מתחילים בתחום בדיקות התוכנה?
• Checklist בסיסי לבדיקות תוכנה
• סיכום

מה זה בדיקות תוכנה?

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

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

לדוגמה, באתר מסחר ניתן לבדוק:

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

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

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

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

בדיקות תוכנה נועדו בין היתר:

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

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

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

שלב 1 – הבנת הדרישות

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

שלב 2 – זיהוי תרחישי הבדיקה

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

שלב 3 – הכנת Test Cases

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

שלב 4 – הכנת סביבת הבדיקות

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

שלב 5 – ביצוע הבדיקות

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

שלב 6 – דיווח על תקלות

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

שלב 7 – תיקון ובדיקה חוזרת

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

שלב 8 – בדיקות רגרסיה

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

סוגי בדיקות תוכנה

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

בין סוגי הבדיקות המרכזיים ניתן למצוא:

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

בדיקות תוכנה ידניות

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

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

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

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

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

בדיקות תוכנה אוטומטיות

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

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

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

בנוסף, כדאי להכיר את כלים לבדיקות אוטומציה ולמאמר על בדיקות תוכנה אוטומטיות – מה זה ומה היתרונות.

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

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

לדוגמה, במערכת הזמנות ניתן לבדוק:

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

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

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

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

לדוגמה, מערכת מסחר עשויה לתקשר עם:

• מערכת תשלומים.
• מערכת CRM.
• מערכת ERP.
• מערכת מלאי.
• שירות משלוחים.
• שירות שליחת הודעות.

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

באתר קיימים גם מאמרים ייעודיים על בדיקות אינטגרציה ב-SAP.

בדיקות E2E – End-to-End

בדיקות E2E בודקות תהליך שלם מנקודת ההתחלה ועד לתוצאה הסופית.

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

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

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

בדיקות E2E יכולות להתבצע ידנית או באמצעות אוטומציה. אחד הכלים המרכזיים בתחום הוא Playwright.

למי שרוצה להעמיק, מומלץ לקרוא את המדריך איך כותבים בדיקת E2E ראשונה עם Playwright.

בדיקות API

API הוא ממשק שבאמצעותו מערכות ורכיבי תוכנה מתקשרים זה עם זה.

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

בבדיקת API ניתן לבדוק בין היתר:

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

בדיקות API חשובות במיוחד במערכות מודרניות שבהן חלק גדול מהלוגיקה מתבצע בשירותי Backend.

בדיקות רגרסיה

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

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

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

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

בדיקות ביצועים ובדיקות עומסים

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

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

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

לדוגמה, אתר שמגיב תוך שנייה למשתמש אחד אינו בהכרח אתר שיגיב באותה מהירות כאשר 1,000 משתמשים שולחים בקשות במקביל.

בבדיקות עומסים ניתן לבחון:

• זמן תגובה.
• מספר בקשות בשנייה.
• שימוש ב-CPU.
• שימוש בזיכרון.
• שיעור שגיאות.
• יכולת התאוששות.

בדיקות יחידה – Unit Testing

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

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

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

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

בדיקות קבלה – Acceptance Testing

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

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

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

בדיקות תוכנה במערכות SAP

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

באתר קיימת סדרת מאמרים ייעודית בנושא:

• בדיקות מערכות SAP – המדריך המלא
• בדיקות SAP לפני עלייה לאוויר
• בדיקות שדרוג גרסת SAP
• שדרוג ועדכוני גרסה SAP
• הסבת נתונים ב-SAP

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

מהו Test Case?

Test Case הוא תיאור מובנה של תרחיש בדיקה.

Test Case טיפוסי יכול לכלול:

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

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

איך מדווחים על באג?

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

דיווח טוב צריך לענות על השאלות:

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

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

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

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

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

• Playwright.
• Selenium.
• Cypress.
• Postman.
• JMeter.
• כלי ניהול Test Cases.
• כלי ניהול תקלות.
• כלי CI/CD.

כבר קיימת באתר השוואה בין Playwright, Cypress ו-Selenium.

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

בדיקות ידניות מול בדיקות אוטומטיות

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

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

איך מתחילים בתחום בדיקות התוכנה?

מי שרוצה להיכנס לתחום צריך להכיר קודם את עקרונות ה-QA ולא רק כלי אחד.

בסיס טוב כולל:

• הבנת מחזור חיי תוכנה.
• היכרות עם סוגי בדיקות.
• כתיבת Test Cases.
• כתיבת דיווחי באגים.
• הבנת דרישות ואפיון.
• היכרות בסיסית עם SQL.
• הבנת HTTP ו-API.
• היכרות עם כלי ניהול בדיקות.
• הבנה בסיסית של אוטומציה.
• היכרות עם Git ותהליכי פיתוח היא יתרון.

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

Checklist בסיסי לבדיקות תוכנה

לפני סיום מחזור בדיקות ניתן להשתמש ברשימת בדיקה בסיסית:

איך לבחור אילו בדיקות לבצע?

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

הבחירה צריכה להתבסס על מספר גורמים:

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

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

מה ההבדל בין QA לבין בדיקות תוכנה?

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

בדיקות תוכנה מתמקדות בבדיקת המוצר ובזיהוי בעיות.

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

לכן QA אינו מסתכם רק בהרצת Test Cases.

בדיקות תוכנה לאורך מחזור החיים

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

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

לכן תהליך איכותי עשוי לכלול:

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

טעויות נפוצות בתהליכי בדיקות

בדיקה רק של תרחיש תקין

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

בדיקה רק של המסך

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

הסתמכות מלאה על אוטומציה

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

היעדר בדיקות רגרסיה

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

Test Cases שאינם מעודכנים

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

בדיקות תוכנה – סיכום

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

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

הסוגים המרכזיים שכדאי להכיר הם:

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

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

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

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

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