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

1. ‫איכות , בדיקות ,הצלחה והגיגים‬
‫...‬
‫מה אני צריך לעשות למען האיכות של‬
‫הקוד שלי ?‬
‫‪ziv@johnbryce.co.il‬‬
‫טאקט - 0006419-80‬
‫‪www.tact.co.il‬‬
‫1‬

2. ‫רוצים להגיע רחוק‬
‫אבל צריכים להזהר ....‬

3. ‫מטרות ההרצאה‬
‫• לעלות את המודעות לחשיבות של איכות הקוד ובעיקר‬
‫לעלות את המודעות לחשיבות של תפקיד המפתח‬
‫ביצירת קוד איכותי‬
‫• הצגת מספר הגיגים על תפיסת העולם והגישה של‬
‫המפתח בפיתוח הקוד והצגת מספר טכניקות ודרכי‬
‫פעולה לייצר קוד איכותי יותר‬
‫3‬

4. ‫מה קורה למוצר שלא דובאג מספיק‬

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

6. ‫שלושת חוקי הבאגים‬
‫• בכל תוכנית יש באג‬
‫• בין כל באג לבאג יש עוד באג‬
‫• באג מביא חבר‬
‫• והחוק הכי חשוב (הדיבר הרביעי) : היצירה של הבאגים איננה‬
‫אקראית, איננה מקרית ואינה "מכת מדינה משמיים". מדובר‬
‫בתופעה שאפשר להלחם בה גם ברמת המניעה וגם ברמת‬
‫הגילוי והורדת עלות הנזק‬
‫6‬

7. ‫הכל משמיים - ומה שצריך לקרות יקרה‬

8. ‫מספר הגיגים על החוק הרביעי‬
‫• לאורך השנים נכנסו מתודולוגיות ושיטות עבודה במקביל לעליה בסיבוכיות‬
‫, בגודל ובמורכבות של המערכות והטכנולוגיות‬
‫• מי שלא הולך קדימה ... הולך אחורה ....‬
‫• ולמרות העליה של כל הפרמטרים ... אנחנו רואים שיפור במגמת של‬
‫איכות הקוד והתוכנה ( לא מספיק עדיין , אבל יש מגמת שיפור ברורה)‬
‫• במחקר על המקומות בהם נמצאים הבאגים הסתבר שלמרות שיצירת‬
‫הבאג נתפסת "כטעות אנוש" יש תבניות פעולה דומות בין כל הבאגים (‬
‫שאלה למחשבה : איכן נמצאים רב הבאגים בתוכנה ?)‬
‫• המסקנה ניתן להלחם בכמות ובאיכות של הבאגים וניתן להוריד את‬
‫העלות של יצירת הבאגים בתוכנה .....‬
‫8‬

9. ‫כלכלת האיכות והבדיקות‬
‫• ניתן להוריד את עלות הכשל הנובעת מהבאגים שאנחנו‬
‫מייצרים‬
‫• עלות המניעה – זולה בסדר גודל מעלות התיקון‬
‫• עלות הגילוי המוקדם – המפתח לשיפור בעלות התיקון‬
‫9‬

10. ‫עלות התקלה ואי החשיבה מראש‬

11. ‫זיהוי ותיקון תקלות בשלב מוקדם בתהליך הפיתוח‬
‫‪back‬‬
‫11‬

12. ‫הצד השני של גרף בוהם‬
‫• עלות התיקון לא רק עולה אלא גם איכות התיקון יורדת ככל‬
‫שנגלה מאוחר יותר את הטעות .....‬
‫• הפרדוקס של גרף בוהם כשהוא מגיע לשולחנו של המפתח :‬
‫• ההשקעה בגילוי ובבדיקות נעשית בעיקר בסוף ( מתי שיש‬
‫לנו את העלות היקרה ביותר ואת האיכות הגרועה ביותר‬
‫לתיקון)‬
‫• התובנה : צריך לעשות יותר בדיקות ויותר בקרה בשלבים‬
‫מוקדמים של הפיתוח ( קרי באחריות המפתח)‬
‫21‬

