בדיקות אוטומטיות – כיצד עושים זאת נכון? חלק ב'

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

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

עבור פיתוח בדיקות אוטומטיות לרמת היחידה, הארגון בדרך כלל מתאים את כלי האוטומציה שלו לסביבות הפיתוח של התוכנה. לעתים סביבות הפיתוח עצמן מספקות פתרונות מובנים (Build-in) למימוש פיתוח והרצת מערך הטסטים האוטומטיים, כמו Team Test Manager ,Coded UI או Ranorex.

לרמות הבדיקה ברמת מערכת יש לבחון כלים רק לאחר Proof of concept – דהיינו, כחלק משלב הערכת הספקים. יש צורך להתקין את הכלי בסביבת העבודה בו נמצאת האפליקציה הנבדקת ואז למפות את האזורים באפליקציה – הן את אלה שניתן לזהות והן את אלה הקשים לזיהוי.

לכל כלי (QTP ,Test Complete ,Selenium ואחרים) יש את היתרונות והחסרונות שלו ולכן, צריך לבחור בקפידה את הכלי שישמש לביצוע הבדיקות האוטומטיות.

בחירה נכונה של אזורים לביצוע אוטומציה

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

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

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

בנייה נכונה ומודולרית של תשתית האוטומציה

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

על הכותב

דובי וינברג הוא מנהל אתר הבדיקות בחברת GE Healthcare, חטיבת הבדיקות של נס. הוא בעל תואר במדעי המחשב מהטכניון ו-18 שנות ניסיון בתחום הבדיקות, תוך התמחות בבדיקות מערכות רפואיות, סלולר, אחסון ו-ווב. ל-וינברג ניסיון רב בהובלת צוותי בדיקות ידניות ואוטומטיות (QTP ו-Squish), וכן ניסיון בינלאומי בהובלת תהליכי QA בארגון (הסמכת ISO 9001). כיום הוא מנהל כ-40 עובדים במסגרת השירות המנוהל של נס ב-GE Healthcare לבדיקות מערכות רפואה גרעינית.