
הטקסט המלא של הדקות הראשונות בהרצאה «מחזור חיים של תקלה - Bug Life Cycle - חלק 4» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, בסרטונים האחרונים דיברנו על הכנה לראיונות עבודה לתפקיד בודק תוכנה, איך נגיע מוכנים בצורה המיטבית על מנת להגדיל את הסיכוי שלנו לזכות בתפקיד. דירגנו את הנושאים שאותם אנחנו צריכים להכיר על מנת להגיע מוכנים ככל האפשר לראיון.
השיעורים האחרונים או הסרטונים האחרונים התמקדו בנושא של היכרות עם מושגים תיאורטיים מתחום הבדיקות אשר מבוססים על קורס ה-STQB. מושגים של מבחן ההסמכה הבינלאומית לבודקי תוכנה.
דיברנו על המושג תקלה, אינסידנט באג ודיברנו על הנושאים התיאורטיים שקשורים לתקלה בסרטון הקרוב. נראה איך אנחנו פותחים באופן מעשי תקלה במערכת לניהול תקלות של ארגון מסוים.
בהסבר מהי תקלה או מהו באג אמרנו שבאג הוא תמיד פועל יוצא של בדיקה המצפה להתנהגות מסוימת שאינה מתממשת תוך כדי בדיקה, או מתממשת בצורה חלקית או לא נכונה, מוטית.
כשאנחנו מדברים על בדיקות או כתיבת טסטים שיבצעו בדיקות, אנחנו מתבססים על מסמכי האפיון, מסמכי התכנון הרשמיים של המוצר שעל פיו עובד צוות הפיתוח, על סמך נקודות שהתקבלו בצורה פורמלית מבחינת תהליך הפיתוח.
בדקות הקרובות ננסה ליצור תקלה חדשה במערכת לניהול תקלות שנקראת SPIRA, בדומה למערכות אחרות כגון Jira, X-ray או QC של HP. המערכת הזאת לניהול תקלות מאפשרת לנו לפתוח תקלות ולשייך אותן למי שאמור לטפל בהן.
לפני שנתחיל ונפתח את התקלה, היא מזכיר את המשך החיים של תקלה או פאג לייף סייקל מחזור חיים של תקלה יש לנו את המצב הפתיחה שהוא ניו או אופן ואחר כך יש לנו את המצב פיקס בדיקה של התיקון ואם הוא לא בוצע תיקון כמו שצריך ביצוע רי אופן אבל אם הוא בוצע כמו שצריך התיקון אנחנו עושים verified וקלוז בארגונים מסוימים יש הבדלים בין השלבים השונים של מחזור חיי התקלה זאת
אומרת בחלק מהארגונים יכול להיות שלא יהיה את השלב של הסיין אלא יהיה מיד אופן או לא יהיה את הפנדינג ל-retest אלא יהיה מיד פיקסט או ריזולט וטסט שוב שנבדק.
אז כל ארגון מחליט בעצמו איך לנהל את המחזור חיים אבל המטרה היא זה לנהל איזשהו תהליך עבודה של העברת אחריות בין הבודק לבין המפתח ואז שוב הבודק על מנת לוודא אמרנו שיש אפשרות שהתקלה אמנם תיפתח אבל תידחה או לא תיפטר משלל סיבות לדוגמה דופליקציה זאת
אומרת שהתקלה כבר פתוחה שהיא נדחית משום שאינה באה להחלטה לפתור אותה מכל מיני סיבות שהיא מיותרת או שהדיווח אינו ממש תקלה אלא משהו שצריך להיות בצורה אחרת אבל לא בתור באג לא בתור תקלה בדוגמה שנתעד בדקות הקרובות לתיעוד תקלה נתמקד בתופעה או בתקלה שאנחנו מוצאים באתר של סופרסל בניסיון לבצע הזמנת מוצר והוספה לסל הקניות קיבלנו
הודעת שגיאה כזאת ואנחנו רוצים לתעד את זה, אנחנו לא רוצים שהתקלה הזאת, התופעה הזאת שקרתה לא תנוטר, לא תיבדק ולכן אנחנו רוצים לתעד אותה בתקלה.
אז איך אנחנו מתעדים את המצב הזה שבו הסמנת מוצר וניסיון הוספה לסל הקניות מקבלת הודעת שגיאה כזאת? אז כדי להתחיל ביצירת התקלה ננחה הצעה על כפתור New Incident בכל מערכת לתיעוד תקלות, אין לנו את הכפתור של הוספת תקלה.
החלק הראשון של הוספת התקלה הוא קביעת הכותרת. אנחנו צריכים לבחור כותרת שתהיה מדויקת ותסביר בדיוק למי שמסתכל על הרשימה של התקלות במה התקלה עוסקת.
אז תהליך, בוא נרשום את זה, תהליך קנייה בניסיון להוסיף מוצר לסל הקניות, בלת הודעת שגיאה שירות אינו זמית, אוקיי? אז אני כתבתי בצורה תמציתית את התקלה שנתקלתי בה.
השלב הבא יהיה לציין את כל הפרטים הבירוקרטיים במרכאות שקשורות לפתיחת התקלה, באיזה גרסה נתקלתי בתקלה, באיזה, אנחנו נמלא רק את השדות חובה, אנחנו רואים פה את השדות שמודגשות בכוכבית, אנחנו צריכים לציין את הבן אדם שאמור לתקן את התקלה.
במקרה הזה אני מציין את עצמי, אבל אנחנו יכולים לקבוע כל בן אדם אחר על מנת שהמפתח עצמו יהיה ה-owner של התקלה או מנהל הפיתוח יהיה ה-owner של התקלה על מנת שנדע שהוא באמת מודע לתקלה ויטפל בה.
אנחנו צריכים לקבוע את הפריוריטי. אמרנו שאנחנו קובעים את הפריוריטי מבחינת החומרה של התקלה, כמה פעמים היא קורית והאם היא מפריעה בתהליך הבסיסי של המוצר, של המערכת שאותה אנחנו בודקים.
במקרה שלנו זו בעיה קריטית, כי היא מונעת מאיתנו לבצע את הקנייה. הסוויריטי זה באיזה דחיפות צריך לבצע מבחינת צוות הפיתוח את התקלה. בדרך כלל אנחנו נשתדל לא לגעת בזה ונאפשר לאנשי הפיתוח לקבוע את הסוויריטי, את הדחיפות של זה.
לצורך העניין נכתוב כרגע מדיום, האחריות שלנו כבודקים זה על שדה הפריוריטי חשיבות הקומפוננט באיזה מוצר זה קרה נגיד נרשום אפליקציה כללי שם המכשיר אם זה קרה במכשיר ספציפי כן האם זה קשור לתקלה אחרת ועוד פרטים טכניים שאנחנו צריכים למלא כשדות חובה עכשיו הגענו לשלב התיאור תקלה כאן אנחנו צריכים להדגיש בדיוק מה השלבים שעשינו על מנת לשחזר
את התקלה