13. ‫תפיסת גוף הבדיקות על ידי הפיתוח – הטעות הקלאסית‬
‫• בשביל מה יש גוף בדיקות מרכזי ובודק תוכנה בפרויקט שלי ?‬
‫• שהם יגלו את הבאגים ... אני עסוק ביצירת הקוד הבא שלי‬
‫(והבאגים החדשים שלי)‬
‫• זה לא באג זה פיצ'ר‬
‫• הם מטרידים אותי כל הזמן בשאלות .... בשביל מה הם‬
‫מקבלים כסף ... בשביל להפריע לי‬
‫• התוצאה – גופי הבדיקות מקבלים הרבה יותר באגים ולא‬
‫משקיעים את הזמן בבדיקות הסופיות והאינטגרטיביות‬
‫(המטרה העיקרית שלהם)‬
‫31‬

14. ‫למה מתכוון המתכנת כשהוא אומר...‬
‫בלתי אפשרי בעליל – אין לי מושג איך עושים את זה.‬
‫בלתי אפשרי - אין לי כוח לעשות את זה.‬
‫קשה – אצטרך לקרוא תיעוד.‬
‫באופן כללי, אפשרי – רק אתמול הורדתי מאינטרנט ספריה שפותרת את הבעיה הזאת.‬
‫עובד – מתקמפל.‬
‫אני מלטש את זה – לא מתקמפל.‬
‫בודק על בעיות לדוגמא – מחפש מצבים שבהם התוכנית לא עפה.‬
‫סביר - בהסתברות של %5.1‬
‫אנו מנסים כמה גישות שונות – עדיין אין לנו מושג מה לעשות.‬
‫אנו מכינים דו"ח מסכם על הגישה החדשה שלנו לפתרון הבעיה- כרגע גייסנו 3 סטודנטים שנה א'.‬
‫אנו ערבים שהלקוח יהיה מרוצה – אנחנו כל כך לא עומדים ב ‪ ,Deadline‬שהלקוח יהיה מאושר כשיקבל לפחות משהו.‬
‫בדיקות קבלה עברו בסדר – לא ציפינו שזה יעבוד.‬
‫צריך לשנות את כל הגישה – הבן אדם היחיד שהבין בזה לפחות משהו, כרגע התפטר.‬
‫כן, כן, נבדוק מה קורה עם זה – שכחו מזה יש לנו גם ככה מספיק על ה ראש.‬
‫תחתמו בבקשה על האפיון – בואו נחלק אחריות לכישלון.‬
‫בא ונשמע את דעתכם – אנו יכולים לשמוע את דעתכם, כמובן, כל עוד מה שאתם אומרים לא משפיע על מה שכבר עשינו.‬
‫שנים של פיתוח - תוכנית אחת בסוף התחילה לעבוד.‬
‫אנו עושים את זה לפי סטנדרטים! – אנחנו תמיד עושים ככה!‬
‫יש הרבה גורמים שמשפיעים על זה – תשכח מלקבל תשובה נורמאלית.‬
‫אנו על סף פריצת דרך – בפעם האחרונה התוכנית כמעט עבדה!‬
‫יש לתוכנה תמיכה מלאה – אנו מבטיחים לשלוח עוד גרסה, אם הקודמת לא תעבוד.‬
‫יש לתוכנה תמיכה חלקית – אם משהו יקרוס, לא יהיה לכם עם מי לדבר.‬
‫הפרויקט צועד לקראת סיומו בצעדי ענק – אנו מקווים שפרויקט של 62 שבועות יסתיים לקראת סוף השבוע ה 84.‬
‫התוכנה עומדת בתקני איכות – התוכנה התקמפלה בסדר.‬
‫41‬

15. ‫שינוי בגישה של המפתחים כלפי הבדיקות‬
‫•הפתרון : הבנה של המפתח שהחלק‬
‫החשוב של איכות הקוד נמצא אצלו. המטרה‬
‫איננה לסיים את הקוד בזמן אלא לסיים את‬
‫קוד איכותי בזמן ... וזה הרבה יותר קשה‬
‫51‬

16. ‫האמונה ביכולת שלנו מייצרת את האפקטיביות והאיכות‬

