סיכונים של אוטומציה של בדיקות
פרקי ההרצאה: סיכונים של אוטומציה של בדיקות
תמלול ההרצאה: סיכונים של אוטומציה של בדיקות
הטקסט המלא של הדקות הראשונות בהרצאה «סיכונים של אוטומציה של בדיקות» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
סעיף 6.1.2 בחומר ההסמכה מדבר על יתרונות וסיכונים של אוטומציה של הבדיקות. דיברנו על כלים שעוזרים לנו להשיג את המשימות ואת המטרות של צוות הבדיקות.
מה הסיכונים והיתרונות של הכנסת כלים אוטומטיים על מנת לשרת אותנו למטרות הבדיקות? קודם כל חשוב לזכור, רכישה של כלי לא מבטיחה הצלחה.
רוב הכלים או חלק גדול מהכלים יש להם עלות. זאת אומרת, יש להם עלות לרישיון, יש להם עלות לפניכה גם אם אין להם עלות ישירה לשימוש כמו כלים מבוססי ג'אווה שהם כלים חינמיים עדיין הצורך שלנו בעצם להכשיר אנשים ולגייס אנשים שהם מתמחים בפיתוח בכלים האלה זה נחשב עלות אז צריך לזכור
שהרבה כלים יש בצידם השקעה אך זה החזר של ההשקעה לא בטוח לא מובן מאליו. שימוש בכלים לבדיקות פותח הזדמנויות ומכיל יתרונות, אך גם יש סיכונים כאמור.
הדבר נכון במיוחד לכלים לביצוע בדיקות. יתרונות אפשריים לשימוש בכלים לתמיכה בביצוע בדיקות כוללים הורדה בעומס של הבדיקות הידעניות זאת אומרת כלי לבדיקות אוטומטיות מקל על הבודקים בתסטים שחוזרים על עצמם, בטסטים הסיזיפיים, בטסטים הבסיסיים שאנחנו צריכים להריץ שוב ושוב.
אז את זה אנחנו יכולים להשיג על ידי כלי בדיקות אוטומטיות. גידול בעקביות ויכולת חזרה, זאת אומרת, כשיש לי כלי אוטומטי, אני בעצם יכול להגדיל את נפח הבדיקות.
אני יכול להורות על ידי סקריפט פשוט או פעולה מתוזמנת להריץ את הטסט שוב ושוב. הערכה יותר אובייקטיבית. כלי אוטומטי, כלי מבוסס רובוט, מבוסס סקריפט שחוזר על עצמו, הוא יותר אובייקטיבי ויותר בטוח בתוצאות מאשר בדיקות אנושיות שנעשות לפעמים על ידי בודקים שונים, שנבדלים זה מזה ביכולת לבדוק, בהסקת המסקנות,
בניסיון שלהם, בכישורים שלהם, נגישות כללית על המידע של הבדיקות. לדוגמה, כלים אוטומטיים וכלים בכלל שמשרתים את הבדיקות, נותנים לנו הנגשה לסטטיסטיקות וגרפים של התקדמות הבדיקות, ניהולה באגים וביצועים.
מהם הסיכונים האפשריים בשימוש בכלים אלה? הציפיות מהכלי, זאת אומרת, לדוגמה כלי לבדיקות אוטומטיות, עשויות להיות לא מציאותיות, זאת אומרת, אנחנו מצפים שהכלי יביא לנו אפקט מסוים, ולמעשה הדרך להשיג את האפקט הזה ארוכה אם בכלל אפשרית.
הארכת זמן, עלות והמאמץ להכנסה הראשונית להטמעה של הכלי עשויה ללקוט בחסר, זאת אומרת, ההכשרה של הבודקים והגיוס של אנשים שיתפעלו את הכלי עלולות להיות ארוכות ממה שתכננו.
הארכת הזמן והמאמץ הנדרש להשגת יתרונות משמעותיים על פני בדיקות ידניות עשויה להיות יותר ארוכה ממה שחשבנו. זאת אומרת, עד שנגיע למצב שבאמת אנחנו מנצלים את כל היתרונות של האוטומציה על פני הבדיקות הידניות, יכול לחרוג מהזמן שהקצבנו.
הארכת המאמץ הנדרש לתחזוקת נכסי הבדיקות, כלומר, לתחזוקת הבדיקות יכולה להיות מין עקב אכילס, זאת אומרת, גם אם הגענו למצב שיש לנו coverage אוטומטי לטסטים רבים, אנחנו צריכים כל הזמן להשקיע בתחזוקה של אותם טסטים.
השינויים, ההתאמה לשינויים שיש במערכת, ושהטסטים ימשיכו לתת תוצאות אמינות. אז הכרחת המאמץ להשגת המטרה הזאת יכולה ללקוט בחסר.
התלות בכלי עשויה להיות גבוהה מדי, וכך כשאנחנו מגיעים למצב שיש תלות בכלי, אז הבודקים הידעניים בעצם לא תמיד ידעו למלא את החסר במקרה שהכלי יוצא משימוש או הכלי לא משיג את כל המטרות שלו.
הכרת גרסאות נכסי הבדיקות עשויה להזנח. שוב, הנושא של תיקון ושיפור של הכלים האוטומטיים. בעיות היחסים הדדיים בין כלים קריטיים עשויים להזנח, למשל כלי ניהול דרישות, Requirement, כלי ניהול תצורה וכלי ניהול פגמים וכלים מספקים שונים.
זאת אומרת, הצורך ליצור אינטגרציה בין כלים שאנחנו רוכשים ומתניעים לתוך סביבת הבדיקות שלנו, לתוך צוות הבדיקות.
ספק של כלי מסוים עשוי לסגור את העסק או עשוי לסגור את הגרסה, כך קרה לדוגמה עם HP שהפסיקו לתמוך ב-QTP ובעצם הוציאו תמיכה רק למוצרים המתקדמים יותר UFT. אבל זה קורה הרבה בתחום הזה וצריך לקחת את זה בחשבון.
בגלל זה עדיף לנו לרכוש כלים שהם חזקים ופופולריים