اطلب مراجعة خبراء عندما تحتاج كشف عوائق التجربة، واختبار مستخدمين عندما تحتاج مشاهدة أداء أشخاص مناسبين، واختباراً وظيفياً ضمن ضمان الجودة عندما تريد التحقق من السلوك مقابل المطلوب. قد تحتاج أكثر من نوع، لكن شراء خدمة تحت اسم «فحص التطبيق» دون تحديد السؤال يجعل المخرجات صعبة التقييم.
المنتج قد ينفذ القاعدة كما صُممت، لكن المستخدم لا يفهمها. وقد تكون الواجهة واضحة بينما يفشل حفظ البيانات. وقد يرى الخبير مشكلة محتملة تحتاج مشاهدة المستخدمين لتحديد سياقها. هذه حالات مختلفة تتطلب أدلة مختلفة، لا تقريراً عاماً يمنح التطبيق درجة واحدة.
قارن السؤال والدليل قبل اسم الخدمة
| النوع | السؤال الأساسي | مصدر الدليل | المخرج المتوقع |
|---|---|---|---|
| مراجعة تجربة وواجهة | أين توجد عوائق أو تناقضات ظاهرة في الرحلة؟ | فحص خبير للنطاق المتفق عليه | مشكلة موثقة وأثر محتمل وأولوية معالجة |
| اختبار قابلية الاستخدام | كيف يفهم المستخدم المهمة ويؤديها فعلياً؟ | مشاهدة مشاركين مناسبين ضمن سياق اختبار | سلوك وتعثر ومساعدة ونتائج مرتبطة بالمهمة |
| اختبار وظيفي | هل ينفذ النظام السلوك المتوقع في الحالات المحددة؟ | تنفيذ حالات تحقق ومقارنة النتائج | نجاح أو إخفاق مع خطوات وأدلة إعادة الرصد |
يصف GOV.UK اختبار قابلية الاستخدام بإشراف بأنه مشاهدة المشاركين أثناء محاولة مهام محددة. مرجع الاختبار. لذلك لا تُسمِّ رأي مصمم يراجع الشاشات «اختبار مستخدمين»، حتى لو كانت ملاحظاته مفيدة جداً.
مثال افتراضي: إتمام طلب يحتاج موافقة
لنفترض منصة افتراضية لطلب تجهيزات مكتبية، يشترط فيها اعتماد مسؤول قبل تأكيد الطلب. يصل المستخدم إلى صفحة تقول «تم الإرسال»، ثم يتصل ليسأل إن كان الطلب مؤكداً. أمام الفريق ثلاثة أنواع من الفحص، وقد ينتج كل منها ملاحظة مختلفة عن الرحلة نفسها.
في مراجعة تجربة وواجهة المستخدم، يلاحظ الخبير أن العنوان والزر يستخدمان كلمتي «تأكيد» و«إرسال» دون شرح الفرق، وأن الحالة في صفحة الطلب لا تظهر الخطوة التالية. يسجّل احتمال التباس مع مواضع المشكلة واقتراح توضيح. هذا لا يثبت عدد المستخدمين المتأثرين أو سلوكهم الفعلي.
في دراسة بحث المستخدمين، يحاول مشاركون مناسبون إتمام المهمة ويشرحون ما يعتقدون أنه حدث. قد يعرف بعضهم أن هناك موافقة، وقد يظن آخرون أن التجهيز بدأ. يوضح التقرير السياق والتفسير والمساعدة إن حدثت، ولا يعمم الملاحظة على السوق أو كل العملاء.
أما اختبار وضمان جودة البرمجيات، فيتحقق من أن الإرسال ينشئ الحالة الصحيحة، وأن صلاحية الاعتماد محصورة بالدور المطلوب، وأن إعادة الإرسال لا تنشئ طلباً إضافياً وفق القاعدة المعتمدة. إذا اجتازت هذه الحالات، فهذا يثبت ما فُحص ضمن النسخة والبيئة، ولا يثبت أن النص مفهوم أو أن جميع العيوب غائبة.
قد ينجح الاختبار الوظيفي تماماً وتظل المشكلة قائمة في معنى الحالة. وقد يختار الفريق معالجة المحتوى أولاً ثم مشاهدة فهمه لدى مستخدمين جدد. هنا يدعم تصميم تجربة المستخدم تغيير التدفق أو شرح الحالة، بدلاً من افتراض أن المطلوب إعادة بناء النظام.
متى تبدأ بكل نوع؟
إذا كان لديك خطأ يمكن وصفه بدقة، مثل عدم حفظ اختيار أو اختلاف حالة بين شاشتين، فابدأ بالتحقق الوظيفي والبيئة اللازمة لإعادة رصده. لا تستخدم جلسات مستخدمين لتحديد سبب خلل تقني معروف يمكن فحصه مباشرة.
إذا كانت الواجهة غير متسقة أو الرحلة متضخمة وتحتاج ترتيباً أولياً للمشكلات، فقد تكون مراجعة الخبير بداية مناسبة. اطلب تمييز ما هو ملاحظة مباشرة عما هو فرضية عن أثرها. وإذا كان القرار يتوقف على فهم المستخدم أو سلوكه، فصمّم اختباراً بالمشاركين المناسبين بدلاً من محاولة حسمه بالآراء الداخلية.
لا يوجد ترتيب واحد يصلح دائماً. أحياناً يجب إصلاح عطل يمنع المهام قبل البحث، وأحياناً يكون سؤال استخدام قائم هو ما يحدد الرحلة التي تستحق فحصاً أعمق. المهم أن يشرح المورد لماذا اختار التسلسل وكيف سيستخدم نتيجة كل مرحلة.
لا تخلط إمكانية الوصول بهذه التسميات
قد تكشف المراجعات عوائق وصول، لكن تقرير تجربة عام ليس تلقائياً تقييماً شاملاً وفق معيار محدد. توضح W3C أن أداة فحص وحدها لا تحسم استيفاء معايير الوصول. مرجع تقييم الوصول. اسأل عن المعيار والنطاق والأساليب والمهارات وما لم يُختبر، ولا تعامل أي تقرير بوصفه شهادة أو ضماناً قانونياً.
كذلك لا يفترض أن اختبار مستخدم واحد يغطي كل القدرات والأجهزة. يجب أن تتناسب حدود الاستنتاج مع المشاركين والبيئة والمهام. إذا احتجت تخصصاً إضافياً، فليكن نطاقاً صريحاً مع مسؤول مؤهل، لا وعداً مخفياً داخل عبارة «فحص شامل».
كيف تقارن عرضين للمراجعة؟
أرسل الرحلات نفسها والنسخة نفسها لكل جهة، واطلب الإجابة عن السؤال نفسه. قارن الوصول المطلوب، ومصدر الدليل، وحجم التغطية، وتصنيف الشدة، ومخرجات التسليم، وما إذا كانت إعادة التحقق بعد الإصلاح داخلة في النطاق. لا تقارن سعري مراجعة خبير واختبار مستخدمين باعتبارهما منتجاً واحداً لمجرد تساوي عدد الصفحات.
معايير قبول مشتركة مع اختلاف الأدلة
- كل نتيجة مرتبطة برحلة أو مهمة أو معيار سلوك محدد.
- يعرف القارئ من أنتج الدليل: خبير، مشارك، أو حالة اختبار.
- النسخة والبيئة والحسابات والحدود موثّقة.
- الملاحظات لا تُعرض كدليل انتشار أو سبب مؤكد دون سند.
- لكل مشكلة أولوية مبررة وخطوة معالجة أو تحقيق.
- إعادة الاختبار ومسؤولية اعتماد الإصلاح واضحتان.
أسئلة شائعة
هل يمكن لجهة واحدة تنفيذ الأنواع الثلاثة؟
يمكن ضمن نطاق متفق عليه إذا تأكد توفر الأدوار والمهارات المناسبة. اطلب أدلة منفصلة لكل نوع، ولا تفترض أن تخصصاً واحداً يغطيها جميعاً.
هل اجتياز ضمان الجودة يعني تجربة سهلة؟
لا. قد يعمل المنتج حسب المواصفات بينما يصعب فهمه. جودة المواصفات وقابلية الاستخدام تحتاجان أدلة إضافية عندما يكونان محل سؤال.
هل نحتاج مستخدمين لمراجعة الخبير؟
لا يلزم ذلك لتعريفها، لكن غياب المشاركين يحد ما يمكن قوله عن السلوك الفعلي. يجب أن يكون هذا الفرق واضحاً في العرض والتقرير.
هل يلزم تنفيذ كل التوصيات؟
لا تلقائياً. قيّم الأثر والدليل والقيود، ثم اعتمد المعالجة المناسبة وتحقق منها. التوصية ليست أمراً ببناء ميزة مهما كانت كلفتها أو صلتها بالهدف.
ابدأ بوصف المشكلة والأدلة الموجودة والقرار الذي يتوقف عليها. اختيار نوع المراجعة يصبح أوضح عندما يتحدد المجهول.
