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

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

כאן נכנסות לתמונה בדיקות רגרסיה (Regression Testing).

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

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

מהי בדיקת רגרסיה ב־SAP?

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

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

הפיתוח החדש קשור לתהליך הזמנות הרכש.

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

אבל שינוי ברכיב מסוים עלול להשפיע גם על:

יצירת הזמנת רכש
קבלת סחורה
חשבוניות
FI
הרשאות
ממשקים למערכות חיצוניות
דוחות
Workflow
Batch Jobs
נתונים שמועברים למערכות אחרות

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

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

זה ההבדל בין בדיקה ממוקדת של שינוי לבין בדיקת רגרסיה.

למה בדיקות רגרסיה קריטיות במיוחד ב־SAP?

מערכת SAP היא מערכת אינטגרטיבית.

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

לדוגמה:

Sales Order → Delivery → Goods Issue → Billing → FI

בעיה בשלב אחד יכולה להתגלות בכלל בשלב אחר.

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

בנוסף, במערכות SAP ותיקות קיימות לעיתים התאמות רבות שנבנו לאורך שנים:

User Exits
BAdIs
Enhancements
Z Programs
Forms
Interfaces
Customizing
Reports
Workflows
Batch Jobs

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

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

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

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

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

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

בדיקות רגרסיה מסתכלות על התמונה הרחבה יותר:

האם הדברים שכבר עבדו לפני השינוי עדיין עובדים?

מתי צריך לבצע בדיקות רגרסיה?

לא רק בשדרוג גדול.

כדאי לבצע רגרסיה גם לאחר:

שדרוג גרסה

למשל מעבר לגרסת SAP חדשה או מעבר מ־ECC ל־S/4HANA.

התקנת Support Package

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

שינוי Customizing

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

שינוי ABAP

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

שינוי ממשק

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

שינוי הרשאות

הרשאה חדשה או שינוי Role יכולים לגרום למשתמש לא להיות מסוגל להשלים תהליך שהיה תקין.

הסבת נתונים

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

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

איך בונים תוכנית רגרסיה ל־SAP?

הטעות הנפוצה היא לפתוח את מערכת ה־Test ולשאול:

"מה כדאי לבדוק?"

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

שלב 1: מיפוי התהליכים הקריטיים

ראשית יש לזהות אילו תהליכים אסור לארגון לאבד.

לדוגמה:

FI

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

MM

יצירת דרישת רכש
יצירת PO
קבלת סחורה
קליטת חשבונית
החזרת סחורה

SD

יצירת הזמנה
בדיקת זמינות
משלוח
Goods Issue
חיוב לקוח

HR

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

WM / EWM

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

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

שלב 2: יצירת Business Process Inventory

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

לדוגמה:

תהליך	מודול	קריטיות	ממשקים	רגרסיה
Order to Cash	SD/FI	גבוהה	CRM, בנקים	חובה
Procure to Pay	MM/FI	גבוהה	ספקים	חובה
סגירת חודש	FI	גבוהה מאוד	BI	חובה
קליטת עובד	HR	בינונית	Payroll	כן
דוח פנימי	FI	נמוכה	אין	לפי סיכון

כך ניתן להחליט בצורה מושכלת מה נכנס ל־Regression Suite.

שלב 3: זיהוי התלות בשינוי

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

נניח שבוצע שינוי ב־MM.

אפשר להגדיר:

Impact גבוה:

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

Impact בינוני:

דוחות מלאי
ממשקי BI

Impact נמוך:

תהליכים שאינם משתמשים ברכיבים שהשתנו

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

שלב 4: בחירת תרחישי בדיקה

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

לדוגמה, במקום לבדוק:

VA01 עובדת.

עדיף לבדוק:

יצירת הזמנה → בדיקת מחיר → יצירת משלוח → ליקוט → Goods Issue → יצירת חשבונית → יצירת מסמך FI.

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

דוגמה לתרחיש Regression ב־SAP

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

Precondition

קיים לקוח פעיל.

קיים חומר פעיל.

קיימת רשומת מחיר תקינה.

Step 1

יצירת Sales Order.

Step 2

בדיקת:

Customer
Material
Quantity
Price
Tax
Availability

Step 3

יצירת Delivery.

Step 4

ביצוע Picking.

Step 5

Goods Issue.

Step 6

יצירת Billing Document.

Step 7

בדיקה ב־FI.

Expected Result

התהליך הושלם ללא שגיאות והמסמכים שנוצרו תואמים זה לזה.

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

מה חייב להיכלל ב־SAP Regression Suite?

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

1. תהליכים עסקיים קריטיים

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

לדוגמה:

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

2. ממשקים

יש לבדוק:

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

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

3. Reports

שדרוג יכול להשפיע על:

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

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

4. Forms

יש לבדוק מסמכים כמו:

חשבוניות
הזמנות
תעודות משלוח
מסמכים חשבונאיים
טפסים פנימיים

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

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

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

רגרסיה טובה אינה רק:

"הכול עובד."

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

לדוגמה:

בדיקה חיובית

משתמש עם הרשאה מתאימה מצליח ליצור PO.

בדיקה שלילית

משתמש ללא הרשאה מתאימה אינו יכול ליצור PO.

דוגמאות נוספות:

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

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

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

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

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

לדוגמה:

נוצרה הזמנת מכירה.

לא מספיק שהמערכת הציגה:

Order Created Successfully

צריך לבדוק:

מספר מסמך
סכום
מטבע
מס
Customer
Material
Quantity
Plant
Storage Location
Status
מסמך FI שנוצר בעקבות התהליך

כלומר:

UI Success ≠ Business Success

בדיקות End-to-End

במערכת SAP יש חשיבות גדולה לבדיקות E2E.

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

לדוגמה:

לקוח מזמין מוצר

↓

Sales Order

↓

Delivery

↓

Picking

↓

Goods Issue

↓

Billing

↓

FI Document

↓

דיווח פיננסי

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

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

האם צריך לבצע את כל בדיקות הרגרסיה בכל שדרוג?

לא בהכרח.

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

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

לכן אפשר לבנות כמה שכבות.

Smoke Regression

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

לדוגמה:

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

Core Regression

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

Full Regression

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

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

Regression Testing מבוסס סיכון

גישה יעילה יותר היא לתת לכל תרחיש Risk Score.

לדוגמה:

קריטריון	ציון
השפעה עסקית	1–5
תדירות שימוש	1–5
מורכבות	1–5
מספר ממשקים	1–5
רגישות כספית	1–5

לאחר מכן אפשר לדרג את התרחישים.

לדוגמה:

תהליך תשלום לספק

השפעה עסקית: 5
רגישות כספית: 5
ממשקים: 4
מורכבות: 4

זה תהליך שמקבל עדיפות גבוהה.

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

Baseline – למה חשוב לדעת איך המערכת עבדה לפני השדרוג?

רגרסיה דורשת נקודת השוואה.

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

לדוגמה:

לפני שדרוג

Order 100245
סכום: 12,500 ₪
מס: 2,125 ₪
סטטוס: Complete

אחרי שדרוג

Order 100891
סכום: 12,500 ₪
מס: 2,125 ₪
סטטוס: Complete

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

Golden Test Data

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

לדוגמה:

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

היתרון הוא שניתן להריץ את אותם תרחישים לאחר כל שינוי ולהשוות תוצאות.

מה לגבי אוטומציה?

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

במקום שמשתמש יבדוק בכל שדרוג מחדש:

Login
יצירת מסמך
הזנת נתונים
שמירה
בדיקת תוצאה

אפשר להפוך חלק מהתרחיש לאוטומטי.

אבל לא כל בדיקת SAP מתאימה באותה מידה לאוטומציה.

מה כדאי לאוטומט?

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

חוזרים על עצמם
יציבים
קריטיים
בעלי Expected Result ברור
ארוכים לביצוע ידני
מבוצעים לאחר כל Release

לדוגמה:

Smoke Tests

יכולים להיות מועמדים מצוינים לאוטומציה.

גם תהליכי E2E יציבים יכולים להתאים.

ומה לא כדאי למהר לאוטומט?

תרחישים:

שמשתנים לעיתים קרובות
חד־פעמיים
לא יציבים
עם UI שמשתנה כל הזמן
בעלי ROI נמוך

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

לכן המטרה אינה:

"כמה שיותר אוטומציה."

אלא:

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

למי שרוצה להשוות בין כלי אוטומציה, באתר יש גם מדריך Playwright לעומת Cypress לעומת Selenium.

Regression Testing לאחר ECC → S/4HANA

מעבר מ־ECC ל־S/4HANA הוא דוגמה מצוינת לפרויקט שבו רגרסיה מקבלת חשיבות מיוחדת.

מדובר לא רק בשינוי גרסה.

יכולים להיות שינויים ב:

Data Model
תהליכים
פונקציונליות
ממשק משתמש
Custom Code
ממשקים
דוחות
הרשאות
תהליכים פיננסיים

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

צריך לבנות Business Process Regression Suite.

במילים אחרות:

לא לבדוק רק:

"האם VA01 עובדת?"

אלא:

"האם תהליך המכירה של הארגון עובד מקצה לקצה?"

בדיקות רגרסיה לפני Go Live

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

