قائمة اختبار نموذج الدفع قبل الإطلاق

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

تبني هذه المقالة قائمة اختبار نموذج الدفع من الأعلى إلى الأسفل: حالات الطلب أولا، ثم مسارات الفشل، ثم الحقول، وأخيرا ما يحتاجه من يكتب هذه الاختبارات فعليا.

لماذا تبدأ القائمة من حالات الطلب لا من الحقول؟

الحقول تختبر بالوحدات، أي هل يقبل الحقل هذا الطول، وهل يرفض ذلك الحرف. وهذه اختبارات ضرورية لكنها لا تلمس ما يحدث فعلا للمال.

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

ولذلك تبدأ القائمة من الحالات، لأن الحالة هي ما يجب أن يكون له نهاية معروفة في نظامك، أي قرار مكتوب في الكود لا نتيجة اتفق عليها بالكلام.

الحالات العشر التي يجب أن تكون معروفة

لكل حالة في هذه القائمة تعريف في نظامك، وتحول مسموح إلى حالة تالية، وسلوك معروف للواجهة. وإن لم تجد واحدة منها معرفة، فذلك نتيجة الاختبار الأهم في هذه المقالة.

وأضف إلى الجدول حالات الخلاف حيث يدعي المستخدم أن الطلب غير صحيح؛ فهي جزء من دورة الحياة ومسارها مختلف عن مسار الرد.

كيف تصنف مسارات الرفض؟

الرفض في نظام الدفع ليس حدثا واحدا، وأهم فائدة من التصنيف أنه يحدد القرار التالي. فأنت لا تريد أن يعيد النظام المحاولة تلقائيا على كل رفض، ولا أن يطلب من المستخدم بطاقة أخرى في كل حالة.

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

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

إعادة المحاولة والخصم المزدوج

أسوأ نتيجة يمكن أن ينتجها نموذج دفع ليست رفضا؛ بل خصم مزدوج لمستخدم ظن أنه أعاد المحاولة بعد فشل.

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

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

الرد والخصم الجزئي

الرد طريق ينسى كثيرون أنه يحتاج اختبارا. لكن القاعدة التي تفشل دائما ليست وجود الرد، بل قابليته للاستخدام في الحالات غير النظيفة.

اختبر الرد على طلب قبض فعلا، وعلى طلب مصرح به ولم يقبض، وعلى طلب أرسل إليه جزء فقط. والنتيجة في كل حالة مختلفة، ومن لا يختبرها يكتشف الفرق عند أول عملية كبيرة الحجم تحتاج إعادة مبلغ.

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

قائمة الفحص الكاملة

1. بطاقة صحيحة تكمل الطلب وتنتج حالة مقبوض.
2. رقم قصير جدا يوقف الإرسال عند النموذج.
3. رقم طويل جدا يوقف الإرسال برسالة مختلفة.
4. حرف ممزوج بالأرقام يوقف الإرسال برسالة مختلفة مرة ثالثة.
5. بادئة لا تنتمي إلى أي شبكة معروفة، وسلوك الواجهة عندها.
6. رقم يجتاز كل فحص بنيوي لكنه مرفوض من المزود.
7. رفض عابر ثم إعادة محاولة تنجح.
8. رفض نهائي، والتأكد أن الواجهة لا تعرض إعادة المحاولة.
9. طلب يطلب خطوة مصادقة إضافية، وإكمالها بنجاح.
10. الطلب نفسه مع فشل خطوة المصادقة.
11. ضغط الزر عدة مرات مع تعطيل مؤقت، وطلب واحد فقط ينشأ.
12. إغلاق الصفحة في منتصف الدفع، وسلوك الطلب المتروك.
13. رد كامل على طلب مقبوض.
14. رد جزئي، والتحقق من الرصيد المتبقي القابل للرد.
15. صفحة تعود من المتصفح بعد أي من الحالات السابقة، والتحقق من أن الواجهة تعرض الحالة الصحيحة لا حالة قديمة مخزنة.

للمطورين: مصفوفة الحالات ومراجعة إعادة الإرسال

الطريقة الأقوى لضمان تغطية هذه القائمة هي أن تدار كمصفوفة لا كقائمة اختبار يدوي. اجعل لكل سطر من الجدول الأول اختبارا آليا يتحقق من ثلاث نقاط: الحالة الناتجة، والحالة التي تظهر في الواجهة، والأثر الذي تحدثه هذه المعاملة في الأنظمة المجاورة كالفاتورة والبريد وتسليم الخدمة.

وأما مراجعة إعادة الإرسال فلها سؤال واحد ناجع: هل يوجد في مسار الدفع كل مسار كاتب يمكن أن يستدعى مرتين بنفس المدخل وينتج نتيجتين مختلفتين؟ افحص على هذا الأساس معالج الطلب، ومعالج البريد، ومهمة التسليم، ولوحة المراجعة اليدوية. وهنا توجد أكثر العيوب صعوبة في التتبع، لأنها لا تظهر في اختبار الحمل ولا في اختبار الوحدة، بل في أول مستخدم يعيد الإرسال فعلا.

وأخيرا وثق مصدر بيانات الاختبار. فالقيم التي تستخدم في هذه الاختبارات إن كانت صحيحة بنيويا وغير مصدرة، فإن تراكمها في مستودع الاختبار لا يحمل خطرا؛ أما إن كانت مأخوذة من قيم حقيقية، فالمستودع نفسه يصير موضعا يخضع للقواعد المعقدة. وتشرح ملاحظات PCI DSS الحد الفاصل بين النوعين، وهو حد لا ينبغي أن تبنى عليه تخمينات.

الخطوات التالية

اتخذ القرار الأول أولا: اكتب جدول الحالات على ورق وحدد ما يحدث في كل حالة. ثم ترجم كل سطر إلى اختبار آلي ولو كان بسيطا، لأن اختبار الحالات الخمس الأخيرة في القائمة أهم من أي اختبار حقول، وهو الذي يمنع أن يصبح أول يوم إطلاق حقيقي هو أول مرة يواجه فيها نظامك هذه الحالات.