מה לכלול בדוח באגים?

כיצד לכתוב דוח באגים טוב

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

ללא סדר מסוים:

מזהה פגמים, מזהה

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

סיכום

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

תיאור

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

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



חוּמרָה

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

  • S1 - קריטי: המשמעות היא שהפגם הוא פקק ראווה עם נזקים פוטנציאליים גבוהים ואין לו דרך לעקוף את הפגם. דוגמה יכולה להיות היישום אינו מופעל כלל וגורם למערכת ההפעלה להיסגר. זה דורש התייחסות מיידית ותיקון.
  • S2 - רציני: המשמעות היא שחלק מהפונקציות העיקריות של היישומים חסרות או לא עובדות ואין פיתרון. דוגמה, יישום לצפייה בתמונות אינו יכול לקרוא כמה פורמטים נפוצים של תמונות.
  • S3 - רגיל: המשמעות היא שחלק מהפונקציונליות העיקרית לא עובדת, אך קיים פיתרון לשימוש שישמש כפתרון זמני.
  • S4 - קוסמטיקה / שיפור: המשמעות היא שהכישלון גורם לאי נוחות ולהתרגזות. דוגמא יכולה להיות שיש הודעה מוקפצת כל רבע שעה, או שתמיד צריך ללחוץ פעמיים על כפתור GUI כדי לבצע את הפעולה.
  • S5 - הצעה: זה בדרך כלל לא פגם והצעה לשיפור הפונקציונליות. זה יכול להיות GUI או העדפות צפייה.

עדיפות

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

  • P1 - דחוף: פירושו דחוף ביותר ודורש פתרון מיידי
  • P2 - גבוה: דרישת החלטה לשחרור חיצוני הבא
  • P3 - בינוני: נדרשת רזולוציה לפריסה הראשונה (ולא בכל הפריסות)
  • P4 - נמוך: רזולוציה רצויה לפריסה הראשונה או לשחרור עתידי הבא

קרא עוד על חומרה לעומת עדיפות

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

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

תאריך ושעה

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

גרסה ובנייה של התוכנה הנבדקת

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

דווח על ידי

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

דרישה קשורה

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

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

קבצים מצורפים / ראיות

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

סיכום

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