מבדיקות Web לבדיקות CRM | ליאור שם טוב
במאמר זה אסקור את חוויית המעבר של בודקים בעלי רקע עיקרי בבדיקות מערכות WEB עם פיתוח IN HOUSE, לבדיקת מערכת CRM (מוצר מדף מספק חיצוני). בודקים החווים לראשונה כניסתה של מערכת מרכזית לארגון שהיא מוצר מדף, עוברים תהליך של שינוי, חידוש, למידה ואתגרים. הכתבה תתמקד בבודקים אשר היו מורגלים במשך שנים רבות לעבוד עם מערכות WEB בפיתוח פנימי, ללא היכרות עם מערכת CRM או מערכות דומות ולראשונה מקבלים מוצר מדף הדורש שכלול בתפיסת הבדיקות. אסייג במעט את המונח "חוסר היכרות" ואציין שבמערכות עם פיתוח פנימי לעיתים יש עבודה עם מוצרי תשתית שגם הם מוצר מדף, למשל עבודה עם תשתית kendo או מנוע חיפוש/חוקה וכיו"ב שהם מנת חלקם של הרבה בודקים אשר התנסו בבדיקות מוצרים אלו או מוצרים דומים. למעשה ב"מוצרי תשתית" מדובר בהתמודדות זהה בדומה לכל מוצר מדף, אבל ברמה מינורית ביחס לכלל המערכת, ההתמודדות ממוקדת למוצר עצמו שמוכל בתוך המערכת עצמה ומהווה את אחד הרכיבים בה (ולא מצב בו כל המערכת היא מוצר מדף), ולכן בתפיסת הבדיקות, התייחסות לכלל המערכת לא משתנה, והשינוי, אם קיים כזה, הוא רק ביחס למוצר המדף התשתיתי, ולכן הבודק לא חש בשינוי משמעותי מבחינת התמונה הכוללת של המערכת.
במאמר לא אתייחס להיבטים של יתרונות וחסרונות או בעד או נגד CRM, אלא אתמקד בהתמודדות הבודקים הניגשים לבדוק לראשונה מערכת CRM.
מבוא
מערכת CRM הינה פלטפורמה לניהול מערכות ארגוניות המפשטת את התהליך העסקי ומממשת אותו עם אובייקטים עסקיים, כאשר מעליהם בנויים קשרים, תהליכים, דוחות ועוד. ה-CRM מאפשר הקמה פשוטה של מערכת על התשתית שהוא מספק, קרי מתן כלים ויכולות נרחבות, אינטגרציה מול מערכות קיימות בפיתוח פנימי, התממשקות למוצרי מדף שונים, עדכוני גרסא מהירים ועוד.
ארגונים אשר מכניסים מערכת CRM או מוצר מדף אחר לצד מערכות בפיתוח עצמי, מהווים לגוף ה-IT אתגר גדול. ה-IT בארגון נדרש לבצע את ההתאמות לחלק או לכל המערכות, שירותים, ממשקים, DB, אינטגרציה וכיו"ב. לעיתים מדובר בהכנסת מערכת CRM חדשה לצורך עסקי חדש, ולעיתים בהחלפת מערכת קיימת. למעשה בשני המצבים מדובר בשינוי רציני ורגשי, הדורש תהליכים ארגוניים מורכבים למשל: מנהלי הארגון נעזרים במומחים מתחום הייעוץ הארגוני אשר מובילים תהליך של שינוי והטמעה למשתמשי הארגון כדי לייצר נחיתה רכה למשתמשים ביום בו תגיע המערכת לשימושם; ה-IT עובר גם הוא שינוי בכל הרמות, בהיבט התשתיתי כפי שתואר לעיל וכפי שיתואר בהמשך, וברמות השונות בארגון למשל: הנהלה, מנתחי מערכות, צוותי פיתוח ובדיקות אשר מתאימים עצמם לעבודה עם מוצר מדף, גיוס אנשים עם ניסיון ב-CRM ו/או הכשרת צוותים קיימים, ביצוע הדרכות ע"י הספק, עמידה בדרישות אבט"מ, הסבות נתונים והיבטים נוספים אשר יריעת כתבה זו קצרה מלהכיל.
במהלך שנות עבודתי פגשתי מערכות CRM בכמה צמתים, בכל צומת הבודקים היו עם ניסיון בבדיקות מערכות CRM, או כהיכרות יחידה של מערכות מסוג זה או כהיכרות נוספת לצד המערכות בפיתוח פנימי הקיימות בארגון. הכתבה תתמקד בצומת בו ניהלתי צוות בודקים אשר נפגשו לראשונה עם מערכת CRM ושם חוותי לראשונה תהליך של הובלת שינוי תודעתי מתפיסת בדיקות מוכרת וידועה לתפיסת בדיקות משוכללת.
במאמר אתאר את התהליך העובר על הבודק במפגש עם מערכת CRM במהלך מחזור פרויקט פיתוח במקטעים הבאים:
- אפיון וכתיבת תסריטים: צוות הבודקים נפגש לראשונה עם אפיון של מערכת CRM באמצעות קריאה מודרכת, במטרה לזקק את הדרישות הרלוונטיות לכתיבת התסריטים.
- בדיקות: התמודדות עם מערכת שהיא מוצר מדף.
- תקלות: זיהוי תקלות אשר מהוות ערך לצוותי הפיתוח וסינון תקלות לא רלוונטיות או שתיקונם מתקיים במימד חיצוני לארגון.
- אוטומציה: מיכון מוצר מדף ושכלול דרכי הזיהוי של אלמנטים.
- סיכום: הצגת מסקנות והמלצות לצוותי בדיקות.
אפיון וכתיבת התסריטים
במערכות עם פיתוח פנימי הבודק מתמודד עם אפיונים אשר מתארים את דרישות המערכת מקצה לקצה, לעומת זאת העבודה עם אפיון של מערכת CRM נראה קצת אחרת מבחינת שמות ומושגים. האפיון מתמקד בעיקר בצד אשר יפותח מאשר בצד המובנה, פחות התייחסות לUI- ויותר מיקוד בקונפיגורציה, לכן התמודדות עם ה"חוסרים" לכאורה, נאלץ הבודק להשלים באמצעות התסריטים (בודקים המנוסים בבדיקות CRM לעיתים יוותרו על השלמת חוסרים בתסריטים, מתוך הנחה שמי שמריץ את התסריטים כבר קיימת לו היכרות עם CRM), כלומר על הבודק להשלים מידע אשר לא קיים באפיון (לא בכדי בדרישות הגיוס מבקשים היכרות מוקדמת עם CRM). אפיון המערכת גורם לבודק לחוסר לוגיקה או הגיון מסויים בהקשר של בניית התסריט; ולכן מוטב שבתחילת הדרך הבודק יקבל הדרכה ולמידה בה הוא יקבל את הידע והכלים להבין ולהכיר את תכונות ומאפייני ה-CRM ובהתאם לזה הוא יגשר על הפערים והחוסרים באפיון. בשלב של הקריאה המודרכת (לאחר שהבודק כבר קרא את האפיון ורשם הערותיו) הבודק מעלה שאלות רבות למאפיין או למיישם וכך מדרישה לדרישה צוות הבודקים בונה את אסטרטגיית הבדיקות, מיפוי הדרישות העסקיות, מבסס את עץ הבדיקות ומקרי הבדיקה עד לשלב כתיבת תסריטי הבדיקות.
היכרות מקדימה עם מערכת CRM יש לה חשיבות באיכות התסריטים, ולכן מאוד מומלץ לפני כתיבת התסריטים, לקבל הדרכה מסודרת ע"י הספק או אנשים בארגון עם ניסיון בכלי, אשר יציגו לצוותי הפיתוח ובדיקות את התכונות הקיימות במערכת, גמישות לעומת קשיחות, מובנה לעומת חידוש, best practices ותרגול בכלי, בנוסף, לקיים עם מנתח המערכות קריאה מודרכת של האפיון. שילוב של הדרכה מצד ספק על המערכת וקריאה מודרכת של האפיון סוגר את הקצוות הנדרשות לבודק לצורך הבנת אסטרטגיית הבדיקות וכתיבת מיטבית של תסריטי בדיקה.
בדיקות
הגענו לשלב המסקרן בפרויקט בו הבודק לראשונה מתחיל להרגיש את מערכת ה-CRM. במהלך הבדיקות הבודק פוגש מעין עולם חדש (יקום מקביל) של מערכת שלא נראית כפי שהורגל עד היום בבדיקות מערכות בפיתוח פנימי, לדוגמא ישויות, חוקים עסקיים, עצמים, UI, אלמנטים, וגם תכונות של המערכת אשר פועלות באופן שונה או מצופה מהיקום המוכר, למשל "כפתורים", במערכת CRM נמצאים כפתורי פעולה, אשר לא תמיד יש להם שימוש, אבל הם שם, אם להסירם או לא זאת שאלה שמופנית למנתח המערכות או למיישם אשר לא תמיד ממהר להסירם (שינויים מובנים נעשים באמצעות שינוי הקונפיגורציה של המסך), סיבה שכיחה לאי הסרת ה"כפתורים" המיותרים, כי אין להם השפעה על התהליך העסקי (למשתמש הסביר זה יראה מוזר ומיותר שיש כפתורים במערכת שאין להם שימוש) החשש, שעם התקדמות פיתוח, המערכת תהיה בשלבים מתקדמים וכאשר תתקבל דרישה של הלקוח להסיר כפתורים מיותרים, אזי יהיה מדובר בתהליך ארוך ויקר בו יש לסרוק את כל המסכים ולבצע בחינה מחודשת איזה כפתור מיותר ואיזה לא (כאשר החלופה המיטבית לטפל בצורך עבור כפתורים מיד עם הקמת מסך חדש), לעומת זאת במערכת WEB המאפיין לא יאפיין כפתורי פעולה אם לא קיים להם צורך עסקי, יתרה מזו, מנתח המערכות גם לא יפתח עתודות של כפתורים לצורך שימוש עסקי אם אין להם צורך מיידי או ערך ללקוח. מצבים אילו חוזרים על עצמם גם ברמת מבנה UI, פקדים, פעולות עסקיות ועוד.
הבודק העובר בין המסכים מוצא עצמו משקיע פחות בבדיקות GUI (תסריטי GUI כמעט ולא נכתבים) או בפונקציונאליות מובנית, אלא בעיקר בחוקים העסקיים המגדירים את ההתנהגות של הישויות במערכת, ולידציות, בדיקת נתונים ומאפיינים המגדירים את התצורה הכללית של אותה ישות (לדוגמא – לאפשר בתוך ישות מסוימת לבצע שליחת מייל חיצוני), לעומת זאת במערכות עם פיתוח פנימי, כל מה שמפותח נבדק.
מבחינת UI במערכת CRM בעיקר במסכי הישויות (טפסים) או תצוגות (מסכים ראשים של הישויות המציגים את כל הרשומות של הישות וסטאטוס הישות) מוצאים שהם זהים או כמעט זהים אחד לשני ולמעשה מדובר בתחושות מאוד מונוטוניות אשר משעממות את הבודק. (באחת ההרצאות שנוכחתי על מערכת CRM, הספק ציין שאין לפתח ציפיות ל"יופי" במערכת או "נגישות" מבחינת UI, אבל תצפו לקבל מערכת מאוד יציבה).
התמודדות הבודק עם המערכת מאתגרת מאוד, לכן מאוד מומלץ, טרם הגעת המערכת לסביבת הבדיקות, שהבודק יבקר אצל צוותי הפיתוח ויבקש לראות את המערכת, וכך הוא נחשף לראשונה ל-UI של הכלי, חש לראשונה את המסכים, תצוגות, ישויות, חוקים העסקיים, מסכי ניהול ואת המודולים המרכיבים את המערכת.
תקלות
עם תחילת הבדיקות, הבודק מתחיל ללמוד ולהכיר את תפיסת המערכת, מבנה המערכת, תצוגות, מסכים ברמת המשתמש, מסכים ברמת מנהל מערכת, תפריטים, מיקום של ישויות, היבטים של פעולות עסקיות, קונפיגורציה, מודולים ומתחיל לזהות (גם תוך כדי ניסוי וטעיה) תקלות במערכת.
התקלות הנפתחות מחלוקות ל-4 קטגוריות עיקריות:
א. תקלות רגילות קלאסיות (חוק העסקי, תצוגה או וולידציה בניגוד לאפיון או נתונים לא תקינים).
ב. תקלות בתצורת המערכת (תקלות קונפיגורציה)
ג. תקלות UI, אשר מטרתן בעיקר לבטא שיפור נדרש בנגישות המידע למשתמש (תקלות אילו מתגלות כאתגר פיתוחי ראשון במעלה, מהסיבה שמערכת CRM מאוד מגבילה את המתכנת בשינויי (UI).
ד. תקלות CRM (תקלות שמפנים לחברה שפיתחה את ה-CRM ואולי בגרסה מסוימת, בעתיד מסוים ינתן פתרון לתקלה ביחד עם כל משתמשי CRM בעולם).
כאשר פותחים תקלות מומלץ לסווג ו/או לתייג אותם בהתאם לקטגוריות. חשיבות לכך גבוהה מהסיבה שבתקלות מתויגות כתקלות CRM או אלמנטים במערכת שהם מובנים ולא מוגדרים כתקלה "קלאסית" מאוד רצוי לשתף את יתר הבודקים; באמצעות שיתוף הידע, הבודקים ולומדים לזהות במהלך הבדיקות מתי מדובר בתקלה אמיתית ומתי לא וחוסכים זמן לצוותי הפיתוח בפתירת תקלות מיותרות, כלומר תקלות אשר הפיתוח לא יכול לתקנם בגלל האופן שבו מובנה ה-CRM.
אוטומציה
האתגר הראשון של צוות האוטומציה בהגיעו לְמַכֵּן פעולות עסקיות במערכת CRM, הוא זיהוי האלמנטים. בניגוד למערכות בפיתוח פנימי שניתן לגשת בקלות דרך קוד לאלמנטים במסך (המתכנת נותן לכל אלמנט שם מזהה שבאמצעותו האוטומציה יכולה לגשת לאלמנט), במערכת שהיא מוצר מדף הגישה לחלק מהאלמנטים היא רק דרך מעטפת ייעודית שאותו מוצר מספק וישנם מצבים בהם לאלמנטים אחרים אין גישה כלל. בסופו של תהליך ובעזרת התייעצות עם צוותי הפיתוח ופורומים רלוונטיים כל מכשול הוא שאיפה וכל שאיפה מקבלת ביטוי כפתרון וסיפוק אדיר לצוות האוטומציה.
לסיכום
לאחר סבב בדיקות ראשון, צוות הבודקים הרגיש כיצד מיומנות הבדיקות עלתה בכמה מונים. לאחר קבלת תכולת העבודה הנוספת הבודקים הרגישו כמו שחיינים מנוסים אשר שולטים בעוד סגנונות שחייה, המחכים בסקרנות לאתגר הבא במערכת, ואכן ישנם אתגרים נוספים (למשל: הסבות נתונים, שילוב בין הרשאות של ה-CRM למערכות האחרות בארגון, אינטגרציה עם מערכות אחרות, ממשקים פנימה והחוצה, עבודה עם S ERVICES ועוד).
אחד הדברים המרשימים אשר התפתח בין צוותי העבודה היא שפה משותפת בין כולם אשר נסקה והתפתחה עם התקדמות פיתוח המערכת והכי חשוב הנאה לאורך כל תהליכי העבודה.
