วิธีเลือกบัญชีอีเมลทดสอบสำหรับ QA

บัญชีอีเมลทดสอบสำหรับ QA คืออะไร?

บัญชีอีเมลทดสอบ หรือที่อยู่อีเมลทดสอบสำหรับ QA คือที่อยู่อีเมลที่ทีมของคุณใช้รับและตรวจสอบอีเมลที่แอปพลิเคชันของคุณส่งออกไป ใช้กล่องจดหมายชั่วคราวสำหรับการตรวจสอบการสมัครและ OTP แบบแมนนวลที่ไม่ละเอียดอ่อน เลือกกล่องจดหมายของบริษัทสำหรับข้อความที่ต้องเก็บไว้ การตอบกลับ หรือไฟล์แนบ และเลือก SMTP sandbox หรือ API กล่องจดหมายแบบโฮสต์เมื่อการทดสอบอัตโนมัติต้องตรวจสอบอีเมลโดยไม่มีคนเข้ามาเกี่ยวข้อง

Tmailor ดูแลบล็อกนี้ ดังนั้นนี่คือจุดที่มันเข้าได้พอดี Tmailor เป็นบริการอีเมลชั่วคราวฟรีที่รับอีเมลเท่านั้น ใช้งานได้บนเว็บ Android iOS และบอท Telegram เหมาะกับกรณีแรก: คนเปิดกล่องจดหมาย ทำการสมัคร แล้วอ่านสิ่งที่เข้ามา สำหรับกรณีสุดท้าย Tmailor Temp Mail API แยกต่างหากช่วยให้การทดสอบอัตโนมัติสร้างที่อยู่แบบรับเท่านั้นและอ่านข้อความจากโค้ดได้ ข้อความจะอยู่ประมาณ 24 ชั่วโมงนับจากที่มาถึง ไม่มีการรับไฟล์แนบ และที่อยู่นี้ไม่สามารถส่งหรือตอบกลับได้ หากคุณเพิ่งเริ่มใช้กล่องจดหมายแบบใช้แล้วทิ้ง ให้เริ่มจาก วิธีการทํางานของอีเมลชั่วคราว

• ไม่จำเป็นต้องมีอีเมลมาถึง (การตรวจสอบฟอร์ม, fixtures, การทดสอบหน่วย): ใช้โดเมนตัวอย่างที่สงวนไว้
• มีคนอ่านอีเมลและไม่มีข้อมูลใดในอีเมลที่ละเอียดอ่อน: กล่องจดหมายชั่วคราวเป็นตัวเลือกที่เร็วที่สุด
• ข้อมูลที่ละเอียดอ่อน การตอบกลับ ไฟล์แนบ หรือหลักฐานที่คุณต้องเก็บไว้: ใช้กล่องจดหมายที่บริษัทควบคุมและได้รับอนุมัติ; เพิ่มแท็กบวกเฉพาะเมื่อระบบอีเมลและแอปพลิเคชันของคุณรองรับเท่านั้น
• ไม่มีคนคอยเฝ้าดู: ใช้ SMTP catcher หากคุณควบคุมการตั้งค่าอีเมลขาออกของแอป หรือใช้ API กล่องจดหมายแบบโฮสต์หากแอปต้องส่งผ่านผู้ให้บริการตามปกติ

การทดสอบอีเมลแบบแมนนวลกับแบบอัตโนมัติ: แผนผังการตัดสินใจ

คำถามสี่ข้อเป็นตัวกำหนดว่าการตรวจสอบหนึ่งครั้งต้องใช้บัญชีอีเมลทดสอบแบบใด: ต้องมีอีเมลมาถึงจริงหรือไม่, คนหรือโค้ดเป็นผู้อ่านอีเมล, อีเมลมีข้อมูลที่ละเอียดอ่อนหรือไม่ และคุณควบคุมได้หรือไม่ว่าแอปพลิเคชันจะส่งอีเมลขาออกไปที่ใด

