PracticU

מחזור חיי תקלה בארגון

בלי כתוביותעם כתוביות
PracticU › קורס בדיקות ידניות - QA › מחזור חיי תקלה בארגון
מילון מושגים:
באג - תקלה או שגיאה בקוד שגורמת לתוכנה להתנהג בניגוד למצופה.
טופס - אזור בממשק שבו המשתמש מזין נתונים בשדות ושולח אותם, למשל טופס הרשמה או התחברות.
רכיב - יחידת בניין עצמאית וניתנת לשימוש חוזר בתוך מערכת או ממשק משתמש, שאחראית על חלק מוגדר מהתפקוד.
תמונה - קובץ גרפי המוצג על המסך. בהקשר של וירטואליזציה או Docker, תבנית מוכנה שממנה יוצרים מכונה או קונטיינר.
דפדפן - תוכנה שמציגה דפי אינטרנט ומריצה את הקוד שבהם, ומאפשרת לגלוש בין אתרים, למשל Chrome או Firefox.
לוג - רישום מתועד של אירועים ופעולות שמתרחשים במערכת או בתוכנה, המשמש למעקב ולאיתור תקלות.
לקוח - תוכנה או מחשב שפונים לשרת ומבקשים ממנו שירות או מידע, למשל דפדפן שמבקש דף אינטרנט.
שרת - מחשב או תוכנה שמספקים שירות למחשבים אחרים (לקוחות) ברשת, למשל אחסון קבצים, אתר אינטרנט או מסד נתונים, ומגיבים לבקשות שלהם.

מחזור חיי תקלה בארגון
אחרי שמצאנו פער בין ההתנהגות הצפויה לבפועל, פותחים באג ומנהלים אותו לאורך כל חייו עד שהוא תוקן ונבדק. ההרצאה מראה מה לכלול בטופס תקלה טוב.
מחזור החיים והכלים
1. סיבות לתקלות: בעיות טכנולוגיות, בעיות אינטגרציה בין רכיבים, טעויות אנוש, חוסר ידע של מפתחים, אפיון לא נכון או חסר, מערכות ישנות וחוסר תמיכה במערכות מסוימות.
2. מחזור חיים: משייכים את הבאג למפתח, בודקים שהוא מקודם ומובן, ובסוף בודקים ומסגרים אותו כשהמערכת מתנהגת כצפוי.
3. כלים נפוצים: Jira, Rally, Gita ו-Bugzilla. כלל אצבע: לאמץ כלי שכבר בשימוש בארגון הפיתוח, למשל TFS אם מפתחים בו.
4. Jira: אפשר לשייך באג ל-user story ולמשימות, לתאר אותו, לשייך אותו לחבר בצוות הפיתוח ולהגדיר Priority, סטטוס ו-Owner.
מה בטופס תקלה
1. שם ותיאור: לדוגמה "המוצר לא התווסף אחרי לחיצה על הוספה לעגלה".
2. שלבי שחזור: בצורה של בהינתן, כאשר, אז.
3. Expected result מול ההתנהגות בפועל: הציפייה היא שהמוצר יהיה בעגלה, ובפועל הוא לא שם.
4. תמונה או סרטון: צירוף מבהיר למטפל את מהות הבעיה.
5. פרטי הסביבה: באתר, איזה דפדפן ואיזו גרסה.
6. לוגים: מהקליינט או מהשרת, והדובר הדגיש שזה הכרחי.
7. שיוך ושדות: מפתח אחראי, Priority (רמת הדחיפות) וסטטוס, כמו מוכן לטיפול פיתוח.
אחרי ההרצאה אפשר לפתוח באג ברור וניתן לשחזור ולעקוב אחריו עד סגירתו.
השיעור הבא בקורס: הגדרת חשיבות באג - Priority vs Severity

פרקי ההרצאה: מחזור חיי תקלה בארגון

  1. 00:00

    פתיחת באג וסיבות לתקלות

  2. 00:38

    שלבי מחזור החיים של באג

  3. 01:13

    כלים לניהול תקלות בארגון

  4. 01:52

    תיעוד באג במערכת Jira

  5. 02:34

    דוגמת בדיקה בעגלת קניות

  6. 03:11

    פתיחת תקלה על עדכון כמות

תמלול ההרצאה: מחזור חיי תקלה בארגון

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

  1. 00:02

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

  2. 00:17

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

  3. 00:36

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

  4. 00:50

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

  5. 01:02

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

  6. 01:22

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

  7. 01:44

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

  8. 02:06

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

  9. 02:34

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

  10. 02:58

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

  11. 03:18

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

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

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

ההרצאה הבאה: הגדרת חשיבות באג - Priority vs Severity

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

  • מחזור חיי תקלה - הדגמה
  • מחזור חיים של תקלה - Bug Life Cycle - חלק 1
  • סיכום ב-3 דקות - ניהול קבוצות בארגון גדול
  • מחזור חיים של תוכנה

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

  • קורס בדיקות ידניות - Manual Testing
  • קורס הכנה למבחן ההסמכה ISTQB