אסטרטגיה של אוטומציה - חלק א

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

לא אחרי הרבה זמן הם באים, אנשי בית התכנה, חדורי מוטיבציה והיבריס. אנחנו יושבים אתם יום - יומיים, קצת מסבירים על המוצר, קצת על הבדיקות ואז נותנים להם כמה ימים לחשוב על פלטפורמה, אבל לוחצים אותם שיקרה מהר (אף אחד לא חושב שעד כה לא הייתה אוטומציה וזה עבד, ואולי כדאי לחכות עוד קצת זמן שיספיק בכדי שנוכל לעשות בחירה נבונה).אח"כ אנחנו נותנים להם אחר כבוד את מסמכי הרגרסיה ושואלים כמה זמן (וכסף) זה ייקח. ארבעה חודשים נאמר לנו. בטוחים? "אולי אולי חצי שנה, אם יהיו בעיות שלא ציפינו להן." כן, גם אם נגייס כותב קוד אוטומציה חדש הוא גם לא ירצה לומר שזה ייקח לפחות תשעה חודשים ובוודאי שלחברה חיצונית יש אינטרס להכניס רגל בדלת. אף אחד לא אומר שאנשי האוטומציה יצטרכו ליווי תכוף של בודק (כי הם לא מכירים את המוצר) ושל מפתח (שיעזור בהתממשקות ובדיקות עמוקות יותר). גם ה"חצי שנה" נראה לנו הרבה, אנחנו חושבים, אבל נחכה. למנהלים נסביר שתוך חודשיים כבר נרוויח ימי עבודה יקרים ועובדים בלתי נראים שיעבדו בכל לילה. אחרי שבוע יש תסריט ראשון, אנחנו מציגים לקבוצה / חברה, כולל למנהלים, וכולם נדהמים מכפתורים הנלחצים באורח פלא על המסך. וואוו. כל הכבוד לכולם! ההמשך לרוב די צפוי. רומפלשטילץ לא מגיע ולכן יש ריצה מטורפת להספיק כמה שיותר. לא חושבים על השאלות החשובות כמו לאיזו שכבה לעשות אוטומציה, האם פשוט ל"תרגם" את מסמכי הרגרסיה ועוד. חצי שנה אח"כ לא רק שאנו לא קרובים, אלא גם מתוסכלים. לא רק שלא חסכנו: הבודקים הידניים ממשיכים בשלהם, אבל אנחנו משלמים לבית התכנה ולרישיונות ולא רואים החזר באופק. המנכ"ל לא אומר לנו שלום במסדרון והבודקים כבר לא טורחים "לספור" את אנשי האוטומציה. אנו הופכים להיות חלק מהסטטיסטיקה שאומרת שרק 20% מהבדיקות שניתן לעשות להן אוטומציה אכן ממומשות (ראו למשל כאן - רק ב-4% יש כיסוי של 90% ומעלה). 

אז מה היה לנו כאן?
בעיה קשה עם המציאות, והתרכזות בטכנולוגיה - שזה חשוב מאוד (אתם לא רוצים להחליף תשתית באמצע, כמו שקרה בכמה חברות שאני מכיר), אבל לא יותר חשוב מהאסטרטגיה. 

אני מודה, אני מכיר את הנושא כבר הרבה זמן אבל לא רציתי לעלות את זה על הכתב עד עכשיו כי היה לי קשה להיפרד מהידע ולהפיץ אותו כך ש"יִתְמַלֵּט לִלְבַבְכֶם, וּבְאוּר אֶשְׁכֶם הִצַּתִּיו, יִתְעַלֵּם, וְאָנֹכִי בְּחֶלְבִּי וּבְדָמִי אֶת-הַבְּעֵרָה אֲשַׁלֵּם". אבל הנה זה בא. 

 ההקשר הגדול של האוטומציה:

מתוך הספר How Google Tests Software

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

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

“Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc.” James Bach
"Automation testing purpose is to confirm the system is running, which is the opposite of testing." Michael Bolton

אז מהי האוטומציה? האוטומציה היא checking, אימות. היא מאמתת תהליך דטרמיניסטי, ויכולה רק לומר "עבר" או "נכשל". 

נובע מכך שהאוטומציה אינה יכולה "לתרגם" רגרסיות כי היא לא "בודקת". היא יכולה לקחת את החלק "המאמת" של הבדיקות: אם לוחצים על כפתור X במצב Y יקרה Z. אם בדרך ה-UI התעוות ומיד "חזר לעצמו", אנו לא נדע על כך לעולם, לא מהתוצאות של הריצה לפחות.לכן גוגל למשל עדיין מריצים בדיקות end-to-end ידניות. מצד שני, והנה בא החלק החיובי - היא יכולה לעשות הרבה יותר מבודק ללא כלי כמו האוטומציה, כי אכן האוטומציה אינה אלא כלי עזר. מה היא כן יכולה לעשות?

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

ומלבד זאת:

• להכין דטה לבדיקות.
• להכין סביבות.
• להיות (כמעט) רנדומלית.
• לשנות קונפיגורציות.
• מניפולציות של דטה
• לגרום לאלרטים לצוץ
• לאסוף ואפילו לעשות אנליזה ללוגים. 

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

מה הכי חשוב כשאנו כותבים את האוטומציה?
תחשבו רגע.האם עניתם "אחוז הכיסוי"? "המהירות"? טעיתם.הנה הסדר הנכון:

