תוכנית בדיקת אימייל אמיתית: הרשמה, איפוס, הזמנה ושינוי כתובת

„האימייל הגיע” אינו תוצאה מספקת לבדיקה.

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

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

בנה מטריצה קטנה ומכוונת

התחל עם הזרימות שיכולות לחסום משתמש:

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

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

השתמש בתיבה אחת לכל תרחיש

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

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

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

אמת את המעטפת לפני הגוף

לפני לחיצה על משהו, אמת:

1. ההודעה נשלחה לכתובת המדויקת שנוצרה עבור הבדיקה הזו.
2. תחום השולח הוא התחום הצפוי עבור הסביבה.
3. נושא ההודעה מזהה את הפעולה מבלי לחשוף מידע רגיש.
4. הגיעו רק מספר ההודעות המתוכנן.
5. חותמת הזמן מאוחרת יותר מהפעולה שהפעילה אותה.

בדיקות אלו תופסות בעיות ניתוב ושכפול לפני שמפרש הגוף מסתיר אותן.

בדוק את התוכן כפי שהמשתמש רואה אותו

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

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

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

מקרים שליליים שמצדקיים

בדיקות שליליות שימושיות כוללות:

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

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

הפרד כשל מוצר מעיכוב מסירה

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

השתמש ברצף האבחון באימות אימייל שלא מגיע: מצא את הצעד השבור לפני הגשת בעיה מעורפלת של "אימייל שבור".

מה לאוטומציה

אוטומט חוזים יציבים:

• צור כתובת ייחודית;
• הפעל את הפעולה במוצר;
• בצע polling עם timeout מוגבל ו-backoff;
• התאמת השולח והנושא הצפויים;
• קרא את ההודעה המתאימה החדשה ביותר;
• אמת את הקוד או הקישור מול המוצר;
• שמור ראיות כשל שימושיות;
• נקה.

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

אוטומציה אמינה של API לתיבות זמניות מכסה את צד ה-API, כולל polling וניקוי.

דוח כשל שימושי

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

המטרה איננה להוכיח שהאימייל אינו אמין. היא לזהות איזה חוזה נכשל ולהשאיר מסלול ניתן לשחזור לתיקון.