معايير قبول البرامج المخصصة للشركات

العرض الجيد بداية للفحص

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

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

اختبر رحلة أعمال كاملة

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

عبارة «الفواتير تعمل» لا تكفي. حدد المدخلات والدور المنفذ والبيانات المتوقعة في الفاتورة والسجلات التي لا ينبغي تغييرها. اختبر الإلغاء بعد الإسناد، وإعدادًا محاسبيًا غير مكتمل، ومحاولة تسجيل الإنجاز مرتين. يستند التعامل المالي إلى قواعد الشركة المعتمدة، ولا يخترعه كاتب الاختبار.

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

اختر دليلًا يناسب الخطر

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

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

اربط النتيجة بالنسخة المختبرة

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

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

تعامل مع العيوب بقرار واضح

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

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

اجعل الموافقة محددة النطاق

يسجل محضر القبول ما نجح وما استُبعد والقيود المتبقية وصاحب قرار التشغيل. القبول المشروط يحتاج شروطًا ومسؤولية واضحة؛ الصمت في الاجتماع لا يعادل موافقة.

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