איך לבחור חשבון דוא"ל לבדיקה עבור QA

מהו חשבון אימייל לבדיקות QA?

חשבון אימייל לבדיקות, או כתובת אימייל לבדיקות QA, היא כתובת שהצוות שלך משתמש בה כדי לקבל ולבחון את האימיילים שהאפליקציה שלך שולחת. השתמש בתיבת דואר זמנית לבדיקות הרשמה ובדיקות OTP ידניות שאינן רגישות. בחר תיבת דואר של החברה כאשר יש לשמור הודעות, תשובות או קבצים מצורפים, ובחר SMTP sandbox או API של תיבת דואר מתארחת כאשר בדיקות אוטומטיות חייבות לבחון אימיילים ללא אדם.

Tmailor מפעיל את הבלוג הזה, ולכן כך הוא משתלב כאן. Tmailor הוא שירות דואר זמני חינמי לקליטה בלבד, באינטרנט, ב-Android, ב-iOS ובבוט Telegram. הוא מתאים למקרה הראשון: אדם פותח תיבת דואר, מפעיל הרשמה וקורא את מה שמגיע. במקרה האחרון, ממשק ה-API הנפרד של Tmailor Temp Mail מאפשר לבדיקות אוטומטיות ליצור כתובות לקליטה בלבד ולקרוא את ההודעות מתוך קוד. ההודעות נשמרות כ-24 שעות מרגע ההגעה, קבצים מצורפים אינם מתקבלים, והכתובת אינה יכולה לשלוח או להשיב. אם אתה חדש בתיבות דואר זמניות, התחל עם איך דואר זמני עובד.

• אין צורך שאימייל יגיע (אימות טפסים, נתוני דמה, בדיקות יחידה): השתמש בדומיין דוגמה שמור.
• אדם קורא את האימייל ושום דבר בו אינו רגיש תיבת דואר זמנית היא האפשרות המהירה ביותר.
• נתונים רגישים, תשובות, קבצים מצורפים או ראיות שעליך לשמור: השתמש בתיבת דואר מאושרת בשליטת החברה; הוסף תגיות plus רק אם מערכת הדואר והאפליקציה שלך תומכות בהן.
• אין אדם שצופה: השתמש ב-SMTP catcher אם אתה שולט בהגדרות הדואר היוצא של האפליקציה, או ב-API של תיבת דואר מתארחת אם האפליקציה חייבת לשלוח דרך הספק הרגיל שלה.

בדיקות אימייל ידניות מול אוטומטיות: עץ החלטות

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

1. האם הבדיקה דורשת שאימייל יגיע? בדיקות פורמט, מצבי ממשק, נתוני דמה ובדיקות יחידה בדרך כלל לא דורשות זאת. השתמש בכתובות בדומיין example.com, example.org או example.net. דומיינים אלה שמורים לתיעוד ולדוגמאות, כך ששום דבר לא מגיע לאדם אמיתי. הימנע מהמצאת דומיינים אקראיים, כי ייתכן שמישהו הוא הבעלים שלהם.
2. האם אדם יקרא את ההודעה במהלך הבדיקה? בדיקות עשן, UAT ידני, הדגמות ומפגשי חקירה כוללים אדם בתהליך. חבילות רגרסיה ומשימות CI בדרך כלל לא.
3. אם אדם קורא אותה, האם יש בה משהו רגיש? רשומות לקוחות אמיתיות, פרטי התחברות, נתונים מפוקחים או הודעות שעליך לשמור כראיות ביקורת אינם שייכים בתיבת דואר זמנית. השתמש בתיבת דואר של החברה במקום. אם התשובה היא לא, תיבת דואר זמנית מספיקה.
4. אם קוד קורא אותה, האם סביבת הבדיקה יכולה לשלוח את הדואר שלה לשרת SMTP לבדיקות? אם כן, SMTP catcher לוכד כל הודעה מבלי למסור אותה. אם לא, מפני שהאפליקציה חייבת לשלוח דרך ספק האימייל הרגיל שלה, השתמש בתיבת דואר מתארחת שהבדיקות שלך קוראות דרך API.

הטבלה משווה את חמש האפשרויות זו לצד זו.

אילו כתובות צריך שדה אימייל לקבל או לדחות?

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

מתי תיבת דואר זמנית מספיקה

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

היתרון הוא המהירות. אין חשבון לבקש מה-IT ואין תיבת דואר משותפת לנקות. המחיר הוא השליטה: אתה מקבל חלון הודעות קצר, ללא קבצים מצורפים, ותיבת דואר שאדם קורא בה ולא קוד.

מתי אתה צריך לוכד SMTP או API של תיבת דואר מתארחת

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

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

