لماذا نحتاج إلى اختبار قبول المستخدم (UAT)؟

مؤلف: Judy Howell
تاريخ الخلق: 5 تموز 2021
تاريخ التحديث: 1 تموز 2024
Anonim
How to Set Expectations for UAT and then Measure
فيديو: How to Set Expectations for UAT and then Measure

المحتوى



المصدر: Lightcome / iStockphoto

يبعد:

بمجرد خضوع البرنامج للوحدة والتكامل واختبار النظام ، قد تبدو الحاجة إلى اختبار القبول زائدة عن الحاجة. لماذا لا يزال اختبار قبول المستخدم (UAT) مهمًا؟ هنا ، تعرف جيدا على فوائد UAT ولماذا فريدة من نوعها.

تجريبي ويموت!

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

خطوة إلى أحذية المستخدمين

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


تاريخ UAT موجز

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

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

يخبرك UAT كيف يمكن استخدام النظام

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


من يستطيع أداء UAT؟

أثناء اختبار المطورين للبرنامج ، يتذكرون تفاصيل حول كيفية كتابة النظام. يمكن أن تؤثر هذه المعرفة على الاختبار ، وقد يتخذ المطورون خطوات مختلفة عن المستخدمين النهائيين ، مثل تنفيذ الخطوات بسرعة أكبر أو رفض التفاصيل الدقيقة التي قد يجد المستخدمون النهائيون أنها مربكة. وبالتالي ، المطورين ليسوا أفضل المرشحين UAT. من هو؟

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

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

No Bugs، No Stress - دليلك خطوة بخطوة لإنشاء برامج لتغيير الحياة دون تدمير حياتك


لا يمكنك تحسين مهارات البرمجة لديك عندما لا يهتم أحد بجودة البرنامج.

تزيد مراحل UAT التدريجية مع جماهير متنوعة من الثقة في قابلية استخدام البرنامج. بالاقتران مع مراحل التطوير التكراري ، يمكن إجراء دورات UAT متعددة لاختبار ميزات جديدة عند تسليمها ، مع التحقق من الوظائف السابقة.

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

النجاح والفشل التدفقات

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

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

للتحقق من الأداء الوظيفي ، يجب توفير بعض المعلومات للمختبرين. خلاف ذلك ، فإنهم لا يعرفون ماذا يفترض أن يفعل البرنامج. ولكن لاختبار قابليتها للاستخدام ، يجب أن يكون الحد الأدنى - مجرد مهمة أو متطلبات تستند ، مثل شراء "x" (المنتج) ودفع "ص" (باستخدام تفاصيل بطاقة الائتمان). يجب وضع العبء على المختبرين لتسجيل الملاحظات والنجاحات والإخفاقات.

فوائد UAT

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

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

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