הגדרות לחומרת באגים ועדיפותם

[אבי ע]

הגדרות לחומרת באגים ועדיפותם ../images/Emo39.gif

(מצורף קובץ וורד עם כל סדרת המסרים הנוכחית) מבוא: מרכיב מרכזי בעבודת אנשי האיכות היא הגדרה נכונה של חומרת הבאגים שמתגלים, ורמת העדיפות שיש לתת לפתרונם. אנסה להציע כאן את הקריטריונים שגיבשתי ואשר אני עובד לפיהם, כפתח לדיון. בפרק הראשון אדון בחומרת באגים, בשני ברמת העדיפות שלהם, ובשלישי אדון בקצרה באמות המידה לאישור (Qualifying) של התוכנה. אמות המידה לחומרת הבאגים גובשו בהנחה שייעשה שימוש גם בדירוג העדיפות שלהם. למרבה הצער, יש חברות (אולי הרוב) שבהן ההתייחסות לשני קריטריונים עוברת את סף היכולת או הרצון של האחראים, ובפועל מתייחסים רק לחומרה. במקרה כזה יש המורידים את דירוג חומרת הבאגים שהינם בעדיפות נמוכה. אני אישית נמנע מכך, ומעדיף להשאיר את חומרת הבאגים כפי שהיא. בדירוגים מסוג זה היעילות המירבית היא בסולם בין 3 ל-5 דרגות. בשני המקרים אני מעדיף סולם של 5 דרגות, אבל בפועל אצלנו הסולמות הם בני 4 דרגות (פירוט בהמשך).

 

[אבי ע]

1. חומרה (Severity) של באגים ../images/Emo39.gif

חלק מההגדרות להלן דורשות הגדרה של סף תקלה (threshold), ספציפית ליישום ולסביבה שנבדקים. ההגדרות שואפות לניסוח שיתאים למירב היישומים, אך במספר תחומים יש לערוך בהן שינויים מהותיים, כמו למשל במערכות תומכות חיים. הקו שהנחה אותי בגיבוש הקריטריונים הוא שילוב של מספר אמות מידה קשיחות, לצד הנחיה להתרשמות סובייקטיבית שהינה חיונית ככל שמדובר בהערכה של האופן בו הלקוח המסויים (או הלקוח הסביר, במוצר מדף) יראה את הבאגים הללו אם וכאשר ייתקל בהם. כמובן ניתן תמיד לפרט יותר או פחות באמות המידה, בהתאם לנסיון מצטבר בכל ארגון לפי אופי היישומים המפותחים בו. 1.קריטי ביותר (Highly Critical): (בפועל רמה זו אינה קיימת אצלנו ואני מאחד אותה עם הבאה בתור) א. תקלה שמונעת בדיקה של מרכיבים מרכזיים במערכת. ב. תקלה מהותית בנושא שהוגדר מראש כבעל חשיבות עליונה (אם יש כזה). ג. תקלה קריטית שמסיבות שונות נראית חמורה במיוחד (אמת מידה סובייקטיבית אבל שימושית). 2.קריטי (Critical): א. פגיעה באבטחת מידע (Security violation), כאשר נושא זה רלוונטי. ב. הצגת נתונים שגויים או חלקיים (כאילו הם כלל הנתונים), פגיעה בנתוני אמת. ג. פגיעה במערכות אחרות או בציוד של המשתמש. ד. היישום נופל (Crash), או עומד ליפול (למשל הודעת סגירה, גם אם ניתן לבטלה ולהמשיך הלאה). ה. מרכיב מהותי של היישום אינו פועל. ו. בעיית משאבים וביצועים המונעת למעשה שימוש סביר ביישום או במרכיב מהותי שלו (כולל כאשר הבעיה נובעת מהרצה במקביל של יישום אחר, שהוגדר או סביר כי יהיה בשימוש). ז. כל תקלה שברור כי הלקוח המסויים (או המשתמש הסביר) לא יסכים בשום פנים ואופן לקבל. 3.חמור (Major): א. תיפקוד (Functionality) של המערכת אינו פועל, ואין דרך לעקוף זאת. ב. תקלה בולטת במיוחד לעיני הלקוח (כגון הודעת שגיאה בפתיחת היישום, גם אם ניתן להמשיך). ג. בעייה חמורה של משאבים או ביצועים, מעבר לסף מסויים שהוגדר (אך עדיין מאפשרת שימוש). ד. כל תקלה שבלתי סביר לספק ללקוח המסויים (או למשתמש הסביר). 4.בינוני (Medium): א. תיפקוד (Functionality) של המערכת אינו פועל, אבל יש דרך סבירה לעקוף זאת. ב. סדר פעולות הנדרש מהמשתמש אינו טוב: לא אינטואיטיבי, מסורבל, מבלבל, גדוש מדי וכדומה. ג. תקלות בממשק הגראפי (GUI): לא אינטואיטיבי, טקסט או נתונים קשים לקריאה או חתוכים, שגיאות כתיב, שגיאות דקדוק בולטות, שגיאות גראפיות צורמות במיוחד, וכדומה. 5.קל, משני (Minor): א. תקלות קלות בממשק הגראפי (GUI): כל אי התאמה לסטנדרט מקובל או שנקבע מראש, חוסר עקביות קל בממשק, אי בהירות קלה מבחינה גראפית או טקסטואלית, חוסר סימטריה, אסתטיקה פגומה, ניסוחים בעייתיים, וכדומה. ב. תקלות קלות אחרות, שאינן פוגעות בתיפקוד ואינן צורמות מאד, אך מוטב לתקנן.

 

[אבי ע]

