اختبار قابلية الاستخدام
اختبار قابلية الاستخدام (Usability Testing) يراقب مستخدمين ممثّلين للجمهور الحقيقي وهم يحاولون إنجاز مهام واقعية في المنتج، ليرى الفريق أين ينجحون وأين يتردّدون أو يخطئون أو يستسلمون. ويعرّف معيار ISO 9241-11 قابلية الاستخدام بأنها مدى إمكانية استخدام نظام أو منتج أو خدمة من قِبل مستخدمين محدّدين لتحقيق أهداف محدّدة بفاعلية وكفاءة ورضا في سياق استخدام محدّد. ويحوّل اختبار قابلية الاستخدام هذه الكلمات الثلاث إلى أشياء يمكن ملاحظتها وعدّها: هل أُنجزت المهمة؟ وكم استغرقت؟ وكم منعطفاً خاطئاً حدث؟ وكيف قيّم الشخص التجربة؟
مثلاً: يُطلب من خمسة عملاء لم يستخدموا تطبيق بنكهم إلا للتحويلات أن يدفع كل منهم فاتورة كهرباء من ورقة أمامه، بينما يراقب مُيسِّر (Moderator) ويسجّل مدوّن ملاحظات (Note-taker) كل تردّد. فإذا لم يجد اثنان من الخمسة مكان المدفوعات، فقد تعلّم الفريق ما لا يكشفه أي اختبار وظيفي: الميزة تعمل، لكن مستخدميها لا يجدونها.
لماذا يهم
قد ينجح المنتج في كل اختبار وظيفي وكل اختبار لإمكانية الوصول ثم يفقد مستخدميه، لأن ميزة تعمل لكن الناس لا يجدونها ولا يفهمونها ولا يُتمّونها هي إخفاق من وجهة نظرهم. ونادراً ما تظهر هذه الإخفاقات في أداة تتبّع العيوب؛ بل تظهر في سلال شراء متروكة ومكالمات دعم وتقييمات بنجمة واحدة، وعندها يكون التراجع عن قرارات التصميم التي سبّبتها مكلفاً.
وللمختبِر يضيف اختبار قابلية الاستخدام نوعاً ثانياً من الأدلة. فالاختبارات الوظيفية تُظهر أن النظام يتبع قواعده، واختبارات قابلية الاستخدام تُظهر هل يستطيع أناس حقيقيون بلوغ أهدافهم به. كما يصقل نظرتك أنت: فبعد أن تشاهد شخصاً يتعثّر أمام أيقونة بلا تسمية، ستبلّغ عن مثل هذه المشكلات مبكراً وبالدليل (فتح 4 من 5 مشاركين «التحويلات» أولاً) بدلاً من الرأي (القائمة مربكة).
قابلية الاستخدام وتجربة المستخدم وثلاثة أنواع من التقييم
تتعلّق قابلية الاستخدام بمستخدمين محدّدين وأهداف محدّدة وسياق محدّد: فمسار الدفع قد يكون قابلاً للاستخدام لعميل يومي على هاتفه وغير قابل للاستخدام لمستخدم جديد على شاشة صغيرة. ويسمّي معيار ISO 9241-11 ثلاثة مكوّنات، يمنح كل منها اختبار قابلية الاستخدام أحد مقاييسه. فالفاعلية (Effectiveness) هي الدقة والاكتمال في تحقيق المستخدمين لأهدافهم، وتُقاس بنجاح المهمة والأخطاء المرتكبة في الطريق إليه. والكفاءة (Efficiency) هي الموارد المستخدمة قياساً إلى النتائج المحقّقة، وأكثرها الوقت، وتُقاس بالوقت المستغرق في المهمة. والرضا (Satisfaction) هو مدى تلبية استجابات المستخدم الجسدية والذهنية والعاطفية الناتجة عن استخدام المنتج لاحتياجاته وتوقعاته، ويُقاس بالتقييمات والاستبيانات.
أما تجربة المستخدم (User Experience, UX) فأوسع من قابلية الاستخدام. تصفها سلسلة معايير ISO 9241 بأنها إدراكات الشخص واستجاباته الناتجة عن استخدام المنتج أو توقّع استخدامه: التوقعات قبل الشاشة الأولى، والمشاعر أثناء الاستخدام، والثقة والذاكرة بعده. وقابلية الاستخدام جزء ضروري من تجربة مستخدم جيدة لا كلّها. ويغطي معيار ISO/IEC 25010:2023 المجال نفسه تحت قابلية التفاعل (Interaction Capability) بخصائص فرعية مثل قابلية التعلّم وقابلية التشغيل والحماية من أخطاء المستخدم. ويميّز منهج ISTQB لاختبار قابلية الاستخدام ثلاث طرق لتقييم قابلية الاستخدام، والفريق الجيد يستخدم أكثر من طريقة واحدة:
- مراجعات قابلية الاستخدام (Usability Reviews): يفحص مراجعون (واحد أو أكثر)، يُفضَّل أن يكونوا خبراء في قابلية الاستخدام أو في مجال العمل، الواجهةَ ويحدّدون أين تخالف متطلبات قابلية الاستخدام أو إرشاداتها أو مبادئها، بدلاً من مراقبة مستخدمين يحاولون إنجاز المهام. وأشهرها التقييم الاستدلالي (Heuristic Evaluation)، أي المراجعة وفق قائمة قصيرة من المبادئ الاستدلالية.
- اختبار قابلية الاستخدام مع مستخدمين ممثّلين: يحاول المشاركون إنجاز مهام واقعية بينما يراقب الفريق ويقيس. ومعظم هذا الدرس يدور حول هذه الطريقة.
- استبيانات المستخدمين: يجيب المشاركون عن استبيان حول تجربتهم، بعد جلسة اختبار أو بعد استخدام حقيقي.
قابلية الاستخدام (ISO 9241-11) تجربة المستخدم (UX)
---------------------------- ----------------------------------
مستخدمون وأهداف وسياق محدّدون الشخص كله، قبل الاستخدام وأثناءه
وبعده
الفاعلية -> النجاح والأخطاء التوقعات والمشاعر والثقة
الكفاءة -> الوقت وذاكرة المنتج
الرضا -> التقييمات تشمل قابلية الاستخدام وأكثر
هذا الدرس: قياس قابلية الاستخدام في جلسة.
الدرس التالي: اختبار تجربة المستخدم للمسارات والتنقل والرسائل والنماذج.التخطيط: الأهداف والمهام والمشاركون
ابدأ بالأسئلة التي يحتاج الفريق إلى إجابتها، مثل «هل يستطيع عميل جديد دفع فاتورة دون مساعدة؟». ثم اكتب المهام على هيئة سيناريوهات واقعية بكلمات المشارك نفسه، مع البيانات التي يحتاجها وتعريفٍ للنجاح. ولا تستخدم أبداً التسميات الظاهرة على الشاشة: فعبارة «افتح المدفوعات وأضف جهة فوترة» تختبر قدرة الناس على اتباع التعليمات، لا قدرتهم على إيجاد المدفوعات.
استقطب مشاركين يطابقون ملف المستخدم الحقيقي: العمر، والخبرة بمنتجات مشابهة، واللغة، والجهاز. والزملاء الذين يعرفون المنتج ليسوا ممثّلين. وتُجري فرق كثيرة جولة بنحو خمسة مشاركين من كل فئة مستخدمين، ثم تصلح ما وجدته، ثم تُجري جولة أخرى، لأن الجولة الثانية كثيراً ما تكشف مجموعة مختلفة من المشكلات. حدّد الأدوار: مُيسِّر يقدّم المهام ويطرح أسئلة محايدة، ومدوّن ملاحظات يسجّل ما يحدث؛ ويمكن لأصحاب مصلحة آخرين، كالمطورين، أن يشاهدوا الجلسة بصفة مراقبين (Observers). ونفّذ جلسة تجريبية واحدة لإصلاح المهام غير الواضحة والتوقيت، واحفظ الموافقة والخصوصية: يوافق المشاركون على المراقبة أو التسجيل، ولا تدخل أي بيانات تعريفية في التقرير.
المهمة 3 من 4 (سيناريو بكلمات المشارك)
«وصلتك فاتورة الكهرباء لهذا الشهر. ادفعها من هذا التطبيق.
رقم الحساب موجود على الفاتورة الورقية أمامك.»
النجاح: الفاتورة مدفوعة من الحساب الجاري، مع ظهور تأكيد
الهدف: نجاح دون مساعدة لـ 4 من 5 مشاركين على الأقل،
خلال دقيقتين، وبمنعطف خاطئ واحد كحد أقصى
لا تقل: «المدفوعات» أو «جهة فوترة» أو «إضافة»، وهي كلمات الشاشةتنفيذ الجلسة: التفكير بصوت عالٍ والمقاييس الأربعة
ابدأ بتمهيد قصير: نحن نختبر المنتج لا المشارك؛ ولا توجد إجابات صحيحة أو خاطئة؛ ونرجو أن تفكّر بصوت عالٍ. في أسلوب التفكير بصوت عالٍ (Think-Aloud) يقول المشارك أثناء العمل ما الذي يبحث عنه وما يتوقعه وما يحيّره. ويراقب المُيسِّر ولا يتدخّل إلا بأسئلة محايدة مثل «بماذا تفكّر الآن؟» أو «ماذا توقّعت أن يحدث؟»، ولا يشرح ولا يساعد أبداً. وإذا توقّف المشارك تماماً، يدوّن المُيسِّر اللحظة، ثم إما ينتقل إلى المهمة التالية وإما يقدّم أصغر تلميح ممكن؛ والمهمة التي تُنجَز بعد تلميح تُسجَّل «بمساعدة» لا ناجحة.
يسجّل مدوّن الملاحظات أربعة مقاييس لكل مهمة، إضافة إلى الاقتباسات والمنعطفات الخاطئة التي تفسّرها:
- النجاح: أُنجزت دون مساعدة، أو أُنجزت بمساعدة، أو فشلت (استسلم المشارك، أو انتهى الوقت، أو أنهى مهمة مختلفة ظنّاً أنها المطلوبة).
- الوقت المستغرق في المهمة: من قراءة المهمة حتى تحقّق معيار النجاح؛ أبلغ عن الوسيط (القيمة الوسطى بعد ترتيب الأوقات)، لأن مشاركاً واحداً تائهاً يشوّه المتوسط.
- الأخطاء: مسارات خاطئة، وعناصر تحكم خاطئة، ومدخلات غير صحيحة، وهل لاحظ الشخص وتعافى؛ تُعدّ لكل مهمة.
- الرضا: تقييم بعد كل مهمة (مثلاً من 1 إلى 5) واستبيان بعد الجلسة، مثل مقياس قابلية استخدام النظام (System Usability Scale, SUS) وهو عشر عبارات تُنتج درجة من 0 إلى 100.
- 1التخطيطالأسئلة المطلوب إجابتها، والمهام بصيغة سيناريوهات، ومعيار نجاح وأهداف لكل مهمة، وملف المشاركقبل الجلسة
- 2الاستقطاب والجلسة التجريبيةنحو خمسة مشاركين ممثّلين من كل فئة مستخدمين؛ وجلسة تجريبية واحدة تصلح المهام غير الواضحة والتوقيت
- 3تمهيد المشاركالموافقة؛ «نختبر المنتج لا أنت»؛ لا إجابات صحيحة أو خاطئة؛ وكيفية التفكير بصوت عالٍمع المشارك
- 4المهام مع التفكير بصوت عالٍيراقب المُيسِّر ويسأل بحيادية ولا يساعد أبداً؛ ويسجّل مدوّن الملاحظات النجاح والوقت والأخطاء والاقتباسات
فرع: توقّف تام: المهمة التالية، أو تلميح وتُسجَّل المهمة «بمساعدة»تنبيه
- 5تقييم بعد المهمة واستبيانتقييم بعد كل مهمة (مثلاً من 1 إلى 5)؛ واستبيان مثل SUS ومقابلة قصيرة بعد المهمة الأخيرة
- 6التحليلعبر المشاركين: نسبة النجاح، ووسيط الوقت، والأخطاء لكل مهمة، والتقييمات؛ وتصبح كل مشكلة نتيجة بدليل وخطورةبعد الجلسة
- 7التقرير والإصلاحنتائج مع عدد المشاركين المتأثرين والمبدأ الاستدلالي المخالَف والتغيير المقترح؛ مقارنةً بالأهداف
طوال الخطوات 4–5 هنا تُسجَّل المقاييس الأربعة: النجاح، والوقت المستغرق في المهمة، والأخطاء، والرضا
عودة إلى الخطوة 1 الجولة التالية بعد تغيير التصميم
ترتيب معتاد لجلسة مُيسَّرة؛ أما الجلسة البعيدة غير المُيسَّرة فتستغني عن المُيسِّر الحيّ وتعتمد على التسجيلات.
التقييم الاستدلالي: مراجعة خبراء دون مستخدمين
التقييم الاستدلالي (Heuristic Evaluation) مراجعة يمرّ فيها عدد قليل من المقيّمين، كلٌّ على حدة، عبر المسارات الرئيسية ويحكمون على كل شاشة وفق قائمة قصيرة من مبادئ قابلية الاستخدام المعروفة، ثم يدمجون ملاحظاتهم ويقدّرون خطورة كل مشكلة. ولا يحتاج إلى مشاركين، فيناسب النماذج الأولية المبكرة والمخططات الهيكلية والأسبوع الذي يسبق اختبار قابلية الاستخدام.
يتنبّأ التقييم الاستدلالي بالمشكلات، بينما يلاحظها اختبار قابلية الاستخدام. يجد المقيّمون مشكلات كثيرة بسرعة وبتكلفة قليلة، لكنهم يشيرون أيضاً إلى أشياء لا يلاحظها المستخدمون أبداً، ويفوّتون أشياء لا يكشفها إلا المستخدمون، ولا يستطيعون إخبارك بنسب النجاح أو الأوقات. استخدمه أولاً، وأصلح الواضح، ثم اختبر مع المستخدمين. وأشهر قائمة مبادئ هي مبادئ جاكوب نيلسن الاستدلالية العشرة لقابلية الاستخدام:
- وضوح حالة النظام: تخبر الواجهة بما يحدث، مثل حالة «تم الحفظ» أو «جارٍ الإرسال».
- التطابق بين النظام والعالم الحقيقي: كلمات ومفاهيم يعرفها المستخدم، لا مصطلحات داخلية.
- تحكّم المستخدم وحريته: طريقة سهلة للتراجع أو الإلغاء أو العودة.
- الاتساق والمعايير: الكلمات والأنماط نفسها في كل مكان، واتباع أعراف المنصة.
- منع الأخطاء: قيود وتأكيدات توقف الأخطاء قبل وقوعها.
- التعرّف بدلاً من التذكّر: الخيارات والإجراءات ظاهرة لا محفوظة في الذاكرة.
- المرونة وكفاءة الاستخدام: اختصارات للمستخدمين المتمرّسين دون إثقال الجدد.
- تصميم جمالي بسيط: لا شيء ينافس المعلومات التي يحتاجها المستخدم.
- مساعدة المستخدمين على التعرّف على الأخطاء وتشخيصها والتعافي منها: رسائل بلغة واضحة تقول ما الخطأ وكيف يُصلَح.
- المساعدة والتوثيق: متاحان عند الحاجة ومركّزان على مهمة المستخدم.
مثال تطبيقي: دفع فاتورة في تطبيق بنكي
يضيف بنك دفع الفواتير إلى تطبيقه. والمستخدمون المستهدفون عملاء حاليون لا يستخدمون التطبيق إلا للتحويلات. يستقطب الفريق خمسة منهم، ويقدّم المُيسِّر المهمة من البطاقة أعلاه مع فاتورة ورقية بوصفها البيانات. الأهداف: ينجح 4 من 5 على الأقل دون مساعدة خلال دقيقتين وبمنعطف خاطئ واحد كحد أقصى، وتقييم بعد المهمة لا يقل عن 4.
بعد الجلسات الخمس يجمع مدوّن الملاحظات النتائج عبر المشاركين: النجاح لكل مهمة، ووسيط الوقت، والأخطاء لكل مهمة، والتقييمات، مقارنةً بالأهداف المتفق عليها في التخطيط. وتتحوّل كل مشكلة ملحوظة إلى نتيجة مع دليلها: أين حدثت، وكم مشاركاً واجهها، وماذا قالوا.
- النتائج: أنجز 2 من 5 المهمة دون مساعدة، واحتاج اثنان إلى تلميح، وفشل واحد؛ وكان وسيط الوقت 4:10 مقابل هدف 2:00، ووسيط المسارات الخاطئة 3 مقابل 1، ووسيط التقييم 2 مقابل 4. لم يتحقق أي هدف، والملاحظات المدوّنة تقول لماذا: فتح أربعة مشاركين «التحويلات» أولاً لأن «المدفوعات» مخفية تحت «المزيد»، ثم كتب اثنان رقم حساب الفاتورة في حقل مبلغ التحويل لأن حقلَي الحساب والمبلغ في تلك الشاشة لا يحملان سوى أيقونات.
- والمشارك المسجَّل على أنه فشل ضغط «ادفع» مرتين: لم يظهر أي تأكيد فوراً وبقي الزر نشطاً، فدُفعت الفاتورة مرتين، ثم استسلم غير متأكد هل دُفعت أصلاً.
- تذهب النتائج إلى أداة التتبّع مع دليلها والمبدأ الاستدلالي الذي تخالفه: التعرّف بدلاً من التذكّر للقائمة المخفية، والتطابق مع العالم الحقيقي للحقول ذات الأيقونات فقط، ووضوح حالة النظام ومنع الأخطاء للتأكيد المفقود. والدفع المزدوج عيب وظيفي أيضاً، يُبلَّغ عنه منفصلاً بخطورة حرج (Critical). والجدول المجمّع أدناه هو ما يُبنى عليه التقرير.
المهمة: دفع فاتورة الكهرباء لهذا الشهر (5 مشاركين)
المقياس الهدف النتيجة
النجاح دون مساعدة / بمساعدة / فشل 4 من 5 دون مساعدة 2 / 2 / 1
الوقت المستغرق في المهمة (الوسيط) <= 2:00 4:10
المسارات الخاطئة لكل مشارك (الوسيط) <= 1 3
التقييم بعد المهمة من 1 إلى 5 (الوسيط) >= 4 2
ملاحظات: 4 فتحوا «التحويلات» أولاً؛ 2 كتبا رقم الحساب في حقل المبلغ؛
1 ضغط «ادفع» مرتين، ولم يظهر أي تأكيدأخطاء شائعة
- كتابة مهام تسمّي عناصر الواجهة («اضغط المدفوعات ثم أضف جهة فوترة»)؛ فهذا يختبر اتباع التعليمات لا قابلية الاستخدام.
- مساعدة المشارك أو التلميح له حين يتعثّر، ثم احتساب المهمة ناجحة.
- الاختبار مع زملاء يعرفون المنتج بدلاً من مستخدمين ممثّلين.
- اعتبار التقييم الاستدلالي دليلاً على أن المستخدمين سينجحون، أو اعتبار خمس جلسات إحصاءً.
- تدوين الآراء فقط («أعجبهم») دون عدّ النجاح والوقت والأخطاء.
- الخلط بين نتيجة قابلية الاستخدام والعيب الوظيفي: كلاهما يدخل أداة التتبّع، لكن مشكلة قابلية الاستخدام تحتاج إلى الملاحظة (ما الذي جرّبه المستخدم وأين تاه) أكثر من خطوات إعادة إنتاج انهيار.
من منظور ضمان الجودة
يملك اختبار قابلية الاستخدام عادةً مصمّم أو باحث تجربة مستخدم حيث يوجد في الفريق؛ وحيث لا يوجد، كثيراً ما يكون المختبِر هو من يجريه. اقترحه عندما يكون المسار جديداً أو مُعاد تصميمه والمخاطر في الفهم لا في المنطق: التهيئة الأولى، والدفع، والنماذج كثيرة الحقول. اختبر مبكراً على نموذج أولي قابل للنقر، حين تكلّف النتيجة تغييراً في التصميم لا إعادة كتابة، ثم مرة أخرى قبل الإصدار. وينبغي أن يشاهد المطورون ومالك المنتج الجلسات، لأن رؤية مستخدم يتعثّر تغيّر الأولويات أسرع من أي تقرير.
سجّل لكل جلسة البنية والجهاز وملف المشارك (لا اسمه أبداً) والمهام والمقاييس الأربعة، واحتفظ بالتسجيلات وفق ما اتُّفق عليه في الموافقة. واكتب كل نتيجة كما تكتب تقرير خطأ مع الملاحظة دليلاً: العنوان، والمهمة، وما جرّبه المشاركون، وكم تأثّر منهم، والمبدأ الاستدلالي المخالَف، والخطورة، والتغيير المقترح. اطلب من مالك المنتج أهداف النجاح قبل الجلسة، واسأل من هم المستخدمون حقاً: فالمنتج الموجّه إلى الجميع يُختبر عادةً مع لا أحد بعينه.
تمرين عملي
خطّط اختبار قابلية استخدام لميزة حجز موعد في عيادة
يتيح تطبيق عيادة للوالدين حجز موعد تطعيم لطفل. الوصف وإحدى الشاشات أدناه. خطّط اختبار قابلية استخدام: اكتب ثلاث مهام على هيئة سيناريوهات مع معيار نجاح لكل منها، واختر أهدافاً للمقاييس الأربعة، واكتب الجمل الثلاث التي ستقولها في التمهيد، وصمّم ورقة مدوّن الملاحظات. ثم أجرِ فحصاً استدلالياً سريعاً لوصف الشاشة وفق مبادئ نيلسن واذكر المشكلات التي تتوقعها.
الميزة: حجز موعد تطعيم
المستخدمون: والدان من 25 إلى 45 سنة، كثيرون منهم يستخدمون التطبيق
لأول مرة، بالعربية أو الإنجليزية
المسار: اختيار الطفل > اختيار التطعيم > اختيار العيادة
> اختيار التاريخ والوقت > التأكيد
شاشة «اختيار التاريخ والوقت»:
- التقويم يعرض كل الأيام باللون نفسه؛ والضغط على يوم مكتمل لا يفعل شيئاً
- المواعيد معروضة 09:00، 09:20، 09:40 ... دون إشارة إلى المحجوز منها
- زر «التالي» معطّل حتى يُختار موعد؛ ولا رسالة تقول لماذا
- سهم الرجوع يعود إلى الشاشة الرئيسية لا إلى «اختيار العيادة»- اكتب ثلاث مهام بكلمات المشارك، لكل منها معيار نجاح.
- حدّد هدفاً للنجاح والوقت والأخطاء والرضا لكل مهمة.
- اكتب التمهيد وسؤال التفكير بصوت عالٍ الذي ستستخدمه.
- اذكر أعمدة ورقة المراقبة.
- افحص وصف الشاشة وفق المبادئ الاستدلالية وسمّ المبادئ المخالَفة.
إظهار الإجابة النموذجية
المهام (بصيغة سيناريو). الأولى: «ابنتك سارة، عمرها سنتان، حان موعد تطعيمها التالي. احجزه في أقرب عيادة إلى منزلك للأسبوع القادم.» النجاح: وجود موعد للطفل والتطعيم والعيادة الصحيحة. الثانية: «طرأ أمر ما: انقل الموعد الذي حجزته للتو إلى الأسبوع الذي يليه.» النجاح: موعد واحد في التاريخ الجديد ولا شيء في القديم (وإذا فشلت المهمة الأولى، يُنشئ المُيسِّر الحجز مسبقاً لتبقى هذه المهمة قابلة للتجربة). الثالثة: «اعثر على التأكيد لتعرضه في الاستقبال.» النجاح: ظهور التأكيد بالتاريخ والوقت والعيادة على الشاشة.
الأهداف: ينجح 4 من 5 مشاركين على الأقل دون مساعدة في كل مهمة؛ ووسيط الوقت 3 دقائق كحد أقصى للحجز ودقيقة واحدة للمهمتين الأخريين؛ ومنعطف خاطئ واحد كحد أقصى لكل مهمة؛ وتقييم بعد المهمة لا يقل عن 4 من 5. ويؤكد مالك المنتج الأرقام أو يعدّلها.
التمهيد: «نحن نختبر التطبيق لا أنت؛ وكل ما يصعب عليك مشكلة علينا نحن إصلاحها. من فضلك قل بصوت عالٍ ما تبحث عنه وما تتوقع أن يحدث. لن أستطيع المساعدة، لكن يمكنك التوقف في أي وقت.» السؤال عند الصمت: «بماذا تفكّر الآن؟»
أعمدة ورقة المراقبة: رمز المشارك، والمهمة، ووقت البدء والانتهاء، والنتيجة (دون مساعدة / بمساعدة / فشل)، والمسارات الخاطئة (العدد والمكان)، وأخطاء الإدخال، والاقتباسات، والتقييم بعد المهمة، وملاحظات المُيسِّر.
الفحص الاستدلالي: الأيام المكتملة تبدو كالأيام المتاحة والضغط عليها لا يفعل شيئاً (وضوح حالة النظام، ومنع الأخطاء)؛ والمواعيد المحجوزة غير مميّزة (التعرّف بدلاً من التذكّر، ومنع الأخطاء)؛ وزر «التالي» معطّل دون سبب (وضوح حالة النظام، ومساعدة المستخدمين على التعرّف على الأخطاء والتعافي منها)؛ وسهم رجوع يخرج من المسار (تحكّم المستخدم وحريته، والاتساق والمعايير). توقّع مسارات خاطئة وحجوزات ضائعة في هذه الشاشة؛ وستُظهر الجلسات كم مشاركاً تأثّر بها.
أسئلة شائعة
كم مشاركاً يحتاج اختبار قابلية الاستخدام؟
ما يكفي لرؤية الأنماط، لا لإثبات إحصاءات. تُجري فرق كثيرة جولة بنحو خمسة مشاركين من كل فئة مستخدمين، وتصلح ما وجدته، ثم تختبر مجدداً؛ والمشكلة التي توقف اثنين من خمسة تستحق الإصلاح أياً كانت النسبة الدقيقة. أما الأرقام الصالحة إحصائياً فتحتاج إلى دراسات أكبر، وغالباً غير مُيسَّرة.
هل اختبار قابلية الاستخدام هو نفسه اختبار قبول المستخدم؟
لا. اختبار قبول المستخدم (UAT) نوع من اختبار القبول: يتحقق من صلاحية النظام المسلَّم للاستخدام من قِبل مستخدميه المقصودين في بيئة تشغيل حقيقية أو محاكاة، ويدعم قرار قبوله. ويجريه عادةً مستخدمون من جهة الأعمال يعرفون المجال، وغالباً بسيناريوهات مكتوبة. أما اختبار قابلية الاستخدام فيقيس هل يستطيع مستخدمون ممثّلون تحقيق أهدافهم دون مساعدة وكيف يعيشون التجربة، وقد يُجرى على نموذج أولي قبل قبول أي شيء بوقت طويل.
هل يمكن أتمتة اختبار قابلية الاستخدام؟
يمكن للأدوات مساعدة القياس: فهي تسجّل الشاشات والنقرات والأوقات، وتُظهر تحليلات المنتج أين يتسرّب المستخدمون. لكن الحكم على ما إذا بلغ الشخص هدفه، ولماذا تردّد، وماذا توقّع، ما زال يحتاج إلى إنسان يراقب أو يراجع التسجيل. والتقييم الاستدلالي أيضاً مراجعة بشرية، وإن كانت قائمة التحقق تحفظ اتساقه.
المراجع
- ISO 9241-11:2018 — Ergonomics of human-system interaction — Part 11: Usability: Definitions and conceptsالإطار الدولي لمفهوم قابلية الاستخدام: الفاعلية والكفاءة والرضا لمستخدمين وأهداف وسياق استخدام محدَّدين، مع اعتبار قابلية الاستخدام نتيجةً للاستخدام.
- Certified Tester Usability Testing (CT-UT)منهج ISTQB التخصصي لاختبار قابلية الاستخدام: قابلية الاستخدام وتجربة المستخدم وإمكانية الوصول، وأساليب التقييم ومناهجه، والمعايير ذات الصلة.
- 10 Usability Heuristics for User Interface Design (Jakob Nielsen)قواعد Jakob Nielsen العامة العشر لتصميم الواجهات — مثل وضوح حالة النظام ومنع الأخطاء — التي وُضعت أصلاً للتقييم الاستدلالي.
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelنموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.
تدرّب بأدوات متقن
ولّد سيناريوهات اختبار عالية المستوى تغطي الجوانب الوظيفية والسلبية والأمنية وسهولة الاستخدام والتوافق لأي ميزة.
حساب النسب المئوية ونسبة التغيّر والزيادة/النقصان وكم تمثّل X من Y بالنسبة المئوية.
ولّد قائمة تحقق QA مخصّصة (وظيفية وواجهة مستخدم وAPI وأمان وأداء وإمكانية وصول وإصدار) لأي ميزة باستخدام الذكاء الاصطناعي من متقن.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.