قالب اختبار قبول المستخدم (UAT): الخطة وحالات الاختبار والاستلام

يحدد المشروع والنسخة الخاضعة للاختبار وإصدار المستند.

يحدد ما تغطيه هذه الجولة، والأهم: ما لا تغطيه.

يفشل الاختبار عندما تكون الإجابة «حد هيجرب». حدد بالاسم المختبرين وشخصا واحدا مخولا بالتوقيع.

لا تبدأ UAT على نسخة غير جاهزة، ستهدر أثمن ما لدى المختبرين: تركيزهم.

• اكتمال اختبارات الجودة الداخلية عند المنفذ، وعدم وجود عيوب حرجة معلومة.
• بيئة staging تعمل وبها حسابات اختبار لكل دور.
• بيانات اختبار محملة (منتجات، مستخدمون، طلبات تجريبية).
• كل المميزات المتفق عليها موجودة في النسخة (لا «قادمة في التحديث التالي» لعناصر ضمن النطاق).

يجب أن يعرف المختبرون أين يختبرون وبأي بيانات دخول، في مكان واحد.

لا تختبر أبدا ببيانات عملاء حقيقية أو بطاقات دفع فعلية.

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

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

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

حرج يعطل المسارات الأساسية بلا بديل   كبير ميزة معطلة مع وجود بديل   صغير خطأ لكن النظام مستخدم   شكلي لمسات بصرية

تعريف «جاهز للإطلاق» قبل بدء الاختبار. يمنع الاختبار اللانهائي والاستلام المتسرع معا.

• تنفيذ 100% من حالات الاختبار.
• صفر عيوب حرجة أو كبيرة مفتوحة.
• العيوب الصغيرة والشكلية في قائمة استكمالات بتاريخ إصلاح متفق عليه.
• نجاح فحص الانحدار (Regression) على المسارات التي مستها الإصلاحات.

القبول المكتوب. بعده تتابع بنود قائمة الاستكمالات ضمن الصيانة، لا كنطاق مفتوح.

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