יום ראשון, 23 במרץ 2008

ניהול סיכוני בדיקה או תוכנה

ניהול סיכונים קיים בכמה רמות:
  1. ניהול סיכונים לפרוייקט. כלומר: האם כח האדם מספיק בכדי לעמוד בזמנים, האם יש לבודקים את הידע המתאין וכו'.
  2. ניהול סיכוני בדיקה. מה הסיכון בפיצ'רים החדשים וכד'.
ניהול סיכונים צריך להתחיל ברמת ה-SysRD.
על כל פיצ'ר שעולה שם יש לתת ציון מבחינת הסיכון.
יש שני קריטריונים:
  1. הסבירות שבעייה תתגלה. הציון: מ-1 עד 5, כאשר 1 הוא שאין סבירות, 5 - כמעט בוודאות.
  2. דרגת החומרה שהבעייה עלולה להגיע אליה. הציון: מ-1 עד 5, כאשר 1 הוא שאין חומרה, 5 - המערכת או הפיצ'ר לא יתפקדו.
למשל אם אנו מפתחים מעבד תמלילים והחלטנו להוסיף לו פיצ'ר חדש: שמירה אוטומאטית.
הביצוע הוא קל - בסה"כ פונקציית שממתינה 5 ד' (או כל פרק זמן) ושומרת את המידע. הסבירות לבעייה הוא 1 או 2 (תלוי באפשרויות הקיימות למשתמש).
אבל פיצ'ר כזה הוא קריטי ברמה שאם הוא לא יעבוד, והמשתמש לא ידע על כך, מישהו עלול לאבד מידע חשוב ולתבוע אותנו. לכן החומרה היא 4.
עכשיו מכפילים וזה יוצא 8 במרחב של מ-1 עד 25.
מה שמאוד חשוב להבין שזה כלי עזר, לא מדוייק מתימטית. לכן צריך גם להסתכל בתוצאה ולראות שזה עושה שכל, ואם אתם לא שלמים איתה אתם יכולים לשנות.
מצד שני זה כן חשוב כיוון שקודם כל זה ברמה מודעת, דבר שני זה בכל זאת נותן כלי טוב למדידת הסיכון.
ומה עושים עם התוצאות?
  1. אם יש קבלה ושיתוף בפיתוח הוא יאמץ את המדדים הללו (או טוב יותר - יהיה שותף מלא) וישים לב לפיצ'רים הבעייתיים במובן של code analysis, unit testing וכד'.
  2. להתחיל בכתיבה וביצוע של בדיקות לפי מדדי הסיכון.
  3. לשים לב במיוחד למקרי הקצה בבדיקות.
  4. לתת להן את הזמן הראוי.
  5. אולי לתת לבודק מנוסה יותר לבדוק.
  6. אולי יהיה מקום ליותר בדיקות רגרסיביות.
את הערכת זמן הבדיקות יש לחלק לשלוש:
  1. בדיקה של הקריטי (נניח ציון מ-16 עד 25)
  2. בדיקה של ה-medium (נניח ציון מ-8 עד 15)
  3. בדיקה של ה-low (נניח ציון מ-1 עד 7)
ואז ניתן לומר: להבטיח שאין באגים קריטיים יקח לי 5 ימים לצורך הדוגמא, בינוניים 3 ונמוכים שניים.
דבר אחד חשוב יש לזכור: לפעמים אפשר לטעות ולא לצפות לכל הבאגים. לכן עדיף להשלים מחזור בדיקות הכולל את המוגדרות כביינוניות.
בנוסף, ייתכן שלאחר זמן בדיקות מסויים נקבל ביטחון בגרסה וניתן יהיה אף להוריד מספר מסויים של בדיקות.

2 תגובות:

  1. דורון אשמח אם תפרט איך מגדירים סבירות שפיצ'ר יעבוד או לא.
    לדוגמא:בדיקת אתר שמוכרדברים
    יש פיצ'רים:
    חיפוש
    כניסת משתמש
    הכנסת פרטי כרטיס אשראי
    הכנסת כתובת וכו'

    איך אני יודע מראש מה הסבירות של כל אחד מהם לעבוד?

    השבמחק
  2. כלומר מבחינת חשיבות ברור שהליך הקנייה עצמה הוא בדרגת חשיבות 5. כנ"ל לגבי logging in, רישום וכד'.

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

    אם יש מעורבות של כמה צוותי פיתוח - הסיכון נוסק לשמים.

    אתה יודע מה, ביננו, גם לפי הכרותך את המפתח (אבל את זה לא הייתי בהכרח מציג).

    כניסת משתמש נראית לי יחסית פשוטה, למרות שיש תקשורת - מאובטחת אני מקווה - בין השרתים לבסיסי הנתונים.
    כנ"ל לגבי הכנסה של מידע אחר לבסיס הנתונים.
    לכן הייתי נותן 2 או 3 (כשיש ספק עדיף לקחת את הגבוה), כלומר ממש "מגרד" את הקריטי.

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

    עוד כמה נק':
    1. זכור שאני מדבר על פרוגרסיה.
    2. זה שמשהו בפריוריטי בינוני לא אומר שאין לבדוק אותו היטב, רק שאפשר מאוחר יותר ולא לשריין "באפר" ענק.

    השבמחק

רשומות פופולריות