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

ניהול סיכונים קיים בכמה רמות:

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 ונמוכים שניים.
דבר אחד חשוב יש לזכור: לפעמים אפשר לטעות ולא לצפות לכל הבאגים. לכן עדיף להשלים מחזור בדיקות הכולל את המוגדרות כביינוניות.
בנוסף, ייתכן שלאחר זמן בדיקות מסויים נקבל ביטחון בגרסה וניתן יהיה אף להוריד מספר מסויים של בדיקות.