למדו מתי להשתמש באוטומציה ומתי לא
קובי הלפרין
"למדו מתי להשתמש באוטומציה ומתי לא" – תחילה – חשוב ללמוד כי למרות ההבטחות של כמה ממשווקי הכלים אין אוטומציה ללא תכנות, בסופו של דבר עם כל ההקלות שחלק מן הכלים מציעים כיום, עדיין כאשר חסרה תמיכה בצורך מסוים – נאלץ לפנות לכתיבת קוד ובעזרת קידוד נוכל להגיע לא פעם למימוש יעיל יותר של חלקים באוטומציה.
אין זה אומר שכל הבודקים חייבים להשתתף בפעילות תכנות מקיפה – אבל לכל קבוצה חייב להיות מתכנת מנוסה אשר יודע כיצד לבצע זאת בצורה איכותית.
רבות כבר נכתב על הנושא כי ההחלטה לבצע אוטומציה לנושא תלויה בהשקעה הנדרשת בהפיכת הבדיקה לאוטומטית ביחס לכמות הפעמים בהן נרצה לבצע הבדיקה מעכשיו והלאה, ובכמות התחזוקה שנצטרך להשקיע בכדי לאפשר לבדיקה זו להמשיך ולהתקיים בגרסאות הבאות של המוצר.
מקרי בדיקה אותם אנו מריצים שוב ושוב על כל בילד – כמו Sanity יהיו אם כן המועמדים הראשונים לאוטומציה, אחריהם נושאים שישתתפו בבדיקות רגרסיה, ואם השלמנו שני יעדים אלו – נוכל להמשיך ולחשוב באותה הדרך היכן יהיה יעיל להשקיע בעתיד.
צריך לזכור כי פעמים רבות לא נממש את מלוא הבדיקה בצורה אוטומטית – ואז יהיה עלינו לוודא כי איננו שוגים באשליית כיסוי אוטומטי – אלא מנהלים זאת ומבצעים הצעדים הנותרים ידנית.
אוטומציה הינה בעצם בדיקה בעזרת המחשב, ורצוי שנזכור כי לעיתים קרובות במקביל להליך האוטומציה ה"מסודר" הקיים בקבוצה, אנו יכולים להיעזר ביכולות המחשב להקל על חיינו בעיקר בתהליכים יום יומיים החל מהתקנת סביבת העבודה וכלה בחילוץ אוטומטי של לוגים רלוונטיים לצירוף לבאגים, ולהאיץ תהליכי תכנון וביצוע גם לצרכים הד-הוקיים – ולתת לכך את המשאבים הדרושים.
לעיתים נוכל להפיק המון מכלי ייעודי – אשר לדוגמא יחלץ את כל הטקסטים הנחשפים למשתמש ויספק לנו קובץ עליו נוכל לבצע במרוכז בדיקת איות בעזרת הכלים הבנויים ב- MS-Word או וכד', במקום להסתמך על ערנות הבודקים למציאת בעיות גנריות אלו.
לעיתים קרובות ניתן לבנות כלים ייעודיים להקמת עמדת הבדיקות, ולהגעה לנקודת ההתחלה של הבדיקות ותכולת מבני הנתונים הנדרשת כבסיס לעבודה הידנית, במקום להשקיע בכך מאמץ ידני שוב ושוב.
מאידך – רצוי לדעת כי אוטומציה מסודרת אינה דבר שניתן להשיג תוך מס' ימים ושבועות – יש לוודא יישור צפיות עם ההנהלה,
צריך לזכור כי לרוב – על כל הערכת זמנים של משימת אוטומציה – יש לקחת עוד כ-50% זמן של דיבוג ותיקון בעיות בלתי צפויות.
וגם לדעת באילו מקרים עדיף "לא להילחם עם האוטומציה" אלא להמשיך ולבצע ידנית.
כמו כן – לעיתים קרובות ממשיכים להשתמש ולבזבז זמן בהרצת בדיקות אוטומטיות – רק כי "הן כבר קיימות" – אך ייתכן מאוד ואלו כבר מזמן לא רלוונטיות, לא ממש מוצאות באגים חדשים, או פשוט לא יעילות כפי שנכתבו במקור – ורצוי להחליפן במקרי בדיקה מורכבים יותר, המותאמים לצרכי רגרסיה.
ודווקא בימים אלו בהם שיטות אג'יליות מעודדות לכתוב בדיקות יחידה אוטומטיות ושיטות כמו TDD מקבלות המון פרסום וקידום – הרי שהסכנות הטמונות בהרצת מקרי בדיקה שאינם יעילים הולכות וגדלות.
רבים מתפארים בכמות של אלפי בדיקות אוטומטיות קצרצרות שכל אחת מהן מבזבזת זמן הכנה וניקוי וייתכן כי אינן יעילות לאורך זמן.
טיפ זה נכתב ע"י קובי הלפרין, חומר קריאה נוסף:
http://www.mkltesthead.com/2013/07/99-ways-workshop-5-learn-when-to.html
סדרת טיפים זו "כיצד להפוך לבודקים טובים יותר" מתבססת על דיון ב: Software Testing Club
99 Things Testers Can Do To Become Better Testers
ה-eBook החינמי שנוצר בעקבות דיון זה: 99ThingsEbook.pdf
וסדרת פוסטים מאת Michael Larsen בשם: Ways Workshop 99 - בה מיכאל מרחיב על כל אייטם וגם מספק הנחיות כיצד לתרגל הנושא.
