ניהול פגמים

תמלול ההרצאה: ניהול פגמים

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

1. 00:02

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

2. 00:32

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

3. 00:56

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

4. 01:25

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

5. 01:48

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

6. 02:14

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

7. 02:35

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

8. 02:45

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

9. 03:09

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

10. 03:22

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

11. 03:39

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

12. 03:53

    אנחנו חייבים לתאר את ה-expected behavior מול ה-actual behavior של התהליך שביצענו לעשות בהשראת הסיפור לקוח או ה-test case term או דרגת ההשפעה של הפגם, אם זה פגם חמור, פגם קריטי או פגם מינורי, וחשיבות התיקון בהשראת החומרה של הפגם, מצב דוח הפגם, לדוגמה האם הוא פתוח, האם הוא נדחה, האם הוא דופליקט,

13. 04:20

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

14. 04:44

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

15. 05:18

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