כיצד לשקף לארגון את התרומה של בדיקות האוטומציה לתהליך הפיתוח?

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

הבעיה: חוסר שיקוף של הערך של בדיקות האוטומציה בארגון

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

המצב הרווח כמכשול או כאתגר

פידבק מהיר הוא עניין יחסי והוא מותאם לכל ארגון לפי שיטות העבודה שלו. ישנם ארגונים שמממשים תצורה של CI/CD כך שהפידבק יתקבל לאחר כל pull request, וישנם ארגונים שמריצים את הטסטים שלהם לפי תזמון אוטומטי או ידני פעם ביום. בכל מקרה, לאחר הרצת הטסטים יתקבל דו"ח התוצאות (להלן 'הדו"ח הגולמי') שישקף לצוות האוטומציה אילו טסטים עברו ואילו טסטים נכשלו. בנקודה זו מה עושים בדרך כלל צוותי האוטומציה? הם מנתחים את התוצאות ומעבירים את הממצאים למי שצריך באימייל, מסרונים וכו'. חלקם אף משתפים את הדו"ח הגולמי לבעלי עניין. הם יכולים לעבוד בצורה כזו הרבה זמן ואם הם עדיין יישארו בתפקידם, עדיין אנשים רבים לא יבינו מה הערך שהם נותנים לארגון.

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

הפתרון: דו"ח סיכום יומי של הטסטים

הפתרון הוא פשוט אך דורש קצת עבודה שמאד תשתלם לכם (אגב, ניתן לאטמט את התהליך באופן חלקי). לשם הדוגמה, נניח שיש לכם ריצת לילה של טסטים לבדיקת מערכת. הדבר הראשון שנעשה בבוקר אחרי הקפה הוא לנתח את הדו"ח הגולמי. כעת נרשום את הממצאים בדו"ח חדש שנקרא לו דו"ח הסיכום היומי. בדו"ח הסיכום היומי נרשום כמה טסטים עברו, וכמה טסטים נכשלו. לגבי כל אחד מהטסטים שנכשלו ננתח את סיבת הכישלון בצורה הכי מעמיקה שניתן ונסווג את הסיבה לכישלון כ: באג/סביבה/טסט תקול/טסט לא יציב וכו'. לאחר סיווג הטסט נכתוב מי האחראי (owner) של התקלה מעתה; למשל, אם מצאנו שמקור הנפילה של הטסט הוא באג במערכת הנבדקת, נרשום את מספר הבאג וה-owner  של הבאג. אם הטסט לא יציב, נרשום את שם מפתח האוטומציה שצריך לייצב את הטסט. את הדו"ח המלא נשלח בכל יום לרשימת תפוצה קבועה וכמובן לכל מי שמופיע בדו"ח כ owner של הנושא שעלה מהטסט שנכשל.

התוצאות: השפעות של הדו"ח על המוצר ועל הצוות

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

דו"ח הסיכום היומי - דוגמה