1. ข้อ การทดสอบจำเป็นต้องมีอีเมลมาถึงหรือไม่? การตรวจสอบรูปแบบ, สถานะ UI, fixtures และการทดสอบหน่วยมักไม่จำเป็น ใช้ที่อยู่ที่ example.com, example.org หรือ example.net โดเมนเหล่านี้สงวนไว้สำหรับเอกสารและตัวอย่าง ดังนั้นจะไม่มีข้อความไปถึงบุคคลจริง หลีกเลี่ยงการคิดค้นโดเมนแบบสุ่ม เพราะอาจมีคนเป็นเจ้าของโดเมนเหล่านั้นอยู่
2. จะมีจะมีคนอ่านข้อความระหว่างการทดสอบหรือไม่? การทดสอบแบบ smoke, UAT ด้วยมือ, การสาธิต และเซสชันการสำรวจ มีคนอยู่ในวงจร ส่วนชุดการทดสอบถดถอยและงาน CI มักไม่มี
3. หากมีคนอ่าน มีข้อมูลที่ละเอียดอ่อนอยู่ในนั้นหรือไม่? ข้อมูลลูกค้าจริง ข้อมูลรับรอง ข้อมูลที่อยู่ภายใต้การกำกับดูแล หรือข้อความที่คุณต้องเก็บไว้เป็นหลักฐานการตรวจสอบ ไม่ควรอยู่ในกล่องจดหมายชั่วคราว ให้ใช้กล่องจดหมายของบริษัทแทน หากคำตอบคือไม่ กล่องจดหมายชั่วคราวก็เพียงพอ
4. หากโค้ดเป็นผู้อ่าน สภาพแวดล้อมทดสอบสามารถส่งอีเมลไปยังเซิร์ฟเวอร์ SMTP สำหรับทดสอบได้หรือไม่? หากได้ SMTP catcher จะดักจับทุกข้อความโดยไม่ส่งต่อ หากไม่ได้ เพราะแอปต้องส่งผ่านผู้ให้บริการอีเมลตามปกติ ให้ใช้กล่องจดหมายแบบโฮสต์ที่การทดสอบของคุณอ่านผ่าน API

ตารางนี้เปรียบเทียบตัวเลือกทั้งห้าแบบเคียงข้างกัน

ช่องอีเมลควรรับหรือปฏิเสธที่อยู่อีเมลใดบ้าง?

ทดสอบการตรวจสอบความถูกต้องของฟอร์มแยกจากการจัดส่งข้อความ ใช้ที่อยู่ที่สงวนไว้ เช่น user@example.com สำหรับกรณีที่ดูถูกต้องแต่ไม่มีการจัดส่งจริง ใส่ที่อยู่ที่มีแท็กบวกและที่อยู่ที่มีซับโดเมน และเพิ่มกรณีที่รูปแบบผิด เช่น ไม่มีส่วน local หรือไม่มีโดเมน ให้ผลลัพธ์ที่คาดหวังสอดคล้องกับตัวตรวจสอบที่ระบบโปรดักชันของคุณใช้จริง

เมื่อกล่องจดหมายชั่วคราวเพียงพอ

กล่องจดหมายชั่วคราวใช้ได้เมื่อมีคนตรวจสอบทีละขั้นตอนและข้อความนั้นไม่มีอะไรที่คุณเสียดายหากหายไปภายในหนึ่งวัน นี่คือการใช้อีเมลใช้แล้วทิ้งเพื่อการตรวจสอบคุณภาพแบบคลาสสิก: คุณต้องการที่อยู่อีเมลสำหรับทดสอบฟอร์มด้วยมือ ไม่ใช่บัญชีที่ใช้งานระยะยาว กรณีทั่วไป ได้แก่ การทดสอบเบื้องต้นของฟอร์มสมัครก่อนเปิดตัว การทดสอบ UAT ด้วยมือกับอีเมลต้อนรับใหม่ การสาธิตการสร้างบัญชีให้ลูกค้าดู หรือเซสชันสำรวจที่คุณลองป้อนข้อมูลแปลก ๆ และดูว่าแอปส่งอะไรออกมา

จุดเด่นคือความรวดเร็ว ไม่ต้องขอบัญชีจากฝ่ายไอทีและไม่มีกล่องจดหมายร่วมให้ต้องคอยล้าง ข้อแลกเปลี่ยนคือการควบคุม: คุณได้หน้าต่างรับข้อความที่สั้น ไม่มีไฟล์แนบ และกล่องจดหมายที่คนอ่านมากกว่าโค้ด

เมื่อคุณต้องใช้ตัวดักจับ SMTP หรือ API กล่องจดหมายแบบโฮสต์

เมื่อการทดสอบทำงานโดยไม่มีคนเฝ้า กล่องจดหมายต้องอ่านได้ด้วยโค้ด เครื่องมือสองกลุ่มตอบโจทย์นี้ และแก้ปัญหาที่แตกต่างกัน

ตัวดักจับ SMTP และแซนด์บ็อกซ์ จะเข้ามาแทนที่เซิร์ฟเวอร์อีเมลขาออกของแอปในสภาพแวดล้อมทดสอบ และเก็บทุกข้อความไว้ให้ตรวจสอบแทนการจัดส่งจริง