2. עדיפות (Priority) של באגים ../images/Emo39.gif

דירוג חומרת הבאגים אינו מושפע מלוחות זמנים, הגבלות בהקצאת משאבים, עלות תיקון הבאגים וכדומה, ואסור שיושפע מהם. איכות התוכנה ומידת מוכנותה נמדדים על סמך חומרת הבאגים (כפי שיתואר בהמשך) כשאת הלקוח / המשתמש לא מעניינים אילוצי הזמנים והמשאבים שלנו. על מנת לקבוע את סדרי העדיפות לטיפול בבאגים, יש לדרגם בהתאם. כמו כן, דירוג החומרה מושפע חלקית בלבד משאלות כגון הסיכוי שמשתמש ייתקל בבאג, או חשיבותו היחסית של התפקוד / תת-התפקוד שבו נתגלה הבאג (יש השפעה חלקית כאשר הבאג מדורג לפי אחת מאמות המידה תלויות המשתמש, אך לא באמות המידה הקשיחות יותר). דירוג העדיפות משלים גם היבטים אלו, ועל כן בסופו של דבר יש לקחת אותו בחשבון גם בעת הערכת מוכנות התוכנה ואפילו איכותה (באופן שיוסבר בפרק הבא). דירוג העדיפות מושפע משיטת הפיתוח. בשיטות פיתוח בשלבים: פיתוח אינקרמנטלי, ופיתוח תוך הדגמת אב-טיפוס במהלכו (ומה גם הוצאתו לפיילוט), נדרשת רמת דירוג נוספת. הדירוג המוצע לעדיפויות הטיפול בבאגים נחלק לחמש רמות במסגרת של שלוש קבוצות (או שתיים, אם אין שלבים): באגים בעדיפות גבוהה (לתיקון במסגרת תכנית הבדיקות הנוכחית) 1.לתיקון מיידי: תקלות שתיקונן נמצא בעדיפות עליונה מסיבות שונות, למשל - א. חיוני לסיום השלב הנוכחי של הפיתוח (לקראת הדגמה או פיילוט בטרם סיום הפיתוח, או במסגרת תכנית בדיקות אינקרמנטלית), עוד לפני תום תכנית הבדיקות המלאה. ב. הערכה שהתיקון עשוי לדרוש זמן ולכן יש להתחיל בהקדם. ג. שיקולי תכנית עבודה של הפיתוח. 2.עדיפות גבוהה: שאר התקלות בתיפקודים הנכללים בתוכנית הבדיקות הנוכחית. באגים בעדיפות רגילה (ניתן לתקנם לאחר תום תכנית הבדיקות הנוכחית) 3.A. עדיפות רגילה: בפיתוח בשלבים (בלבד) - תקלות שתיקונן אינו הכרחי לשלב הנוכחי אך נדרש לסיום תוכנית הבדיקות הסופית. לאחר סיום כל שלב נבדקות כל התקלות ברמת עדיפות זו, ומועלות לעדיפות הגבוהה אלה שתיקונן חיוני לשלב החדש. באגים בעדיפות נמוכה 3.B. עדיפות נמוכה: א. תקלות המתגלות רק בתרחישים שסבירות התרחשותם נמוכה. ב. תקלות בתפקודים שאינם מתחייבים בהכרח מהדרישות המקוריות, אבל כדאי להשאירם אם התיקון אינו מסובך או יקר (אם לא יתוקנו ניתן להעלים, או במקרים מסויימים להשאיר כ"אקסטרה" עם התקלה). 4.עדיפות נמוכה מאד: תקלות שאפשר כי לא יתוקנו כלל, למשל - א. תקלות המתגלות בתרחישים נדירים ביותר, בפרט כאשר לתיקונן עלות, השלכות או סיכונים מרחיקי לכת. ב. תקלות בתפקודים שבבירור אינם מתחייבים מהדרישות המקוריות. את חומרת הבאגים קובעים אנשי האיכות ולהם זכות "וטו" בנושא. לעומת זאת, בדירוג עדיפות הבאגים יש משקל רב יותר לשיקולי הפיתוח. איש האיכות יקבע דירוג ראשוני, ואנשי הפיתוח יוכלו לשנות אותו בתוך הקבוצות לעיל אך לא ביניהן.

 

[אבי ע]

3.אמות מידה לאישור תוכנה ../images/Emo39.gif

אמות מידה לאישור תוכנה (Qualifying) צריכות להגזר ממקרי המבחן (Test Case) ורמת התקלות בהם, לפי החומרה והעדיפות כפי שהוגדרו לעיל. לשם אישור תוכנה נדרשים התנאים הבאים: 1.אפס תקלות ברמת קריטי/ חמור ובעדיפות גבוהה. 2.איכות תוכנה מעל לרמה מסויימת, לפי אמת מידה שנקבעה מראש. שתי אפשרויות לדוגמא: א. מעל אחוז מסויים של מקרי מבחן הנקיים מכל תקלה. האחוז מחושב לפי אחוז מקרי המבחן בהם לא קיימת תקלה כלשהי, מתוך כלל מקרי המבחן. ב. מדד איכות מתקדם מעל לרמה מסויימת. למשל, לכל מקרה מבחן משוייך ערך מספרי לפי רמת התקלה שבו (ערך גבוה יותר לתקלה חמורה פחות, ערך מירבי להיעדר תקלה), והמדד מחושב לפי סיכום כלל הערכים שניתנו, ביחס לסיכום המירבי האפשרי (כשכל המקרים נקיים מתקלות).

 

[erandd]

יוכנס למאמרים

תודה על המאמץ והמאמר