fa

یک برنامه تست واقعی ایمیل: ثبت‌نام، بازنشانی، دعوت و تغییر آدرس

یک برنامه تست عملی برای جریان‌های محصول مبتنی بر ایمیل، با هویت‌های تست پاک، ادعاهای مفید، موارد منفی، و شواهدی که توسعه‌دهندگان می‌توانند بر روی آن اقدام کنند.

26 تیر 1405

یک مهندس کیفیت که چندین مسیر کاربری مبتنی بر ایمیل را تست می‌کند

«ایمیل رسید» یک نتیجه تست کافی نیست.

یک پیام ثبت‌نام می‌تواند به صندوق ورودی برسد اما گیرنده اشتباه، لینک منقضی‌شده، طرح‌بندی موبایل خراب، نام میزبان تولید یا خط موضوعی که در زبان دیگر معنایی ندارد. تست ایمیل خوب تمام مسیر کاربری را دنبال می‌کند و شواهد کافی برای تشخیص شکست فراهم می‌آورد.

صندوق‌های ورودی موقت در اینجا مفید هستند زیرا هر اجرا می‌تواند با یک آدرس پاک شروع شود. صندوق ورودی باید قابل حذف باشد؛ اما نتیجه تست نباید باشد.

ساخت یک ماتریس کوچک و هدفمند

با جریان‌هایی که می‌توانند کاربر را مسدود کنند، شروع کنید:

  • تأیید حساب جدید؛
  • بازنشانی رمز عبور؛
  • دعوت به تیم یا فضای کاری؛
  • تأیید تغییر ایمیل؛
  • لینک ورود یا کد یک‌بار مصرف؛
  • هشدار امنیتی پس از یک عمل حساس.

برای هر جریان، مسیر خوشحال (happy path)، یک اعتبار منقضی‌شده یا دوباره استفاده‌شده، و یک خطای سمت گیرنده را تست کنید. این کار عیوب واقعی بیشتری را نسبت به ارسال ده‌ها پیام یکسان مسیر خوشحال شناسایی می‌کند.

استفاده از یک صندوق ورودی برای هر سناریو

استفاده مجدد از یک آدرس باعث ابهام می‌شود. یک پیام بازنشانی قدیمی می‌تواند با جدیدترین اشتباه گرفته شود و تست‌های همزمان می‌توانند لینک‌های یکدیگر را مصرف کنند.

برای هر مورد تست یا اجرای تست یک آدرس منحصر به فرد تولید کنید. آن را همراه با شماره ساخت، محیط، زبان و سناریو ثبت کنید. اگر تستی شکست بخورد، آدرس بخشی از شواهد می‌شود و می‌تواند قبل از انقضای نگهداری بررسی شود.

از آدرس‌های واقعی مشتریان در محیط staging استفاده نکنید. این کار پیام‌های ناخواسته، آلودگی تحلیل‌ها و دشواری در پاک‌سازی خودکار را به همراه دارد.

اعتبارسنجی پاکت قبل از محتوا

قبل از کلیک کردن روی هر چیزی، بررسی کنید:

  1. پیام به دقیقاً آدرسی که برای این تست ایجاد شده بود ارسال شد.
  2. دامنه فرستنده همان دامنه مورد انتظار برای محیط است.
  3. موضوع، اقدام را شناسایی می‌کند بدون اینکه داده‌های حساس را فاش کند.
  4. فقط تعداد پیام‌های مورد نظر دریافت شد.
  5. زمان‌سنجی (timestamp) پس از عملی که آن را تحریک کرده بود، باشد.

این بررسی‌ها مشکلات مسیریابی و تکرار را قبل از اینکه تجزیه‌کننده محتوا آن‌ها را پنهان کند، شناسایی می‌کنند.

تست محتوا همان‌گونه که کاربر می‌بیند

پیام را هم در نمای صفحه‌نمایش باریک و هم پهن باز کنید. بررسی کنید که اقدام اصلی قابل مشاهده باشد، متن ساده جایگزین قابل درک باشد و آدرس‌ها یا URLهای طولانی طرح‌بندی را خراب نکنند.

برای جریان مبتنی بر کد، تأیید کنید که جدیدترین کد یک بار کار می‌کند و پس از استفاده ناموفق است. برای جریان مبتنی بر لینک، قبل از باز کردن آن، میزبان و محیط را تأیید کنید. یک پیام staging که به محیط تولید اشاره دارد، حتی اگر لینک از نظر فنی کار کند، مانع انتشار می‌شود.

همچنین جزئیات کمتر جذاب را بررسی کنید: رفتار reply-to، تماس پشتیبانی، متن انقضا، زبان، و نام حساب یا فضای کاری که در پیام نشان داده شده است.

موارد منفی که ارزش نگهداری دارند

تست‌های منفی مفید شامل موارد زیر هستند:

  • درخواست کد دوم و تأیید اینکه اولین کد نامعتبر شده است؛
  • باز کردن لینک منقضی‌شده؛
  • باز کردن یک لینک دو بار؛
  • تغییر وضعیت حساب قبل از استفاده از پیام؛
  • دعوت از آدرسی که قبلاً به یک عضو تعلق دارد؛
  • وارد کردن آدرس نامعتبر یا خراب؛
  • تاخیر در تحویل به اندازه‌ای که از مرز انقضا عبور کند.

این تست‌ها شرایط رقابتی و پیام‌های خطای گمراه‌کننده‌ای را آشکار می‌کنند که یک بررسی ساده صندوق ورودی هرگز پیدا نمی‌کند.

جداسازی شکست محصول از تأخیر تحویل

وقتی پیامی گم می‌شود، زمان‌سنجی‌های مربوط به عمل کاربر، صف‌گذاری برنامه، تحویل به ارائه‌دهنده و رسیدن به صندوق ورودی را در صورت موجود بودن این سیگنال‌ها حفظ کنید. یک اسکرین‌شات از صندوق ورودی خالی فقط ثابت می‌کند که پیام در آن لحظه قابل مشاهده نبوده است.

قبل از ثبت یک مشکل مبهم «ایمیل خراب»، از توالی تشخیصی موجود در ایمیل تأیید نمی‌رسد: مرحلهٔ خراب را پیدا کنید استفاده کنید.

چه چیزی را خودکار کنیم

قراردادهای پایدار را خودکار کنید:

  • آدرس منحصر به فردی تولید کنید؛
  • عمل محصول را فعال کنید؛
  • با زمان‌سنجی محدود و بازگشت (backoff) نظرسنجی کنید؛
  • فرستنده و موضوع مورد انتظار را تطبیق دهید؛
  • جدیدترین پیام مطابق را بخوانید؛
  • کد یا لینک را نسبت به محصول اعتبارسنجی کنید؛
  • شواهد مفید شکست را ذخیره کنید؛
  • پاک‌سازی کنید.

بازبینی بصری، کیفیت متن و رفتارهای غیرمعمول مشتری را در یک مرحله دستی متمرکز نگه دارید. خودکارسازی در تکرار خوب است، نه در سلیقه.

اتوماسیون قابل‌اتکای API صندوق ورودی موقت بخش API را پوشش می‌دهد، از جمله نظرسنجی و پاک‌سازی.

گزارش شکست مفید

گزارشی که توسعه‌دهندگان می‌توانند بر روی آن اقدام کنند شامل سناریو، محیط، آدرس، زمان تحریک، فرستنده مورد انتظار، پیام‌های مشاهده‌شده، آخرین زمان نظرسنجی، وضعیت پاسخ و یک اسکرین‌شات یا بخش پاک‌سازی شده از متن است. هرگز اسرار زنده یا لینک‌های تأیید قابل استفاده مجدد را به یک مشکل عمومی پیوست نکنید.

هدف این نیست که ثابت شود ایمیل نامطمئن است. هدف شناسایی قراردادی است که شکست خورده و ایجاد مسیر قابل تکرار برای رفع آن.

GPTMail