-->

יום שני, 3 באוקטובר 2011

איכות תוכנה - ארגז כלים (3)

המשך ל פוסט 2: איכות תוכנה - ארגז כלים

מחפשים כיצד לשפר את איכות התוכנה ומחפשים אחר ה Best Practices בתעשייה?

בטבלה למטה ריכזתי את הטכניקות העיקריות שעברו את מבחן ההוכחה בתעשייה. ציינתי גם התייחסות כמה אתם יכולים לצפות לשיפור באיכות הפנימית (IQ - Internal Quality) או החיצונית (EQ - External Quality). אנשים לדוגמה מופתעים ש Unit Tests לא תופס הרבה באגים - אבל זו עובדה מוכרת. לעומת זאת טכניקות כמו Code Inspection ו TDD פחות מוכרות ברחבי התעשייה - אבל מניסיוני הן אפקטיביות ביותר. שימו לב שהטכניקות הקלות יותר להטמעה הן אלו שנפוצות בקרב האירגונים - זה דבר טבעי.

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

בתחתית הטבלה ציינתי עוד כמה נקודות חשובות.

טכניקה
השפעה על איכות חיצונית EQ
השפעה על איכות פנימית IQ
כמות השקעה
קושי הטמעה
הערות
תהליכים – לרוב קורים לפני או בזמן הפיתוח. לא מסכנים את הקוד. יעילים בצורה מפתיעה.
CI
לא רלוונטי
בינונית
נמוכה
נמוך
הרצת בדיקה ואינטגרציה בצורה אוטומטית מיד אחרי כל שינוי קוד ולא בסוף גרסת הפיתוח. נקודת פתיחה טובה ובסיס לבדיקות רגרסיה.
Bug Tracking
גבוהה
נמוכה
נמוכה (לארגון)
נמוך
מעקב יסודי אחר כמות הבאגים וקצב הפתיחה / סגירה.עם המדידה באים הלחצים והרעיונות לשיפור. הכרחי!
 Requirements Inspection & verification
גבוהה
עקיפה בלבד
בינונית
בינוני
לעתים קרובות לא נעשה או נעשה בצורה חפיפה. הכוונה להשקעה יסודית בבחינת ואימות הדרישות.
 Formal Design Inspection
נמוכה
גבוהה
בינונית
גבוה
לעתים קרובות לא נעשה או נעשה בצורה חפיפה. בחינת אלטרנטיבות אמיתיות וסיבות על כל שינוי מהותי במערכת שנבע אפילו מתיקן באג – לא אותם מסמכים שמתארים את המובן מאליו מתובל ב interfaces וקוד!
גבוהה
גבוהה
בינונית
בינוני עד גבוה
קריאה אינטנסיבית של קוד ללא מחשב + דיון. זהו לא ה  freestyle Code Review שעושים לעתים בארגונים.
Peer Review
נמוכה
בינונית
נמוכה
נמוך עד בינוני
ישיבה עם מתכנת או ראש צוות עד רבע שעה לפני check-in 
בדיקות רגרסיה – מגבירים את הביטחון והיכולת לבצע refactoring בבטחה. כיסוי גבוה נדרש להשגת האפקט.
Unit-Tests
נמוכה
בינונית
גבוהה
גבוה
לכל class בקוד – בדיקה. נכתב ע"י המפתח. קשה מאוד להטמעה בקוד שנכתב ללא unit tests
Integration / Component Tests
בינונית
נמוכה
בינונית
בינוני
בדיקה ל flow בקוד שכולל מספר classes. נכתב ע"י המפתח.
Acceptance Tests
בינונית
זניחה
בינונית
בינוני עד גבוה
בדיקת black box למערכת עצמה, הזרקה של input ובדיקת התוצאות. נבדק לעתים קרובות ע"י "צוות אינטגרציה"
GUI Tests
בינונית
זניחה
גבוהה
בינוני
בדיקת ה UI ע"י כלים שמדמים browser (כמו Selenium). בדיקות קשות לתחזוקה אך הדרך האוטומטית לבדיקת GUI.
TDD
זניחה
גבוהה
בינונית
בינוני
טכניקה משופרת לכתיבת unit-test, משפר את המודולריות בקוד, יעילות כתיבת הבדיקות וכתיבת בדיקות יציבות יותר. כיף חיים!
אחרים
גבוהה
זניחה
גבוהה
נמוך
צוות QA שעובד בצורה נבונה ומתמקד בבדיקת הפונקציות החשובות והמורכבות של המערכת
Testing Tools
נמוכה
זניחה
בינונית
נמוך
השקעה בכלי עזר שיעזרו למפתחים ו QA לבדוק מהר יותר וטוב יותר. מאפשר למפתחים לבדוק יותר ולהתעייף פחות.
נמוכה
זניחה
בינונית
גבוה
העמדת המערכת בעומס גבוה לראות מה נשבר ראשון. לרוב מגלה מספר מצומצם של בעיות, אך בעיות שהיו קורים אצל לקוחות.
Alpha / Beta Test
בינונית
זניחה
נמוכה
גבוה (מחוץ לפיתוח)
להגיע ללקוח מהר עם מוצר לא גמור ולבדוק את המוצר אצלו ובעזרתו. מסייע לאימות Requirements שיכול להיות קריטי להצלחת המוצר!
Static Code Analysis
בינונית
נמוכה
נמוכה
נמוך
כלים אוטומטים שמנתחים את הקוד למצוא בעיות. PMD, Find bugs ו CheckStyle הם המפורסמים בג'אווה, כאשר יש כלים כמו Sonar או פלאג-אינים כמו QA Plug שמרכזים את כולם ביחד.

