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