اختبار قابلية الاستخدام

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

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

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

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

تم وصف معيار الـ"خمسة مستخدمين" لاحقاً من خلال نموذج رياضي[9] ينص على نسبة المشاكل الغير المكتشفة وذلك بترميز تلك المشاكل بالحرف U

${\displaystyle U=1-(1-p)^{n}}$ 

حيث p هو احتمالية تحديد موضوع واحد لمشكلة محددة و n هو عدد المواضيع (أو جلسات الاختبار). يظهر هذا النموذج على أنه رسم بياني مقارب تجاه عدد المشاكل القائمة الحقيقية (انظر الشكل أدناه).

في بحث لاحق، تم استجواب مطالبة نيلسن بشغف مع كل من الأدلة التجريبية[10] ونماذج رياضية أكثر تقدماً.[11] التحديان الرئيسيان لهذا التأكيد هما:

1. نظراً لأن قابلية الاستخدام مرتبطة بمجموعة محددة من المستخدمين، فمن غير المرجح أن يمثل حجم العينة الصغير هذا إجمالي السكان، وبالتالي فإن البيانات من هذه العينة الصغيرة من المرجح أن تعكس مجموعة أكثر من السكان الذين قد يمثلونها.
2. ليست كل مشكلة في قابلية الاستخدام سهلة على حد سواء للكشف. تحدث مشاكل مستعصية لإبطاء العملية الكلية. في ظل هذه الظروف، يكون تقدم العملية أكثر ضحالة مما توقعته صيغة نيلسن / لاندوير.[12]

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

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

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

الدليل الخاص بـ Apple Computer 1982 للمطورين ينصح باستخدام اختبار قابلية الاستخدام:[14]

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

نصحت Apple المطورين بأنه "يجب أن تبدأ الاختبار في أقرب وقت ممكن، باستخدام الأصدقاء المقربين والأقارب والموظفين الجدد":[14]

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

يجب على المصممين مشاهدة أشخاص يستخدمون البرنامج بشكل شخصي، حيث أن:[14]

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

كان اختبار قابلية الاستخدام موضوعاً رسمياً للتعليم الأكاديمي في تخصصات مختلفة.[15]

• بوابة علم الحاسوب
• بوابة تقنية المعلومات

اختبار قابلية الاستخدام في المشاريع الشقيقة

---

• صور وملفات صوتية من كومنز