1) التحضير قبل الاختبار

1.1 تعريف بيئة الاختبار

• حدد ما إذا كان الاختبار على: بيئة تطوير (Dev) أو تجريبية (Staging) أو إنتاج (Prod) مع قيود مختلفة.
• وثّق مزوّد الرسائل: SMTP/مزود طرف ثالث، أو خدمة رسائل داخلية، أو Queue (مثل SQS/RabbitMQ).
• حدد قنوات OTP: بريد فقط، أو SMS فقط، أو كلاهما، وهل يوجد خيار تبديل القناة داخل الواجهة.
• تأكد من تزامن الوقت بين السيرفرات (NTP) لأن صلاحية OTP تتأثر بفروق التوقيت.

1.2 اختيار نوع البريد المؤقت

• بريد “قصير جدًا” لاختبار سيناريوهات الانتهاء السريع (جلسة قصيرة) للتحقق من التعامل مع التأخير.
• بريد “مؤقت مرن” لمدة أطول لاختبار إعادة الإرسال، ورسائل المتابعة، والتحقق من إمكانية الرجوع لنفس العنوان.
• بريد “استقبال فقط” (Receive-only) إن كان متاحًا، للتحقق من أن النظام لا يعتمد على أي قدرات إرسال.

1.3 بيانات الاختبار والسيناريوهات

• جهّز مجموعة إيميلات مختلفة: عناوين قصيرة/طويلة، أحرف خاصة مسموحة، نطاقات متعددة.
• جهّز حالات مستخدمين: جديد تمامًا، تم التسجيل سابقًا، محظور، غير مفعل، حذف حساب.
• اتفق على سياسة البيانات: عدم إدخال معلومات حساسة أو أرقام هواتف حقيقية أثناء هذه الاختبارات.

2) قائمة تدقيق واجهة التسجيل (Signup UI)

2.1 التحقق من الحقول (Client-side Validation)

• تنسيق البريد: قبول صيغة صحيحة، رفض صيغ خاطئة، عرض رسالة خطأ واضحة.
• المسافات: إزالة المسافات قبل/بعد البريد، ومنع الفراغات داخل البريد إن وُجدت.
• حساسية الأحرف: التعامل مع البريد كحالة غير حساسة (case-insensitive) في العادة.
• النسخ واللصق: التأكد من أن اللصق لا يكسر التنسيق، ولا يضيف رموز غير مرئية.
• منع التكرار: إذا كان البريد مستخدمًا سابقًا، يجب أن يظهر الخطأ بشكل واضح دون تسريب معلومات زائدة.

2.2 تجربة المستخدم

• زر الإرسال واضح ويعمل بحالة تحميل، ويُمنع النقر المتكرر أثناء الطلب.
• رسائل الخطأ لا تختفي بسرعة، وتشرح ما يجب فعله بدقة.
• في التطبيق: تحقق من لوحة المفاتيح (email keyboard) وأن زر “Next/Done” يعمل كما ينبغي.
• إمكانية الوصول: تسميات الحقول، تباين الألوان، وقراءة الشاشة للمستخدمين.

3) قائمة تدقيق إرسال OTP (Trigger OTP)

3.1 نجاح الطلب (Happy Path)

• عند إرسال طلب OTP، يتم إنشاء رمز صالح وتسجيله/تتبعه (بدون كشفه للمستخدم).
• تظهر للمستخدم شاشة/حالة تؤكد إرسال الرمز مع تعليمات مختصرة.
• يوجد عدّاد أو توضيح للوقت المتبقي قبل السماح بإعادة الإرسال (إن كانت السياسة هكذا).
• تأكد أن الطلب ينجح مع البريد المؤقت كما ينجح مع البريد العادي (إذا لا يوجد حظر متعمد).

3.2 حدود الطلبات (Rate Limits)

