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

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

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

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

מה זה Go Live ב-SAP?

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

זה יכול לקרות במגוון תרחישים:

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

בכל אחד מהמקרים האלה, צוות ה-QA צריך להתייחס ל-Go Live כאל שער איכות (Quality Gate) ולא כאל תאריך ביומן.

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

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

למה בדיקות SAP לפני Go Live כל כך חשובות?

מערכת SAP אינה מערכת מבודדת.

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

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

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

לדוגמה:

הזמנה נוצרת בהצלחה → המערכת הפיננסית אינה מקבלת אותה → החשבונית אינה נוצרת → הנתון אינו מגיע ל-BI → הדוח הניהולי שגוי.

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

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

זו בדיוק הסיבה שבדיקות SAP צריכות להיות End-to-End.

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

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

להלן צ'קליסט מרכזי שאפשר להשתמש בו כבסיס ל-Go/No-Go.

תחום	מה צריך לבדוק?	סטטוס
דרישות עסקיות	כל הדרישות הקריטיות נבדקו	☐
בדיקות פונקציונליות	התהליכים עובדים בהתאם לדרישות	☐
אינטגרציה	כל הממשקים הקריטיים נבדקו	☐
E2E	התהליכים מקצה לקצה תקינים	☐
רגרסיה	תהליכים קיימים לא נפגעו	☐
נתונים	נתוני המיגרציה תקינים	☐
הרשאות	לכל משתמש קיימת גישה מתאימה	☐
ביצועים	המערכת עומדת בעומסים	☐
אצווה	Jobs קריטיים עובדים	☐
דוחות	דוחות קריטיים תקינים	☐
הדפסות	Forms ו-PDF תקינים	☐
אבטחה	הרשאות ובקרות נבדקו	☐
UAT	משתמשים עסקיים אישרו את המערכת	☐
תקלות	אין תקלות קריטיות פתוחות	☐
תפעול	צוות התמיכה מוכן	☐
גיבוי	גיבוי ושחזור נבדקו	☐
Rollback	קיימת תוכנית חזרה לאחור	☐
Go/No-Go	התקבלה החלטה רשמית	☐

1. בדיקות דרישות עסקיות

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

לכל דרישה משמעותית רצוי שיהיה:

Requirement.
Test Case.
תוצאה צפויה.
תוצאה בפועל.
סטטוס.
Defect במקרה של כשל.
אישור גורם עסקי.

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

לדוגמה, במקום לבדוק רק יצירת הזמנה, צריך לבדוק:

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

זהו תהליך עסקי שלם.

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

בדיקות פונקציונליות הן הבסיס לכל תהליך Go Live.

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

לדוגמה:

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

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

לדוגמה:

תרחיש חיובי

המשתמש מזין נתונים תקינים → המסמך נוצר.

תרחיש שלילי

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

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

בדיקות E2E הן מהבדיקות החשובות ביותר לפני Go Live.

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

לדוגמה:

Order to Cash

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

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

באתר קיימת הרחבה בנושא E2E Testing – מה זה ואיך מבצעים בדיקות מקצה לקצה.

4. בדיקות אינטגרציה

SAP כמעט תמיד מתקשרת עם מערכות נוספות.

לכן צריך ליצור רשימת Interfaces מלאה.

לכל ממשק מומלץ לבדוק:

האם ההודעה יוצאת?
האם היא מגיעה ליעד?
האם המבנה תקין?
האם הנתונים תקינים?
האם קיימת תגובת Success?
מה קורה במקרה של כשל?
האם המערכת מבצעת Retry?
האם קיימת התראה?
האם ניתן לזהות הודעה שנכשלה?
האם ניתן לבצע Reprocessing?

דוגמה

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

בדיקה בסיסית:

SAP → Bank

אבל בדיקת Go Live טובה יותר תבדוק גם:

SAP → Bank → Response → SAP → Accounting → Reporting

5. בדיקות רגרסיה

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

לכן צריך לבצע Regression Testing.

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

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

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

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

6. בדיקות נתונים ומיגרציה

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

