קוד נוצר בשניות. מה צריך לבדוק לפני המיזוג?

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

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

1. מתחילים מהבקשה

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

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

2. קוראים את הגבולות

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

3. בודקים את ההסבר מול הקוד

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

4. מחפשים בדיקה שמסוגלת להיכשל

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

5. חושבים על הפעלה וחזרה

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

תבנית קצרה לתיאור השינוי

הבעיה: [פעולה ותוצאה שגויה]
השינוי: [ההתנהגות החדשה]
נבדק: [תרחיש + סביבה + תוצאה]
לא נבדק: [פער רלוונטי]
הפעלה וחזרה: [שלב או מגבלה]

לדיון: איזו בדיקה אצלכם מצאה טעות שקשה היה לראות בקריאת הקוד בלבד?