• اختبر إرسال OTP عدة مرات بسرعة لمعرفة متى يظهر الحظر (إن وُجد) وكيف يتم عرضه للمستخدم.
• تحقق أن النظام لا يسمح بتجاوز الحد عبر تحديث الصفحة أو إعادة فتح التطبيق.
• راقب إن كان الحظر مرتبطًا بالبريد فقط أو بالـ IP أو الجهاز أو بصمة المتصفح.
• تأكد أن رسائل الحظر لا تكشف تفاصيل حساسة (مثل “هذا البريد غير مسموح” بطريقة يمكن استغلالها).

3.3 التعامل مع فشل مزود البريد/الرسائل

• محاكاة فشل الإرسال: مزود خارجي متعطل، Queue متوقفة، أو تأخير كبير.
• التأكد من وجود رسالة للمستخدم: “حصلت مشكلة، حاول لاحقًا” مع الحفاظ على تجربة واضحة.
• تحقق من إعادة المحاولة من الخلفية (Retry) إن كانت موجودة، ومنع التكرار غير المرغوب.

4) قائمة تدقيق استلام البريد (Inbox Delivery)

4.1 وقت وصول الرسالة

• اختبر وصول الرسالة خلال ثوانٍ، وخلال دقيقة، وخلال عدة دقائق (تأخير واقعي).
• راقب سلوك الواجهة إذا تأخر البريد: هل تقترح إعادة الإرسال؟ هل تقول “قد يستغرق دقيقة”؟
• في البريد المؤقت القصير: اختبر سيناريو وصول الرسالة بعد انقضاء الجلسة لمعرفة كيف يتعامل المستخدم.

4.2 محتوى رسالة OTP

• العنوان (Subject) واضح ويُعرّف الخدمة بدون إفراط أو كلمات قد تسبب تصنيف الرسالة كسبام.
• الرمز ظاهر بوضوح (نص كبير/سهل النسخ)، ولا يعتمد فقط على صورة.
• يوجد سياق: لماذا وصل الرمز؟ وما مدة الصلاحية؟ وماذا تفعل إن لم تطلبه أنت؟
• تحقق من الروابط إن وجدت: لا تُحمّل مخاطر، وتفتح في المتصفح الصحيح، ولا تكسر على iOS/Android.

4.3 النسخ واللصق من البريد

• اختبر نسخ OTP من البريد المؤقت ولصقه في الحقل، خاصة في الهاتف حيث يتغير سلوك النسخ.
• تحقق من أن الحقل يقبل أرقام فقط (إن كان OTP رقميًا)، ويمنع المسافات تلقائيًا.
• على iOS: تحقق من اقتراح OTP التلقائي من لوحة المفاتيح إن كانت الرسالة تدعم ذلك.

5) قائمة تدقيق إدخال OTP والتحقق (Verify OTP)

5.1 نجاح التحقق

• إدخال OTP الصحيح يؤدي إلى نجاح فوري وانتقال منطقي للخطوة التالية.
• بعد النجاح، يجب أن يصبح OTP غير صالح للاستخدام مرة أخرى (One-time).
• تحقق من أن الجلسة (Session) أو التوكن (Token) يتم إنشاؤه بشكل صحيح.
• تأكد من أن المستخدم لا يُعاد إلى شاشة OTP بعد تحديث الصفحة دون سبب.

5.2 فشل التحقق (Wrong OTP)

• إدخال رمز خاطئ يعطي رسالة دقيقة: “الرمز غير صحيح” دون كشف الرمز الصحيح.
• عدد المحاولات: تحقق من الحد الأقصى، وما يحدث بعد تجاوزه (قفل مؤقت/طلب OTP جديد).
• تحقق من سلوك الحقل: هل يتم مسح الرموز؟ هل يبقى آخر إدخال؟ ما الأفضل لتجربة المستخدم؟

5.3 انتهاء صلاحية OTP

• اختبر انتهاء الصلاحية فعليًا بانتظار مدة أطول ثم إدخال الرمز القديم.
• التطبيق/الموقع يجب أن يعرض سبب الفشل: “انتهت صلاحية الرمز” مع زر واضح لإعادة الإرسال.
• تحقق من عدم قبول رموز قديمة بعد إصدار رمز جديد لنفس البريد.

6) إعادة الإرسال (Resend OTP) بدون مشاكل

6.1 شروط إعادة الإرسال

• زر إعادة الإرسال يظهر بعد عدّاد، أو يكون معطّلًا مع توضيح السبب.
• عند الضغط، يتم إصدار OTP جديد ويلغى القديم فورًا (إن كانت السياسة هكذا).
• اختبر عدة مرات لمعرفة ما إذا كانت الرسائل تتراكم في البريد المؤقت بشكل مربك.

6.2 التمييز بين الرسائل

• التأكد من أن المستخدم يستطيع معرفة أحدث OTP بسرعة (تنسيق الرسالة، وقت الإرسال، أو تمييز واضح).
• إذا وصلت الرسائل بترتيب غير متوقع، يجب ألا ينجح إلا آخر رمز فعّال.
• تأكد أن واجهة OTP لا تقبل تلقائيًا رمزًا من رسالة قديمة بسبب النسخ السريع.

7) الحظر والقبول: Disposable Domains Policy

7.1 إذا كان النظام يسمح بالبريد المؤقت

• اختبر نطاقات متعددة للتأكد من عدم وجود حظر خاطئ (False Positive).
• تأكد من أن التسجيل لا يتطلب “تحقق إضافي” فقط لأن البريد مؤقت دون رسالة واضحة.
• راقب سلوك مكافحة الإساءة: هل يفرض CAPTCHA؟ هل يرفع متطلبات الأمان؟

7.2 إذا كان النظام يمنع البريد المؤقت

• يجب أن تظهر رسالة احترامية وواضحة: “استخدم بريدًا يمكن الوصول إليه لاحقًا” دون إحراج أو غموض.
• لا تكشف اسم قائمة الحظر أو تفاصيل تقنية يمكن استغلالها.
• تأكد من أن المنع يحدث مبكرًا قبل إرسال OTP لتقليل التكلفة والضغط على الأنظمة.
• اختبر نطاقات شبيهة قد يتم حظرها بالخطأ بسبب تشابه الأسماء.

8) سيناريوهات الحافة (Edge Cases) التي تُفاجئ الفرق عادةً

8.1 البريد يصل لكن المستخدم في شاشة أخرى

• ارجع خطوة للوراء ثم عد لشاشة OTP: هل الحالة محفوظة؟ هل الزر يعمل؟
• تحديث الصفحة: هل يضيع البريد الذي تم إدخاله؟ هل يعيد الطلب تلقائيًا؟
• في التطبيق: إغلاق وفتح سريع، أو تبديل بين التطبيقات: هل تبقى شاشة OTP مستقرة؟

8.2 مستخدم يغير البريد بعد طلب OTP

• تأكد من وجود خيار “تغيير البريد” وأنه يلغي OTP السابق ويرسل جديدًا للبريد الجديد.
• تحقق من عدم حدوث التباس بين بريدين مختلفين في نفس الجلسة.

8.3 أكثر من جهاز

• اطلب OTP من جهاز، وأدخل الرمز من جهاز آخر إن كانت المنصة تسمح بذلك.
• تحقق من سياسات الأمان: هل يتم ربط OTP بجلسة/متصفح محدد؟ وكيف ينعكس ذلك على تجربة المستخدم؟

8.4 تعدد المناطق والتوقيت

• اختبر تباين المنطقة الزمنية في الجهاز: هل تتغير طريقة عرض صلاحية OTP أو العدّاد؟
• اختبر على شبكة مختلفة (Wi-Fi/بيانات) لمعرفة تأثير التأخير على الاستلام.

9) التحقق من الأمان (Security QA)

9.1 منع تسريب المعلومات