• Mailpit הוא כלי חינמי בקוד פתוח שאתה מפעיל בעצמך. הוא לוכד דואר כברירת מחדל ומציע ממשק רשת ו-API מסוג REST לבדיקות אינטגרציה.
• MailHog פועל באותו אופן אך ישן יותר. מפתחי Mailpit מתארים אותו ככזה שאינו מתוחזק עוד, לכן בדוק את מצבו לפני שתאמץ אותו.
• Mailtrap Email Sandbox הוא גרסה מתארחת של אותו רעיון, עם גישה ל-SMTP ול-API. הוא נפרד ממוצר השליחה בייצור של Mailtrap.
• Ethereal הוא שירות SMTP מזויף וחינמי המשמש בעיקר עם Nodemailer. ההודעות נתפסות לצורך תצוגה מקדימה ולעולם אינן נמסרות.

ממשקי API של תיבות דואר מתארחות מעניקים לבדיקות כתובות אמיתיות בדומיינים של הספק, כך שהאפליקציה שלך שולחת דואר דרך הספק הרגיל שלה והבדיקה קוראת את התוצאה דרך API. ה-API של Temp Mail של Tmailor עצמו פועל כך, עם SDKs רשמיים ל-Python, Node.js ו-PHP.

• Mailosaur מציע כתובות דואר לבדיקה, API וספריות לקוח שעובדות עם מסגרות כמו Cypress, Playwright ו-Selenium. הוא מכסה גם קודי SMS.
• MailSlurp יוצר תיבות דואר לפי דרישה דרך ה-API וה-SDKs שלו. הבדיקות יכולות להמתין להודעה, ואז לשלוף קודים, קישורים וקבצים מצורפים.

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

מתי תיבת דואר של החברה עם תגיות Plus היא הבחירה הטובה יותר

תגיות Plus מאפשרות לתיבת דואר אחת של החברה לקבל וריאציות רבות של כתובות. דואר ל-qa+signup או qa+reset בדומיין החברה שלך מגיע לתיבת ה-qa, שם אפשר לסנן אותו לפי תגית. Google Workspace תומך בכך, ומיקרוסופט מתעדת שכתובות עם פלוס ב-Exchange Online מופעלות כברירת מחדל אלא אם מנהל מכבה אותן.

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

איך להריץ בדיקת הרשמה ידנית עם תיבת דואר זמנית

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

1. פתח תיבת דואר. צרו תיבת דואר זמנית חינמית בדפדפן, או השתמש באפליקציית Tmailor או בבוט ה-Telegram, והעתק את הכתובת. במחשב שולחני, תוסף דפדפן Tmailor יכול גם למלא אותה בשדה האימייל של הגרסה שאתה בודק.
2. הירשם בגרסה שאתה בודק. השתמש בכתובת בסביבת ה-staging או ה-QA שלך ורשום את השעה שבה שלחת את הטופס.
3. עקוב אחרי האימייל. בדוק איזו הודעה הגיעה, את שם השולח ואת כתובת ה-From, את הנושא, וכמה זמן לקח.
4. השלם את השלב. לחץ על הקישור או הזן את הקוד. ודא שהחשבון משנה מצב פעם אחת בלבד ששימוש חוזר באותו קישור נכשל עם הודעה ברורה.
5. תעד את הראיות במקום אחר. העתק את הקישור, הקוד, חותמות הזמן וצילום מסך למקרה הבדיקה שלך. ההודעות נשמרות כ-24 שעות מרגע ההגעה, ולכן תיבת הדואר אינה רשומת הבדיקה שלך.
6. שמור את ה-access token אם בכוונתך לבדוק שוב. ה-token פותח את אותה כתובת מאוחר יותר, למשל כדי להריץ מחדש איפוס סיסמה. הוא אינו משחזר הודעות שפג תוקפן, ו-token שאבד אינו ניתן לשחזור.

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

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

תיבת דואר אחת או כתובת אחת לכל בדיקה?

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

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

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

מה לבדוק באימיילי הרשמה וקליטה

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

אימיילים במסע הרשמה טיפוסי

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

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

מה לבדוק בכל מייל בדיקה

• שולח ונמען: שם השולח והכתובת שלו, Reply-To, וכתובת ה-To המדויקת.
• נושא וגוף: גם גרסת ה-HTML וגם גרסת הטקסט הפשוט, עם שמות נכונים, פרטי תוכנית ושפה.
• קישורים: היעד והאם הוא מצביע על הסביבה הנכונה. מייל מסביבת סטייג'ינג שמקשר לפרודקשן הוא באג אמיתי.
• קודים: פורמט, אורך, נוסח הודעת התפוגה, והאם התפוגה המוצהרת תואמת למה שהשרת אוכף.
• תזמון: כמה זמן לקח להודעה להגיע לאחר הטריגר.
• קבצים מצורפים: אם זרימה שולחת PDF או חשבונית, בדוק אותה בתיבת דואר של החברה או בכלי בדיקה. Tmailor אינו מקבל קבצים מצורפים.

