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

עולם התוכנות האוטומטיות לטובת בדיקות מוצרים החל לפרוח בתחילת שנות ה-2000, עם פריחתן של חברות הסטארט-אפ והתפתחותן של שיטות הפיתוח האג'יליות. אולם, אם נבחן את אחוזי ההצלחה של אלה שמבצעים בדיקות אוטומטיות – יעילות, שביעות רצון ותמורה מול עלות פיתוח, נגלה יחס מדאיג של 20% מרוצים ממנו מול 80% מאוכזבים.

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

הנה כמה מההנחות השגויות הרווחות:

"בדיקות אוטומטיות יורידו משמעותית את כמות הבודקים הידניים".

"מטרת הבדיקות האוטומטיות היא להגיע ל-100% כיסוי של דרישות המוצר".

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

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

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

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

הגדרת יעדים נכונים וריאליים לביצוע הבדיקות האוטומטיות

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

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

• אישור Build לילי רק לאחר מעבר מוצלח של טסטים אוטומטיים ברמת הקוד (רמת ה-Unit).
• חבילת אוטומציה לאישור גרסה הנמסרת לבדיקות – בדיקות שפיות (רמת ה-Unit ו/או רמת המערכת).
• חבילות אוטומציה למימוש כל בדיקות הרגרסיה של מחלקת הבדיקות (מערכת).
• חבילות אוטומציה בכל נושא שבו תמורת עלות פיתוח קטנה יחסית ניתן לקבל תמורה גדולה.
• חבילות אוטומציה עבור כל נושא שלא ניתן לבדוק ידנית עקב אילוצים שונים – למשל דיוקים, ביצועים או עומסים.

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

בבואנו להקים צוות בדיקות אוטומטיות, עלינו להקפיד בבחירתם של:

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

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

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

על הכותב

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