• Mailpit เป็นเครื่องมือโอเพนซอร์สฟรีที่คุณรันเอง โดยจะดักจับอีเมลเป็นค่าเริ่มต้น และมีเว็บ UI กับ REST API สำหรับการทดสอบแบบผสานรวม
• MailHog ทำงานแบบเดียวกันแต่เก่ากว่า ผู้ดูแล Mailpit ระบุว่าไม่ได้รับการดูแลอีกต่อไปแล้ว ดังนั้นควรตรวจสอบสถานะก่อนนำไปใช้
• Mailtrap Email Sandbox เป็นเวอร์ชันโฮสต์ของแนวคิดเดียวกัน โดยเข้าถึงได้ผ่าน SMTP และ API และแยกจากผลิตภัณฑ์ส่งอีเมลจริงของ Mailtrap
• Ethereal เป็นบริการ SMTP ปลอมฟรีที่ใช้ร่วมกับ Nodemailer เป็นหลัก ข้อความจะถูกดักไว้เพื่อดูตัวอย่างและไม่ถูกส่งถึงผู้รับจริง

API กล่องจดหมายแบบโฮสต์ ให้ที่อยู่อีเมลจริงสำหรับการทดสอบบนโดเมนของผู้ให้บริการ แอปของคุณจึงส่งอีเมลผ่านผู้ให้บริการปกติ และการทดสอบอ่านผลลัพธ์ผ่าน API Temp Mail API ของ Tmailor เองก็ทำงานแบบนี้ โดยมี SDK อย่างเป็นทางการสำหรับ Python, Node.js และ PHP

• Mailosaur มีที่อยู่อีเมลทดสอบ, API และไลบรารีไคลเอนต์ที่ทำงานร่วมกับเฟรมเวิร์กอย่าง Cypress, Playwright และ Selenium นอกจากนี้ยังรองรับรหัส SMS ด้วย
• MailSlurp สร้างกล่องจดหมายตามต้องการผ่าน API และ SDK การทดสอบสามารถรอข้อความ แล้วดึงโค้ด ลิงก์ และไฟล์แนบออกมาได้

ฟีเจอร์และแพ็กเกจของผู้ให้บริการเปลี่ยนแปลงได้ ดังนั้นควรตรวจสอบรายละเอียดล่าสุดบนเว็บไซต์ทางการของแต่ละรายก่อนผูกชุดทดสอบเข้ากับรายใดรายหนึ่ง

เมื่อใดที่กล่องจดหมายบริษัทที่มีแท็กบวกเป็นตัวเลือกที่ดีกว่า

แท็กบวกช่วยให้กล่องจดหมายบริษัทหนึ่งกล่องรองรับที่อยู่อีเมลได้หลากหลายรูปแบบ อีเมลที่ส่งถึง qa+signup หรือ qa+reset ที่โดเมนบริษัทของคุณจะไปอยู่ในกล่องจดหมาย qa ซึ่งคุณสามารถกรองตามแท็กได้ Google Workspace รองรับฟีเจอร์นี้ และเอกสารของ Microsoft ระบุว่า plus addressing ใน Exchange Online เปิดใช้งานเป็นค่าเริ่มต้น เว้นแต่ผู้ดูแลระบบจะปิดไว้

ใช้วิธีนี้เมื่อโฟลว์มีข้อมูลลูกค้าจริง ใช้เวลานานกว่าหนึ่งวัน ต้องการการตอบกลับหรือไฟล์แนบ หรือสร้างหลักฐานที่ผู้ตรวจสอบอาจขอได้ อย่าลืมข้อจำกัดด้วย แท็กเป็นรูปแบบต่าง ๆ ของกล่องจดหมายเดียวกัน ไม่ใช่กล่องจดหมายแยกกัน การทดสอบที่รันพร้อมกันจึงอาจอ่านข้อความของกันและกันได้ บางแบบฟอร์มสมัครสมาชิกปฏิเสธเครื่องหมายบวก และบางแอปถือว่าตัวแปรที่ติดแท็กเป็นบัญชีเดียวกัน ทั้งสองพฤติกรรมนี้ล้วนควรมีกรณีทดสอบของตัวเอง

วิธีรันการทดสอบสมัครสมาชิกด้วยตนเองด้วยกล่องจดหมายชั่วคราว

การทดสอบสมัครสมาชิกด้วยตนเองที่ใช้อีเมลชั่วคราวสำหรับการทดสอบต้องมีสามอย่าง: ที่อยู่อีเมลใหม่ บิลด์ที่คุณกำลังทดสอบ และที่บันทึกสิ่งที่เข้ามานอกกล่องจดหมาย ให้รันกับระบบที่คุณเป็นเจ้าของหรือได้รับอนุญาตให้ทดสอบเท่านั้น

