פרק חדש של "מפתחים מחוץ לקופסה" מארח את אסף בלזמוביץ', VP Test Ops ב-YouCC, שמסביר למה מפתחים כבר לא סומכים על טסטים ומה אפשר לעשות

מאת שחר פולק ודותן טליתמן

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

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

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

יותר טסטים ≠ יותר יציבות

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

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

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

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

המרדף אחר 100% כיסוי הוא טעות יקרה

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

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

לינק לפודסקט: