סוגית בבחירת כלי אוטומציה

מאת: מסורי שלומי, מומחה אוטומציה – טאקט בדיקות
(מקבוצת מטריקס). 

 

 

 

 

 

 

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

 

 דוגמה: חברה מסוימת בחרה בכלי A לצורך בדיקות Web. הטמעת הכלי בוצעה בצורה מיטיבית אך כשנוספו מודולים חדשים למערכת הנבדקת העושים
 שימוש ברכיבי Web  מתקדמים וכן יצאה דרישה, לאור ההצלחה, למכן גם את Backend  שיושב על תחנות Unix, נתקלו בבעיית מימוש.

 בסופו של תהליך היה על מנהל הבדיקות לעמוד מול הדילמה:

ý      האם לרכוש / לפתח כלי נוסף ?

ý      להחליף את הכלי הקיים (כולל הסבת התרחישים שכבר נכתבו) ?

ý      לוותר על בדיקות אוטומציה בחלקים הבעיתיים !!!

 

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

 

 בבואנו לבחור את הכלים בהם נשתמש יש לקחת בחשבון מספר גורמים:

1. תמיכה בסביבות עבודה הרלוונטיות למוצר/לארגון.
2. עלות רכישה ותחזוקה הן של הכלי והן של התסריטים אשר יכתבו באמצעותו.
3. אינטגרציה עם כלים הקיימים בארגון
4. גמישות בשפת הפיתוח
5. תמיכה בטכנולוגיות הנדרשות בארגון
6. זמן הכשרה / זמינות מפתחים עם ידע מתאים.
7. תמיכה וידע זמין

  

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

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

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

פרמטר נוסף הוא עלות הסבת התסריטים אל ומכלים אחרים.

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

 

3. אם לא דיווחת לא עשית – הטמעת הדיווח של תוצאות הריצה בכלי הדיווח הראשי מהווה פרמטר חשוב בבחירת הכלי. ככלל, כלי אוטומציה המגיע מאותה "משפחה" אמור להתממשק בצורה שקופה עם כלי ניהול הבדיקות/ פיתוח בחברה.

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

4. שפת פיתוח התסריטים מהווה לעיתים מדד לשקלול, הן לעניין הסבת תסריטים קיימים, והן לעניין הכשרת מפתחי בדיקות לשפת הפיתוח הנתמכת. כלים התומכים בריבוי שפות נראים בד"כ גמישים יותר, אך מצד שני, שימוש בבליל שפות בין התסריטים יקשה על תחזוקה וסטנדרטיזציה של התסריטים.
5. יש לוודא תמיכת הכלי בטכנולוגיות שבהן עושה שימוש המערכת הנבדקת (הנוכחית והעתידית), אם בתמיכה מובנית ((Add-in או כיכולת הרחבה (Extensibility).
6. זמן הכשרה של מפתחי האוטומציה לצורך השימוש בכלי, הינו פרמטר שיש להתייחס אליו.

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

7. יכולת התמיכה בכלי באה לידי ביטוי הן ברמת התמיכה הניתן לכלי והן בנתח השוק היחסי שתופס הכלי.

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

 

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

 

 לסיכום: להלן טבלת שקלול מוצעת המתבססת על 7 הפרמטרים שציינתי:

 

פרמטר