Your SlideShare is downloading. ×
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
QA testing developer by Ziv
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

QA testing developer by Ziv

634

Published on

הגיגים בנושא בדיקות תוכנה לאנשי בדיקות ולמפתחים. …

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
634
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×