1. เปิดกล่องจดหมาย สร้างกล่องจดหมายชั่วคราวฟรี บนเว็บ หรือใช้แอป Tmailor หรือบอท Telegram แล้วคัดลอกที่อยู่อีเมล บนเดสก์ท็อป ส่วนขยายเบราว์เซอร์ Tmailor ยังสามารถกรอกข้อมูลนี้ลงในช่องอีเมลของเวอร์ชันทดสอบของคุณได้ด้วย
2. สมัครสมาชิกบนบิลด์ทดสอบของคุณ ใช้ที่อยู่ในสภาพแวดล้อม staging หรือ QA ของคุณและจดเวลาที่คุณส่งแบบฟอร์ม
3. เฝ้าดูอีเมล ตรวจสอบว่าข้อความใดมาถึง ชื่อผู้ส่ง ที่อยู่ผู้ส่ง หัวข้อ และระยะเวลาที่ใช้
4. ทำขั้นตอนให้เสร็จ คลิกที่ลิงก์หรือกรอกรหัส ยืนยันสถานะบัญชีเปลี่ยนครั้งหนึ่งและใช้ลิงก์เดิมซ้ําล้มเหลวด้วยข้อความชัดเจน
5. บันทึกหลักฐานไว้ที่อื่น คัดลอกลิงก์ โค้ด เวลาประทับ และภาพหน้าจอลงในกรณีทดสอบของคุณ ข้อความจะอยู่ประมาณ 24 ชั่วโมงหลังจากมาถึง ดังนั้นกล่องจดหมายจะไม่ใช่บันทึกการทดสอบของคุณ
6. บันทึก Access Token ไว้หากคุณจะทดสอบซ้ำ โทเค็นจะเปิดที่อยู่เดียวกันอีกครั้งในภายหลัง เช่น เพื่อรีเซ็ตรหัสผ่านใหม่ มันจะไม่กู้คืนข้อความที่หมดอายุแล้ว และโทเค็นที่สูญหายไม่สามารถกู้คืนได้

เมื่อเซสชันหนึ่งต้องใช้หลายบทบาทพร้อมกัน เช่น ผู้ใช้ฟรี ผู้ใช้ทดลอง และเพื่อนร่วมทีมที่ได้รับเชิญ มุมมองกล่องจดหมายหลายกล่อง จะแสดงที่อยู่อีเมลได้สูงสุดห้าที่อยู่เคียงกันในแท็บเบราว์เซอร์เดียว แต่ละบทบาทมีที่อยู่อีเมลของตัวเอง คุณจึงเห็นได้ว่าอีเมลใดเป็นของบัญชีใด

มุมมองนี้ยังคงเป็นแบบแมนนวล กล่องจดหมายถูกสร้างโดยคนในเบราว์เซอร์ ไม่ได้จัดเตรียมด้วยโค้ด จึงไม่สามารถแทนที่ API กล่องจดหมายแบบโฮสต์สำหรับการรันแบบขนานโดยไม่มีคนดูแลได้

กล่องจดหมายเดียวหรือหนึ่งที่อยู่ต่อการทดสอบ?

กล่องจดหมายที่ใช้ร่วมกันกล่องเดียวก็เพียงพอสำหรับการตรวจสอบแบบเร็ว ๆ แต่จะเริ่มวุ่นวายอย่างรวดเร็ว เมื่อมีการทดสอบหลายรายการทำงานพร้อมกัน หัวข้ออีเมลที่คล้ายกันทำให้ยากที่จะบอกว่าอีเมลฉบับใดเป็นของสคริปต์ใด และการดีบักก็กลายเป็นการเดา

การใช้หนึ่งที่อยู่ต่อหนึ่งกรณีทดสอบช่วยแก้ปัญหานี้ได้ บันทึก ภาพหน้าจอ และอีเมลจะสอดคล้องกัน และเมื่ออีเมลขาดหายก็ชี้ไปที่สถานการณ์เดียวแทนที่จะเป็นทั้งหมด คู่มือเกี่ยวกับ การรันกล่องจดหมายชั่วคราวหลายกล่อง อธิบายเวิร์กโฟลว์นี้ไว้อย่างละเอียดยิ่งขึ้น

บางเส้นทางการใช้งานต้องใช้ที่อยู่เดิมอีกครั้งในอีกหลายวันถัดมา เช่น การทดลองใช้ที่เปลี่ยนเป็นลูกค้าจ่ายเงิน หรือผู้ใช้ที่กลับมาหลังจากเลิกใช้งานไปแล้ว ที่อยู่อีเมลชั่วคราวที่นํากลับมาใช้ใหม่ ช่วยให้ที่อยู่นั้นยังเข้าถึงได้ผ่าน Access Token แต่ไม่ได้เก็บอีเมลไว้ ควรบันทึกลิงก์และรหัสที่คุณต้องการไว้ในขณะที่แต่ละขั้นตอนทำงาน และย้ายขั้นตอนใดก็ตามที่ต้องพึ่งพาข้อความเก่าไปยังกล่องจดหมายของบริษัท หากผู้ทดสอบลงชื่อเข้าใช้บัญชี Tmailor ฟรี ก่อนสร้างที่อยู่สำหรับเพอร์โซนา แต่ละที่อยู่จะถูกบันทึกไว้ใน Created Emails ดังนั้นโทเค็นที่หายไปจึงไม่ได้หมายถึงที่อยู่ที่หายไปอีกต่อไป

