מחזור חיים של תקלה - Bug Life Cycle - חלק 3
פרקי ההרצאה: מחזור חיים של תקלה - Bug Life Cycle - חלק 3
תמלול ההרצאה: מחזור חיים של תקלה - Bug Life Cycle - חלק 3
הטקסט המלא של הדקות הראשונות בהרצאה «מחזור חיים של תקלה - Bug Life Cycle - חלק 3» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום בשיעורים הקודמים דיברנו על תקלה דיברנו על המושג מהי תקלה מהו באג מהו באג פונקציונלי דינמי מהו באג סטטי לא פונקציונלי דיברנו על איך אנחנו קובעים את חומרת התקלה בשיעור הקרוב נדבר על איך אנחנו קובעים את פרטי הבאג או איך אנחנו מתעדים את התקלה אמרנו שכל תקלה חייבת להיות מתועדת בצורה ברורה וקלה לשחזור זה חלק מהמבחן של התקלה
אם אנחנו צריכים להעביר ולתאר את התקלה בצורה שהיא תהיה ברורה למי שאמור לטפל בה או מי שאמור להיות מיודע עליה, אם זה מנהל או איש הפיתוח שאמור לתקן את התקלה.
כל באג חייב להכיל את כל המידע הנדרש על מנת לספק בסיס חקירה והבנה של המשמעויות שלו על המערכת. זאת אומרת, אנחנו ננסה לספק במערכת לתיעוד התקלה, לתיעוד התקלות, כל המידע על מנת למנוע חזרה ובקשת עוד מידע מהמפתח.
אנחנו נרצה להכניס לתוך תיאור התקלה את כל המידע שהוא יצטרך על מנת לעבוד בצורה עצמאית. באג יכיל פעולות ברורות לשחזור מצד משתמש המערכת.
זאת אומרת כשאנחנו מתארים באג אנחנו נרצה לכתוב שלב אחרי שלב בצורה ברורה ופשוטה מה צריך לעשות על מנת לראות את התקלה. באג אמור להכיל את כל פרטי המערכת שבה הוא התרחש לצורך שחזור מדויק, זאת אומרת איזה גרסה דפדפן, איזה מערכת הפעלה, איזה סוג תקשורת יש לי, האם זו תקשורת קווית, תקשורת וי-פיי,
תקשורת 4G או 5G וכדומה. באג יכיל לוגים או מומלץ שבאג יכיל את הלוגים, אותם קבצים שמכילים את ההתנהגות של המערכת מאחורי הגווי, מאחורי הקלעים, מעבר לתיאור של הגווי.
זאת אומרת, נשתדל לצרף לוגים שמעידים על התנהגות המערכת מעבר להתנהגות של הבודק הפשוט. איך נצרף לוגים? אנחנו נצטרך לדעת את זה. נצטרך ללמוד את המערכת על מנת לספק את הלוגים האלה.
באג חייב להכיל כותרת ברורה ותיאורית שתסביר למי שמסתכל עליו בדו"ח על מה הוא מדבר. באג רצוי שיכיל תמונה, צילום מסך של הודעת שגיאה או המסך שבו התרחשה התקלה, אם אנחנו מדברים על צד לקוח, משתמש אז אנחנו נרצה לתאר בדיוק איפה קרה ההודעת שגיאה, איפה קרה התקלה.
התקלה תהיה משוייכת לגורם שאחראי על תיקונו, זאת אומרת לא יכול להיות שבאג יישאר עלינו בסיום הכתיבה שלו או בסיום התיעוד שלו, חייבים להעביר אותו לגורם מתקן. הבאג צריך להכיל קישור ל-Test Case שבאמצעותו נחשף אם אנחנו רוצים לראות עוד דברים שקשורים לאותו תהליך, אוקיי?
אז רצוי שהתקלה תהיה מקושרת גם לטסט קייס שדרכו מצאתי את התקלה, אנחנו נדבר בדיוק מה זה טסט קייס בהמשך. איך נקבע מחזור החיים של התקלה או של באג?
לכל ארגון יש את האבחנה או את ההעדפה שלו לניהול מחזור חיי הבאג, אבל לכל הארגונים יש מכנה משותף בנושא הזה של מחזור חיי התקלה. מחזור חיי התקלה או הבאג הוא הדרך של צוות הבדיקות לוודא ניטור ומעקב אחרי ההתקדמות בטיפול בתיקון התקלה.
זאת אומרת, מרגע המציאה של התקלה בעקבות ביצוע טסט קייס, אני פותח תקלה ואני רוצה לתעד את זה שהיא טופלה בצורה משביעת רצון.
לצורך כך אני בונה איזשהו מדרגות של שלבים, ששלב שלב יוודא ויבטיח לי בעצם שהתקלה תוקנה. לדוגמה, מחזור חיי הבאג מתחיל בפתיחה של התקלה ושיוך מהבודק שמצא את התקלה אל המפתח או מנהל הפיתוח שאמור ולמיין ולהקצות את התקלה לגורם שאמור לטפל בה.
או שהוא אמור להגיד לי שזו לא תקלה, או שהוא אמור להגיד לי שאני צריך לבדוק את זה עוד פעם, או שהוא אמור להסביר לי מה אני צריך לעשות על מנת לראות שזו תקלה או לא תקלה.
אחרי שהתקלה מופנית לגורם או לאיש הפיתוח המתקן, מבוצע תיקון בקוד לדוגמה, או בקונפיגורציה, או הדרכה, או הסבר מבחינתי כבודק.
אני יכול לראות שהסטטוס של התקלה במערכת לניהול תקלות הופך מפתוח למשוייך או משוייך למתוקן מ-open או-assigned ל-resolved. מהמצב הזה אנחנו יכולים להגיד שהכדור שוב אצל בודק התוכנה והוא צריך לוודא כי אכן התקלה תוקנה בסביבת הבדיקות החדשה הכוללת את התיקון כלומר אם
בוצע תיקון אז שבעת בדיקות עברה איזשהו עדכון שמכיל את התיקון החדש ואז אנחנו צריכים לבצע את הטסט קייס שדרכו מצאנו את התקלה שוב את הפעולות שדרכן מצאנו את התקלה בצורה חוזרת.
זאת אומרת לראות שזה לא משתחזר. לדוגמה הודעת שגיאה לא מופיעה. אם הבאג אכן תוקן ווידאנו את זה הסטטוס מועבר לטופל או נסגר זאת אומרת מ-result ל-close או מ-ready to check ל-result ואנחנו יכולים להגיד שהוא בדרך לסגירה.
אם מצאנו שהתקלה עדיין מתרחשת והתיקון לא היה משביע רצון, אנחנו יכולים לבצע פתיחה מחדש של התקלה. וככה תהליך חוזר על עצמו. באתר של גורו 99 אנחנו יכולים לראות דוגמה ל-defect life cycle, באג life cycle.
יש לנו את המצב new שבו אנחנו איתרנו את התקלה בעזרת טסט קייס, עשינו אסיינד לתקלה לאותו מנהל בדיקות, מנהל פיתוח או מפתח הסטטוס עובר לopen זאת