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