לפני Go Live יש לבדוק:

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

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

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

לדוגמה:

אם עברו 100,000 לקוחות, כדאי לוודא:

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

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

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

צריך לבדוק משתמשים לפי תפקידים ולא רק משתמש בודד.

לדוגמה:

משתמש פיננסי

צריך לבצע:

צפייה.
יצירה.
שינוי.
אישור.

אבל ייתכן שאסור לו לבצע פעולות מסוימות.

משתמש מנהל

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

בדיקת Negative Authorization

לא רק:

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

אלא גם:

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

זו בדיקה קריטית במיוחד בסביבה פיננסית.

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

מערכת שעובדת היטב עם 20 משתמשים לא בהכרח תעבוד היטב עם 2,000.

לכן לפני Go Live צריך להעריך:

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

חשוב לבדוק גם תרחישים מציאותיים.

לדוגמה:

08:00 בבוקר

אלפי משתמשים מתחברים במקביל + Jobs רצים + ממשקים מעבירים נתונים.

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

9. בדיקות Batch Jobs

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

יש להכין רשימה של כל ה-Jobs הקריטיים:

Job name.
תדירות.
זמן ריצה.
בעלים.
תלות ב-Jobs אחרים.
מערכת יעד.
תנאי כשל.
מנגנון התראה.

יש לבדוק:

☐ Job מתחיל בזמן.

☐ Job מסתיים בהצלחה.

☐ הנתונים שנוצרים תקינים.

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

☐ צוות התמיכה יודע לזהות כשל.

☐ ניתן להריץ מחדש.

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

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

לכן יש לבדוק:

דוחות תפעוליים.
דוחות פיננסיים.
דוחות מנהלים.
BI.
Export ל-Excel.
PDF.
סינון.
מיון.
הרשאות.
טווחי תאריכים.
סכומים.
ספירות.

חשוב לבצע גם Reconciliation.

לדוגמה:

סכום במערכת המקור:

10,000,000 ₪

סכום בדוח:

9,997,500 ₪

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

11. בדיקות Forms והדפסות

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

יש לבדוק:

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

במיוחד בעברית יש לבדוק:

RTL.
יישור.
עברית/אנגלית באותו מסמך.
מספרים.
מטבעות.
תווים מיוחדים.

12. בדיקות תרחישי קצה

לפני Go Live אסור להסתפק ב"Happy Path".

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

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

השאלה שצריכה להישאל היא:

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

13. בדיקות אבטחה

אבטחה צריכה להיות חלק בלתי נפרד מתהליך ה-Go Live.

יש לבדוק:

הרשאות.
Roles.
Segregation of Duties.
משתמשים לא פעילים.
משתמשי מערכת.
גישה לנתונים רגישים.
שינויי הרשאות.
Audit Logs.
גישה לממשקים.

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

14. בדיקות UAT

UAT – User Acceptance Testing – היא נקודת מעבר חשובה בין צוות ה-QA לבין העסק.

ב-UAT המשתמשים העסקיים צריכים לאשר:

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

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

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

לפני סיום UAT כדאי לוודא:

☐ כל התהליכים הקריטיים נבדקו.

☐ משתמשים עסקיים השתתפו.

☐ תקלות קריטיות נסגרו.

☐ תקלות High נפתרו או קיבלו אישור עסקי.

☐ קיימת חתימת Business Owner.

15. ניהול תקלות לפני Go Live

לא כל Bug חייב לעצור Go Live.

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

חומרה	דוגמה	החלטה אפשרית
Critical	אי אפשר לבצע תהליך ליבה	No-Go
High	פונקציה עסקית חשובה אינה עובדת	לרוב No-Go
Medium	קיימת מגבלה עם Workaround	החלטת Steering
Low	בעיית UI קטנה	ניתן לשקול פתיחה לאחר Go Live

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

לדוגמה:

3 תקלות פתוחות

נשמע מצוין.

אבל אם אחת מהן מונעת הפקת חשבוניות – זה עלול להיות No-Go.

16. בדיקות Smoke לפני העלייה

מיד לפני Go Live או מיד לאחר הפריסה יש לבצע Smoke Test.

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

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