• عند إدخال بريد غير مسجل: لا تعرض “هذا البريد غير موجود” بطريقة تسهل التخمين.
• عند التسجيل: لا تكشف إن كان البريد موجودًا إلا بقدر الضرورة وبأسلوب لا يدعم Enumerations.
• الردود من الـ API يجب أن تكون متسقة: نفس بنية الرسالة وأكواد الأخطاء قدر الإمكان.

9.2 الحماية من الإساءة

• CAPTCHA عند الاشتباه: اختبر متى يظهر وكيف يعود للاختفاء بعد نجاح التحقق.
• Rate limit على IP والبريد والجهاز: تأكد أنه يوقف الإساءة دون إزعاج المستخدم الطبيعي.
• تأكد أن OTP لا يظهر في سجلات الواجهة الأمامية أو في رسائل الخطأ أو في روابط URL.

9.3 سلامة الروابط داخل البريد

• إذا كانت الرسالة تحتوي رابط تحقق: اختبر أنه يعمل مرة واحدة فقط، ولا يمكن إعادة استخدامه.
• تحقق من الحماية ضد إعادة التوجيه (Open redirect) إن كان الرابط يعيد المستخدم لصفحة معينة.
• على الهاتف: تأكد أن الرابط يفتح داخل التطبيق (Deep link) إن كان مفعلًا، أو يفتح المتصفح بشكل صحيح.

10) التحقق من القياس والمراقبة (Observability)

10.1 مؤشرات يجب تتبعها أثناء الاختبار

• زمن إصدار OTP وزمن وصول الرسالة (إن كانت القياسات متاحة).
• نسبة فشل الإرسال (SMTP/Provider errors) مقابل فشل التحقق (Wrong/Expired).
• نسبة طلبات إعادة الإرسال، ومتوسط عدد المحاولات قبل النجاح.
• حالات الحظر بسبب Rate limit أو سياسات منع البريد المؤقت.

10.2 سجلات وأخطاء يمكن أن تساعد QA

• تسجيل معرف الطلب (Request ID) للمستخدم في الواجهة ليُستخدم عند دعم العملاء أو التحقيق.
• تسجيل أسباب الفشل داخليًا بشكل غني، لكن عرض رسالة مبسطة للمستخدم.
• تأكيد عدم كتابة OTP نفسه في السجلات حتى في البيئات التجريبية، إلا بسياسة واضحة ومؤقتة للغاية.

11) سيناريوهات اختبار جاهزة (Test Cases) بصياغة قابلة للتنفيذ

11.1 حالات النجاح

• تسجيل ببريد مؤقت، استلام OTP بسرعة، إدخاله صحيحًا، إكمال إنشاء الحساب.
• تسجيل ببريد مؤقت، تأخير بسيط في وصول الرسالة، النجاح بعد انتظار منطقي.
• إعادة إرسال OTP مرة واحدة، استلام الرمز الجديد، نجاح التحقق بالرمز الجديد فقط.

11.2 حالات الفشل المتوقعة

• إدخال OTP خاطئ عدة مرات حتى الوصول للحد، ثم تحقق من رسالة القفل المؤقت.
• إدخال OTP بعد انتهاء الصلاحية، ثم إعادة الإرسال والنجاح.
• استخدام بريد مؤقت محظور (إن كانت السياسة تمنع)، والتحقق من الرسالة وسلوك الواجهة.
• ضغط زر الإرسال بسرعة عدة مرات: تحقق من منع التكرار وعدم إرسال عدة OTP بلا داعٍ.

11.3 حالات حافة

• تغيير البريد بعد طلب OTP: تأكد من إلغاء القديم وإصدار جديد للبريد الجديد.
• تحديث الصفحة أثناء العدّاد: تحقق من استمرارية العدّاد وعدم كسره.
• تبديل الشبكة أثناء التحقق: تأكد من رسائل الخطأ وإمكانية إعادة المحاولة دون فقدان الحالة.

12) توصيات عملية لفريق QA داخل سير العمل

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