אזהרה אחת לגבי תצוגה. תיבת דואר זמנית מראה איך מציג צופה ווב אחד את ה-HTML שלך. היא לא מראה איך אותו מייל נראה ב-Gmail, ב-Outlook, ב-Apple Mail, במצב כהה או במסך טלפון קטן, לכן תכנן בדיקות תצוגה נפרדות אם זה חשוב.

זרימות שינוי כתובת מייל ושחזור חשבון

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

איך לבדוק OTP ומקרי קצה של אימות

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

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

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

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

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

כשאין אדם שצופה, הבדיקה זקוקה לתיבת דואר שהיא יכולה לקרוא דרך קוד. כלומר, API של לוכד SMTP או API של תיבת דואר מתארחת. תיבת הדואר האינטרנטית של Tmailor אינה הכלי הזה, אבל Tmailor Temp Mail API כן: בדיקות יכולות ליצור כתובות לקליטה בלבד, לרשום ולקרוא הודעות, ולקבל את הקוד החד-פעמי או קישור האימות שה-API מוצא. שרת MCP מאפשר לסוכני בינה מלאכותית כמו Claude, Cursor או VS Code Copilot לעשות את אותו הדבר עבור תהליכי הרשמה שבבעלותך או שמותר לך לבדוק.

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

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

גם תהיה ברור לגבי מה שמבחן עובר מוכיח. "האפליקציה יצרה והעבירה את המייל," "דומיין בדיקה מאוחסן קיבל אותו דרך תשתית דואר אלקטרוני ציבורי," ו"Gmail הניח אותו בתיבת הדואר הנכנס, לא ספאם" הם שלוש עובדות שונות. תופס SMTP מוכיח את הראשון, API בתיבת דואר נכנס מארח מוכיח את השניים הראשונים, ואף אחד מהם לא מוכיח את השלישי. להגדרת צינור ב-GitHub Actions, GitLab CI ו-CircleCI, ראו את המדריך לבדיקות דואר אלקטרוני בצינורות CI/CD.

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

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

• אין נתונים אמיתיים בתיבת דואר זמנית. לעולם אל תנתב רשומות לקוחות אמיתיות, פרטי התחברות, מפתחות API או נתונים מפוקחים לכתובת דואר זמנית. השתמש במשתמשים סינתטיים עם שמות בדויים מובהקים.
• בדוק רק את מה שמותר לך לבדוק. הרץ בדיקות הרשמה מול המוצר שלך או מול מערכת שאתה מורשה לבדוק, וכבד את מגבלות הקצב והתנאים של השירות. אל תשתמש בדואר זמני כדי ליצור חשבונות בכמויות באתרים של צד שלישי. בדיקות נפח ועומס שייכות לסביבת הסטייג'ינג שלך, עם לוכד SMTP או API של תיבת דואר מתארחת.
• הרחק תעבורת QA מנתוני הייצור. תייג חשבונות בדיקה באופן ברור והחרג אותם מלוחות ניתוח נתונים ולוחות צמיחה. הימנע משליחת כמויות גדולות של דואר בדיקה מדומיין השליחה של הייצור שלך, שבו החזרות ותלונות עלולות לפגוע במוניטין שלו.
• כתוב את המדיניות. ציין אילו תהליכים רשאים להשתמש בתיבת דואר זמנית, אילו דורשים תיבת דואר של החברה, כמה זמן נשמרים נתוני הבדיקה ומי בעל הגישה. סקירות אבטחה וציות עוברות מהר יותר כשהגבולות כבר כתובים על הנייר.

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

מגבלות שכדאי להתחשב בהן

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

• Tmailor מיועד לקליטה בלבד. הוא יכול לבדוק דואר הרשמה, אימות ו-OTP נכנס, אבל לא תהליכי מענה או כל דבר שנשלח מהכתובת.
• Tmailor אינו מקבל קבצים מצורפים, ולכן דואר של חשבוניות, חוזים או מסירת מסמכים דורש תיבת דואר של החברה או כלי בדיקה.
• ההודעות נשמרות כ-24 שעות מרגע ההגעה. ייצא את הקישורים, הקודים וחותמות הזמן שתזדקק להם לבדיקה ארוכה יותר.
• אסימון גישה פותח מחדש כתובת, אך לא הודעות שפג תוקפן, ואסימון שאבד אינו ניתן לשחזור.
• את תיבת הדואר המקוונת קורא אדם. קריאת תיבת דואר ללא השגחה מחייבת לוכד SMTP או API של תיבת דואר מתארחת, כגון ה-API של הדואר הזמני של Tmailor.
• יש שירותים שחוסמים דומיינים של דואר זמני. אם תהליך שאתם בודקים עושה זאת בכוונה, אמתו אותו עם כתובת אמיתית או כתובת בשליטת החברה.

בחירת תיבת הדואר הנכונה לבדיקה

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

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