לדוגמה:

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

אם Smoke Test נכשל – עוצרים ומבינים למה.

17. בדיקות Cutover

Cutover הוא תהליך המעבר עצמו.

יש לבדוק אותו לפני יום ה-Go Live באמצעות Dry Run.

לדוגמה:

שלב 1 – Freeze

עצירת שינויים.

שלב 2 – Backup

גיבוי המערכות.

שלב 3 – Migration

העברת נתונים.

שלב 4 – Validation

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

שלב 5 – Configuration

יישום הגדרות ייצור.

שלב 6 – Interfaces

הפעלת ממשקים.

שלב 7 – Smoke Test

בדיקות ראשוניות.

שלב 8 – Business Validation

אישור משתמשים.

שלב 9 – Go Live

פתיחת המערכת למשתמשים.

18. בדיקת Rollback

אחת השאלות החשובות ביותר לפני Go Live היא:

מה עושים אם Go Live נכשל?

חייבת להיות תשובה ברורה.

תוכנית Rollback צריכה להגדיר:

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

Rollback שאינו מתורגל הוא לא באמת תוכנית חירום.

19. מוכנות צוות התמיכה

Go Live אינו מסתיים כאשר המערכת עולה.

להפך – שם מתחילה תקופת Hypercare.

לפני העלייה יש לוודא:

☐ צוות תמיכה זמין.

☐ קיימת רשימת אנשי קשר.

☐ יש חלוקת אחריות.

☐ יש Escalation Matrix.

☐ יש ערוץ דיווח תקלות.

☐ מוגדר SLA.

☐ יש אנשי SAP זמינים.

☐ יש אנשי תשתיות זמינים.

☐ יש אנשי אינטגרציה זמינים.

☐ יש נציגים עסקיים זמינים.

20. Hypercare לאחר Go Live

בימים הראשונים לאחר Go Live צריך להיות מנגנון ניטור מוגבר.

מומלץ לעקוב אחר:

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

כדאי לבצע Daily Go Live Review לפחות בתקופה הראשונה.

צ'קליסט Go/No-Go מלא

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

פונקציונלי

☐ כל הדרישות הקריטיות נבדקו.

☐ כל תהליכי הליבה עברו.

☐ תרחישים חיוביים עברו.

☐ תרחישים שליליים עברו.

☐ תרחישי קצה עברו.

E2E

☐ כל התהליכים מקצה לקצה עברו.

☐ כל המערכות המשולבות נבדקו.

☐ הנתונים עוברים בין המערכות.

☐ התוצאות העסקיות נכונות.

רגרסיה

☐ תהליכים קיימים נבדקו.

☐ שינויים לא פגעו בפונקציות קיימות.

☐ ממשקים קיימים נבדקו.

נתונים

☐ Migration הסתיים.

☐ מספר רשומות אומת.

☐ נתונים קריטיים אומתו.

☐ Reconciliation בוצע.

הרשאות

☐ Roles נבדקו.

☐ משתמשים קריטיים נבדקו.

☐ הרשאות עודפות הוסרו.

☐ Negative Testing בוצע.

ביצועים

☐ Load Test בוצע.

☐ זמני תגובה תקינים.

☐ עומס משתמשים נבדק.

☐ Jobs במקביל נבדקו.

תפעול

☐ Monitoring פעיל.

☐ Alerts פעילים.

☐ Backup תקין.

☐ Restore נבדק.

☐ צוות התמיכה מוכן.

Cutover

☐ Cutover Plan אושר.

☐ Dry Run בוצע.

☐ זמני הפעולות ידועים.

☐ בעלי תפקידים מוגדרים.

☐ Rollback Plan מוכן.

Business

☐ UAT הושלם.

☐ Business Owner אישר.

☐ תהליכים קריטיים אושרו.

☐ משתמשים הודרכו.

מי צריך לתת אישור Go Live?

החלטת Go Live אינה צריכה להיות באחריות ה-QA בלבד.

בפרויקט SAP משמעותי צריכים להיות מעורבים לפחות:

Project Manager.
QA Manager.
SAP Lead.
Business Owner.
IT Manager.
Security.
Infrastructure.
Integration.
Data/Migration Lead.
Operations/Support.

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

העסק צריך להחליט האם הסיכון מקובל.

איך יודעים שהמערכת באמת מוכנה?

אפשר להשתמש בנוסחה פשוטה:

Go Live Readiness = Functionality + Data + Integration + Performance + Security + Business Acceptance + Operational Readiness

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

לדוגמה:

מערכת יכולה להיות:

100% פונקציונלית.
100% רגרסיה.
100% UAT.

אבל אם המיגרציה שגויה – היא אינה מוכנה.

10 שאלות שחייבים לשאול לפני Go Live

לפני הישיבה הסופית, כדאי לשאול:

1. האם כל התהליכים העסקיים הקריטיים נבדקו?

2. האם כל הממשקים הקריטיים נבדקו?

3. האם נתוני המיגרציה אומתו?

4. האם קיימות תקלות Critical או High?

5. האם קיימת דרך עבודה במקרה של כשל?

6. האם בוצע Cutover Dry Run?

7. האם Rollback אפשרי?

8. האם צוות התמיכה מוכן?

9. האם משתמשי המפתח אישרו את המערכת?

10. האם ההנהלה מבינה את הסיכונים שנותרו?

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

אוטומציה בבדיקות SAP לפני Go Live

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

כאן נכנסת האוטומציה.

ניתן לבצע אוטומציה עבור:

תרחישים חוזרים.
Smoke Tests.
Regression.
בדיקות UI.
בדיקות API.
בדיקות אינטגרציה.
בדיקות נתונים.
Validation.

כלים כמו Playwright ו-Selenium יכולים להיות רלוונטיים במיוחד כאשר קיימת שכבת Web או Fiori שדורשת בדיקות UI.

למי שרוצה להעמיק בנושא, מומלץ לקרוא את Playwright לעומת Cypress לעומת Selenium – השוואה מלאה.

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

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

טעות 1: לבדוק רק את ה-SAP

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

טעות 2: להתמקד ב-Happy Path

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

טעות 3: לא לבדוק נתונים

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

טעות 4: להתעלם מהרשאות

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

טעות 5: לא לבצע Cutover Dry Run

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

טעות 6: לא להגדיר Go/No-Go

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

טעות 7: להתייחס ל-QA כאל שלב האחרון

QA צריך להיות מעורב כבר בתכנון ה-Go Live ולא רק בשבוע האחרון.

איך לבנות אסטרטגיית בדיקות טובה ל-Go Live?

גישה מומלצת היא לעבוד בשכבות.

שכבה 1 – Unit

בדיקת רכיב בודד.

שכבה 2 – Functional

בדיקת פונקציה עסקית.

שכבה 3 – Integration

בדיקת החיבור בין מערכות.

שכבה 4 – E2E

בדיקת תהליך עסקי מלא.

שכבה 5 – Regression

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

שכבה 6 – Performance

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

שכבה 7 – Security

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

שכבה 8 – UAT

אישור העסק.

שכבה 9 – Cutover

בדיקת המעבר עצמו.

שכבה 10 – Smoke

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

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

ומה קורה אחרי Go Live?

אחד העקרונות החשובים ביותר הוא ש-Go Live אינו קו הסיום של הבדיקות.

לאחר העלייה לאוויר מתחיל שלב חדש:

Production Validation.

בשלב הזה יש לעקוב אחר:

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

רצוי להגדיר תקופת Hypercare עם צוות מורחב וזמינות גבוהה.

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

סיכום

בדיקות SAP לפני Go Live הן הרבה יותר מרשימת Test Cases.

המטרה האמיתית היא לענות על שאלה אחת:

האם הארגון יכול לסמוך על המערכת ביום שבו היא הופכת למערכת הייצור?

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

פונקציונליות + אינטגרציה + E2E + רגרסיה + נתונים + הרשאות + ביצועים + אבטחה + UAT + Cutover + תמיכה.

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

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

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

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

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

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