fbpx

למה קוראים לתקלה באג?

שגיאות, פגמים וכשלים – Errors, Bugs & Failures

 

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

האופן שבו אימצנו את המילה BUG שמור למתכנתת אמריקאית בשם גרייס הופר Grace Hopper שהיתה תת אלוף בצי האמריקני, שירתה ביחידת המחשבים והיתה למפתחת המהדר הראשון לשפת תיכנות. הופר הניחה את היסודות לשפת COBOL וזכתה בפרסים רבים בתחום המחשוב.

ב2016 – החליט נשיא ארצות הברית ברק אובמה להעניק לה את מדליית החירות הנשיאותית, עיטור הכבוד הגבוה במדינה (לאחר מותה.)

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

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

בארגון הבינלאומי להסמכת בודקי תוכנה (ISTQB) מציינים אתהמושגים הבאים:

Error/Mistake (שגיאה) – פעולה אנושית הגורמת לתוצאה שגויה.

דוגמא: מתכנת שמפאת לחץ זמן שכח להכניס לקלט של משתנה – בדיקות תקינות.

Bug/Defect (פגם) – פגם או ליקוי בתוצר עבודה כלשהו שגורם לכך

שהתוצר לא עונה על הדרישות או המפרטים שלו.

דוגמא: לא הוסיפו בדיקה בקוד אם הערך = NULL בשדה שאינו חובה.

Failure (כשל) – סטייה של רכיב או מערכת מהפעולה הצפויה או מהתוצאה הצפויה.

דוגמא: לחצן חיפוש אנשי קשר לא מוביל לתוצאות למרות שקיימים נתונים במאגר.

היחס בין המושגים שפירטתי מופיע בתרשים הבא:

שורשו של כל פגם הוא בשגיאה והאנשים הם המקור לטעויות, כפי שנאמר: "מי שלא עושה – לא טועה". המקור לטעויות יכול לנבוע מסיבות שונות:

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

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

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

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

  • באג בקוד "מת" (קוד שאינו בשימוש)
  • סטייה מסטנדרט של קוד: כתיבה לא מקצועית, קוד לא יעיל (קוד ספגטי)
  • תיעוד לא שלם של הקוד

פגמים, שורש הבעיה וההשפעות שלהם

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

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

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

 

מודול שניתן לאמץ כדי להבין את שורש הבעיה נקרא בשם מודול סיבה – תוצאה.

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

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

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

 

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

 

לסיכום

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

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

רוצה שנדבר בWhatsapp?