สิ่งที่ควรตรวจสอบในอีเมลการสมัครและการเริ่มต้นใช้งาน

เริ่มจากการทำรายการอีเมลทุกฉบับที่เส้นทางการใช้งานสามารถส่งได้ แล้วจึงตัดสินใจว่าแต่ละการทดสอบควรตรวจสอบอะไร ทีมมักค้นพบอีเมลเพิ่มเติมก็ต่อเมื่ออีเมลนั้นปรากฏขึ้นกลางการทดสอบ หลังจากการทดลองด้านการเติบโตหรือการเปลี่ยนแปลงด้านความปลอดภัยเพิ่มอีเมลที่ไม่มีใครจดบันทึกไว้

อีเมลในเส้นทางการสมัครใช้งานทั่วไป

• ลิงก์ยืนยันหรือรหัสใช้ครั้งเดียว
• อีเมลต้อนรับและลำดับการเริ่มต้นใช้งานอย่างรวดเร็ว
• การลงชื่อเข้าใช้ด้วย Magic-link
• การรีเซ็ตรหัสผ่าน
• การเปลี่ยนที่อยู่อีเมล ซึ่งส่งไปยังทั้งที่อยู่เดิมและที่อยู่ใหม่
• การแจ้งเตือนความปลอดภัยเมื่อมีอุปกรณ์ใหม่หรือตำแหน่งใหม่
• การแจ้งเตือนสำหรับการสมัครที่ยังทำไม่เสร็จ

สำหรับแต่ละรายการ ให้จดบันทึกทริกเกอร์ เวลาที่คาดว่าจะเกิดขึ้น และเงื่อนไขที่ทำให้เปลี่ยนไป เช่น แพ็กเกจ ภูมิภาค หรือภาษา กำหนดช่วงเวลาการจัดส่งที่อนุญาตตามข้อกำหนดที่บันทึกไว้ของผลิตภัณฑ์คุณ แทนที่จะสมมติว่าใช้เกณฑ์เดียวกันได้ทุกที่ ข้อความยืนยันทันทีกับลำดับอีเมลต้อนรับที่ตั้งเวลาไว้ย่อมต้องการความคาดหวังที่ต่างกัน เมื่อกำหนดความคาดหวังเหล่านี้แล้ว ทุกการทดสอบก็มีสิ่งที่ชัดเจนให้ตรวจสอบ

สิ่งที่ควรยืนยันในแต่ละอีเมลทดสอบ

• ผู้ส่งและผู้รับ: ชื่อและที่อยู่ผู้ส่ง, Reply-To และที่อยู่ To ที่แน่นอน
• หัวเรื่องและเนื้อหา: ทั้งเวอร์ชัน HTML และข้อความล้วน พร้อมชื่อ รายละเอียดแพ็กเกจ และภาษาที่ถูกต้อง
• ลิงก์: ปลายทางและว่าชี้ไปยังสภาพแวดล้อมที่ถูกต้องหรือไม่ อีเมลจากสภาพแวดล้อม staging ที่ลิงก์ไปยัง production ถือเป็นบั๊กจริง
• รหัส: รูปแบบ ความยาว ข้อความแจ้งการหมดอายุ และว่าวันหมดอายุที่ระบุตรงกับที่เซิร์ฟเวอร์บังคับใช้หรือไม่
• เวลา: ข้อความใช้เวลานานเท่าใดจึงจะมาถึงหลังจากทริกเกอร์
• ไฟล์แนบ: หากโฟลว์ส่ง PDF หรือใบแจ้งหนี้ ให้ทดสอบในกล่องจดหมายของบริษัทหรือเครื่องมือทดสอบ Tmailor ไม่รับไฟล์แนบ

ข้อควรระวังเรื่องการแสดงผล กล่องจดหมายชั่วคราวแสดงให้เห็นว่าโปรแกรมดูบนเว็บตัวหนึ่งแสดง HTML ของคุณอย่างไร แต่ไม่ได้บอกว่าอีเมลเดียวกันจะดูเป็นอย่างไรใน Gmail, Outlook, Apple Mail, โหมดมืด หรือหน้าจอโทรศัพท์ขนาดเล็ก ดังนั้นหากสิ่งเหล่านี้สำคัญ ควรวางแผนตรวจสอบการแสดงผลแยกต่างหาก

กระบวนการเปลี่ยนอีเมลและการกู้คืนบัญชี

กระบวนการกู้คืนบัญชีมักพังในแบบที่เงียบกว่าตอนสมัคร ตรวจสอบว่าการเปลี่ยนอีเมลส่งการยืนยันไปยังที่อยู่ใหม่และแจ้งเตือนไปยังที่อยู่เดิม ว่าลิงก์รีเซ็ตที่ใช้แล้วไม่สามารถนำกลับมาใช้ซ้ำได้ ลิงก์รีเซ็ตอันเก่าจะหยุดทำงานหลังจากส่งลิงก์ใหม่ไปแล้ว และลิงก์ที่เปิดบนอุปกรณ์เครื่องที่สองจะพาผู้ใช้ไปสู่สถานะที่สมเหตุสมผล โฟลว์ OTP ควรได้รับการทบทวนความเสี่ยงแยกต่างหาก โดย ตรวจสอบความเสี่ยง OTP สําหรับ QA และ UAT ครอบคลุมเมตริก ช่วงเวลาการส่งซ้ำ และความเป็นเจ้าของ

วิธีทดสอบ OTP และกรณีขอบของการยืนยัน

ทดสอบโฟลว์ OTP และการยืนยันกับกรณีการส่งล่าช้า การส่งซ้ำ รหัสที่หมดอายุและไม่ถูกต้อง และลิงก์ที่เปิดบนอุปกรณ์อื่น แต่ละกรณีควรตรวจสอบทั้งผลลัพธ์จากเซิร์ฟเวอร์และข้อความที่แสดงให้ผู้ใช้เห็น ทดสอบเฉพาะระบบที่คุณเป็นเจ้าของหรือได้รับอนุญาตให้ทดสอบเท่านั้น การทดสอบ OTP ที่ดีจะจงใจทำให้โฟลว์พัง:

• การมาถึงช้า: รอก่อนตรวจสอบกล่องจดหมาย และยืนยันว่า UI อธิบายสิ่งที่เกิดขึ้นและมีวิธีส่งใหม่ที่ชัดเจน
• พฤติกรรมการส่งซ้ำ: ขอรหัสชุดที่สองและตรวจสอบว่ารหัสแรกถูกยกเลิกหรือยังใช้ได้
• การหมดอายุ: กรอกรหัสหลังจากพ้นอายุที่ระบุไว้ และยืนยันว่าข้อความแสดงข้อผิดพลาดตรงกับสิ่งที่เกิดขึ้น
• รหัสผิด: ยืนยันว่าขีดจำกัดจำนวนครั้งที่ลองและข้อความแจ้งช่วงรอมีเหตุผลสำหรับผู้ใช้
• ลิงก์วิเศษข้ามอุปกรณ์: ขอลิงก์บนแล็ปท็อป เปิดบนโทรศัพท์ และตรวจสอบว่าผู้ใช้ไปลงเอยที่ใด

สำหรับภาพรวมที่กว้างขึ้นว่ารหัสใดไปถึงกล่องจดหมายชั่วคราวและรหัสใดไม่ไป โปรดดูคู่มือเกี่ยวกับ อีเมลชั่วคราวสําหรับรหัส OTP

หากผลิตภัณฑ์ของคุณตั้งใจปฏิเสธโดเมนอีเมลใช้แล้วทิ้ง ให้ทดสอบเส้นทางนั้นโดยตรง ยืนยันว่าข้อความปฏิเสธชัดเจน และที่อยู่อีเมลจริงหรือที่อยู่อีเมลที่บริษัทควบคุมยังคงสมัครได้สำเร็จ อย่าสลับไปมาระหว่างโดเมนชั่วคราวอื่นเพื่อหลบเลี่ยงการบล็อก ไม่ว่าจะเป็นผลิตภัณฑ์ของคุณเองหรือของผู้อื่น การยืนยันว่าการบล็อกทำงานคือการทดสอบ การเอาชนะมันไม่ใช่ คำอธิบายนี้เกี่ยวกับ เหตุผลที่เว็บไซต์บล็อกโดเมนอีเมลชั่วคราว ครอบคลุมเหตุผลเบื้องหลังตัวกรองเหล่านั้น

สิ่งที่เปลี่ยนแปลงเมื่อการทดสอบอีเมลทำงานแบบไม่มีคนดูแล

เมื่อไม่มีใครคอยดู การทดสอบต้องมีกล่องจดหมายที่อ่านได้ผ่านโค้ด ซึ่งหมายถึง API ของ SMTP catcher หรือ API ของกล่องจดหมายแบบโฮสต์ กล่องจดหมายเว็บ Tmailor ไม่ใช่เครื่องมือนั้น แต่ Tmailor Temp Mail API คือเครื่องมือนั้น การทดสอบสามารถสร้างที่อยู่แบบรับอย่างเดียว แสดงรายการและอ่านข้อความ และรับรหัสครั้งเดียวหรือลิงก์ยืนยันที่ API พบ เซิร์ฟเวอร์ MCP ช่วยให้เอเจนต์ AI เช่น Claude, Cursor หรือ VS Code Copilot ทำเช่นเดียวกันกับขั้นตอนการสมัครสมาชิกที่คุณเป็นเจ้าของหรือได้รับอนุญาตให้ทดสอบ

มีนิสัยบางอย่างที่ช่วยให้การทดสอบอีเมลแบบไม่มีคนดูแลมีเสถียรภาพ ไม่ว่าคุณจะเลือกเครื่องมือใด:

• ให้แต่ละรอบการทดสอบมีที่อยู่ของตัวเองและมี correlation ID เพื่อที่อีเมลที่มาช้าจากรอบก่อนหน้าจะไม่ไปทำให้การตรวจสอบผิดพลาดผ่านได้
• ใช้การรออีเมลมาถึงโดยเฉพาะพร้อมการเว้นช่วงแบบ backoff ที่เหมาะสม แยกจากเวลาหมดเวลารวมของการทดสอบ และบันทึกว่าแต่ละข้อความใช้เวลานานเท่าใด
• จับคู่ข้อความให้ตรงตามผู้รับและหัวข้อ แทนที่จะอ่าน "อีเมลล่าสุด"
• ปิดบังรหัสและลิงก์วิเศษในบันทึก CI เพราะบันทึกมักมีอายุยืนยาวกว่ากล่องจดหมาย

และต้องชัดเจนว่าการทดสอบที่ผ่านพิสูจน์อะไร "แอปสร้างและส่งต่ออีเมล" "โดเมนทดสอบแบบโฮสต์ได้รับอีเมลผ่านโครงสร้างพื้นฐานอีเมลสาธารณะ" และ "Gmail จัดวางไว้ในกล่องจดหมาย ไม่ใช่สแปม" เป็นข้อเท็จจริงที่แตกต่างกันสามประการ SMTP catcher พิสูจน์ข้อแรก API ของกล่องจดหมายแบบโฮสต์พิสูจน์สองข้อแรก และทั้งสองอย่างไม่ได้พิสูจน์ข้อที่สาม สำหรับการตั้งค่า pipeline บน GitHub Actions, GitLab CI และ CircleCI โปรดดูคู่มือ การทดสอบอีเมลใน pipeline ของ CI/CD

รักษาข้อมูลการทดสอบให้ปลอดภัยและปฏิบัติตามกฎระเบียบ

ใช้ตัวตนสังเคราะห์และเนื้อหาที่ไม่ละเอียดอ่อนในกล่องจดหมายทดสอบชั่วคราว และทดสอบการสมัครสมาชิกเฉพาะกับระบบที่คุณเป็นเจ้าของหรือได้รับอนุญาตให้ประเมินเท่านั้น กันบัญชี QA ออกจากระบบวิเคราะห์ข้อมูลการผลิต เคารพขีดจำกัดอัตรา และย้ายข้อมูลที่อยู่ภายใต้การกำกับดูแล ข้อมูลรับรอง ไฟล์แนบ และหลักฐานที่เก็บไว้ไปยังระบบที่บริษัทควบคุมและอนุมัติ

• ไม่มีข้อมูลจริงในกล่องจดหมายชั่วคราว อย่าส่งข้อมูลลูกค้าจริง ข้อมูลรับรอง API key หรือข้อมูลที่อยู่ภายใต้การกำกับดูแลไปยังที่อยู่อีเมลชั่วคราว ใช้ผู้ใช้สังเคราะห์ที่มีชื่อปลอมอย่างชัดเจน
• ทดสอบเฉพาะสิ่งที่คุณได้รับอนุญาตให้ทดสอบเท่านั้น ทดสอบการสมัครสมาชิกกับผลิตภัณฑ์ของคุณเองหรือระบบที่คุณได้รับอนุญาตให้ทดสอบ และเคารพขีดจำกัดอัตราและเงื่อนไขของบริการนั้น อย่าใช้อีเมลชั่วคราวเพื่อสร้างบัญชีจำนวนมากบนเว็บไซต์ของบุคคลที่สาม การทดสอบปริมาณและโหลดควรทำในสภาพแวดล้อม staging ของคุณเอง โดยใช้ SMTP catcher หรือ API ของกล่องจดหมายแบบโฮสต์
• กันทราฟฟิก QA ออกจากตัวเลขการผลิต ติดป้ายบัญชีทดสอบให้ชัดเจนและตัดออกจากแดชบอร์ดวิเคราะห์และแดชบอร์ดการเติบโต หลีกเลี่ยงการส่งอีเมลทดสอบจำนวนมากจากโดเมนที่ใช้ส่งในระบบการผลิตของคุณ เพราะการตีกลับและการร้องเรียนอาจส่งผลเสียต่อชื่อเสียงของโดเมน
• เขียนนโยบายเป็นลายลักษณ์อักษร ระบุว่าขั้นตอนใดใช้กล่องจดหมายชั่วคราวได้ ขั้นตอนใดต้องใช้กล่องจดหมายของบริษัท เก็บข้อมูลทดสอบนานเท่าใด และใครมีสิทธิ์เข้าถึง การตรวจสอบด้านความปลอดภัยและการปฏิบัติตามกฎระเบียบจะเร็วขึ้นเมื่อขอบเขตถูกกำหนดไว้เป็นลายลักษณ์อักษรแล้ว

เมื่อฝ่ายความปลอดภัยถามว่าผู้ให้บริการจัดการข้อมูลอย่างไร ให้ดูว่าพวกเขาเก็บข้อมูลอะไร เก็บข้อความนานแค่ไหน และการเข้าถึงทำงานอย่างไร ภาพรวมของ อีเมลชั่วคราวและความเป็นส่วนตัวออนไลน์ นี้ครอบคลุมคำถามเหล่านั้นจากมุมมองของผู้ใช้ การตัดสินใจว่าขั้นตอนใดใช้กล่องจดหมายใช้แล้วทิ้งได้ยังคงเป็นหน้าที่ของทีมกฎหมาย ความเป็นส่วนตัว และความปลอดภัยของคุณเอง

ขีดจำกัดที่ต้องวางแผนรับมือ

กล่องจดหมายเว็บ Tmailor เหมาะกับการตรวจสอบอีเมลขาเข้าที่ไม่ละเอียดอ่อนด้วยมือในช่วงสั้น ๆ (Temp Mail API มีไว้สำหรับการทำงานอัตโนมัติ) ก่อนเลือก ให้ตัดสินใจว่าเวิร์กโฟลว์ต้องการการดำเนินการขาออก ไฟล์แนบ หลักฐานที่ต้องเก็บไว้นาน หรือการกู้คืนที่อยู่แบบถาวรหรือไม่ ข้อกำหนดใดข้อหนึ่งเหล่านี้ต้องใช้กล่องจดหมายที่บริษัทควบคุมหรือเครื่องมือทดสอบเฉพาะทาง รายการตรวจสอบด้านล่างอธิบายเหตุผล

• Tmailor รับอีเมลเท่านั้น จึงตรวจสอบอีเมลสมัครสมาชิก การยืนยัน และ OTP ขาเข้าได้ แต่ตรวจสอบขั้นตอนการตอบกลับหรือสิ่งใดที่ส่งออกจากที่อยู่นั้นไม่ได้
• Tmailor ไม่รับไฟล์แนบ ดังนั้นอีเมลใบแจ้งหนี้ สัญญา หรือการส่งเอกสารจึงต้องใช้กล่องจดหมายของบริษัทหรือเครื่องมือทดสอบ
• ข้อความจะอยู่ประมาณ 24 ชั่วโมงนับจากเวลาที่มาถึง ส่งออกลิงก์ รหัส และเวลาที่การสืบสวนที่ยาวนานกว่าจะต้องใช้
• Access Token ใช้เปิดที่อยู่ใหม่ได้ แต่ไม่ใช่ข้อความที่หมดอายุแล้ว และ token ที่สูญหายไม่สามารถกู้คืนได้
• กล่องจดหมายบนเว็บถูกอ่านโดยบุคคล การอ่านกล่องจดหมายแบบไม่มีคนดูแลต้องใช้ตัวดัก SMTP หรือ API กล่องจดหมายแบบโฮสต์ เช่น Tmailor Temp Mail API
• บางบริการบล็อกโดเมนอีเมลใช้แล้วทิ้ง หากโฟลว์ที่คุณทดสอบทำเช่นนี้โดยเจตนา ให้ตรวจสอบด้วยที่อยู่จริงหรือที่อยู่ที่บริษัทควบคุม

การเลือกกล่องจดหมายทดสอบที่เหมาะสม

เลือกกล่องจดหมายตามสิ่งที่การทดสอบต้องพิสูจน์ ใช้โดเมนตัวอย่างที่สงวนไว้เมื่อไม่จำเป็นต้องส่งถึงจริง ใช้กล่องจดหมายชั่วคราวสำหรับการตรวจสอบด้วยมือที่ไม่ละเอียดอ่อน ใช้กล่องจดหมายของบริษัทสำหรับเส้นทางที่ต้องเก็บรักษาหรือละเอียดอ่อน ใช้ตัวดัก SMTP เมื่อคุณควบคุมการตั้งค่าขาออก และใช้ API กล่องจดหมายแบบโฮสต์สำหรับการทดสอบแบบไม่มีคนดูแลตั้งแต่ต้นจนจบ

สำหรับกรณีที่ต้องทำด้วยมือ ให้เปิดกล่องจดหมายชั่วคราว และเริ่มจากโฟลว์การสมัครที่คุณจะเปิดตัวถัดไป อีเมลชั่วคราวมีข้อดีมากมาย มากมายนอกเหนือจาก QA เช่นกัน