טעויות נפוצות בבחירת כלי בדיקה אוטומטי מבוססות על ההנחה שהטמעת הכלי תחסוך משאבי בדיקות רבים וכי מדובר בהשקעה חד פעמית. לכן, כמאמר חכמינו "סוף מעשה במחשבה תחילה" רצוי להקדיש חשיבה מרובה בתחילת הדרך, כיוון שהחלפת כלי אוטומציה כרוכה בעלויות גבוהות ולעיתים אף בלתי ישימה.
דוגמה: חברה מסוימת בחרה בכלי A לצורך בדיקות Web. הטמעת הכלי בוצעה בצורה מיטיבית אך כשנוספו מודולים חדשים למערכת הנבדקת העושים שימוש ברכיבי Web מתקדמים וכן יצאה דרישה, לאור ההצלחה, למכן גם את ה-Backend שיושב על תחנות Unix, נתקלו בבעיית מימוש.
בסופו של תהליך היה על מנהל הבדיקות לעמוד מול הדילמה:
• האם לרכוש / לפתח כלי נוסף ?
• להחליף את הכלי הקיים (כולל הסבת התרחישים שכבר נכתבו) ?
• לוותר על בדיקות אוטומציה בחלקים הבעיתיים !!!
על אף שהאסוציאציה המידית העולה באיזכור כלי בדיקה אוטומטים קשורה למוצר ספציפי, יש לשקול בכובד ראש את ההחלטה לאיזה כיוון לפנות. כיוון שבחירת כלי בדיקות אוטומטי הינה צעד חשוב ובעל השלכות ארוכות טווח.
בבואנו לבחור את הכלים בהם נשתמש יש לקחת בחשבון מספר גורמים:
1. תמיכה בסביבות עבודה הרלוונטיות למוצר/לארגון.
2. עלות רכישה ותחזוקה הן של הכלי והן של התסריטים אשר יכתבו באמצעותו.
3. אינטגרציה עם כלים הקיימים בארגון
4. גמישות בשפת הפיתוח
5. תמיכה בטכנולוגיות הנדרשות בארגון
6. זמן הכשרה / זמינות מפתחים עם ידע מתאים.
7. תמיכה וידע זמין
1. סביבת ההרצה הרלוונטית למערכות הנבדקות בארגון הינה סינון ראשוני וחשוב לגבי ארסנל הכלים הזמינים לרשותנו. במערכות שלא פועלת בסביבת חלונות יש לוודא כי הכלים הקיימים תומכים בסביבה הנדרשת. מדד זה הינו מסנן ראשי, כלומר אי עמידה בהגדרה זו פוסל על הסף את הכלי הנבדק.
2. חישוב העלויות של הכלי הנבחן צריך לכלול מעבר לתשלום הראשוני על הרישיון, תחזוקה ו/או תשלום תקופתי (במידה ויש), גם את זמן הפיתוח והתחזוקה של התשתיות והתסריטים לאורך חיי המערכת הנבדקת.
פרמטר
נוסף הוא עלות הסבת התסריטים אל ומכלים אחרים. את העלויות יש לחשב באופן יחסי עבור כל אחד מהכלים העומדים על הפרק.
3. אם לא דיווחת לא עשית – הטמעת הדיווח של תוצאות הריצה בכלי הדיווח הראשי מהווה פרמטר חשוב בבחירת הכלי. ככלל, כלי אוטומציה המגיע מאותה "משפחה" אמור להתממשק בצורה שקופה עם כלי ניהול הבדיקות/ פיתוח בחברה.
ישנם כלים המאפשרים אינטגרציה קלה גם עם כלי ניהול נוספים מעבר לחבילת המוצרים אליה הוא משתייך. כמו כן, יש כלים המאפשרים לבנות ממשקים שכאלה באופן עצמאי על בסיס API של הכלי.
4. שפת פיתוח התסריטים מהווה לעיתים מדד לשקלול, הן לעניין הסבת תסריטים קיימים, והן לעניין הכשרת מפתחי בדיקות לשפת הפיתוח הנתמכת. כלים התומכים בריבוי שפות נראים בד"כ גמישים יותר, אך מצד שני, שימוש בבליל שפות בין התסריטים יקשה על תחזוקה וסטנדרטיזציה של התסריטים.
5. יש לוודא תמיכת הכלי בטכנולוגיות שבהן עושה שימוש המערכת הנבדקת (הנוכחית והעתידית), אם בתמיכה מובנית (Add-in או כיכולת הרחבה Extensibility).
6. זמן הכשרה של מפתחי האוטומציה לצורך השימוש בכלי, הינו פרמטר שיש להתייחס אליו. יש לקחת בחשבון שקל יהיה יותר לגייס מפתחי אוטומציה המתמחים בכלים הנפוצים בשוק מאשר לגייס מפתחי אוטומציה בעלי ניסיון בכלים הנפוצים פחות.
7. יכולת התמיכה בכלי באה לידי ביטוי הן ברמת התמיכה הניתן לכלי והן בנתח השוק היחסי שתופס הכלי.
יש לבחון גם את היקף הפרסומים הבלתי תלויים ברשת כמו: פורומים, אתרים, בלוגים, קטעי קוד זמינים ברשת לצורך ביצוע מטלות סטנדרטיות וכדו'.
שקלול פרמטרים אלו לפי משקל בהשוואה לכלים הנסקרים ייתן מדד אמין וכמותי ויאפשר קבלת החלטות מושכלת.
אודות שלומי מסורי
שלומי מסורי בעל ניסיון של למעלה מ-9 שנים בפיתוח ובבדיקות אוטומציה.
מתוכן כ-5 שנים בTact. מנהל כיום את צוות האוטומציה בבנק לאומי.
לחלוק, לשתף, לעורר השראה ולהעצים מנהלי מידע, זה המוטו של
קובי שפיבק Bsc ו- MBA. קובי הוא מורה דרך טכנולוגי שמלווה את עולם המחשוב: כתכנת, מהנדס, מנהל, יזם, עיתונאי, יועץ ומרצה, משנת 1976. כעורך הראשי של תחקירי pCon הוא כתב וערך ב-19 השנים האחרונות, למעלה מ-960 תחקירים מקצועיים, שמסייעים למנהלי מחשוב במאות ארגונים, ליהנות מיותר עניין, זמן פנוי וכסף זמין.
מנהלי מחשוב, שמעוניינים לקרוא או להפנות לקובי שפיבק שאלות מקצועיות, מוזמנים לעשות זאת במסגרת תשובות המומחה.
אם לא מצאת שירות זה כשימושי, בבקשה ספר לנו.
אם אתה כן נהנה מהשירות שתף חברים שגם להם הוא יכול לעזור.
תחשוב על החיוך, הסיפוק, ההרגשה הטובה, כשגם רעך ייהנה כמוך והמלץ עכשיו.