7 גורמים המשפיעים על ההחזר הצפוי מהשקעה באוטומציה פונקציונלית של בדיקות
מאת: איתי אגמון, 9.8.21, 15:14
 
הגורמים המשפיעים על ההחזר הצפוי מהשקעה באוטומציה של בדיקות תוכנה פונקציונליות, ובכך על כדאיות התהליך, הם מגוונים. מובאים 7 גורמים עיקריים, שיכולים לעזור להגיע להחלטות נבונות בהקשר של בדיקות אוטומציה.

1) מחזור שחרור גרסה וזמן הרצת רגרסיה

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

2) סוגי ממשקי המערכת ויציבותם

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

3) היצמדות לפירמידת הבדיקות

ככל שניתן וככל שיש היענות גדולה יותר מצד כל הגורמים הלוקחים חלק בפיתוח המוצר להיצמדות לפירמידת הבדיקות, כך ההסתברות להחזר גדולה יותר כמו גם היכולת ליישם מודלים של Continuous Testing ו-Shift Left. במידה ולא קיימת הקפדה על אוטומציה לטובת איכות תוכנה עוד בשלבי הפיתוח ע"י מתכנתי המוצר, היכולת לקבל רמת ביטחון גבוהה באיכות המוצר יורדת.
 
רמת ההיתכנות להיצמדות לפירמידה גבוהה במערכות הדיגיטל, לעומת זאת במערכות המבוססות על טכנולוגיות ישנות יותר שם היכולת לכך נמוכה ובמקרים מסוימים, אינה אפשרית כלל. לדוגמה, מערכות מונוליטיות בעלות קוד בסיס גדול הממומש בשפות מיושנות כדוגמת קובול.
 

4) תלות במערכות צד שלישי

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

5) שליטה על נתוני וישויות מערכת

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

6) דטרמיניסטיות הבדיקות

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

7) יציבות המערכת הנבדקת

מערכות נבדקות, שאינן יציבות, או תלויות בתצורות מערכת, שאינן יציבות, יכולות להקשות על פיתוח והרצת הבדיקות. מצבים אלה יכולים לקרות במערכות, שרמת ה-Maturity שלהן נמוכה, כלומר, הן בשלבי פיתוח מוקדמים, ישנם פגמים במערכות עצמן, או מורכבות גבוהה בסביבות בהן המוצרים נבדקים, לדוגמה מעבדות לבדיקות של ציוד רשתות תקשורת. חוסר יציבות של המערכת הנבדקת מקשה ומאטה את תהליכי הפיתוח של המבדקים ופוגמת בביצוע הרצות אוטומציה.
 
צילום תמונה עליונה: יניב סופר
 
מאת: איתי אגמון, אוגוסט 2021.
מנהל טכנולוגיות ראשי ב-Matrix Top-Q