להוסיף (חשוב!): Eat your own dogfood

עוד כמה הערות:

Formal code / design / requirement inspection - כמו שניסיתי לציין בטבלה יש הרבה ארגונים שעושים חלק מזה, אבל בצורה לא יסודית ולא יעילה. ראיתי המון מסמכי designs בחיים שחבל שנכתבו. הרבה ישיבות design או requirements review שהיו ריקות מתוכן כי לאלו שאמורים לעשות את הביקורת לא היה ידע מספק "לעשות את העבודה". לסיכום: קל ליפול בטכניקות הללו לביצוע בינוני בלי לשים לב.

בדיקות רגרסיה
הסוגים השונים של הבדיקות הן לא כ"כ אלטרנטיבות אחת לשנייה, אלא יותר משלימות. רגרסיה טובה כוללת הרבה unit-tests, מספר לא מבוטל של integration ו acceptance tests ומעט GUI Tests (פרמידת הבדיקות). פוסט טוב שמסביר קצת יותר ניתן למצוא כאן.

עוד נקודה חשובה על רגרסיה ואוטומציה בלבד היא שאוטומציה לא תמיד משתלמת. ישנם אזורים רבים בקוד שכמעט לא יישברו ועלות הבדיקה שלהם יקרה. חשוב לחוש את ה tradeoff ולהיות מסוגלים להשקיע בצורה נבונה "כלכלית".

כלי ניתוח קוד סטטים - הכלים הנ"ל כוללים המון חוקים מיותרים. חשוב לסנן את החוקים החשובים  ולהתמקד בהם, אחרת הדו"חות המופקים יכולים להיות מטרד לא קטן -

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

בהצלחה!

3 תגובות:

  1. לא ברור מדוע אתה קורא לשלבי הבדיקות "רגרסיה",
    בכל שלב בדיקה יש את הפעם הראשונה שהבדיקה מתבצעת, ויש את בדיקות הרגרסיה אשר מוודאות כי שום דבר בלתי קשור לא ניזוק כתוצאה משינוי או הוספת תכונות למוצר.
    (השינויים עצמם נבדקים כפרוגרסיה ע"פ הצורך)

    halperinko - Kobi Halperin@

    השבמחק
  2. מנסים לשפץ את איכות התוכה באצעות ארגזי כלים מתאימים

    השבמחק
  3. ארגז כלים כזה יתחזק לך את התוכנה

    השבמחק