הפעם בחרתי בסיכום לא מחייב של מאמר מאת ג'יימס באך ומייקל בולטון על אוטומציה.
את המאמר השלם ניתן להשיג כאן: www.satisfice.com/articles/cdt-automation.pdf
יש כלים טובים שיכולים לעזור לבדיקות, אך בתעשייה כולה השימוש בהם הוא רע, מבלבל וגורם לבזבוז וכאב. הסיבה - גישה ריטואלית, צרה ורדודה לכלים. את הגישה הזו מעודדת האמונה השקרית שבדיקות זה דבר מכני וחוזר על עצמו. בדיקות טובות, כמו פיתוח, הוא תהליך אינטלקטואלי מאתגר. לכן על הכלים להיות בשימוש ע"י אנשים שמבינים את המורכבות של הכלים ושל הבדיקות. זה נכון לכל סוג של עבודה.
כיום שלטת הגישה של אוטומטיזציה של הבדיקות ע"י אוטומטיזציה של המשתמש. אומנם לא אומרים זאת אבל מתנהגים בהתאם לזאת. גישה זו אינה נכונה כיוון ש:
1. אי אפשר לעשות אוטומציה של משתמשים אלא לכל היותר אוטומציה לחלק ממה שהם עושים, אבל זה לא כל הסיפור.
2. בדיקה של פלט ניתנת לאוטומציה, אבל בודקים עושים מעבר לזאת.
3. בדיקת פלט זה מעניין אבל כלים אוטומטיים עושים יותר מזה.
יש במאמר תמונה של רובוט עובד עם שואב אבק כמחליף האדם בעבודה חדגונית ומשעממת. אבל, אומרים המחברים, אין כאן תיאור של התכניתנים, של אלה שבנו את הניהול שלו ואת הטעויות שנעשו בדרך.
לא ככה באמת נראות בדיקות אוטומטיותלא ככה באמת נראות בדיקות אוטומטיות
Want to add a caption to this image? Click the Settings icon.
הכותבים רואים בזבוז ענק של משאבים לבדיקות אוטומטיות של GUI במקום מציאת באגים עמוקים. האוטומציה כ"כ מורכבת לפעמים שזה כמו להחזיק עוזרת שמוכנה להיכנס הביתה רק כשהוא כבר נקי. עדיף להוציא את הכסף על אנשים שעושים אינטראקציה מורכבת ומתוחכמת עם המוצר ובהשקעה קטנה יותר להשיג כלים שיעזורו לבודקים לבדוק טוב יותר.
הבעיה מתחילה בביטוי "בדיקות אוטומטיות" כשבפועל הבדיקות מתחילות בצורה יצירתית וקריטית בתכנון.
הביטוי בנוסף דו משמעי: גם הריצה עצמה וגם כל התשתית שכוללת את הריצה.
הכותבים ראו שנוטים לכתוב תסריטים אוטומטיים נאיביים של משתמש זחוח חסר דמיון וזה רץ במהירות גבוהה של משתמש לא רגיל. אבל זה לא מה שבודק עושה. כל אדם מגיע עם מי שהוא לבדיקה. אפשר לעשות סימולציה של חלק ממה שמשתמש עושה אבל לא לשכפל אותו.
איך לשנות את זה?
א. לקרוא להם כלים ולא אוטומציה, להבין שהם זקוקים להדרכה אנושית ועוזרים לאדם להשיג עוד יכולות. להבין שאדם עושה הרבה יותר: האדם משתפר, חושב, מרגיש וכד'. הבודק האנושי ער לשינויים שהאוטומציה לא כמו הבהוב מסך מהיר.
ב. לחשוב על בדיקות כדבר הרבה יותר מאשר בדיקת פלט. בדיקות זה הערכת מוצר ע"י לימוד שלו דרך סיור וניסוי שכולל ברמה מסוימת שאילת שאלות, לימוד, יצירת מודלים תיאורטיים, צפייה והפרעה וכד'. רק אנשים יכולים לעשות את זה ולהחליט על הערך. הבודק מחליט איפה להתחיל את הבדיקה, מהו באג.
זה מה שקורה כשמישהו אנושי בודק:
- we design our testing by learning and modelling the product, determining test conditions to cover, generating specific test data, identifying and developing oracles (i.e. the means to recognize problems when we encounter them), and establishing procedures to explore and
experiment.
- we interact with the product by configuring, operating and observing it.
- we evaluate the product by using appropriate oracles to detect inconsistencies between the product and qualities that we might consider ideal.
- we record and report the testing work that has been done.
- we manage the testing work, which includes understanding the current status of testing, analyzing product risk, scoping and assigning testing tasks.
המחברים מפרידים בין ווידוא (checking) שזה תהליך שמעריך ע"י הפעלת אלגוריתם של חוקי החלטה ובדיקה ספציפית של מוצר. במילים שלי: כשרק מעניין אותנו לוודא שכשעושים א' ב' ואח"כ ג' יוצא כתוצאה דטרמיניסטית ד'. לזה אפשר לעשות אוטומציה. אבל זה לא כל הסיפור על המוצר, כי את הסיפור המלא רק אדם יכול לעשות. ווידוא זה חלק מהבדיקות.
המחברים סקפטיים לגבי ווידוא של GUI. התחזוקה רבה יחסית כי ה-GUI משתנה לעיתים תכופות והפיתוח ארוך יותר.
ג. מצא את הדרכים הרבות להשתמש בכלים. במאמר עצמו יש רשימה של מתי כלים עשויים לעזור לנו.
בחר כלים בהתאם להקשר, כלומר לסט הגורמים שאמורים להיות בשיקול קבלת ההחלטה. זה אומר להתחשב ב:
מה שמקיף אותנו ואת מקומנו בעולם.
את הלקוחות שלנו ואת המשימה שלנו.
אנשים אחרים המעורבים ומה הם מנסים לעשות.
כלים וטכנולודיות שנגישים לנו.
פעולות שאנו יכולים לעשות וההשפעה שעשויה להיות להן.
המחיר (והזמן) המיידיים של פעולות אלו.
המחיר לטווח הארוך של פעולות אלו.
הערך של לימוד מניסוי בכלים חדשים.
קשה להצליח בבחירת הכלים מהפעם הראשונה וזה בסדר. זה הרעיון של CDT - שאין פתרון קבוע מראש ולהבין את חסרונות הכלים שבחרנו.
בגישת CDT אנו מעדיפים:
כלים שעשויים לעזור לכמה מטרות ולא רק לאחת. למשל כלים שמתממשקים להרבה כלים אחרים, תומכים בהרבה פורמטים.
עדיף כלים זולים או חינמיים מכלים יקרים כולל כאלה שהם חזקים. זה נובע מכך שההנהלה תתקשה להחליט לזנוח את הכלי גם אם הוא לא טוב בגלל מחירו. בנוסף כלים חינמיים גורמים לנו להתנסות בטכניקות שונות וזה מפתח את החשיבה והיכולות שלנו.
כלים שדורשים יותר תמיכה ושליטה אנושית עדיפים. זאת כיוון שכלים כאלה גורמים לנו לאבד את היכולות שלנו.
כלים שנתמכים ע"י קהילה גדולה ואקטיבית עדיפים.
עדיף כלים שאינם דורשים מומחים. זול להתחיל לעבוד איתם, קל לתפעל אותם ולא בעלי שפה מיוחדת ולא דורשים הרבה להעברה או הדרכה.
כלים שבשליטתך עדיפים, כמו אופן-סורס.
כלים שהם פורטביליים למספר פלטפורמה עדיפים.
עדיפים כלים שקל לעשות להם דיפלוי.
השקיעו בטסטביליות. הצלחה בכלים תלויה מאוד בכמה קל לטכנולוגיה שאתה משתמש בה לתקשר עם כלים. לכן עדיף לפתח טסטביליות במוצרים שלך, כלומר שקל לתפעל אותם בעזרת סקריפטים ושכלים יכולים לעקוב אחרי הסטייטים והפלט שלהם. למשל מוצרים עם קונטרולים (אלמנט בממשק משתמש גראפי) סטנדרטיים קלים יותר מאשר כאלה עם קונטרולים ייחודיים.
כדאי לוודא שכך נבנה המוצר בריוויו של כל איטרציה או לוודא שזה קיים כתהליך מתחילת הפרויקט.
המאמר ממשיך בתיאור שלשה מקרי בדיקה ודיון על הבעייתיות של יישום אוטומציה על GUI.
אין תגובות:
הוסף רשומת תגובה