SAP Testing | QA | Go Live

SAP Testing Checklist: רשימת בדיקות מלאה לפני Go Live

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

המטרה של SAP Testing Checklist היא להפוך את שלב ההכנה ל־Go Live מתהליך המבוסס על תחושות והנחות לתהליך מסודר, מתועד ומבוקר. הרשימה במאמר יכולה לשמש צוותי QA, מנהלי פרויקטים, מנהלי SAP, אנשי Business, מיישמים, מנהלי IT ומשתמשי מפתח.

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

מהו SAP Testing לפני Go Live?
למה Checklist מסודר כל כך חשוב?
שלב 1: בדיקת מוכנות כללית
שלב 2: בדיקת דרישות ותהליכים עסקיים
שלב 3: בדיקות פונקציונליות
שלב 4: בדיקות אינטגרציה וממשקים
שלב 5: בדיקות הסבת נתונים
שלב 6: בדיקות רגרסיה
שלב 7: בדיקות הרשאות ואבטחה
שלב 8: בדיקות ביצועים ועומסים
שלב 9: בדיקות E2E של תהליכים עסקיים
שלב 10: UAT ואישור משתמשים
שלב 11: ניהול תקלות לפני Go Live
שלב 12: בדיקות Cutover ויום העלייה לאוויר
Checklist סופי לפני Go Live
טעויות נפוצות בבדיקות SAP
סיכום

מהו SAP Testing לפני Go Live?

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

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

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

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

למה Checklist מסודר כל כך חשוב?

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

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

כיסוי

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

שקיפות

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

בקרה

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

תיעוד

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

שלב 1: בדיקת מוכנות כללית

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

Checklist מוכנות

☐ גרסת SAP המיועדת ל־Go Live הותקנה בסביבה הרלוונטית.
☐ כל ה־Transports הרלוונטיים הועברו.
☐ התצורה בסביבת הבדיקות תואמת ככל האפשר לסביבת הייצור.
☐ הנתונים הדרושים לבדיקה זמינים.
☐ משתמשי הבדיקה וההרשאות הוגדרו.
☐ ממשקים חיצוניים זמינים לבדיקה.
☐ Jobs מתוזמנים נבדקו או הוגדרו לסביבת הבדיקה.
☐ כלי ניטור ולוגים זמינים לצוות.
☐ קיימת תוכנית עבודה ברורה לסבב הבדיקות.
☐ הוגדרו קריטריוני Entry ו־Exit.

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

שלב 2: בדיקת דרישות ותהליכים עסקיים

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

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

שאלות שצריך לשאול

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

שלב 3: בדיקות פונקציונליות ב־SAP

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

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

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

שלב 4: בדיקות אינטגרציה וממשקים

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

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

Checklist ממשקים

☐ כל הממשקים הקריטיים מופו.
☐ לכל ממשק הוגדר מקור ויעד.
☐ נבדקה שליחת מידע מ־SAP החוצה.
☐ נבדקה קליטת מידע למערכת SAP.
☐ נבדקו מבני הנתונים.
☐ נבדקו שדות חובה.
☐ נבדקו ערכים לא תקינים.
☐ נבדקו הודעות שגיאה.
☐ נבדקו Retry ו־Error Handling במידת הצורך.
☐ נבדקו לוגים.
☐ נבדקה התאוששות מכשל בממשק.
☐ נבדקה תקינות הנתונים לאחר הקליטה.

שלב 5: בדיקות הסבת נתונים

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

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

שלמות

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

דיוק

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

קשרים

האם הקשרים בין אובייקטים נשמרו?

תהליכים

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

שלב 6: בדיקות רגרסיה ב־SAP

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

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

להרחבה: בדיקות רגרסיה ב־SAP: איך לוודא ששדרוג לא שבר תהליכים קיימים .

מה לכלול ב־Regression Pack?

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

שלב 7: בדיקות הרשאות ואבטחה

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

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

שלב 8: בדיקות ביצועים ועומסים

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

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

