מאת: רם יוניש, סמנכ"ל שיווק ומכירות, טאקט בדיקות
אני לא סטיבן הוקינג וזה ממש לא מאמר על חורים שחורים (למרות שלחלק מהאנשים זה נשמע ככה)
המאמר מנסה לסקור מגמה שמלווה אותנו הרבה מאוד זמן וצוברת תאוצה בעיקר בשנים האחרונות של קיצור משכי הפיתוח וזמני הבדיקות. בנוסף לסקירת המגמה אנסה לתת גם כלים/ טיפים לבודקי תוכנה עבור כל אחד ממודלי הפיתוח בהווה ובעתיד הקרוב/ רחוק.
מנהל פרויקט בכיר, שנחשד בציניות קלה, אמר פעם: "זה מרגיש כאילו אני תקוע בין השמרנים לבין האג'יליסטים אנחנו לא יכולים להשתמש במודלים מסורתיים של מעבר בין שלבים, כי זה לא מספיק "זריז" (agile), ובפעם האחרונה, כאשר את ניסינו להטמיע scrum נכשלנו כישלון חרוץ. האם אין גישה נכונה ומתאימה יותר לפרויקטים שלנו? "
במאמרה של ג'ואנה רוטמן (ראו קישור בתחתית הכתבה) היא מתארת את ההתפחות האבולציונית של מודלים למחזור חיי הפיתוח לאורך השנים. ג'ואנה מתארת 4 מודלים שונים שלכל אחד מהם התפתחו טכניקות מתאימות: Serial model (waterfall, V model), Iterative model (spiral), Incremental model and Agile (scrum, xp, kanban…)
המודלים הבאים מתוארים לפי סדר כרונולגי, מהמיושנים/ מסורתיים לחדשים יותר.
מודלים סידרתיים (Serial):
מחזור חיים סדרתי הוא כזה שבו כל השלבים מופיעים בסדר כרונולגי ברור. יש לסיים שלב אחד לפני שמתחיל השלב הבא (או לפחות דורשים כי אם אתה נמצא בשלב N, יש להשלים את השלב הנוכחי בטרם יתחיל שלב N+2).
המודלים המסורתיים השכיחים ביותר הינם מפל המים ומודל V. מודלים אלו מהווים אחוז ניכר ממחזורי הפיתוח בישראל בכל מגזרי התעשיה ובעיקר בארגוני IT (כגון: בנקים, ביטוח, קופות חולים, חברות אשראי, חברות סלולר ומשרדי ממשלה) ובחברות ביטחוניות ורפואיות המצריכות תהליך מסודר ומתועד ברמת פירוט גבוהה.
תרשים מודל סידרתי/ סיריאלי:
מודלים איטרטיביים (Iterative):
במודל האיטרטיבי, אנחנו קודם כל מפתחים אב טיפוס (prototype) של רכיבי המוצר/ מערכת ורק לאחר שמאשרים אותו מתחילים פיתוח מסודר. לעיתים שומרים את הקוד שנכתב לצורך אב הטיפוס ולעיתים זורקים אותו, אבל העיקרון הוא למצוא דרכים יעילות לבנות אב טיפוס שמדגים מה הרכיב/ המודול צריך לעשות בצורה הטובה ביותר ובשלב מוקדם.
במחזור חיי פיתוח איטרטיבי משתמשים בעיקר בחברות מוצר ובחברות startup שכן יש יתרון ברור להציג אבטיפוס טרם התקדמות בפיתוח המוצר.
תרשים מודל איטרטיבי:
מודלים "מצטברים" (Incremental):
במודלים אינקרמנטלים מפתחים את המערכת ב"חבילות". "החבילות" יכללו בדרך כלל מודולים סגורים של המערכת, שפותחו בצורה מלאה. ככל שמייצרים יותר מודולים כאלו המערכת שלמה יותר.
בשיטות האינקרמנטליות משך הפיתוח של כל מודול מתקצר וכולל בתוכו את כל השלבים האופייניים למודלים הסדרתיים (דרישות - אפיון – פיתוח – בדיקות ).
החסרון במודלים אלו הינו בכך שמשך בדיקות הרגרסיה המצטבר ארוך יותר אך מאידך במידה ומבצעים אותם נכון (מסיימים קודם כל לפתח חבילות הקשורות להיבטים תשתיתיים/ רוחביים ורק אחר כך פיצ'רים) ומשאירים מספיק זמן לבדיקות אינטגרציה ו- E2E אזי המוצר יקבל פידבק מוקדם יותר ויהיה מתאים יותר לצרכי הלקוח.
המודל האינקרמנטלי מעניין מאוד אבל אין הרבה חברות שמשתמשות בו, או שיש חברות שמשתמשות בו אבל קוראות לו אחרת...
תרשים מודל אינקרמנטלי:
מודלים "אג'ילים" (agile):
המודלים האג'ילים צצו כפטריות שלאחר הגשם בעיקר על מנת לתת מענה לאתגרים של "העת החדשה" כגון הצורך בגמישות רבה מאוד וזריזות בפיתוח ומענה לצרכי השוק.
במודלים האג'ילים (זריזים) משכי הפיתוח מתקצרים מאוד ומוגדרים בתוך time box של שבועיים עד חודש בדרך כלל. ב- scrum לדוגמא, מגדירים את רשימת הפריטים שיש לפתח (feature back log) ומתעדפים אותם. כל "צוות משימה" בוחר לעצמו את הפריטים אותם הוא מסוגל לפתח ואחראי להצלחת הרכיב. כל time box או ספרינט כולל את כל ה"שלבים המסורתיים" ביחד, כלומר,אפיון הרכיב,פיתוחו ובדיקתו, כך שבסיום הספרינט אותו רכיב למעשה מוכן להטמעה בסביבת הייצור או כחלק מהמוצר בסביבת Pre-production.
קיימים מודלים נוספים מלבד scrum, כגון: KanBan, Lean, XP ו- DSDM. על מודלים אלו תוכלו לקרוא במאמר על "בדיקות בסביבת agile שפרסמנו במהדורה הראשונה של המגזין באוקטובר 2010.
מתוך כל המודלים הנ"ל scrum זה ללא ספק המודל שתפס הכי חזק בישראל. ניתן לראות היום הרבה מאוד גופים שמנסים להטמיע scrum בכל מיני דרכים והתאמות למבנה והצורך הארגוני. עם זאת, לדעתי המודל הזה מתאים בעיקר לחברות מוצר ולחברות הזנק (start up) ופחות לחברות מסורתיות, ארגוני IT וחברות מהתחום הביטחוני והרפואי.
אחת הבעיות בהטמעה של מודלים אלו הוא הקיבעון המחשבתי של אנשי בדיקות מנוסים שמבחינתם "ללא מסמך אפיון לא ניתן להתחיל לבדוק". חשוב להבין את הבעייתיות והשינוי הנדרש מחברה שרגילה לפתח מוצר/ גרסה בטווח של שנה ועוברת לשיטה שבה בכל 3 שבועות מוציאים "חלקי מוצר" עובדים וגמורים לייצור.
על מנת להצליח לעמוד בלוחות זמנים קצרים כאלו המודלים האג'ילים כוללים בחובם עוד לא מעט טכניקות ושיטות לייעול הפיתוח והבדיקות כגון: פיתוח מונחה בדיקות (TDD), פיתוח בדיקות קבלה במקביל לפיתוח הפיצ'רים (ATTD), שימוש נכבד ב- exploratory testing כשיטה מובילה לבדיקות, הטמעת תהליכי אוטומציה בפיתוח ובבניית בילדים (continuous integration) והרבה שימוש בתעדוף על בסיס ניתוח סיכונים (risk based testing).
תרשים מודל Agile:
כיצד מודלים אלו משפיעים עליי כבודק תוכנה?
המודלים האג'ילים, ו- scrum חטכניקה מובילה, למעשה משנים את התפיסה הקלאסית של שלבי פיתוח. בנוסף, בשל לוחות הזמנים הקצרים מתבצע בדרך כלל מעט מאוד תיעוד בתהליך.
לנו כבודקים המשמעות היא שאין זמן לכתוב תכנית בדיקות או תרחישי בדיקות מפורטים ואין זמן לבצע ריגרסיות מעמיקות. במודל זה הבודקים הם חלק מצוות משימה והאחריות לאיכות התוצר היא של כל הצוות ולא רק של הבודקים ("כולם בודקים"). בנוסף, הבודקים משתלבים בתכנון וביצוע הבדיקות למן הרגע הראשון של "האפיון" (user story) ובמהלך הפיתוח עצמו. במודלים אלו אנו נדרשים ומחוייבים לבצע הרבה יותר אוטומציה ורצוי גם ממש כחלק ממשימות הפיתוח עצמן (Test Driven Development). לעיתים הבודקים אחראים לפתח את כלי האוטומציה או להכשיר את המפתחים לבצע בדיקות בעצמם (ולבקר אותן)
חשוב מאוד לשים לב שהבודקים לא ייבלעו בתוך צוות הפיתוח. חייבת להיות להם עמדה של כח ויכולת להשפיע על השחרור של הרכיב בסיום הספרינט בהתאם להיקף הבדיקות שבוצע בפועל. לבודקים הנמצאים בתוך צוותי scrum חייבות להיות יכולות מקצועיות גבוהות מאוד וגם יכולות אישיותיות (כמעט ברמה של ראשי צוותים).
מודלים אחרים/ עתידיים:
אז מה העתיד הקרוב/ הרחוק צופן לנו?
אחת המגמות המאוד ברורות, שבאה לתת מענה להתקצרות משכי הפיתוח והבדיקות הינה העברת אחריות רבה יותר לאיכות המוצרים/ גרסאות לצוותי הפיתוח והוספת משימות אוטומציה לשלבי כתיבת הקוד. כבר היום אנו רואים שימוש גובר והולך ב- TDD (test driven development), הוספת תסריטי אוטומציה בתהליכי קומפילציה ובניית בילדים (continues integration) ותכנון תסריטי בדיקות של תהליכים עיסקיים (ATDD) כבר בשלב כתיבת הקוד וביצוע בדיקות יחידה.
בנוסף לאוטומציה, טכנולוגיה וכלים נראה מגמה נוספת של בודקי תוכנה שהם חלק בלתי נפרד מהאנשי המוצר. כפי שחלק נכבד מפעילות הבדיקות תהיה תלויה ביכולת שלנו לפתח תוכנה ותהיה התקרבות וחפיפה בין המפתחים "לבודקים האוטומטיים", תהיה גם התקרבות מאוד חזקה לשלב הגדרת הדרישות והאפיון של המוצר/ מערכת. נראה מהנדסי בדיקות שהם גם מנתחי מערכות, מאפיינים ומנהלי מוצר שמצד אחד מגדירים את דרישות המוצר ובמקביל גם מוודאים שהוא מפותח בהתאם לאותן דרישות.
כיצד מודלים אלו ישפיעו עליי כבודק תוכנה?
נראה יותר ויותר בודקים עם רקע ויכולות של פיתוח תוכנה. בודקים אלו יישבו כחלק מצוותי הפיתוח ויכתבו תסריטי אוטומציה כחלק מהספרינט עצמו.
נראה שימוש גובר והולך בכלי אוטומציה, כלי עזר וטכניקות מתקדמות שיסייעו לנו לבצע בדיקות בכיסוי מספק (לא בהכרח גבוה מאוד) ובאיכות גבוהה.
אם כיום בארגונים משתמשים בעיקר בכלי לניהול בדיקות וכלי אוטומציה בודד, בשנים הקרובות יהיו לכל בודק 5-10 כלים "קטנים" שיסייעו לו לעשות את הבדיקות מהר ויעיל יותר. כלים אלו יסייעו לו לאתר מה חשוב לבדוק (היכן יש סיכוי גבוה יותר למצוא באגים), לצמצם מקרי בדיקה (ראו מאמרו של טלמון בן כנען על all pairs במגזיון הנוכחי), לבנות DATA לבדיקות (ראו מספר דוגמאות מצויינות בבלוג הבא: http://strazzere.blogspot.com/search/label/Test%20Data) להריץ בדיקות (כולל כלים שונים לדפדפנים שונים), לזהות פערים בין נתונים או דפים (שיטה שנקראת blink testing: http://strazzere.blogspot.com/2010/06/blink-tests-in-blink.html) וכמובן לתעד את הבדיקות ואת התקלות (לדוגמא באמצעות: SnagIt, time snapper ).
מי שכבר מכיר את הגרסה החדשה/ העתידית של HP software המחליפה/ משלימה של- QC למעשה יודע שבתוך "החבילה" הזו יש הרבה מאוד יכולות, כמו לדוגמא היכולת לבצע בדיקה ידנית בקונפיגורציה מסויימת של המערכת (נניח Win XP, IE&…) שתרוץ במקביל על עוד 4-5 סביבות שונות (IE 8,9, FF, chrome…). הפיצ'ר החדש הזה שנקרא mirroring מאפשר למעשה לבצע פי 5 יותר בדיקות במשך אותו הזמן.
הדוגמא הזו של HP software, כמו גם יכולות האוטומציה כחלק מתהליך הפיתוח הקימות ב- visual studio 2010 ( and Coded UI MTM) של מיקרוסופט בהחלט מהוות סמן ימני בולט וברור למגמה של השוק.
לסיכום:
השוק משתנה, תהליכי הפיתוח והבדיקות מתקצרים ועימם צצים כלים חדשים ושיטות חדשות לביצוע בדיקות.
להערכתי בשנים הבאות השוק יתחלק לשני סוגי בודקים:
1. איש אוטומציה מומחה שיישב קרוב מאוד לגופי הפיתוח – מחייב יכולות פיתוח גבוהות מאוד
2. בודק ידני מומחה שילמד להשתמש במספר רב של כלי עזר לבדיקות
מי שייקפא על שמריו, לא ינסה ללמוד ולהטמיע שיטות חדשות לבדיקות ייפלט משוק הבדיקות תוך 5-10 שנים מהיום, כי זה יהפוך להיות הסטנדרט בתעשיה (בוודאי במדינות כמו הודו וסין לשם תעבור רוב העבודה ה"פשוטה").
הדרך להתקדם וללמוד שיטות וכלים חדשים מבוססת על סקרנות ולמידה. אני מאוד ממליץ להצטרף לפורומים מקצועיים ולבלוגים מקצועיים בהם ניתן לקבל הרבה מאוד מידע רב ערך. דוגמאות לבלוגים כאלו ניתן למצוא גם בתוך המאמר הזה
שיהיה בהצלחה לכולנו.
רם
מקורות מידע:
Mike Kelly: Agile software testing strategies for managers -