اختبار قبول النظام: حوّل الاتفاق لسيناريوهات واضحة

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

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

ابدأ من احتياج له نتيجة

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

دليل GOV.UK لقصص المستخدم يربط المستخدم واحتياجه وهدفه، ويشرح معايير القبول كقائمة نتائج تؤكد تغطية الحاجة. استخدم الفكرة لتوضيح الاتفاق، مش لكتابة عبارات شكلية لا يمكن اختبارها.

جهز بطاقة اختبار لكل سيناريو

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

الجدول مثال تعليمي لا مواصفات نظام موجود. طريقة التعامل مع كل حالة تعتمد على القواعد التي اعتمدها صاحب العملية قبل البناء.

اختبر الرحلة مش كل شاشة وحدها

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

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

سجّل العيب بحيث يتكرر

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

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

أعد الاختبار بعد الإصلاح

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

في الإغلاق، اكتب ما نجح وما بقي وما تم قبوله بحدوده ومن وافق عليه. لو عيب له متابعة، حدد المسؤول والأثر وخطة التعامل المؤقتة. لا تكتب «مقبول بالكامل» بينما وظيفة أساسية لم تُختبر.

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