שלב 9: בדיקות E2E של תהליכים עסקיים

בדיקת E2E, כלומר End-to-End, בוחנת את התהליך מנקודת ההתחלה ועד לתוצאה העסקית הסופית. זוהי אחת הבדיקות החשובות ביותר לפני Go Live משום שהיא מחברת בין מודולים, משתמשים, נתונים ומערכות.

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

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

שלב 10: UAT ואישור משתמשים

UAT, או User Acceptance Testing, בוחן האם המערכת עומדת בציפיות ובצרכים העסקיים של המשתמשים. זהו שלב שבו משתמשי מפתח צריכים לבצע תהליכים מהעולם האמיתי ולאשר שהתוצאה מתאימה לעבודה שלהם.

Checklist UAT

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

שלב 11: ניהול תקלות לפני Go Live

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

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

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

שלב 12: בדיקות Cutover ויום העלייה לאוויר

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

Checklist Cutover

☐ קיימת תוכנית Cutover מאושרת.
☐ לכל משימה יש Owner.
☐ לכל משימה מוגדר זמן ביצוע.
☐ קיימת תלות ברורה בין משימות.
☐ גיבויים בוצעו ונבדקו לפי נהלי הארגון.
☐ ההסבה הסופית תוכננה.
☐ הממשקים הוגדרו למצב הנכון.
☐ Jobs הוגדרו לתזמון הנכון.
☐ משתמשים קריטיים מוכנים לעבודה.
☐ צוותי תמיכה זמינים.
☐ הוגדר מנגנון Escalation.
☐ קיימת תוכנית Rollback או Recovery בהתאם לאופי הפרויקט.

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

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

Checklist סופי לפני Go Live

זהו הסיכום המעשי שאפשר להכניס למסמך הפרויקט ולעבור עליו לפני החלטת Go / No-Go:

☐ כל התהליכים העסקיים הקריטיים זוהו.
☐ כל הדרישות הקריטיות קושרו לתרחישי בדיקה.
☐ הבדיקות הפונקציונליות הושלמו.
☐ בדיקות אינטגרציה הושלמו.
☐ כל הממשקים הקריטיים נבדקו.
☐ הסבת הנתונים נבדקה ואושרה.
☐ בדיקות רגרסיה הושלמו.
☐ בדיקות הרשאות הושלמו.
☐ בדיקות ביצועים בוצעו כאשר הן רלוונטיות.
☐ תהליכי E2E קריטיים עברו בהצלחה.
☐ UAT הושלם.
☐ אין תקלות קריטיות פתוחות ללא החלטה מאושרת.
☐ כל ה־Workarounds הקריטיים מתועדים.
☐ תוכנית Cutover מאושרת.
☐ צוות התמיכה מוכן ליום העלייה.
☐ תוכנית Recovery / Rollback קיימת בהתאם לצורך.
☐ הוגדרו בדיקות Smoke לאחר Go Live.
☐ בעלי התפקידים הרלוונטיים אישרו את המוכנות.

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

טעויות נפוצות בבדיקות SAP לפני Go Live

1. בדיקת Happy Path בלבד

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

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

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

3. הזנחת ממשקים

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

4. אי־בדיקת נתונים

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

5. רגרסיה מצומצמת מדי

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

6. UAT ברגע האחרון

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

7. אין קריטריוני Go / No-Go

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

סיכום: SAP Testing הוא תהליך של ניהול סיכונים

SAP Testing לפני Go Live אינו מסתכם בהרצת תסריטי בדיקה וסימון Passed. המטרה האמיתית היא לספק לארגון תמונה אמינה של רמת המוכנות שלו.

Checklist איכותי צריך לכסות את כל שרשרת הערך: דרישות, תהליכים עסקיים, פונקציונליות, אינטגרציה, נתונים, רגרסיה, הרשאות, ביצועים, E2E, UAT, תקלות ו־Cutover.

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

Go Live מוצלח מתחיל הרבה לפני יום העלייה לאוויר

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

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

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

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