Downloaded 13 times
Uploaded byRam Yonish
QA testing developer by Ziv
הגיגים בנושא בדיקות תוכנה לאנשי בדיקות ולמפתחים. נכתב והעובר ע"י זיו מנדל, מנכ"ל משותף, טאקט בדיקות תוכנה, ג\'ון ברייס ומטריקס גלובל במסגרת כנס SQAT 2010
QA testing developer by Ziv
- 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