למה פרויקטי אוטומציה נכשלים?

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

בואו נתחיל מההתחלה. 

אני לא מכיר אף חברת תוכנה שמרוצה מכיסוי האוטומציה וממצב האוטומציה שלה. 

לרוב שיפור האוטומציה יהיה חלק מהמטרות השנתיות - אם ברמת כיסוי באחוזים, אם במספר פיצ'רים חדשים מכוסים או אם בפרוייקטים מרחיקי לכת.

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

למה כרטיס הגרלה? כי בדיוק כמו כרטיס הגרלה, ההצלחה בפרויקטים האלה היא לרוב קטנה. קטנה מאד.

רוב הפרויקטים הולכים לפח הזבל.

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

1. אין יעד ברור לפרוייקט האוטומציה

לא, אחוזים זה לא יעד. 

אחוזים זה אפילו קצת מעליב. 

הייתם יכולים לדמיין פיצ'ר במוצר שחלק מההגדרה שלו זה משהו שקורה באחוזים?

 

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

זה סוגר את הפינה של להגדיר יעדים (וזה כיף למצוא יעד מדיד, כל מי שהגדיר יעדים יודע).

אבל מה אנחנו רוצים להשיג פה בעצם? את היעדים או שיפור אמיתי במוצר?  במקרה הטוב - טיפה (לא מורגשת) בים. 

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

2. האוטומציה באה להחליף את האנשים שבודקים כיום

לא, האוטומציה לא באה להחליף תהליכים של בדיקות קיימות. זה לא ה-State Of Mind הנכון.
תפקיד האוטומציה היא לתת שירות של תמונה עדכנית על מצב המוצר.

כשמתכננים פרויקט אוטומציה, צריך לחשוב על ה-Dashboard הסופי שהתוצאות מוצגות בו.

מחשבה מהסוף להתחלה (TDD משהו..) עוזרת למקד את הפרויקט בדברים החשובים, במדדים החשובים ובתגובות אליהם.

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

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

3. טסטים שכתובים רע

אין מה לעשות, גם זה קורה.

טסטים חייבים להיות נקיים ברמה של אקונומיקה - ברמה כזו שאפשר ממבט חטוף להבין מה קורה שם.

אם צריך להוציא לפונקציות - תוציאו. גם פונקציות של שורה. 
אם צריך לשכפל קוד - תשכפלו. זה עדיף על תלות במשהו שיכול להפיל כמה טסטים או קוד ארוך ולא ברור.

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

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

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

טסט צריך לוודא התנהגות, לא מבנה של קוד.

4. יחס בין השקעה לבין רווח (ROI)

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

כמו כל פרויקט תוכנה - צריך לבצע את הפרוייקט הזה באג'יליות ובשלבים. 

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

הרבה יד על הדופק וראיה סופר ביקורתית היא בגדר חובה.

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

5. חוסר ידיעה של מה יש ומה אין

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

טסטים שאנחנו לא יודעים על קיומם ואין להם Owner ברור, לרוב לא יתוחזקו - מתישהו ישברו וימחקו. 

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

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

6. טסטים שלא רצים או נותנים פידבק בזמן לא סביר

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

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

7. פיזור האחריות על האוטומציה ברחבי הארגון

דמיינו רחוב ריק בהם בו רק אתם ואדם נוסף.

פתאום האדם הנוסף מקבל התקף לב.

סביר להניח שתעצרו ותעזרו לו.

עכשיו דמיינו רחוב הומה באנשים.

פתאום אחד מהאנשים מקבל התקף לב.

סביר להניח שתחכו שמישהו אחר יגש אליו.

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

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

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

---

ובנימה אישית -  יצא לי להיות חלק מפרויקטי אוטומציה של Unit Test, של Integration Tests ושל UI Tests. 

בחלק מהפרוייקטים הייתי בורג קטן, בחלק בורג מרכזי. 

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

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

לסיכום:

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

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

זהו.

בהצלחה לכולם.