
הטקסט המלא של הדקות הראשונות בהרצאה «מחזור חיי תקלה Bug Life Cycle» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
הפסקנו בהגדרה של מהי תקלת תוכנה וראינו איך אנחנו מדווחים על תקלת תוכנה במערכת כגון ג'ירה. בשלב הזה אני רוצה להזכיר מושג נוסף חשוב מאוד בעולם הבדיקות שנקרא מחזור חיי תקלה.
השאלה הראשונה שאני רוצה להתייחס אליה היא למה לתקלה בכלל צריך שיהיה מחזור חיים. תקלה, אני מזכיר, היא פער בין הציפייה מהמערכת, כפי שמבין אותה איש הבדיקות, לבין ההתנהגות של המערכת בפועל.
יש פער באיכות שאיש בדיקות מצפה מהמערכת לבין ההתנהגות בפועל. כלומר, יש איזשהו פגם, איזשהו מום במערכת לפי האבחון של איש הבדיקות, שהוא רוצה לדווח ולעדכן את האנשים במערכת לגבי התקלה הזאת.
כשהוא רוצה לדווח על התקלה הזאת, הוא יכול לדווח את זה לכמה גורמים. הוא יכול לדווח את זה לאיש הפיתוח, זאת אומרת, האיש הטכנולוגי, האיש שאחראי על הפיתוח של המערכת, עצמו של התוכנה או אחד המנהלים שאחראים על צוות הפיתוח או למנהל המוצר.
כלומר, הוא יכול לשאול האם ההתנהגות שהוא חושב שהיא לא תקינה היא באמת לא תקינה. חשוב לזכור שאיש בדיקות רצוי מאוד שיתבסס על מסמכי אפיון כשהוא פותח תקלות.
אז כשאנחנו פותחים את התקלה אנחנו בעצם מתחילים את המחזור החיים של התקלה, ה-life cycle, אנחנו פותחים אותה, היא במצב של המתנה לטיפול.
אז בואו נראה מה החלקים של מחזור חיי התקלה אחרי שפתחנו, ומי מטפל בכל שלב ושלב. זה איזשהו שקף שמראה את המחזור חיים של תקלה.
הוא מתחיל במצב של חדש, אחר כך הוא הופך ל-open. כלומר, אני פותח את התקלה ומשייך אותה לאחד מהשניים, איש הפיתוח או איש המוצר, ואני מבקש מהם שיסתכלו על התקלה.
עכשיו, התשובה שיכולה להיות היא אחת מהשתיים: או שהם ממשיכים לטפל ולתקן בתקלה, וזה הדבר המועדף עלינו, כלומר, פתחנו תקלה אמיתית, או שהם אומרים, אנחנו לא הולכים לתקן אותה.
מה הסיבות שהם יכולים להגיד שהם לא הולכים לתקן אותה? שהיא לא תקלה אמיתית. זאת אומרת, שלא הבנו נכון את המערכת,