هل من الطبيعي استلام المشروع بدون اختبار تكامل API، أم كان ينبغي أن نشترط ذلك في العقد؟

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

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

جمدوا الدفعة الأخيرة على الفور. أرسلوا إيميل للوكالة وقولوا لهم: "بناءً على معايير القبول لدينا، لن يتم توقيع محضر الاستلام حتى يتم توثيق 5 سيناريوهات أساسية في بيئة اختبار مزود الدفع (السحب الناجح، عدم كفاية الرصيد، إلغاء 3D secure، انتهاء المهلة، والاسترداد التلقائي)." وسترون كيف سيتغير موقفهم فوراً.

ارتكبنا نفس هذا الخطأ قبل عامين في مشروع جولات بميزانية 18.000 EUR. وثقنا في الوكالة ورفعنا الموقع للخدمة مباشرة؛ وفي أول أسبوع تم سحب الأموال في 22 معاملة دون أن يتم تسجيل الحجز في التقويم. اضطررنا لإرجاع 3.100 EUR للعملاء وإغلاق النظام لمدة 10 أيام. الأيام الثلاثة التي وفرناها من وقت الاختبار كلفتنا أسبوعين من المشاكل.

هل هناك بند في العقد الذي وقعتموه يتعلق باختبار القبول أو مرحلة الإطلاق الفعلي؟ إذا كانوا قد وضعوا بنداً قياسياً مثل "يعتبر المشروع معتمداً إذا لم يتم الاعتراض عليه خلال 14 يوماً من تسليمه للعميل"، فقد تحتاجون لتقديم اعتراض خطي على الفور قبل انتهاء هذه المدة.

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

عند الاستلام، يجب أن تطلبوا هذه المستندات الثلاثة: 1) جدول نتائج السيناريوهات التي تم تشغيلها في بيئة sandbox، 2) لقطات شاشة لرسائل الخطأ التي تظهر للعميل في العمليات الفاشلة، 3) تقرير مطابقة العمليات التي تمت ببطاقات الاختبار بين لوحة تحكم الدفع وقاعدة بيانات الموقع. بدون هذه الوثائق، لا يعتبر النظام قد تم تسليمه.

لا تقلقوا ولكن لا تتراجعوا أيضاً. المبرمجون يكرهون إجراء الاختبارات لأن اكتشاف الـ bugs فيها يؤخر موعد التسليم... بصراحة تمسكوا بموقفكم وحقكم، ولا تخرج الـ 4.000 EUR من الخزينة قبل وصول تقرير الاختبار.

ارتحت لقراءة هذه الإجابة، يبدو أن المشكلة ليست عندي وحدي. إذا لم تُكتب معايير القبول، فإن وقت انتهاء العمل يبقى مفتوحاً للنقاش.

إذا لم تقم بصياغة هذا كتابيًا من البداية، فستنشأ خلافات لاحقًا.

دعوني ألخص ما قيل حتى الآن. النظام يستمر بعد التسليم؛ الصيانة بند منفصل.

يجب ربط جدول المدفوعات بمراحل العمل، وليس بالتقويم. مثبت بالتجربة.

أنت محق، لقد مررت بنفس المسار. النظام يستمر بعد التسليم؛ الصيانة بند منفصل.

وضع عملية لطلبات التغيير لا يبطئ العمل، بل يسرّعه. هذا كل شيء، أرجو المعذرة إذا أطالت.

بالضبط، بل إن هذا الجانب غير معروف بشكل كافٍ. النظام يستمر بعد التسليم؛ الصيانة بند منفصل.

إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.

لم أكن أعلم بهذا. انظروا أولاً إلى البيانات المتاحة لديكم عند اتخاذ القرار.

بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

أحسنت في فتح هذا العنوان.

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

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

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

مررت بهذا الطريق، دعني أشرح. على كل حال الخطأ المرتكب من جانب اختبار تكامل api قابل للإصلاح عادةً، لكنه مكلف.

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

أتابع الموضوع.