חומרת התקלה מול סבירות התקלה

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

עולם התקלות ותיעדוף התקלות בפרט, מול צוותי הפיתוח היא מיומנות קריטית בהצלחת פרויקט ובטח בתפקיד בדיקות תוכנה וצמיחה לתפקידים ניהוליים בעולמות ה QA. וכשאנחנו אומרים תיעדוף אנחנו מסתכלים עליהם שני וקטורים: חומרה וסבירות התקלה.

אז מה ההבדל בכלל בין חומרה ובין סבירות תקלה?

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

סבירות תקלה – היא למעשה עד כמה שכיחה התקלה שהיא תתרחש על ידי המשתמשים, בואו ניקח דוגמא, אם הכניסה לאפליקציה באמצעות הקשה של שם משתמש וסיסמא נכשלת תמיד, אז הסבירות לתקלה היא גבוהה הרי וכל המשתמשים שלנו עוברים דרך מסך ה LOGIN, ואם תהליך זה נכשל זה אומר שכל המשתמשים שלנו לא עובדים. אבל מה קורה אם ייצא דוח רבעוני לקובץ, עד כמה הוא שכיח? במקרה זה הוא כמובן יהיה נמוך כי למעשה גם ייצוא הקובץ הוא בשימוש אחת לרבעון, וגם לא תמיד אנחנו זקוקים ליצוא פלט לקובץ. דוגמא נוספת לשכיחות בינונית היא לדוגמא עדכון כתובת מגורים, האומנם אנחנו לא עוברים כל יום דירה, אבל סבירות שהמשתמשים שלנו יעברו דירה בשלוש שנים היא גבוהה, ככה שאם יש לנו אלף משתמשים זה אומר שהשימוש בפונקציה היא אחת ליום (365*3 = 1,095~ קרוב לאלף משתמשים שלנו, כלומר ממוצע של 1 ליום)

איך מייצרים מזה תיעדוף איכותי לצוותי הפיתוח?

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

זה נראה כך:

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

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

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

בודק תוכנה? רוצה להתמקצע, כנס עכשיו לקורס שלנו >>