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

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

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

---

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

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

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

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

בין הסיכונים האפשריים:

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

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

---

שלב ראשון: הגדרת אסטרטגיית הבדיקות

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

אסטרטגיית הבדיקות צריכה להתייחס לפחות ל:

1. תהליכים עסקיים קריטיים.
2. מודולי SAP שנפגעים מהשדרוג.
3. התאמות ופיתוחים ייחודיים לארגון.
4. ממשקים.
5. דוחות.
6. הרשאות.
7. נתונים.
8. ביצועים.
9. תהליכי Batch.
10. אינטגרציה עם מערכות חיצוניות.
11. תהליכי סוף יום/חודש/שנה.
12. תהליכים עם השפעה כספית או רגולטורית.

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

לדוגמה:

תהליך	קריטיות	השפעת השדרוג	סוג בדיקה
יצירת הזמנה	גבוהה	גבוהה	Regression + E2E
הפקת חשבונית	גבוהה	גבוהה	פונקציונלית + אינטגרציה
דוח ניהולי	בינונית	בינונית	Regression
ממשק בנק	גבוהה	גבוהה	Integration
משתמש אדמיניסטרטיבי	נמוכה	נמוכה	Smoke

---

מה חייבים לבדוק לפני השדרוג?

1. Baseline – יצירת נקודת השוואה

אחת הפעולות החשובות ביותר לפני שדרוג היא ליצור Baseline.

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

Baseline יכול לכלול:

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

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

---

2. מיפוי תהליכים עסקיים קריטיים

לא נכון להתחיל מתפריט ה-SAP ולשאול "מה נבדוק?"

צריך להתחיל מהשאלה:

מה הארגון חייב להיות מסוגל לבצע ביום הראשון לאחר השדרוג?

לדוגמה:

תהליך מכירה

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

תהליך רכש

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

תהליך פיננסי

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

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

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

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

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

---

3. בדיקת Customizing

שדרוג SAP עלול להשפיע על הגדרות קיימות.

לכן יש לבדוק:

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

יש להשוות בין סביבת ה-Before לבין סביבת ה-After ולזהות שינויים שאינם צפויים.

---

4. בדיקת פיתוחים והתאמות Custom

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

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

למשל:

• ABAP.
• User Exits.
• BAdI.
• Enhancements.
• Forms.
• Reports.
• Interfaces.
• פונקציות ייחודיות.
• התאמות למסכים.
• תוכניות Batch.

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

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

לדוגמה:

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

גבוה: פיתוח המשפיע על תהליך רכש.

בינוני: דוח ניהולי.

נמוך: פונקציה המשמשת מספר מצומצם של משתמשים.

---

5. בדיקות נתונים

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

לכן צריך להשוות:

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

חשוב במיוחד לבצע Data Reconciliation.

לדוגמה:

יתרת חשבון לפני השדרוג = X
יתרת חשבון לאחר השדרוג = X

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

---

6. בדיקות ממשקים

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

היא עשויה לתקשר עם:

• בנקים.
• מערכות CRM.
• מערכות ביטוח.
• מערכות ERP אחרות.
• מערכות שכר.
• אתרי אינטרנט.
• אפליקציות.
• מערכות BI.
• מערכות ממשלתיות.
• מערכות ספקים.
• מערכות לקוחות.

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

יש לבדוק לא רק שהממשק "רץ", אלא גם:

1. האם הנתונים נשלחים?
2. האם הנתונים מתקבלים?
3. האם המבנה תקין?
4. האם ערכים נשמרים?
5. האם שגיאות מטופלות?
6. האם Retry עובד?
7. האם הודעות השגיאה מגיעות למקום הנכון?
8. האם נפח גדול של נתונים מטופל כראוי?

---

7. בדיקת הרשאות

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

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

יש לבדוק:

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

חשוב לבצע גם בדיקות שליליות:

מה המשתמש אינו אמור להיות מסוגל לבצע?

---

8. בדיקות דוחות

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

יש לבדוק:

• האם הדוח עולה?
• האם הוא מחזיר נתונים?
• האם הכמויות נכונות?
• האם הסכומים נכונים?
• האם הפילטרים עובדים?
• האם מיון עובד?
• האם Export עובד?
• האם הדוח רץ בזמן סביר?

בדוחות כספיים יש לבצע השוואה מול ה-Baseline.

---

9. בדיקות Batch ו-Jobs

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

לכן צריך לבדוק:

• Jobs מתוזמנים.
• Jobs ליליים.
• Jobs של סוף יום.
• Jobs של סוף חודש.
• ממשקים אוטומטיים.
• תהליכי ניקוי.
• דוחות אוטומטיים.
• תהליכי הפקת קבצים.

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

---

בדיקות לאחר השדרוג

לאחר שהשדרוג הסתיים, מתחיל שלב קריטי לא פחות: Post Upgrade Testing.

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

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

---

10. Smoke Test – בדיקה ראשונית

מיד לאחר העלייה יש לבצע Smoke Test קצר.

לדוגמה:

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

אם Smoke Test נכשל, אין טעם להתחיל מיד Regression Testing מלא.

---

11. Regression Testing

Regression Testing הוא אחד המרכיבים המרכזיים בבדיקות שדרוג SAP.

המטרה:

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

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

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

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

---

12. בדיקות E2E

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

לדוגמה:

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

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

