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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

7. בניית תהליך הרצת טסטים וניתוח תוצאות יעיל ומהיר

8. הגדרת מטריקות ומדדים לאוטומציה

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

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

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

א. אישור build לילי רק לאחר מעבר מוצלח של טסטים אוטומטיים ברמת הקוד (רמת ה-unit)

ב. חבילת אוטומציה לאישור גרסא הנמסרת לבדיקות – בדיקות שפיות (רמת unit ו/או מערכת)

ג. חבילות אוטומציה למימוש כל בדיקות הרגרסיה של מחלקת הבדיקות (מערכת)

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

ה. חבילות אוטומציה לכל נושא, שלא ניתן לבדוק ידנית עקב אילוצים שונים (דיוקים, ביצועים, עומסים, וכו')

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

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

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

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

 

מאת: דובי וינברג, מנהל אתר הבדיקות בחברת GE Healthcare , חטיבת הבדיקות בנס .

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

עוד בנושא...

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