למה UAT נכשל דווקא כשהוא נראה מוצלח
בסבבי UAT רבים כל התסריטים מסומנים כעוברים, ושבועיים אחרי העלייה לאוויר נפתחות עשרות פניות. זה לא פרדוקס. זה תוצאה ישירה של בדיקה שנבנתה סביב מסכים.
בדיקה סביב מסך שואלת "האם אפשר ליצור רשומה". בדיקה סביב תהליך שואלת "האם נציג יכול לקבל פנייה, לזהות שהלקוח קיים תחת שם אחר, לבדוק את הזכאות שלו במערכת הליבה, לפתוח טיפול, להעביר אותו לגורם אחר ולסגור אותו — כשהלקוח קיים פעמיים במערכת". התסריט השני מוצא את מה שהראשון מפספס.
המדריך מציג את מבנה ה-UAT שמכוון לשאלה השנייה. הקשר לשלבי הפרויקט האחרים מופיע במדריך הטמעת Salesforce.
מה חייב להיות מוכן לפני שמתחילים
- סביבה יציבה שאינה מקבלת פריסות באמצע הסבב, למעט תיקוני חוסם מאושרים.
- נתוני בדיקה בהיקף ובמורכבות דומים לייצור.
- משתמשים בעלי הרשאות אמיתיות — לא Admin לכולם. חצי מתקלות ההרשאות מתגלות רק כשהבודק הוא בעל הפרופיל הנכון.
- קריטריוני קבלה מוגדרים לכל תהליך ליבה.
- מנגנון דיווח יחיד לתקלות, עם שדות חובה מינימליים.
הפריט שהכי נוטים לדלג עליו הוא השלישי, והוא זה שמייצר את התקלות המביכות ביותר ביום העלייה.
איך בונים תסריט שמוצא בעיות
תסריט טוב מתחיל בפרסונה ובמצב פתיחה, לא בלחיצה. מבנה שעובד:
- מי — תפקיד והרשאה מדויקים.
- מצב פתיחה — איזה מידע קיים במערכת לפני שהתסריט מתחיל.
- מה קורה — האירוע העסקי שמפעיל את התהליך.
- מה הבודק עושה — ברמת פעולה עסקית, לא ברמת קליק.
- התוצאה הצפויה — כולל מה קרה במערכות אחרות.
- מה לא אמור לקרות — הרשומה לא נחשפת למי שלא אמור, ההתראה לא נשלחת פעמיים.
הסעיף השישי הוא מה שמפריד בין רשימת בדיקות לבין בדיקה מקצועית.
שש משפחות תרחישים שחייבות להיכלל
| משפחה | דוגמה לתרחיש | מה היא חושפת |
|---|---|---|
| מסלול תקין | תהליך שלם מקצה לקצה | האם התהליך בכלל בר-ביצוע |
| חריגה עסקית | ביטול, זיכוי, החזרה לשלב קודם | לוגיקה שנבנתה רק לכיוון אחד |
| נתונים בעייתיים | לקוח כפול, שם בעברית ובאנגלית, שדה ריק | מיפוי וניקוי לא מספקים |
| הרשאות | משתמש שמנסה לגשת לרשומה של יחידה אחרת | חורים במודל החשיפה |
| כשל אינטגרציה | מערכת היעד אינה זמינה | טיפול בשגיאה, לולאות, כפילות |
| נפח | פעולה קבוצתית על מספר גדול של רשומות | מגבלות ביצועים ואוטומציה |
היעדר משפחה שלמה מהרשימה הוא סימן שהבדיקה תיתן ביטחון מדומה.
סיווג חומרה — התנאי לניהול הסבב
בלי סיווג מוסכם, כל תקלה נראית דחופה וההחלטה על עלייה לאוויר הופכת לוויכוח. מודל בן ארבע רמות מספיק:
| רמה | הגדרה | השפעה על עלייה לאוויר |
|---|---|---|
| חוסם | אי אפשר להשלים תהליך ליבה, אין מעקף | חוסם |
| חמור | התהליך אפשרי עם מעקף כבד או שנתונים שגויים נשמרים | חוסם אלא אם אושר במפורש |
| בינוני | חוסר נוחות משמעותי, מעקף סביר | לא חוסם, נכנס לתוכנית תיקון |
| נמוך | נוסח, סדר שדות, שיפור | נאסף לגל הבא |
הכלל החשוב: את הסיווג קובע בעל התהליך יחד עם הצוות הטכני, ולא מי שדיווח על התקלה.
תנאי מעבר לייצור
מנסחים אותם לפני תחילת הסבב ולא בסופו:
- אפס תקלות חוסמות פתוחות.
- כל תקלה חמורה נסגרה או אושרה בכתב עם מעקף וזמן תיקון.
- כל תהליכי הליבה הורצו בסבב שני ללא כשל חדש.
- בעלי התהליך אישרו בכתב.
- קיימת תוכנית נסיגה שנבדקה, ולא רק נכתבה.
דוגמה להמחשה: קרן פנסיה
התרחיש היפותטי ונועד להמחשה. קרן פנסיה בדקה תהליך טיפול בפניות עמיתים. סבב UAT ראשון עבר כמעט במלואו. הצוות שם לב שכל הבודקים השתמשו בפרופיל אחד מורחב, כי הקצאת הפרופילים המדויקים התעכבה.
בסבב שני, עם הפרופילים האמיתיים, נמצאו אחת עשרה תקלות: נציגים לא ראו רשומות של עמיתים שהועברו בין מסלולים, כפתור אישור חריגה הופיע למי שאינו מוסמך, ודוח עומסים החזיר תוצאות חלקיות לראשי צוות. אף אחת מהתקלות לא הייתה קשורה לפונקציונליות שנבדקה בסבב הראשון — כולן היו במודל החשיפה.
המסקנה המעשית שאומצה שם: אין פותחים סבב UAT לפני שכל המשתתפים יושבים על הפרופיל שבו יעבדו בייצור.
טעויות ניהוליות שמייקרות את הסבב
- פריסת גרסאות באמצע הסבב, שמאפסת את תוקף הבדיקות שכבר בוצעו.
- בודקים שמדווחים ב-WhatsApp ובדוא"ל במקביל למערכת המעקב.
- תסריטים שכתובים ברמת קליק, שהופכים כל שינוי בממשק לעדכון תיעוד.
- קיצור הסבב השני מלחץ לוח זמנים — זהו הסבב שמגלה רגרסיות.
הדפוסים האלה מופיעים לצד כשלים נוספים במדריך הטעויות הנפוצות, והאחריות לכל אחד מהם מוגדרת במדריך צוות פרויקט Salesforce.
כשמדובר בהחלפת מערכת קיימת
בפרויקט החלפה נוסף ל-UAT תפקיד שני: השוואה. אותם עשרה תרחישים מורצים בשתי המערכות, והתוצאות מושוות שדה מול שדה. זה הכלי היעיל ביותר לגלות פערי מיפוי לפני שהם הופכים לפערי אמון. סדר הפעולות במעבר כזה מפורט במדריך החלפת CRM ב-Salesforce.
מה שנשאר אחרי הסבב
תסריטי ה-UAT אינם מסמך חד פעמי. הם הבסיס לבדיקות הרגרסיה בכל שחרור עתידי, והם המקור הטוב ביותר לחומרי הדרכה — כי הם כתובים בשפת התהליך ולא בשפת המערכת. שמירתם בפורמט שאפשר להריץ שוב היא ההשקעה הזולה ביותר שאפשר לעשות לקראת השנה הבאה.