Skip to content
14 ביולי 2011 / kirschilan

לבדוק או לבדוק, זאת השאלה


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

Source: http://farm1.static.flickr.com/32/47551096_be4d6ca9a4_d.jpg

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

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

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

רעיון זה נתמך על ידי הרעיון של user stories: את ה DoD (Definition of Done) מומלץ להגדיר בצורה של בדיקות. במלים אחרות, ה Product Owner יגדיר מראש את סט הבדיקות שיש להריץ בסוף הספרינט, ואת סט התוצאות שיש לצפות לו כשמריצים את הבדיקות הללו.

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

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

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

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

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

ועוד לא אמרנו מילה על TDD. או על קוד נקי. או על CI. או על…

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

מודעות פרסומת

2 תגובות

להגיב
  1. אלעד סופר / יול 15 2011 10:02 pm

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

    • kirschilan / יול 16 2011 8:29 am

      ברכות יימסרו 🙂
      אמנם נדיר, אבל זה כיף לראות צוות כזה. הכי כיף לראות שבאמת כיף להם לעבוד כצוות!

להשאיר תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s

%d בלוגרים אהבו את זה: