اختبار البريد المعاملاتي هو انتظام فحص البريد الذي يرسله منتجك نيابة عن نفسه، قبل أن يتلقاه أشخاص حقيقيون. تأكيد تسجيل، وإعادة تعيين كلمة مرور، وإشعار طلب، وفاتورة: كل واحد منها يحرك بحدث، ويملأ من بيانات، ويتوقع أن يصل مرة واحدة بالضبط. وأنماط الفشل عادية ومكلفة: محفز لا يقع أبدا، وقالب يعرض اسما فارغا، ورابط يشير إلى بيئة خاطئة، وإعادة محاولة تنتج ثلاث إيصالات متطابقة.
ما الذي يعد بريدا معاملاتيا
يرسل البريد المعاملاتي لأن شيئا وقع، إلى شخص طرف في ذلك الحدث. ليس رسالة إخبارية ولا عرضا ترويجيا، والتمييز ليس نظريا: إنه يغير المحتوى المناسب، وما يتوقعه المستلم، وما تعنيه إلغاء الاشتراك بنقرة واحدة في كل حالة.
والحد يضطرب في الممارسة، والاضطراب هو حيث تبدأ المشكلات. وضع كتلة ترويجية داخل رسالة إعادة تعيين كلمة مرور طريقة مجربة لإغاظة الناس. وإرسال تأكيد طلب عبر خط التسويق يعني أن تفضيل كتم أو إلغاء اشتراك يمكن أن يوقف بصمت رسالة يحتاجها المستلم فعلا.
فقرر إلى أي خط تنتمي كل رسالة، واجعل ذلك القرار ظاهرا في التهيئة لا في ذاكرة أحدهم.
فحص قائمة المحفزات قبل الإطلاق
ابدأ من الأحداث، لا من القوالب. ولكل حدث يجب أن ينتج بريدا، تأكد من أن رسالة تنتج فعلا، وترسل إلى العنوان الصحيح، وتعرف بأنها تنتمي إلى ذلك الحدث.
- أنشئ الحساب، وطلب تأكيد العنوان، وتغير العنوان.
- طلبت إعادة تعيين كلمة المرور، وتغيرت كلمة المرور.
- أجري الطلب، وسدد المبلغ، وصدر استرداد.
- أنتجت فاتورة أو إيصال.
- الإشعارات المجدولة أو المتعلقة بالأمن التي يعد بها المنتج.
ولكل سطر الأسئلة نفسها: هل يقع مرة واحدة، وهل يحمل المستلم الصحيح، وهل ينجو من إعادة المحاولة؟ القائمة التي تسمي الحدث أنفع من التي تسمي القالب، لأن الأحداث هي ما يغيب فعلا.
هل تعرض المتغيرات دائما؟
العرض هو الموضع الذي ما زال فيه منتج مختبر جيدا يشحن عيوبا ظاهرة، لأن قالبا يعرض بشكل صحيح ببيانات كاملة قد يعرض بشكل مختلف تماما ببيانات ناقصة.
والحالات الجديرة بالتجربة هي الفارغة. مستخدم باسم واحد، ومستخدم بلا اسم عرض إطلاقا، وطلب ببند واحد وطلب بلا بنود، وقيمة نصية فارغة بدل قيمة غائبة. كل واحدة من هذه يجب أن تنتج شيئا يستطيع إنسان قراءته، وألا تنتج أي منها نص عنصر نائب خاما أو فجوة حيث كانت الجملة تتوقع اسما.
وعادتان تساعدان. امنح كل متغير قيمة احتياطية محددة، حتى ينتج الغياب عبارة معقولة لا فراغا. واعرض في مسار الكود نفسه الذي يستخدمه المنتج، حتى يختبر الاختبار القالب الحقيقي لا نسخة منه تنحرف عنه.
ما الذي يحدث حين يقع الحدث نفسه مرتين؟
افترض أن مزود الدفع نادى واجهتك مرتين، أو أن طابورا أعاد التسليم لأن إقرارا ضاع. يجب ألا يتلقى المستخدم إيصالين لطلب واحد.
هذه خاصية في جهة الإرسال لا في خادم البريد، وتستحق اختبارا مباشرا: سلم الحدث نفسه مرتين وأكد أن رسالة واحدة تنتج. والآلية المعتادة معرف يقدمه الحدث، ويسجل عند قبول الرسالة، فيعرف التسليم الثاني كمكرر. وأيا كانت الآلية، يجب أن يختبرها الاختبار لا أن يفترضها، لأن الأحداث المكررة طبيعية في الأنظمة الموزعة، والبريد لا يملك وسيلة لإلغاء رسالة أرسلت.
لماذا تهم هوية الإرسال؟
لأن الأنظمة المستقبلة تقرر الثقة برسالة ما جزئيا بناء على مصدرها الظاهري. النطاق المرسل يهيأ عادة بسجلات تصريح وتوقيع تنشر في منظومة النطاقات، وهذه السجلات هي ما يتيح للمستقبل أن يعرف أن الرسالة جاءت فعلا من النطاق الذي تدعي. والآليات معيارية، والنقطة التشغيلية أن نطاقا مهيأا لحركة ويب عادية ليس مهيأ آليا لإرسال البريد، وإطلاقا يتخطى هذه الخطوة قد ينتج رسائل تبدو بريدا مزعجا من اليوم الأول.
وضبط ذلك مهمة من يملك النطاق، وتفاصيله تعتمد على مزود البريد. وما تستطيع قائمة التحقق فعله هو تأكيد أن الضبط أنجز فعلا في البيئة التي تطلق فيها، لا في البيئة التي اختبرت فيها فقط.
اللغات وتنسيقات الوقت وفروق البلدان
المنتج الذي يخدم أكثر من سوق يرث خطأين سهلين. الأول النص: رسالة مترجمة في متنها لكن سطر موضوعها وتذييلها تركا باللغة الأصلية. والثاني التنسيق: تاريخ يقرأ بوضوح في سوق ويقرأ بشكل مربك في أخرى، أو رقم بفاصل عشري مختلف عن الذي يتوقعه المستلم.
والفحص الملموس هو أن تحرك كل رسالة في كل لغة يشحنها المنتج وتقرأ الرسالة كاملة، بما فيها الموضوع، كما يقرأها مستلم. وإن كان المحتوى يشير إلى تفصيل خاص ببلد ما — تنسيق معرف، أو تسمية ضريبية، أو عرف بريدي — فإن صفحات السوق المعنية مرجع مفيد لما يتوقعه ذلك السوق.
وكل ما ترسله في هذه الجولة يجب أن يذهب إلى عناوين أنشأتها لهذا الغرض. لا شيء مما وصف هنا هوية حقيقية أو جهة اتصال عميل حي، ولا يجوز أن يشحن أي قالب يحتوي عنوان شخص حقيقي.
للمطورين: التكرار ومعالجة الفشل والسجلات
أربع خصائص تستحق تغطية صريحة في المجموعة.
التكرار أولا: حدث واحد، رسالة واحدة، بصرف النظر عن عدد مرات تسليم الحدث. أكد ذلك بتسليمه مرتين.
معالجة الفشل ثانيا: قرر ما يحدث حين يرفض مزود البريد أو تنتهي مهلته. الإرسال الفاشل يجب أن يسجل، وأن تعاد محاولته وفق جدول، وأن يظهر — لا أن يبتلع. الفشل الصامت يعني اكتشاف المشكلة من عميل.
القيم الاحتياطية للقوالب ثالثا: حدد ما يعرضه كل متغير عند غيابه، واختبر حالة الغياب. هذه فئة العيوب التي تصل إلى الإنتاج أكثر من غيرها، لأن بيانات الاختبار الكاملة تخفيها.
السجلات رابعا: احفظ ما يكفي لتشخيص رسالة مفقودة، ولا تحفظ ما يحول السجل إلى عبء بيانات. سجل معرف الحدث ونسخة القالب والنتيجة. ولا تسجل متن الرسالة، ولا تسجل رابط إعادة التعيين، لأن سطر سجل يحتوي رابطا صالحا هو بيانات اعتماد بعمر تخزين طويل.
وللبريد الذي تولده اختباراتك أنت، فإن عنوانا ينشأ للتشغيل يبقي التحققات ضيقة ويخرج صناديق الآخرين من المعادلة؛ وأداة البريد المؤقت تنشئ واحدا في ثوان، وكيف يعمل البريد المؤقت يشرح ما يحدث للرسائل بعد ذلك، والتقاط البريد داخل الاختبارات يغطي الحالات التي لا ينبغي أن يغادر فيها البريد الجهاز أصلا.
الخطوات التالية
خذ قائمة المحفزات أعلاه وضع أمام كل سطر البيئة التي رأيته يعمل فيها آخر مرة والشخص الذي قرأ الرسالة آخر مرة. كل سطر بلا علامة خطر إطلاق. ثم أرسل إلى نفسك كل رسالة من عنوان أنشئ للاختبار على صفحة البريد المؤقت، واقرأها كما يقرأها مستلم — في سطر الموضوع كما في المتن، وبناء على ذلك راجع اختبار مسار التحقق لترى ما يجري حول الرسالة لا داخلها.