Multi-purpose Testing Tool Kit

[Issi Hazan]

Multi-purpose Testing Tool Kit

פוסט חדש שלי על 3 תבניות חשיבה שמאפשרות לתקוף כל בעיית Testing.

קישור מצ"ב

 

[halperin]

מעולה - ... ועכשיו בעברית...

 

[Issi Hazan]

ברצינות...

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

 

[halperin]

אני עדיין מקווה למצוא כמה שיכתבו בעברית

ובמקום "להסתבך" בלהוסיף עוד דף...
אתה יודע ששמור לך מקום בבלוג המשותף של ITCB

טוב.... נפסיק להציק לך!

 

[עמית ו]

רק חצי קשור - אבל לגבי נוסחת הסיכון

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

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

בנוסף - האם לדעתך שני הפרמטרים האלה שקולים (כלומר - האם תקלה שתתרחש בהסתברות 7 ותגרום לנזק 3 שקולה לתקלה שתתרחש בהסתברות 3 אבל תגרום לנזק 7) ?

 

[Issi Hazan]

מאוד קשור

תודה עמית! אני מסכים עם מה שכתבת מאוד ובהחלט הייתי יכול להדגיש אותו יותר בפוסט.

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

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

 

[Rשף]

השתמשתי מעט, לפעמים פשוט בצורה אינטואיטיבית

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

מי שמתכנן סבב של scrum נתקל בבעייה דומה בהערכת זמנים, הפתרון המוצע הוא Planning poker