كتب user acceptance tests

اختبار قبول المستخدم (بالإنجليزية: User Acceptance Testing)‏ هو عملية الحصول على تأكيدٍ بأن نظامٍ ما يلبي المتطلبات المتفق عليها بالتبادل فيما بين الأطراف. فخبير المادة الموضوعية، والذي غالباً ما يكون المالك أو زبون العنصر موضع الاختبار، يقوم بتوفير مثل ذلك التأكيد بعد المحاولة أو المراجعة. وفي عملية تطوير البرمجيات، يمثل اختبار قبول المستخدم أحد المراحل النهائية للمشروع وغالباً ما يقع قبيل قبول العميل أو الزبون للنظام الجديد.

وهنا يقوم مستخدموا النظام بأداء تلك الاختبارات، والتي يقوم المكورون باشتقاقها من بنود تعاقد العميل أو توصيف متطلبات المستخدم (بالإنجليزية: Requirements analysis)‏.

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

و من الطبيعي ألا تُرَكِّز اختبارات السمتخدم، والتي يقوم غالباً المستخدم النهائي أو العملاء بأدائها، على التعرف على المشكلات البسيطة مثل أخطاء الهجاء أو المشكلات التجميلية، أو حتى عيوب شوستوبر (showstopper defect)، مثل عمليات انهيار البرمجيات [software crashes)؛ وذلك لأن المختبرين والمطورين يقومون بتحديد مثل تلك المشكلات مسبقاً، إصلاحها وعلاجها، وذلك خلال مراحل الفحص الأولي للوحدة (unit testing)، فحص التكامل (integration testing)، فحص النظام نفسه.

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

اختبار قبول المستخدم كمياً

يمثل اختبار قبول المستخدم كمياً (أو بصورةٍ أبسط "المدخل الكمي") عمليةً معكوسةً لاختبار قبول العمل (Business Acceptance Testing) والتي تستهدف توفير بديلٍ أفضل وأسرع لمرحلة اختبار قبول المستخدم التقليدية. ويتم تنفيذ عملية اختبار العمق (Depth-testing) في مقابل متطلبات العمل فقط عند نقاطٍ خاصةٍ مخططةٍ في التطبيق أو الخدمة محل الفحص والاختبار. فمن المفترض أن يكون هناك اعتمادٌ على كود توصيلٍ أفضلٍ للجودة من مرحلة التطوير/ البناء بالإضافة إلى أن الفهم الكامل لعملية العمل المناسبة لهو متطلبٌ رئيسيٌ. ونلاحظ أن تلك المنهجية - لو تم تنفيذها بأسلوبٍ صحيحٍ - تسفر عن تحولٍ سريعٍ ضد الخطة، والخاصة بعددٍ منخفضٍ ومقلصٍ من سيناريوهات الاختبارات والتي تعتبر أكثر تعقيداً وأوسع مجالاً في العرض من عملية اختبار قبول المستخدم التقليدية، كما أنها تمثل المرادف لمستوى الثقة الذي تم تحقيقه عبر نافذة التوصيل الأقصر، مما يسمح بوصول المنتجات أو التغيرات إلى السوق بصورةٍ أسرعٍ.

وهنا يعتمد مدخل اختبار قبول المستخدم الكمي على نموذجٍ "بوابيٍ" ثلاثي الأبعاد. وتتمثل الأفكار الرئيسية لذلك النموذج في:

1. الاختبار الخطي (البعد الواحد)
2. الاختبار الرجعي (ثنائي الأبعاد)
3. الاختبار التكيفي (ثلاثي الأبعاد).

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

• فحوصات التوافق الداخلي (ICS)
• فحوصات الخدمات/ الأنظمة الرئيسية (MSC)
• الانحدار التفاعلي / الوقت الحقيقي (RTR).

و قد تم تحدسد ملامح المدخل الكمي من قِبَلِ طريقة "غوريلا" لاختبارات القبول والتي كانت نفسها استجابةً لمراحل الاختبار والتي أثبتت أنها باهظة التكاليف لتكون ثابتة للعديد من المشاريع الصغيرة أو المتوسطة.