מתודולוגיה ותהליכי בדיקות | נטליה רחמני
רוצים להכניס כלי אוטומציה חדש לארגון או להחליף קיים? לא יודעים איך לגשת לנושא ואיך להתחיל תהליך POC? חוששים מתוצאות לא חד משמעיות עקב התהליך שישאירו מקום לספק?
בכתבה זו אסביר איך מובילים את התהליך בצורה שלא תשאיר מקום לספק ואיך מתאימים כלי אופטימלי עבור הארגון שלכם.
החלפת הכלי או הטמעת הכלי החדש בארגון, זהו תהליך שכדאי לגשת אליו מתוכנן היטב, עם הגדרת יעדי תהליך ומה רוצים להשיג בבחירת הכלי החדש לעומת הכלי הישן. תהליך יכלול הגדרת הקריטריונים ברורים על פי מה מודדים את הכלי (קריטריונים מומלץ לאשר מראש על יד בעלי עניין הרלוונטיים. מעבר לבודקים יש צוותים נוספים שיכולים להשתמש בכלי). הצגה של קריטריונים לבעלי עניין הנוספים, יש היבט נוסף שניתן להרוויח והוא: סוג של "מחויבות” של צוותים נוספים לנושא של החלפת הכלי ושימוש עתידי בו. "מחויבות" צוותי הפיתוח יכולים לתרום לא מעט להצלחת הטמעת הכלי בארגון.
אז איך עושים את זה כהלכה למעשה?
לפני שמתחילים את התהליך חשוב מאוד להבין למה אתם רוצים לבחור כלי חדש? מה היתרונות והחסרונות המשפיעות על העבודה של הצוות ברמה היומית בכלי הקיים ? תשבו עם הצוות ותבינו למה אתם רוצים להחליף את הכלי. באחד הפרוייקטים אני שמעתי לאורך הזמן מהצוות תלונות שונות על הכלי, אבל לא משהו קונקרטי,ולכן קיימתי ישיבה בנושא וביקשתי להביא יתרונות וחסרונות על הכלי המשפיעות על העבודה על מנת לקבל החלטה האם ללכת לתהליך POC. ראינו צוות אשר מבזבז לא מעט זמן על תחזוקת הכלי ברמה היומית, חלק מהפונקציות לא קיימות בכלי למרות הציפייה המקצועית, כל זה לצד העלות גבוהה של הכלי.המסכנה הייתה שאנחנו רוצים ללכת לתהליך POC ולפי תוצאותיו להבין האם אנחנו מוכנים להחליף את הכלי או לא.
בואו נראה יחד מה הם השלבים הנדרשים לבחירת הכלי:
- לאחר הבנת ה-"למה" יש לתכנן את התהליך POC כחלק ממפת הדרכים של הגרסה, מגדירים זמן סביר לביצוע POC על ידי אנשי צוות הרלוונטיים.
- ניתן לבחור 3 כלים הקיימים בשוק להחלטה. בוא נראה איך בוחרים את שלושת הכלים לתהליך POC. סוקרים את שוק הכלים, מתייעצים עם מנהלי בדיקות אחרים ועם אנשי R&D נוספים, במילים אחרות חוקרים את "השטח" כדי להבין מה יכול להתאים לכם לארגון.
- מגדירים מה תהליך מערכתי מקצה לקצה שרוצים לבדוק (כמובן יכול להיות יותר מאחד). בעיניי חשוב לא לבחור תהליך מורכב, אבל יש לוודא שהוא מכסה את הפונקציונליות הראשית של מערכת. המטרה כאן לראות איך הכלי מתמודד עם תהליך מקצה לקצה של המוצר.
- להגדיר קריטריונים לבחירת כלי אוטומציה. יש לא מעט קריטריונים שניתן להתייחס אליהם כ"כלי מדידה", אבל חשוב לבחור מתוכם מה כדאי לכם ולמוצר שלכם.
ראו דוגמא:
לפני תחילת תהליך POC, אנו בוחרים קריטריונים עבור כלי אוטומציה לממשק משתמש שבחרנו לארגון שלנו. ניתן לראות שהגדרנו מה העדיפות לכל קריטריה עבור הכלי, במחשבה מה הצורך של המוצר ומה חשוב לנו בתור צוות בדיקות אוטומציה. כמובן, עדיפות וקריטריה עלולים להשתנות בהתאם לצורך ולמוצר החברה.
ניתן לראות שהגדרנו מגוון קריטריונים שחלקם מאוד טכניים וחלקם הקשורים לעלויות שהכלי הנבחר עלול להביא איתו, וכן אפילו כדאי להכניס קריטריה כגון מה העלות ההכשרה של הצוות בארגון. חשוב לחשוב על כל האספקטים בהטמעת הכלי שיכול להיות רלוונטי, זה יעזור לקבל תמונה מלאה ובחירה.
לאחר הגדרת הקריטריונים מומלץ לקיים פגישה עם בעלי עניין הרלוונטיים לנושא ולהציג בפניהם את הקריטריונים שנבחרו, ולהסביר מה המשמעות של כל אחד מהם. חשוב לשמוע דעות נוספות על הקריטריונים שנבחרו, חלק מעדיפות לקריטריונים יכולה להשתנות לאחר הפגישה. דבר נוסף, להסכים על תהליך מערכתי מקצה לקצה שנבחר עבור POC. כך תהיו בטוחים שאתם בדרך הנכונה לפני תחילת ה-POC ותוכלו להרוויח "מחויבות" נוספת לתהליך מצד בעלי העניין.
- נכנסים לתהליך POC .
שלב ראשון על פי הפרמטרים שהגדרנו אנו לומדים את הכלים, חלק מהמידע ניתן למצוא ברשת וחלק באמצעות העבודה על הכלי. (התקנה, כתיבת תרחישים, ניסיון להוציא דוחות וכו’).
שלב שני הוא כתיבת תרשים מקצה לקצה בכל אחד מהכלים.
במהלך התהליך מומלץ למנהל הבדיקות לעקוב מקרוב אחרי התקדמות ה-POC ולבצע סטטוס התקדמות פעם ביומיים שלושה ולראות התקדמות לפי התכנית שהוגדרה מראש.
- לקבוע פגישה פנים צוותית במטרה להציג התוצאות ולענות על השאלות לגבי הכלים וביצועם.
- לקבוע פגישה מסכמת עם בעלי עניין הרלוונטיים לצורך הצגת התוצאות, שאלות וקבלת החלטה על בחירת הכלי.
לסיכום:
תהליך POC יכול להיות תהליך מאתגר, אך עם זאת תהליך מלמד, שובר שגרה והרגשה שמרימים משהו חדש עם ציפייה לתוצאות טובות יותר. חשוב להוביל תהליך בצורה מסודרת ומוגדרת מראש וכן מערבת את כל בעלי העניין על מנת להבטיח תוצאות אובייקטיביות ולא משאירות ספק.
