בדיקות והבטחת איכותMenu

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

​במאמר הראשון שפרסמנו שבוע שעבר, ניתחנו את הסיבות לכישלונות של רוב תהליכי הבדיקות האוטומטיות והרחבנו על 2 השלבים הראשונים להצלחת התהליך-

1. הגדרת יעדים נכונים וריאליים

2. בחירת כח אדם מקצועי ומיומן

במאמר השני נמשיך להרחיב על 3 השלבים הבאים בתהליך נכון של בדיקות אוטומטיות :

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

4. בחירה נכונה של האזורים במוצר למימוש הבדיקות האוטומטיות

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

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

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

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

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

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

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

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

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


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

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

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

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

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

 

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

עוד בנושא...

עוד פרסומים בנושא אשר עשויים לעניין אותך