הפקת לקחים מבאג שלא התגלה

JohnDoe5

New member
לא הבנתי

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

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

JohnDoe5

New member
וובכן

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