שדרוג מערכת SAP הוא אחד הפרויקטים המורכבים ביותר שארגון יכול לבצע במערכות המידע שלו. גם כאשר מטרת השדרוג נראית פשוטה – מעבר לגרסה חדשה, התקנת Support Package, עדכון רכיב או מעבר ל־S/4HANA שהוא אירוע גדול מאוד מאוד – בפועל מדובר בשינוי שעלול להשפיע על תהליכים עסקיים, ממשקים, הרשאות, נתונים, דוחות, אינטגרציות ופיתוחים קיימים.
זו בדיוק הסיבה שבדיקות תוכנה במהלך שדרוג SAP אינן יכולות להיות "עוד סבב בדיקות" לפני העלייה לייצור.
הן צריכות להיות חלק בלתי נפרד מתהליך השדרוג כולו.
באתר כבר קיים מדריך רחב בנושא בדיקות SAP – המדריך המעשי לבדיקת מערכות שלמות, ולכן במאמר הזה נתמקד בשאלה המעשית יותר: איך בונים אסטרטגיית בדיקות נכונה כאשר מערכת SAP עוברת שדרוג או עדכון גרסה?
למה שדרוג SAP מחייב אסטרטגיית בדיקות מיוחדת?
במערכת רגילה אפשר לעיתים לבודד את הרכיב שהשתנה ולבדוק אותו.
ב־SAP התמונה מורכבת הרבה יותר.
שינוי ברכיב אחד יכול להשפיע על תהליך עסקי שלם.
לדוגמה:
הזמנת לקוח → בדיקת אשראי → משלוח → חשבונית → הנהלת חשבונות → גבייה → דוח פיננסי
אם עדכון גרסה משנה התנהגות באחד השלבים, ייתכן שהבעיה תתגלה רק בשלבים מאוחרים יותר.
לכן בדיקות שדרוג SAP צריכות לבחון לא רק:
"האם הפונקציה החדשה עובדת?"
אלא גם:
"האם כל מה שעבד לפני השדרוג עדיין עובד עכשיו?"
זו למעשה המשמעות של Regression Testing בסביבת SAP.
מה יכול להשתנות בעקבות שדרוג SAP?
שדרוג גרסה אינו בהכרח שינוי פונקציונלי שהמשתמש העסקי רואה מיד.
השינוי יכול להופיע ברמות שונות:
1. פונקציונליות
תפריטים, מסכים, שדות, תהליכים עסקיים והתנהגות של טרנזקציות יכולים להשתנות.
2. בסיס הנתונים
מבנה טבלאות, שדות, אינדקסים או אופן הגישה לנתונים עשויים להשתנות בהתאם לסוג השדרוג והארכיטקטורה.
3. ממשקים
מערכת SAP כמעט אף פעם אינה פועלת לבדה.
היא עשויה להיות מחוברת ל:
- מערכות CRM
- מערכות ביטוח
- מערכות בנקאיות
- מערכות שכר
- מערכות BI
- מערכות ניהול מסמכים
- APIs
- מערכות צד שלישי
- פורטלים ואפליקציות
לכן כל ממשק כזה הוא נקודת בדיקה.
למי שרוצה להעמיק בנושא, באתר קיים גם המדריך המקיף לבדיקות API.
4. הרשאות
שדרוג עלול להשפיע על Roles, הרשאות, גישה לטרנזקציות או התנהגות של משתמשים.
לכן לא מספיק לבדוק שמשתמש Admin מצליח לבצע פעולה.
צריך לבדוק גם משתמשים בעלי הרשאות מוגבלות.
5. ביצועים
גם אם כל הפונקציות עובדות, ייתכן שתהליך שבעבר הסתיים בתוך מספר שניות הפך לאיטי משמעותית.
בסביבת ERP ארגונית, שינוי כזה יכול להפוך לבעיה עסקית.
שלושת שלבי הבדיקה של שדרוג SAP
אפשר לחלק את אסטרטגיית הבדיקות לשלושה שלבים מרכזיים:
- לפני השדרוג
- במהלך השדרוג
- אחרי השדרוג
הטעות הנפוצה היא להשקיע כמעט את כל המאמץ בשלב השלישי.
בפועל, ככל שההכנה טובה יותר לפני השדרוג, כך קטן הסיכון בזמן העלייה לייצור.
שלב ראשון: בדיקות לפני השדרוג
לפני שמתחילים לשדרג, צריך להבין מה בדיוק עומד להשתנות.
מיפוי המערכת
השלב הראשון הוא יצירת תמונת מצב של המערכת הקיימת.
יש למפות:
- מודולים
- תהליכים עסקיים
- ממשקים
- פיתוחים
- דוחות
- Jobs
- הרשאות
- משתמשים
- אינטגרציות
- מערכות חיצוניות
- תהליכים קריטיים
המטרה היא ליצור Baseline.
כלומר:
איך המערכת מתנהגת היום, לפני השינוי?
בלי Baseline קשה מאוד לדעת לאחר השדרוג אם משהו באמת התקלקל.
יצירת Test Inventory
אחת השיטות היעילות ביותר היא ליצור רשימת בדיקות מרכזית.
לדוגמה:
| תחום | תהליך | חשיבות | סוג בדיקה |
|---|---|---|---|
| כספים | יצירת חשבונית | גבוהה | Functional |
| רכש | יצירת הזמנה | גבוהה | Regression |
| מכירות | יצירת Sales Order | גבוהה | E2E |
| משתמשים | Login | גבוהה | Smoke |
| ממשקים | שליחת נתונים | גבוהה | API |
| דוחות | הפקת דוח | בינונית | Regression |
| Jobs | הרצת Job לילי | גבוהה | Integration |
הרשימה הזו הופכת את תהליך השדרוג למשהו שניתן למדוד ולנהל.
אילו בדיקות לבצע לפני השדרוג?
Functional Testing
בודקים שהתהליכים העסקיים הקיימים עובדים בצורה תקינה.
לדוגמה:
- יצירת לקוח
- יצירת הזמנה
- אישור הזמנה
- יצירת חשבונית
- ביטול מסמך
- החזר כספי
- תהליך רכש
- תשלום
- הפקת דוח
Regression Testing
זהו אחד מסוגי הבדיקות החשובים ביותר בשדרוג SAP.
המטרה היא לא לבדוק רק את מה שהשתנה, אלא לוודא שמה שכבר עבד – עדיין עובד.
במקום לשאול:
מה חדש בגרסה?
צריך לשאול:
מה עלול להישבר בגלל הגרסה החדשה?
זו חשיבה שונה לחלוטין.
Risk-Based Testing בשדרוג SAP
אי אפשר תמיד להריץ מאות או אלפי בדיקות.
לכן צריך לתעדף.
אפשר לתת לכל תהליך ציון המבוסס על:
Business Impact × Probability of Failure × Complexity
לדוגמה:
| תהליך | השפעה עסקית | מורכבות | עדיפות |
|---|---|---|---|
| שכר | גבוהה | גבוהה | קריטית |
| חשבוניות | גבוהה | בינונית | גבוהה |
| דוח פנימי | נמוכה | נמוכה | נמוכה |
| Login | גבוהה | נמוכה | גבוהה |
כך צוות ה־QA לא מבזבז את רוב הזמן על בדיקות בעלות סיכון נמוך.
בדיקות עומק לשינויים במערכת SAP
שדרוג משמעותי מחייב מעבר לבדיקות פונקציונליות בסיסיות.
כדאי לשלב גם בדיקות עומק.
באתר קיים מאמר בנושא איך לבצע בדיקות עומק לשינויים במערכות.
במקרה של SAP, בדיקות עומק יכולות לכלול:
- נתונים היסטוריים
- תהליכים חריגים
- משתמשים מיוחדים
- תרחישי קצה
- מסמכים ישנים
- אינטגרציות
- הרשאות
- Jobs
- ביצועים
- התאמות בין מערכות
בדיקות בזמן השדרוג
במהלך השדרוג עצמו, תפקיד ה־QA אינו בהכרח להריץ Test Cases.
בשלב הזה יש חשיבות גדולה ל־Monitoring ולווידוא שהמעבר מתבצע בהתאם לתוכנית.
צריך לבדוק:
- האם כל שלבי ההתקנה הסתיימו?
- האם קיימות שגיאות?
- האם קיימות תקלות Migration?
- האם כל השירותים זמינים?
- האם הממשקים פעילים?
- האם ה־Jobs חזרו לפעילות?
- האם קיימות שגיאות במערכת?
- האם יש שינוי משמעותי בזמני תגובה?
שלב שלישי: בדיקות לאחר השדרוג
זהו השלב הקריטי.
לאחר שהמערכת עולה, לא רצים מיד לכל הבדיקות.
מתחילים ב־Smoke Testing.
המטרה היא לענות על שאלה פשוטה:
האם המערכת בכלל יציבה מספיק כדי להתחיל בדיקות מלאות?
Smoke Testing לאחר שדרוג
סבב Smoke יכול לכלול:
- התחברות למערכת
- פתיחת מסכים מרכזיים
- הרצת טרנזקציה מרכזית
- יצירת מסמך
- שמירת נתונים
- בדיקת הרשאות
- בדיקת ממשק מרכזי
- בדיקת Job קריטי
- הפקת דוח מרכזי
אם אחד מהתהליכים הקריטיים נכשל, אין טעם להמשיך מיד לאלפי בדיקות Regression.
באתר קיים גם מדריך בנושא Smoke Testing בעולם ה־FinTech.
Regression Testing – הלב של בדיקות SAP
לאחר שה־Smoke עבר בהצלחה, מתחילים Regression Testing.
כאן צריך לבדוק את התהליכים המרכזיים שהמערכת ביצעה לפני השדרוג.
לדוגמה, בארגון שעובד עם תהליכי מכירות:
Customer → Sales Order → Delivery → Invoice → Accounting
לא מספיק לבדוק שכל מסך בנפרד עובד.
צריך לוודא שהתהליך כולו עובד.
E2E Testing במערכת SAP
כאן נכנסות לתמונה בדיקות End-to-End.
במקום לבדוק:
האם יצירת הזמנה עובדת?
בודקים:
האם לקוח יכול לבצע את כל התהליך העסקי מתחילתו ועד סופו?
לדוגמה:
יצירת לקוח → יצירת הזמנה → אישור → משלוח → חיוב → רישום חשבונאי
זו בדיקה בעלת ערך עסקי גבוה בהרבה.
למי שרוצה להעמיק, באתר קיים מדריך E2E Testing – מה זה ואיך מבצעים בדיקות מקצה לקצה.
בדיקות ממשקים – המקום שבו הרבה שדרוגים נכשלים
מערכת SAP בדרך כלל מחוברת לעשרות מערכות.
לכן אחרי שדרוג חובה לבדוק את זרימת המידע בין המערכות.
לדוגמה:
SAP → API → מערכת חיצונית
או:
מערכת חיצונית → API → SAP
צריך לבדוק:
- האם ההודעה נשלחת?
- האם היא מתקבלת?
- האם הנתונים נכונים?
- האם פורמט הנתונים נשמר?
- מה קורה במקרה של שגיאה?
- האם Retry עובד?
- האם נוצרות כפילויות?
- האם המערכת מתמודדת עם Timeout?
בדיקות נתונים – לא פחות חשובות מהמסכים
אחת הטעויות הגדולות היא להתמקד במה שהמשתמש רואה.
שדרוג SAP יכול להשאיר את המסכים תקינים לחלוטין כאשר הנתונים מאחוריהם אינם תקינים.
לכן צריך לבצע גם Data Validation.
לדוגמה:
לפני השדרוג
לקוחות: 125,430
אחרי השדרוג
לקוחות: 125,430
זה סימן חיובי – אבל לא מספיק.
צריך לבדוק גם:
- רשומות
- סכומים
- תאריכים
- סטטוסים
- קשרים בין טבלאות
- מסמכים
- נתוני Master
- נתוני Transaction
בדיקת הרשאות לאחר שדרוג
הרשאות הן תחום שקל מאוד לשכוח.
צריך לבדוק משתמשים מסוגים שונים:
- משתמש רגיל
- מנהל
- משתמש פיננסי
- משתמש תפעולי
- משתמש קריאה בלבד
- משתמש טכני
- משתמש מערכת
השאלה אינה רק:
האם המשתמש יכול להיכנס?
אלא:
האם המשתמש יכול לבצע בדיוק את הפעולות שהוא אמור לבצע – ולא מעבר לכך?
בדיקות ביצועים
שדרוג SAP הוא הזדמנות מצוינת לבצע השוואת ביצועים.
כדאי למדוד לפני ואחרי:
| פעולה | לפני השדרוג | אחרי השדרוג |
|---|---|---|
| Login | 2 שניות | 2.5 שניות |
| פתיחת מסך | 1.5 שניות | 2 שניות |
| יצירת מסמך | 3 שניות | 4 שניות |
| הפקת דוח | 20 שניות | 35 שניות |
| ממשק | 5 שניות | 7 שניות |
המספרים עצמם פחות חשובים מהשינוי.
אם פעולה קריטית הפכה לאיטית משמעותית, צריך להבין מדוע.
אוטומציה בבדיקות SAP
ככל שהמערכת גדולה יותר, קשה יותר לבצע Regression מלא באופן ידני.
לכן אוטומציה יכולה להפוך לכלי משמעותי.
עם זאת, לא צריך להפוך כל Test Case לאוטומטי.
עדיף להתחיל מתהליכים:
- קריטיים
- חוזרים
- יציבים
- בעלי נפח גבוה
- בעלי ערך עסקי משמעותי
לדוגמה:
Login → יצירת מסמך → שמירה → בדיקת תוצאה
אם קיימת תשתית אוטומציה, אפשר להריץ את הבדיקות בכל סביבת QA לאחר כל Build או שינוי משמעותי.
Playwright ו־SAP – האם אפשר לשלב?
כאשר קיימים ממשקים מבוססי Web סביב SAP, כלי אוטומציה מודרניים יכולים להשתלב בחלק מתרחישי הבדיקה.
באתר קיים מדריך Playwright למתחילים.
בנוסף, מי שמתלבט בין כלי אוטומציה שונים יכול לקרוא את ההשוואה בין Playwright, Cypress ו־Selenium.
הבחירה בכלי תלויה בארכיטקטורה של המערכת, בממשק הנבדק וביכולת התחזוקה של תשתית האוטומציה.
Continuous Testing בשדרוגי SAP
ארגונים שמבצעים עדכונים בתדירות גבוהה יכולים להפיק תועלת מגישה של Continuous Testing.
במקום לחכות לשדרוג גדול ואז לבצע "פרויקט בדיקות", הבדיקות הופכות לחלק מתהליך הפיתוח וה־Delivery.
הגישה יכולה להיראות כך:
Change → Build → Automated Tests → Integration Tests → Regression → Deployment
באתר קיים מאמר ייעודי בנושא Continuous Testing – 10 דברים שחשוב לדעת.
מתי לעצור את העלייה לייצור?
אחד הנושאים החשובים ביותר בתהליך הוא Definition of Done.
לא מספיק לומר:
"רוב הבדיקות עברו."
צריך להגדיר מראש תנאי Go/No-Go.
לדוגמה:
Go
- כל תהליכי ה־Critical עברו
- אין תקלות Severity 1
- אין תקלות Severity 2 פתוחות ללא אישור
- הממשקים הקריטיים תקינים
- הרשאות תקינות
- נתונים אומתו
- Smoke עבר
- Regression קריטי עבר
- בעלי התהליך העסקי אישרו
No-Go
אם קיימת תקלה קריטית שמשפיעה על תהליך עסקי מרכזי – אין לעלות רק בגלל שהגענו לתאריך.
מה עושים ביום העלייה לייצור?
ביום ה־Go-Live מומלץ לעבוד לפי Runbook מסודר.
לדוגמה:
T-60
- בדיקת זמינות
- בדיקת שירותים
- בדיקת בסיס נתונים
- בדיקת ממשקים
T+15
- Login
- Smoke Test
- בדיקת תהליך קריטי
T+30
- בדיקת מסמכים
- בדיקת ממשקים
T+60
- תהליכים עסקיים מרכזיים
T+120
- Regression ראשוני
סוף היום
- בדיקת Jobs
- בדיקת Logs
- בדיקת ממשקים
- בדיקת תקלות
- אישור Business
מהי הטעות הגדולה ביותר בבדיקות שדרוג SAP?
הטעות הגדולה ביותר היא לחשוב שהבדיקות הן באחריות צוות ה־QA בלבד.
שדרוג SAP הוא פרויקט עסקי וטכנולוגי.
צריך שיתוף פעולה בין:
- QA
- מפתחים
- SAP Basis
- צוותי אינטגרציה
- אנשי אבטחת מידע
- מנהלי מערכת
- משתמשים עסקיים
- בעלי תהליכים
- מנהלי פרויקט
QA יכול לזהות שהמערכת אינה מתנהגת כמצופה.
אבל רק בעל התהליך העסקי יכול לקבוע אם ההתנהגות מקובלת מבחינה עסקית.
Checklist לבדיקות שדרוג SAP
לפני סיום השדרוג, כדאי לעבור על הרשימה הבאה:
לפני השדרוג
☐ מיפוי תהליכים
☐ מיפוי ממשקים
☐ מיפוי הרשאות
☐ יצירת Test Inventory
☐ הגדרת תהליכים קריטיים
☐ יצירת Baseline
☐ הכנת נתוני בדיקה
☐ הכנת Test Environment
בזמן השדרוג
☐ Monitoring
☐ בדיקת Logs
☐ בדיקת Migration
☐ בדיקת שירותים
☐ בדיקת ממשקים
☐ תיעוד חריגות
לאחר השדרוג
☐ Smoke Testing
☐ Functional Testing
☐ Regression Testing
☐ E2E Testing
☐ API Testing
☐ Integration Testing
☐ Data Validation
☐ Security Testing
☐ Authorization Testing
☐ Performance Testing
לפני Go-Live
☐ אין תקלות קריטיות
☐ תהליכים עסקיים קריטיים עברו
☐ ממשקים תקינים
☐ נתונים אומתו
☐ הרשאות נבדקו
☐ Business Approval
☐ Go/No-Go התקבל
סיכום
בדיקות תוכנה במהלך שדרוג ועדכוני גרסה של SAP הן הרבה יותר מבדיקה של כמה מסכים וטרנזקציות.
הן צריכות לבדוק את המערכת כמכלול.
הגישה הנכונה היא לבנות שכבות:
Baseline → Smoke → Functional → Regression → Integration → API → E2E → Data → Security → Performance
הדגש החשוב ביותר הוא לא לבדוק רק את מה שהשתנה.
צריך לבדוק גם את כל מה שעלול להיפגע בגלל השינוי.
וזה ההבדל בין בדיקת גרסה חדשה לבין ניהול סיכון אמיתי בשדרוג מערכת SAP.
כאשר צוות ה־QA מתחיל את העבודה כבר בשלב התכנון, ממפה את התהליכים הקריטיים, בונה Regression Suite, משלב אוטומציה במקומות המתאימים ומגדיר מראש קריטריוני Go/No-Go – הסיכוי להפתעות לאחר העלייה לייצור יורד משמעותית.
בסופו של דבר, המטרה של בדיקות SAP אינה להוכיח שהגרסה החדשה עובדת.
המטרה היא להוכיח שהעסק יכול להמשיך לעבוד בבטחה גם אחרי השינוי.
לקרוא מאמרים זה נחמד אבל לא יביא אותך לתוצאה שאתה רוצה, בדיוק בשביל זה הכנו עבורך את הקורס הדיגיטלי המהיר, תוך שעתיים וחצי תלמד את תחום הבדיקות ידניות, תוכל להתחיל לעבוד מהבית דרך FIVERR או ולהתכונן נכון לראיונות עבודה שיעזרו לך לצלוח אותם. כנס כאן הקורס ממוקד בבדיקות תוכנה ידניות הנותן בסיס חזק לתחום.
לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן
TesQA 