שכבה 1 – Smoke

המערכת זמינה.

המשתמשים יכולים להתחבר.

הטרנזקציות הבסיסיות עובדות.

שכבה 2 – Functional

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

שכבה 3 – Integration

הממשקים עובדים.

שכבה 4 – End-to-End

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

שכבה 5 – Regression

התהליכים הקיימים לא נפגעו.

שכבה 6 – User Acceptance Testing

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

שכבה 7 – Production Readiness

בודקים גם:

Jobs
Interfaces
הרשאות
Monitoring
Reports
Forms
Scheduling
נתונים
תפעול

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

איך מחליטים שהרגרסיה הסתיימה?

לא מספיק לומר:

"כל הטסטים עברו."

צריך להגדיר Exit Criteria.

לדוגמה:

100% מהתרחישים הקריטיים עברו.
אין Defects ברמת Severity 1.
אין Defects קריטיים פתוחים ללא אישור עסקי.
הממשקים הקריטיים עברו.
תהליכי End-to-End עברו.
משתמשים עסקיים אישרו את התהליכים.
הנתונים שנוצרו תקינים.
Jobs קריטיים עובדים.
Reports מרכזיים מחזירים תוצאות תקינות.

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

כאן חשוב לא לבצע מיד Retest ולסמן Pass.

צריך לבצע ניתוח.

שלב 1

לתעד את התוצאה בפועל.

שלב 2

להשוות ל־Baseline.

שלב 3

לבדוק האם מדובר ב:

Regression אמיתי
שינוי מכוון
שינוי בנתוני Test
בעיית Environment
הרשאה
ממשק
בעיית תשתית

שלב 4

לפתוח Defect במקרה הצורך.

שלב 5

לתקן.

שלב 6

להריץ Retest.

שלב 7

להריץ גם בדיקות Regression נוספות סביב האזור שנפגע.

השלב האחרון חשוב במיוחד.

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

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

אחד הכלים החשובים בניהול בדיקות הוא Traceability.

צריך להיות אפשרי לענות על השאלות:

מה השתנה?

↓

על אילו רכיבים השינוי משפיע?

↓

אילו תהליכים עסקיים מושפעים?

↓

אילו Test Cases מכסים אותם?

↓

מה הייתה תוצאת הבדיקה?

כך ניתן לקבל החלטה מבוססת ולא להסתמך על תחושה.

Regression Testing Checklist ל־SAP

לפני סיום הרגרסיה כדאי לעבור על הרשימה:

מערכת

Login
Navigation
תהליכים מרכזיים
ביצועים בסיסיים

FI

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

MM

Purchase Requisition
Purchase Order
Goods Receipt
Invoice
מלאי

SD

Sales Order
Delivery
Picking
Goods Issue
Billing

אינטגרציה

ממשקים נכנסים
ממשקים יוצאים
הודעות
שגיאות
נתונים

הרשאות

משתמש רגיל
משתמש מנהל
משתמש ללא הרשאה
פעולות רגישות

תפעול

Batch Jobs
Reports
Forms
Monitoring
Scheduling

10 טעויות נפוצות בבדיקות רגרסיה ב־SAP

1. בודקים רק את השינוי

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

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

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

3. אין Baseline

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

4. מתעלמים מממשקים

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

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

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

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

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

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

אוטומציה שאינה מתאימה לתהליך יכולה להפוך לנטל תחזוקה.

8. אין Risk-Based Testing

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

9. לא בודקים תרחישים שליליים

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

10. עוצרים אחרי Pass ראשון

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

איך הייתי בונה Regression Suite לארגון SAP?

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

לדוגמה:

20–30 תהליכים עסקיים קריטיים

ומחלק אותם ל־4 רמות:

Tier 1 – Critical

תהליכים שאסור שייכשלו.

Tier 2 – High

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

Tier 3 – Medium

תהליכים חשובים אך בעלי חלופות.

Tier 4 – Low

פונקציות פחות קריטיות.

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

Business Scenario → Test Case → Test Data → Expected Result → Owner → Frequency → Automation Status

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

השורה התחתונה

בדיקות רגרסיה ב־SAP אינן בדיקה של "האם השדרוג הצליח".

הן בדיקה הרבה יותר חשובה:

האם העסק עדיין יכול לעבוד כפי שעבד לפני השינוי?

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

בשדרוגים גדולים, במיוחד כאשר מדובר בשינוי גרסה משמעותי או מעבר ל־S/4HANA, חשוב עוד יותר לבנות Regression Suite מסודר ולא להסתמך על בדיקות אקראיות.

בסופו של דבר, המטרה אינה להריץ כמה שיותר Test Cases.

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

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

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

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

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

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