PracticU

מחזור חיים של תקלה - Bug Life Cycle - חלק 4

בלי כתוביותעם כתוביות
PracticU › קורס הכנה לראיונות עבודה QA › מחזור חיים של תקלה - Bug Life Cycle - חלק 4
מילון מושגים:
באג - תקלה או שגיאה בקוד שגורמת לתוכנה להתנהג בניגוד למצופה.
רכיב - יחידת בניין עצמאית וניתנת לשימוש חוזר בתוך מערכת או ממשק משתמש, שאחראית על חלק מוגדר מהתפקוד.
URL - הכתובת שמזהה משאב באינטרנט, למשל דף אתר, וכוללת פרוטוקול, שם מארח ונתיב.
לוג - רישום מתועד של אירועים ופעולות שמתרחשים במערכת או בתוכנה, המשמש למעקב ולאיתור תקלות.
דפדפן - תוכנה שמציגה דפי אינטרנט ומריצה את הקוד שבהם, ומאפשרת לגלוש בין אתרים, למשל Chrome או Firefox.
תגובה - המידע שהשרת מחזיר ללקוח בתשובה לבקשה, הכולל בדרך כלל נתונים וקוד סטטוס.
בקשה - פנייה שלקוח שולח לשרת כדי לקבל מידע או לבצע פעולה. השרת מחזיר עליה תגובה.

מחזור חיים של תקלה - Bug Life Cycle - חלק 4
השיעור מדגים פתיחה מעשית של תקלה במערכת לניהול תקלות, על בסיס תקלה שנמצאה באתר סופרמרקט בניסיון להוסיף מוצר לסל הקניות.
השלבים העיקריים
1. התרחיש: בניסיון להוסיף מוצר לסל הקניות באתר סופרסל מתקבלת הודעת שגיאה "שירות אינו זמין". הבודק רוצה לתעד את התופעה כדי שלא תישאר בלי מעקב.
2. כותרת: כותרת תמציתית ומדויקת, למשל: תהליך קנייה, בניסיון להוסיף מוצר לסל הקניות, מתקבלת הודעת שגיאה "שירות אינו זמין".
3. שדות חובה: הגרסה, האחראי לתיקון (המפתח או מנהל הפיתוח), החומרה, הדחיפות, הקומפוננטה והמכשיר. לפי הדובר, החומרה כאן קריטית, כי התקלה מונעת את הרכישה. את הדחיפות צוות הפיתוח קובע בדרך כלל.
4. תיאור: שלבי השחזור, כולל כתובת האתר (URL), ההתנהגות המצופה לעומת ההתנהגות בפועל, והטקסט של הודעת השגיאה. הדובר ממליץ לתת כמה שיותר פרטים כדי למנוע שאלות מהמפתח.
5. צילום מסך: מצורף צילום של הודעת השגיאה, בכלי צילום כמו Greenshot.
6. לוגים: בכלי המפתחים של הדפדפן (F12) נמצאה תגובה 504, שלפי הדובר משמעותה שהבקשות לא הצליחו להתקבל. גם הודעה זו צורפה לתקלה.
7. מסלול התקלה: התקלה נכנסת למצב New ומגיעה לצוות הפיתוח. אחרי תיקון נבדקת מחדש ואחר כך נסגרת.
שימו לב
הפרטים שמצורפים לתקלה נותנים לצוות הפיתוח כלים לבדוק אם אפשר לשחזר ולפתור אותה, ולכן הם חשובים כמו התיאור עצמו.
עכשיו אפשר לפתוח תקלה מלאה ומדויקת במערכת לניהול תקלות, ולצרף לה ראיות.
השיעור הבא בקורס: כתיבת Test Case

פרקי ההרצאה: מחזור חיים של תקלה - Bug Life Cycle - חלק 4

  1. 00:00

    סיכום הנושאים התיאורטיים על תקלה

  2. 01:41

    מערכת SPIRA לניהול תקלות

  3. 03:01

    תקלה שנדחית כדופליקציה

  4. 03:42

    תיעוד תקלה באתר קניות

  5. 04:24

    פתיחת תקלה חדשה במערכת

  6. 05:51

    שדות החובה בטופס התקלה

  7. 07:07

    חומרה ודחיפות של התקלה

  8. 07:49

    תיאור התקלה ושלבי השחזור

תמלול ההרצאה: מחזור חיים של תקלה - Bug Life Cycle - חלק 4

הטקסט המלא של הדקות הראשונות בהרצאה «מחזור חיים של תקלה - Bug Life Cycle - חלק 4» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.

  1. 00:02

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

  2. 00:23

    השיעורים האחרונים או הסרטונים האחרונים התמקדו בנושא של היכרות עם מושגים תיאורטיים מתחום הבדיקות אשר מבוססים על קורס ה-STQB. מושגים של מבחן ההסמכה הבינלאומית לבודקי תוכנה.

  3. 00:38

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

  4. 00:54

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

  5. 01:12

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

  6. 01:38

    בדקות הקרובות ננסה ליצור תקלה חדשה במערכת לניהול תקלות שנקראת SPIRA, בדומה למערכות אחרות כגון Jira, X-ray או QC של HP. המערכת הזאת לניהול תקלות מאפשרת לנו לפתוח תקלות ולשייך אותן למי שאמור לטפל בהן.

  7. 02:01

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

  8. 02:40

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

  9. 02:55

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

  10. 03:23

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

  11. 04:05

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

  12. 04:21

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

  13. 04:47

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

  14. 05:02

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

  15. 05:47

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

  16. 06:23

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

  17. 06:47

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

  18. 07:01

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

  19. 07:23

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

  20. 07:50

    את התקלה

לקורס המלא: קורס הכנה לראיונות עבודה QA

ההרצאה הקודמת: מחזור חיים של תקלה - Bug Life Cycle - חלק 3

ההרצאה הבאה: כתיבת Test Case

הרצאות קשורות מקורסים אחרים

  • מחזור חיי תקלה - Bug Life Cycle
  • מחזור חיים של תוכנה
  • מחזור חיים של תקיפה
  • מחזור חיי תקלה בארגון

קורסים נוספים במסלול

  • קורס מבוא ל-QA - מידע חשוב לבודק תוכנה
  • קורס פוסטמן - Postman - בדיקות לאתרי אינטרנט - API
  • קורס Robot Framework - בדיקות QA ממשק גרפי
  • קורס יסודות התכנות - שפת JAVA - קורס ג'אווה למתחילים
  • קורס סלניום בסיסי - בדיקות אוטומטיות - Selenium
  • קורס סלניום מתקדם - CI/CD - Continues Integration