17. ‫מה אתה יכול לעשות למען המדינה והמוצר , מפתח יקר שלי ...‬
‫• בתהליך הפיתוח‬
‫• בסיום הפיתוח‬
‫• בתיקון הבאג‬
‫71‬

18. ‫בתהליך הפיתוח‬
‫81‬

19. ‫על ארבעה בנים דיברה התורה‬
‫• חכם - לעשות את הדבר הנכון , בדרך הנכונה‬
‫• תם - לעשות את הדבר הנכון , בדרך הלא נכונה‬
‫• זה שאיננו יודע לשאול - לעשות את הדבר הלא נכון בדרך‬
‫נכונה‬
‫• רשע - לעשות את הדבר הלא נכון , בדרך הלא נכונה‬
‫שאלה מעניינת : מי הטיפוס הפופלארי בקרב המפתחים ?‬
‫והמסקנה ?‬
‫91‬

20. ‫הכוונות הטובות לא מספיקות .....‬

21. ‫בתהליך הפיתוח של ‪Class‬‬
‫• הבנת הדרישות והממשקים (כולל עקרון העקיבות והשלמות)‬
‫• בניית תרחישי הבדיקה לפני ביצוע הקוד‬
‫• תכנון ועיצוב הקוד מונחה בדיקות : ‪test driven - TDD‬‬
‫‪ (development‬חייב להיות חלק משיקולי הפיתוח)‬
‫• כתיבה נקיה והתמקדות בחשיבה בנקודות הרגישות של הקוד (‬
‫כולל תעוד הקוד)‬
‫• כתיבת ה- ‪ J UNIT/N-UNIT‬לכל ה- ‪Class‬‬
‫12‬

22. ‫בסיום הפיתוח‬
‫22‬

23. ‫המפתח בסיום הפיתוח‬

24. ‫בסיום הפיתוח של ‪Class‬‬
‫• ביצוע מבדקי היחידה של הקוד ותעודם (קופסא שקופה וקופסא‬
‫שחורה)‬
‫• ביצוע ‪( CODE REVIEW‬עצמאית , על ידי בן זוג או כלים )‬
‫• בדיקות רמת הכיסוי של הבדיקה ( בעזרת כלים – כמובן עדיף)‬
‫• תעוד הנקודות הרגישות ....‬
‫• העברת הידע הנדרש והתמיכה לגוף הבדיקות‬
‫• ביצוע בדיקות אינטגרציה (עדיף בסביבה נפרדת) טרם העברת‬
‫הגרסה לבדיקות (כולל בדיקות ‪ sanity‬אוטומטיות)‬
‫• להכניס לתהליכי בדיקות שוטפים ‪Continuous integration‬‬
‫(חשוב מאוד לתהליכי הפיתוח שהביצוע של הבדיקות יתבצע‬
‫בצורה הדרגתית שוטפת ואוטומטית)‬
‫42‬

25. ‫בתיקון הבאג‬
‫52‬

26. ‫בתיקון הבאג‬
‫• שחזור הופעת הבאג במסגרת ה- ‪J-UNIT‬‬
‫• ביצוע חוזר של הבדיקות ( ולא רק של מה שתיקנו)‬
‫• תעוד במערכת הבאגים של מהות הבאג ובעיקר תעוד‬
‫ההשפעה של התיקון על הקוד ותעוד הבדיקות שנעשו (אם‬
‫צריך מעדכן ומוסיף ‪)J-UNIT‬‬
‫• העברת הידע לבודק כולל מפת ההשפעה האפשרית של‬
‫התיקון ( ואפשר לתת לו גם משוב חיובי על גילוי הבאג )‬
‫• ניסיון להבין מדוע נוצר הבאג , איך היה אפשר למנוע אותו ואיך‬
‫אפשר למנוע את הבאגים הבאים‬
‫62‬

27. ‫ולסיום כל אחד יכול ....‬

28. ‫אפקט 84 שעות‬
‫"אתה יכול להוביל סוס מת אל הנהר, אבל אתה לא יכול להכריח אותו לשתות“‬
‫-- ראש העיר טורונטו, אלן למפרט‬

29. ?‫שאלות‬
www.matrix-global.net
29 www.matrix-global.net