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

SAP היא לא אחת מהן.

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

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

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

זו הסיבה שבעיניי בדיקות SAP הן הרבה יותר מבדיקת מסכים.

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

מה זה בכלל SAP Testing?

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

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

בפועל, המטרה היא לענות על שאלה פשוטה:

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

לדוגמה, בחברת ביטוח יכול להיות תהליך שבו:

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

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

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

למה בדיקות SAP מורכבות יותר מבדיקת מערכת רגילה?

אחת הסיבות המרכזיות היא שמערכת SAP בדרך כלל אינה עומדת לבדה.

היא יכולה להיות מחוברת ל:

• מערכות CRM
• מערכות פיננסיות
• מערכות שכר
• מערכות ביטוח
• מערכות ניהול מלאי
• מערכות רכש
• מערכות BI
• מערכות תשלומים
• APIs
• מערכות צד שלישי
• מסדי נתונים
• מערכות Legacy

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

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

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

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

אין בדיקת SAP אחת.

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

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

אלה הבדיקות הבסיסיות ביותר.

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

לדוגמה:

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

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

השאלה היא:

האם הפעולה גרמה לתוצאה העסקית הנכונה?

2. בדיקות אינטגרציה ב-SAP

זה אחד התחומים החשובים ביותר במערכות SAP.

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

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

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

לדוגמה:

מערכת מקור
    ↓
API / Interface
    ↓
SAP
    ↓
עיבוד עסקי
    ↓
מסד נתונים
    ↓
מערכת יעד

כל חץ בתרשים הזה הוא נקודת בדיקה.

3. בדיקות End-to-End ב-SAP

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

לדוגמה:

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

זו למעשה בדיקת E2E.

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

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

4. בדיקות רגרסיה ב-SAP

ככל שמערכת SAP ותיקה ומורכבת יותר, בדיקות רגרסיה הופכות לקריטיות.

הרעיון פשוט:

בדקנו שינוי חדש – אבל האם משהו שהיה תקין לפני השינוי עדיין עובד?

נניח ששינינו תהליך חיוב.

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

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

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

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

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

5. בדיקות הרשאות ואבטחה

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

צריך לבדוק לא רק:

האם המשתמש יכול לבצע פעולה?

אלא גם:

האם המשתמש שלא אמור לבצע אותה באמת לא יכול?

לדוגמה:

משתמש רגיל → יכול לצפות.

מנהל → יכול לאשר.

משתמש פיננסי → יכול לבצע פעולה פיננסית.

משתמש ללא הרשאה → לא אמור להיות מסוגל לבצע אותה.

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

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

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

ב-SAP כדאי לבחון בין היתר:

• זמני תגובה
• עומס משתמשים
• Jobs
• Batch Processing
• זמני עיבוד
• עומס על ממשקים
• זמני שליפת נתונים
• תהליכים שרצים במקביל

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

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

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

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

לפני שדרוג כולם שואלים:

"מה השתנה?"

אבל בעיניי זו לא השאלה היחידה.

צריך לשאול גם:

"מה אסור לנו שיישבר?"

וזה הבדל עצום.

איך מתכננים בדיקות לשדרוג SAP?

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

לא מרשימת הטרנזקציות.

לדוגמה:

תהליך מכירה

לקוח → הזמנה → אספקה → חשבונית → תשלום.

תהליך רכש

בקשת רכש → הזמנה → קבלה → חשבונית → תשלום.

תהליך פיננסי

מסמך → חשבונאות → התאמה → דיווח.

תהליך משאבי אנוש

עובד → שינוי נתונים → חישוב → שכר → דיווח.

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

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

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

שכבה ראשונה – Smoke Test

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

האם בכלל אפשר להתחיל לעבוד?

לדוגמה:

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

אם ה-Smoke Test נכשל – אין טעם להמשיך מיד לאלפי בדיקות.

שכבה שנייה – בדיקות פונקציונליות

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

שכבה שלישית – Regression

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

שכבה רביעית – Integration

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

שכבה חמישית – End-to-End

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

הסבת נתונים ב-SAP – אחד המקומות שבהם אסור להתפשר

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

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

אבל השאלה היא:

האם הנתונים עברו נכון?

לא רק האם "עברו".

מה בודקים בהסבת נתונים?

נניח שיש לנו:

100,000 לקוחות במערכת הישנה.

אחרי ההסבה אנחנו מצפים ל:

100,000 לקוחות במערכת החדשה.

אבל בדיקת כמות בלבד אינה מספיקה.

צריך לבדוק:

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

דוגמה פשוטה לבדיקת Data Migration

נניח שבמערכת הישנה:

Customer ID: 12345
Name: ישראל ישראלי
Status: Active
Balance: 12,500

אחרי ההסבה:

Customer ID: 12345
Name: ישראל ישראלי
Status: Active
Balance: 12,500

נראה תקין.

אבל מה אם:

• ה-Balance עבר ללא ספרה?
• התאריך השתנה?
• הסטטוס הוחלף?
• השדה הפך ל-null?
• נוצרה כפילות?

לכן הסבת נתונים דורשת Data Validation, ולא רק בדיקת טעינה.

Reconciliation – התאמת נתונים

זה אחד הכלים החשובים ביותר בבדיקות הסבה.

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

לדוגמה:

אבל גם כאן חשוב לא לעצור בסיכומים.

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

בדיקות ממשקים – אל תסתכל רק על SAP

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

היא לא.

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

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

לדוגמה:

CRM
 ↓
API
 ↓
SAP
 ↓
Processing
 ↓
Financial System
 ↓
BI

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

מה קורה כאשר ממשק נכשל?

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

לדוגמה:

• מערכת המקור לא זמינה
• API מחזיר Error
• שדה חובה חסר
• נשלח ערך לא חוקי
• נשלחת רשומה כפולה
• מגיע מידע בפורמט שגוי
• התהליך נקטע באמצע
• יש Timeout

ואז צריך לשאול:

איך SAP מתנהגת?

האם היא:

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

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

איך לבנות Test Strategy לפרויקט SAP?

אם הייתי צריך להתחיל היום פרויקט בדיקות SAP, הייתי מתחיל לא מה-Test Cases אלא מהסיכונים.

הייתי שואל:

מה התהליך העסקי הכי קריטי?

איזה מידע אסור לאבד?

איזה ממשק הכי מסוכן?

איזה שינוי הכי גדול בוצע?

אילו תהליכים תלויים בשינוי?

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

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

Traceability – הקשר בין דרישה לבדיקה

בפרויקטים גדולים חשוב לדעת:

איזו דרישה נבדקה באיזה Test Case ומה הייתה התוצאה?

לדוגמה:

Requirement
     ↓
Business Process
     ↓
Test Scenario
     ↓
Test Case
     ↓
Test Result
     ↓
Defect

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

בפרויקט SAP משמעותי זה יכול לעשות הבדל גדול במיוחד לפני Go-Live.

איך להשתמש באוטומציה בבדיקות SAP?

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

האם אפשר לבצע אוטומציה גם ב-SAP?

בהחלט.

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

כדאי להתחיל מתהליכים שהם:

• קריטיים
• חוזרים על עצמם
• יציבים
• בעלי נתונים נשלטים
• בעלי ערך גבוה לרגרסיה

לדוגמה:

Login
↓
יצירת לקוח
↓
יצירת עסקה
↓
בדיקת חישוב
↓
יצירת מסמך
↓
בדיקת תוצאה

אם התרחיש הזה רץ בכל Regression Cycle, אוטומציה יכולה להיות השקעה מצוינת.

מה לא הייתי הופך לאוטומציה?

לא כל תהליך מתאים.

אם מדובר בתהליך:

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

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

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

לא שואלים "מה אפשר לאוטמט?" אלא "מה משתלם לאוטמט?"

בדיקות SAP לפני Go-Live

רגע ה-Go-Live הוא אחד הרגעים שבהם הלחץ בפרויקט עולה משמעותית.

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

לדוגמה:

חובה לבדוק

• כניסה למערכת
• משתמשים והרשאות
• תהליכים עסקיים קריטיים
• ממשקים
• נתונים
• דוחות
• תהליכים פיננסיים
• Jobs
• Batch Processes
• תהליכים יומיים
• תהליכים חודשיים
• תהליכי סוף חודש

ובעיניי יש עוד בדיקה חשובה:

מה קורה אם משהו משתבש?

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

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

בדיקות Post Go-Live

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

להפך.

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

לדוגמה:

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

אני אוהב לחשוב על התקופה הזו כעל Hypercare של QA.

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

אנחנו מחפשים באופן יזום סימנים לכך שמשהו השתבש.

הטעויות הנפוצות ביותר בבדיקות SAP

טעות 1: לבדוק רק את המסך

מסך תקין לא אומר שתהליך תקין.

טעות 2: להתמקד רק בשינוי

שינוי קטן יכול להשפיע על תהליכים שלא השתנו.

טעות 3: לבדוק רק תרחישים חיוביים

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

מה קורה כאשר משהו לא תקין?

טעות 4: להסתמך רק על כמות הנתונים

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

טעות 5: להזניח ממשקים

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

טעות 6: לבצע אוטומציה לפני שמייצבים את התהליך

אוטומציה של תהליך לא יציב מייצרת הרבה תחזוקה ומעט ביטחון.

טעות 7: לשכוח תהליכים תקופתיים

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

קל מאוד לפספס אותם ב-Sprint רגיל.

Checklist קצר לבדיקות SAP

לפני שאני סוגר פרויקט או שינוי משמעותי, הייתי רוצה להיות מסוגל לענות "כן" על רוב השאלות הבאות:

• האם בדקנו את התהליכים העסקיים הקריטיים?
• האם ביצענו Regression?
• האם בדקנו אינטגרציות?
• האם בדקנו הרשאות?
• האם בדקנו תרחישים שליליים?
• האם בדקנו נתונים?
• האם ביצענו Reconciliation?
• האם בדקנו Jobs ו-Batch Processes?
• האם בדקנו ביצועים?
• האם בדקנו תהליכי סוף יום/חודש?
• האם בדקנו תהליכי E2E?
• האם בדקנו את המערכת לאחר השינוי בסביבה הקרובה לייצור?
• האם קיימת תוכנית בדיקות לאחר Go-Live?

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

איך אני חושב על בדיקות SAP?

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

אפשר להגיע ל-5,000 Test Cases ועדיין לפספס תקלה קריטית.

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

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

מה הכי חשוב לעסק?

מה הכי מסוכן?

מה הכי סביר שיישבר בעקבות השינוי?

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

סיכום: בדיקות SAP הן בדיקות של מערכת – אבל בעיקר של העסק

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

צריך לחשוב על:

• בדיקות פונקציונליות
• בדיקות אינטגרציה
• בדיקות E2E
• בדיקות רגרסיה
• בדיקות הרשאות
• בדיקות ביצועים
• שדרוגי גרסה
• הסבת נתונים
• התאמות נתונים
• ממשקים
• אוטומציה
• בדיקות Post Go-Live

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

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

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

הוא רוצה שהעבודה שלו תסתיים.

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

הכסף צריך להגיע למקום הנכון.

הנתונים צריכים להיות מדויקים.

והארגון צריך להמשיך לעבוד.

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

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

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

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