לכן תהליכים קריטיים צריכים להיבדק מקצה לקצה.

---

13. בדיקות אינטגרציה לאחר השדרוג

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

לדוגמה:

SAP → מערכת בנק → אישור → חזרה ל-SAP.

או:

SAP → מערכת CRM → יצירת לקוח → חזרה ל-SAP.

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

---

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

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

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

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

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

---

15. בדיקות עומסים

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

לדוגמה:

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

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

---

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

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

הדגש הוא על שני כיוונים:

Positive Testing
האם המשתמש יכול לבצע את הפעולות שהוא צריך?

Negative Testing
האם המשתמש חסום מפעולות שהוא אינו אמור לבצע?

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

---

17. בדיקות תהליכים עסקיים קריטיים

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

האם העסק יכול לעבוד?

זו שאלה שונה לחלוטין מ"האם SAP עובד?"

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

לכן יש לבצע Business Validation עם משתמשי מפתח מהארגון.

---

18. בדיקות User Acceptance Testing – UAT

בשלב זה משתמשים עסקיים מבצעים תרחישים אמיתיים.

לדוגמה:

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

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

---

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

יש לבצע Data Validation גם לאחר השדרוג.

מומלץ להגדיר מראש רשימת נתונים להשוואה:

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

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

---

20. בדיקות לאחר Go Live

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

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

יש לעקוב אחר:

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

זהו למעשה שלב של Production Validation.

---

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

לא כל תקלה צריכה לעצור Go Live.

לכן יש להגדיר מראש מנגנון Severity.

לדוגמה:

Severity 1 – קריטי

המערכת או תהליך עסקי קריטי אינם זמינים.

בדרך כלל: אין אישור ל-Go Live.

Severity 2 – גבוה

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

בדרך כלל: נדרש פתרון או Workaround מאושר.

Severity 3 – בינוני

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

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

Severity 4 – נמוך

בעיה קוסמטית או בעלת השפעה מוגבלת.

בדרך כלל: אינה מונעת Go Live.

---

צ'קליסט בדיקות שדרוג SAP

אפשר להשתמש ברשימה הבאה כבסיס לצ'קליסט:

לפני השדרוג

• הגדרת Scope.
• זיהוי תהליכים קריטיים.
• יצירת Baseline.
• מיפוי מודולים.
• מיפוי פיתוחי Custom.
• מיפוי ממשקים.
• מיפוי Jobs.
• מיפוי דוחות.
• מיפוי הרשאות.
• הגדרת נתוני השוואה.
• הכנת תרחישי Regression.
• הכנת תרחישי E2E.
• הכנת תרחישי Integration.
• הכנת תרחישי UAT.
• הגדרת Severity.
• הגדרת Exit Criteria.

מיד לאחר השדרוג

• Login.
• Smoke Test.
• בדיקת משתמשים.
• בדיקת הרשאות.
• בדיקת טרנזקציות מרכזיות.
• בדיקת נתונים.
• בדיקת ממשקים.
• בדיקת Jobs.
• בדיקת דוחות.

לפני Go Live

• Regression הושלם.
• E2E הושלם.
• Integration הושלם.
• UAT הושלם.
• נתונים אומתו.
• ביצועים נבדקו.
• תקלות קריטיות נסגרו.
• Workarounds אושרו.
• משתמשי מפתח אישרו את התהליכים.
• Exit Criteria התקיימו.

לאחר Go Live

• ניטור מוגבר.
• בדיקת תהליכים קריטיים.
• בדיקת ממשקים.
• בדיקת Jobs.
• בדיקת ביצועים.
• מעקב אחר תקלות משתמשים.
• השוואת נתונים.
• מעקב אחר תקלות Production.
• סיכום Post Go Live.

---

אוטומציה בבדיקות שדרוג SAP

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

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

כלים מודרניים כמו Playwright יכולים להשתלב בבדיקות של ממשקי Web כאשר הארכיטקטורה והתשתית מתאימות לכך. למי שמעוניין להעמיק בתחום, כדאי לקרוא את Playwright למתחילים – 20 דברים שחייבים לדעת, וכן את ההשוואה Playwright לעומת Cypress לעומת Selenium.

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

---

הטעות הגדולה: לבדוק רק את מה שהשתנה

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

הגישה:

"המודול הזה לא השתנה, אז אין צורך לבדוק אותו."

עלולה להיות בעייתית.

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

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

---

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

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

הפתרון הוא Risk-Based Testing.

במקום לשאול:

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

שואלים:

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

ומדרגים את הבדיקות לפי:

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

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

---

שילוב בדיקות עומק לשינויים משמעותיים

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

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

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

---

ומה לגבי Go Live?

החלטה על Go Live אינה צריכה להתבסס על המשפט:

"רוב הבדיקות עברו."

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

לדוגמה:

Go Live אפשרי כאשר:

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

כך החלטת Go Live הופכת מהחלטה אינטואיטיבית להחלטה המבוססת על ראיות.

---

סיכום

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

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

לאחר השדרוג יש לבצע שילוב של:

• Smoke Testing.
• Regression Testing.
• בדיקות E2E.
• בדיקות Integration.
• בדיקות נתונים.
• בדיקות הרשאות.
• בדיקות ביצועים.
• בדיקות Batch.
• UAT.
• Production Validation.

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

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

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

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

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