1. קריאות התוצאות. כן, בדיוק, זה מה שאמרתי, התוצאות. אם: - הן לא ברורות: מה בדיוק נבדק, מה בדיוק הייתה התוצאה בשפת דיבור. - הן לא קלות להבנת המצב, כמה נכשלו וכד' במבט אחד. - חסרות צילומי מסך, וידאו ולוגים. - לא מקלות על פתיחת הבאג. - לא מדויקות. - לא מצביעות בדיוק על הבעיה. אז תזרקו אותן אחר כבוד לבית הקברות של הקוד. אם מי שמריץ את האוטומציה, יצטרך לעבוד שלושה ימים בניתוח התוצאות על ריצה של שעתיים שחסכה בדיקות ידניות של יומיים, זה לא יעבוד.
2. מהימנות התוצאות ו/או חוסר יציבות: אם התוצאות אינן מהימנות - אותו כנ"ל. אם בכל פעם הוא יצטרך לשחזר במשך שעות בעיה ובסוף זו בעיה בקוד של… האוטומציה הוא יפסיק לנסות. בעיה זו עלולה להיות אקוטית במיוחד בבדיקות GUI שם דברים רבים עלולים להשפיע על התוצאה.
3. קלות ההרצה - שלושה ארבעה קליקים ו-יאללה הריצה יוצאת לדרך.
4. על הקוד להיות רובסטי ושלא צריך לשנותו לעתים קרובות.
5. על הריצות להיות מהירות (ביחס למוצר). 

על מה נבנה את האוטומציה?
הרבה פעמים אנשים רצים לעשות אוטומציה ל-GUI כי זה נראה הכי טבעי. הבעיה שהבדיקות האלה הופכות ל-obsolete מכיוון שה-GUI נוטה להשתנות תדיר וגם עלול לתת תוצאות שונות ברזולוציות / מכשירים שונים.לכן האוטומציה צריכה להיות כמה שיותר קרובה "לברזלים", ל-API, REST, להרצה של פרוססים וכד'. גם ככה לרוב שם ההיגיון העסקי נמצא.במידה שיש הרבה לוגיקה ב-GUI צריך לשקול מה ייבדק איך. 

 ממה היא תהיה בנויה?
מ-building blocks, כלומר בלוקים שכל אחד עושה פעולה לוגית כמו לוגין, החלפת סיסמה וכד'. כך זה שמריץ את האוטומציה יוכל לבנות סנריו בקלות לפי ההקשר כמו למשל בדיקת תיקון של באג: הבודק יגרור את הבלוקים כך שיווצר סנריו רלוונטי. כך נרוויח גם תחזוקה קלה, מרוכזת וממוקדת.כדאי שתהיה אפשרות לשמירת פלואים שאותם נריץ כרגרסיה.היא תקרא נתונים רבים מקבצים חיצונים (Data-driven testing) כך שנוכל לשנות אינפוטים וגם נמנה אותה בצורה כזו שתהיה "לנו היכולת לבנות טסטים אוטומטיים גם מבלי לדעת קוד" (Keyword-driven testing). 

איך זה יתנהל בפועל מבחינת תפקידים?
כדאי לשקול צוות תשתיות, אנשי אוטומציה שכותבים רק קוד. הם אלא שמכינים סביבות (Virtual Machines, מכשירים סלולריים, אמולטורים), מריצים את הקוד, מייצרים את הדו"ח ועוד.במקרה של אג'ייל (וגם אם לא) הבודקים יכולים לבנות את הסקריפטים עצמם שלמשל שולחים ריקווסטים ובודקים ריספונסים או עובדים על ה-GUI.בד"כ הבודקים מריצים את האוטומציה.במקרה שאין אוטומציה בתוך צוות הבדיקות או צוות האג'ייל, עדיין כדאי שאנשי האוטומציה יכירו את המוצר ויעבדו קרוב מאוד לבודקים. אחרת הם כל הזמן יתעכבו, יבנו דברים לא רלוונטים ובגדול זה כנראה יכשל. 

 עם מה מתחילים?

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

 ובאותו נושא: כאן הגודל לא קובע! זה שיש לכם 500 בדיקות או אלף -  זה לא מרשים. השאלות במקרה כזה יהיו:

• כמה כיסוי יש לכם?
• מתי זה רץ בפעם האחרונה?
• כמה בדיקות נכשלות באופן קבוע?

אם עניתם משהו כמו: 20%, לפני חודש, 10% ומעלה - זה לא עוזר לאף אחד. 

 האוטומציה לא אמורה לספק 100% כיסוי!מה לא כדאי להמיר?

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

כלל אצבע: 80% מהבדיקות הידניות ניתנות להמרה. 

 

איך יודעים שהאוטומציה אכן אמינה בתוצאות שלה?

יש נטייה באוטומציה לשגות ביצירת אימותים שהם False Negative, כלומר הריצה או התוצאה לא מוצאת את הבעיה, כי - לא כתבנו את הבדיקה נכון, כי לא הסתמכנו על מה שמורה על הבעיה ועוד. במקרה כזה אנו חושבים שהריצה (או החלק הספציפי) היא חיובית ואין בעיה כשהמצב בפועל אינו טוב.ישנה גם נטייה ל-False Positive אבל במקרה הזה נבין שיש בעיה ונתקן. 

איך פותרים את העניין של ה-False Negative?

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

 

בחלק השני נדבר על מדידות של אוטומציה ו-Return of Investment.