معايير القبول في مشروع التطبيق: كيف تكتب شرطًا يُختبر

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

مثال افتراضي للتوضيح تطبيق لموزع مستلزمات يطلب منه عملاؤه من المنشآت، ولوحة تحكم لفريق المبيعات. الأرقام بين القوسين قيم مثال تستبدلها بما يناسب مشروعك. رقّم كل معيار حتى يُشار إليه في محضر الاختبار والعقد.

1. الدخول برقم الجوال ورمز التحقق

• ق-1.1: بافتراض رقم جوال سعودي مسجل، عندما يُدخل بصيغة 05 أو 9665 أو +9665، فإن النظام يقبله ويوحده بصيغة واحدة.
• ق-1.2: عندما يطلب المستخدم الرمز، فإن زر إعادة الإرسال يبقى معطلًا (60 ثانية) مع عداد ظاهر، ولا يُسمح بأكثر من (5) طلبات في الساعة للرقم نفسه.
• ق-1.3: بافتراض رمز منتهي الصلاحية أو مستخدم، عندما يُدخل، فإن الدخول يُرفض برسالة محددة النص ولا تُنشأ جلسة.
• ق-1.4: بافتراض رقم غير مسجل، فإن المستخدم يُحوَّل إلى مسار التسجيل دون أن يكشف النظام إن كان الرقم مسجلًا لطرف آخر.

2. إنشاء طلب

• ق-2.1: بافتراض سلة فيها منتجات، عندما يؤكد العميل الطلب، فإن طلبًا واحدًا فقط يُنشأ حتى لو ضُغط زر التأكيد مرتين متتاليتين.
• ق-2.2: بافتراض منتج نفدت كميته بعد إضافته للسلة، عند التأكيد، فإن العميل يرى اسم المنتج والكمية المتاحة ويختار التعديل أو الحذف قبل الإرسال.
• ق-2.3: عند إنشاء الطلب، فإن مندوب العميل يستلم إشعارًا، ويظهر الطلب في اللوحة بحالة «جديد» مع وقت الإنشاء.
• ق-2.4: بافتراض انقطاع الشبكة أثناء الإرسال، فإن التطبيق لا يعرض الطلب ناجحًا ما لم يؤكده الخادم، ولا يُنشئ طلبًا مكررًا عند إعادة المحاولة.

3. الدفع الإلكتروني

• ق-3.1: بافتراض دفع ناجح في البوابة، فإن حالة الطلب تتغير إلى «مدفوع» ويستلم العميل إيصالًا، ويطابق المبلغ المسجل في النظام مبلغ العملية لدى البوابة.
• ق-3.2: بافتراض خروج المستخدم من التطبيق أثناء التحقق لدى البنك ثم عودته، فإن الطلب يعكس النتيجة الفعلية للعملية لا حالة معلقة دائمًا.
• ق-3.3: بافتراض عملية نجحت لدى البوابة ولم يصل إشعارها للخادم، فإن آلية مطابقة تحدّث الطلب خلال (15 دقيقة) دون تدخل يدوي.
• ق-3.4: لا تُخزَّن بيانات البطاقة في التطبيق ولا في الخادم، ويُتحقق من ذلك بمراجعة الكود وقاعدة البيانات.

4. تقرير المبيعات في لوحة التحكم

• ق-4.1: بافتراض فترة مختارة، فإن إجمالي التقرير يساوي مجموع الطلبات المدفوعة في الفترة ناقصًا المستردة، ويُتحقق منه باستعلام مستقل على بيانات اختبار معروفة.
• ق-4.2: بافتراض مستخدم بدور «مندوب»، فإنه يرى أرقام عملائه فقط، ولا يصل إلى أرقام غيره بتغيير رابط أو معامل في الطلب.
• ق-4.3: التصدير بصيغة (Excel) يحمل الأرقام نفسها المعروضة في الشاشة، وأسماء الأعمدة بالعربية.

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

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

حقل «من يحكم» مهم أكثر مما يبدو: المعيار الذي لا يملك أحد في منشأتك صلاحية اعتماده سيبقى معلقًا حتى نهاية المشروع. أما تنفيذ الاختبار نفسه مع فريقك فموضوع مقالة اختبار قبول المستخدم UAT.

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

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

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