כתיבת באגים - מתודולוגיה?
כמה פעמים פנה אליכם מפתח בנוגע לחוסר בהירות בבאג? האם חשבתם שהוא "מתקטנן"? כמה פעמים מצאתם ריגרסיה בתיקון, האם ערכתם את הבאג? האם אתם מקפידים על פורמט אחיד?
האם כתיבת באגים היא נושא שחשוב לדבר עליו?
רב הבודקים שיצא לי להכיר לא שמים דגש על הפורמט בו נכתב הבאג, על עקביות, פירוט מידע וצירוף משתמש וזאת במחשבה שהעניין שולי.
בואו ננסה לתת על הנושא פרספקטיה נוספת; כמה זמן לוקח לכם לקרוא קטע כתוב של אדם אחר? כמה זמן לוקח לכם להבין קטע טכני בו יש חןמר חדש? כל הדברים והפרטים האלו לוקחים זמן ולפעמים זמן רב.
מיקוד, דיוק וקיצור זמן:
כתיבת באג לפעמים כוללת פרטים רבים ולפעמים פחות. לפעמים באגים כוללים סנריו ארוך ממה שצריך וכולל מידע שאינו רלוונטי לבעיה, ולפעמים באג שייך בכלל למבנה מסויים של מידע מצטבר ולא תמיד נוכל לאתר את הבעיה במערכות מורכבות ובעיקר במערכות מובייל ללא הבנת קוד.
ישנן כמה דברים שכדאי לעשות על מנת להעיץ תהליך הבנה של המפתח ומיקודו:
- נסו למצוא את הסנריו הקצר ביותר שתוכלו; לפעמים נמצא בסנריו מידע לא רלוונטי בכלל ותוך כדי בדיקות ניתן למצוא את מרכז הבעיה.
- צרפו פרטים כגון כגון; פרטי משתמש, סוג משתמש, ו/או לוג.
- צילום מסך יכול לקצר מאוד את זמן ההבנה בבאגים של UI.
- שימרו על תבנית קבועה וקצרה: בפרויקטים ארוכים אנו עובדים בצוות קבוע וסיגון הרגל יכול לקצר את זמן הקריאה וההבנה של הניסוח.
- אם יש לכם גישה לDB או שרת במערכות גדולות; עשו ולידציה להבין מה מקור הבעיה ואל תניחו שהבעיה מקורה בצד לקוח, יתכן עיבוד מידע שגוי, כשל המרה בשרת....
- באג שחזר אם הסנריו עבר שינוי אל תחזירו אותו באג אלא שייכו לקודם ופיתחו חדש מסודר ומדוייק.
- תבנו את הבאג לוגית ולא סיפורית, קצר ומדוייק ככל שניתן.
אם בכל זאת נתקלת בחוסר בהירות ויש לכם סביבת פיתוח, סכמו לדמות את המקרה ותקראו למפתח להתחבר ולבדוק.
בעיקר בחברות הזנק ישנן צורות ניסוח שונות ומגוונות, ישנן חברות שיש בהן קיים פער בטרמינולוגיה בשונה מחברות גדולות והמסודרות בהן כבר אתה נכנס לתוך מערכת משומנת והמטרה לשנו לקצר את התהליך ולעזור בעליית איכות המוצר.
בהצלחה בבדיקות.
תגובות