اختبار تجربة المستخدم
اختبار تجربة المستخدم (UX Testing) هو فحص المختبِر بنفسه لتجربة استخدام المنتج: تسلك كل مسار مستخدم (User Flow) كما يسلكه عميل حقيقي، وتحكم عند كل خطوة هل يتيح التنقل والنماذج والرسائل لهذا الشخص أن يبلغ هدفه دون حيرة. والمرجع ليس ذوقك، بل توقعات معلنة مثل التصميم المعتمد ومعيار WCAG 2.2.
مثال: «اطلب وجبة» في تطبيق لتوصيل الطعام مسار من ست شاشات. تفحص جولة تجربة المستخدم (UX Pass) أن كل شاشة تقول أين أنت، وأن زر «متابعة» يقود إلى ما تعِد به تسميته، وأن رفض البطاقة يُنتج رسالة تقول ما العمل بعد ذلك، لا «حدث خطأ ما».
لماذا يهم
قد ينجح المنتج في كل اختبار وظيفي ويخسر مستخدميه مع ذلك: المسار يكتمل والرسالة صحيحة تقنياً، لكن الناس يتركون السلة لأن الخطوة التالية غير واضحة. ولأن شيئاً لم ينهر، نادراً ما يُبلَّغ عن هذه الإخفاقات.
ويحوّل اختبار تجربة المستخدم عبارة غامضة مثل «الإحساس غير مريح» إلى نتائج يستطيع الفريق التصرف بناءً عليها، كلٌّ منها مربوط بخطوة وبتوقع خولف. ويضع معيار ISO/IEC 25010:2023 هذه الصفات تحت قابلية التفاعل (Interaction Capability) بخصائص فرعية مثل قابلية التشغيل والحماية من أخطاء المستخدم والوصف الذاتي، فنتيجة تجربة المستخدم المدعومة بتوقع معلن عيب في الجودة كأي عيب آخر.
ما الذي يفحصه اختبار تجربة المستخدم
في اختبار قابلية الاستخدام، كما رأيت في الدرس السابق، يُراقَب مشاركون حقيقيون. أما اختبار تجربة المستخدم كما تمارسه فرق ضمان الجودة فهو الفحص الذي تجريه أنت بنفسك، في كل سبرنت، من دون مشاركين. وهو ليس مصطلحاً في ISTQB؛ وأقرب تقنية إليه في ISTQB هي الاختبار المبني على قوائم التحقق، إحدى التقنيات المبنية على الخبرة. وجولة تجربة المستخدم هي ذلك بالضبط: قائمة تحقق ثابتة تُطبَّق أثناء سلوك مسار، وهي صورة أضيق من التقييم الاستدلالي وقابلة للتكرار.
ولمرجع الاختبار (Test Oracle)، أي المصدر الذي تأخذ منه النتيجة المتوقعة، أربعة أجزاء: التصميم المعتمد، وأعراف المنتج نفسه (الزر الواحد يتصرف بالطريقة نفسها في كل مكان)، واستدلالات قابلية الاستخدام (Heuristics) المعروفة مثل الاستدلالات العشرة لمجموعة Nielsen Norman، ومعيار WCAG 2.2 الذي تبلغ معاييره عن النماذج والتنقل والأخطاء من الدقة ما يكفي للاستشهاد بها. والنتيجة المدعومة بأحدها عيب؛ أما المدعومة بالتفضيل وحده فاقتراح.
- مسارات المستخدم: الشاشات من الهدف إلى تأكيده، مع طرق الخروج والعودة.
- التنقل: أين المستخدم، وإلى أين يستطيع الذهاب، وكيف يعود.
- النماذج: التسميات والتلميحات والقيم الافتراضية وتوقيت التحقق والبيانات بعد الخطأ.
- الرسائل: الأخطاء والتأكيدات والحالات الفارغة التي تقول ما حدث وما العمل بعده.
النماذج ورسائل الخطأ
تكثر عيوب تجربة المستخدم في النماذج، لأن المنتج يطلب فيها من المستخدم أن يبذل جهداً. افحص كل نموذج في ثلاث جولات. فارغاً: تسميات مرئية، وحقول إلزامية معلَّمة بالكلمات، وتلميحات صيغة مثل DD/MM/YYYY قبل الكتابة، وقيم افتراضية معقولة، ولوحة مفاتيح على الجوال تناسب الحقل، وكلها تمنع الأخطاء (الاستدلال الخامس: منع الأخطاء). ببيانات صالحة واقعية: اسم عربي كامل، ورقم هاتف بمسافات، وقيم ملصوقة. ببيانات غير صالحة، كما في درس الاختبار الإيجابي والسلبي.
في جولة البيانات غير الصالحة راقب التوقيت وما بعد الخطأ. فالتحقق الذي ينطلق والمستخدم ما زال يكتب نتيجة تُسجَّل؛ والتوقع المعتاد أن ينتظر حتى يغادر المستخدم الحقل أو يرسل النموذج، ثم ينقل التركيز إلى أول خطأ. ويجب أن تبقى القيم المكتوبة بعد الخطأ، ومكان الرسالة بجانب حقلها. ويشترط WCAG في المعيار 3.3.1 تحديد الحقل الذي فيه الخطأ ووصف الخطأ نصاً، وفي 3.3.3 اقتراح التصحيح إذا كان معروفاً، وفي 3.3.7 الإدخال المتكرر أن تُملأ تلقائياً أو تُتاح للاختيار المعلوماتُ التي سبق إدخالها في العملية نفسها، مع استثناءات منها إعادة الإدخال لأسباب أمنية. فخطوة الدفع التي تُلزم المستخدم بكتابة عنوان التوصيل من جديد عيب تستطيع الاستشهاد بالمعيار عليه.
ويطلب الاستدلال التاسع رسائلَ بلغة بسيطة بلا رموز، تحدد المشكلة بدقة وتقترح حلاً. وفي الحقل يصبح ذلك أربعة أجزاء قابلة للفحص، بكلمات بسيطة بلا لوم: أن تسمّي الرسالة الحقل، وتقول ما الخطأ تحديداً، وتقول كيف يُصحَّح، وتعطي مثالاً مقبولاً حين يتعلق الأمر بصيغة. فالرسالة Error 4011: Invalid input لا تحوي أياً منها، أما «رقم الجوال: هذا الرقم فيه 8 أرقام. أدخل 9 أرقام تبدأ بـ5، مثل 512345678» فتحويها كلها. وتخضع التأكيدات والحالات الفارغة للفحص نفسه.
Error 4011: Invalid input فتضع رمزاً وعبارة غامضة في الموضعين الأولين ولا تحوي تصحيحاً ولا مثالاً.رسالة جيدة
الجزء 1:Mobile number:
الرسالة الضعيفة كما شُحنت
الجزء 1:Error 4011:
- 1–4كلمات بسيطة من أوله إلى آخره: لا رمز ولا لوم
- 1تسمّي الحقل أو الموضعأين المشكلة، بالكلمات نفسها التي تستعملها التسمية. أما الرسالة الضعيفة فتضع هنا رمز خطأ لا يقول للمستخدم شيئاً.WCAG 3.3.1
- 2تقول ما الخطأ تحديداًقيمة المستخدم مقيسةً بالقاعدة: 8 أرقام حيث المطلوب 9. أما
Invalid inputفلا تسمّي قاعدة ولا قيمة.WCAG 3.3.1 - 3تقول كيف يُصحَّحالقاعدة بصيغة تعليمات يستطيع المستخدم تنفيذها، وهو ما يطلبه المعيار 3.3.3 في WCAG حين يكون التصحيح معروفاً.غائب في الرسالة الضعيفة
- 4تعطي مثالاًقيمة كانت ستُقبل، ليقلّد المستخدم شكلها بدلاً من التخمين.غائب في الرسالة الضعيفة
افحص أيضاً ما حول الرسالة: أنها بجانب الحقل، وأن القيمة المكتوبة ما زالت فيه، وأن التركيز انتقل إلى الحقل، وأن الصياغة نفسها في كل النماذج.
النسخة النصية
الحقل: رقم الجوال. القاعدة: 9 أرقام تبدأ بـ 5.
ضعيفة: Error 4011: Invalid input.
جيدة: رقم الجوال: هذا الرقم فيه 8 أرقام.
أدخل 9 أرقام تبدأ بـ 5، مثل 512345678.
افحص أيضاً: الرسالة بجانب الحقل نعم / لا
القيمة المكتوبة ما زالت في الحقل نعم / لا
انتقل التركيز إلى الحقل نعم / لا
الصياغة نفسها في كل النماذج نعم / لاجرّبها: مولّد اختبارات التحقق جرّبها: مولّد حمولات خطأ وهمية جرّبها: مولّد أسماء وهمية
قائمة تحقق تجربة المستخدم مطبَّقة على إتمام الشراء
حوّل هذه الأسئلة إلى قائمة تحقق بمعرّفات، وشرط واحد جوابه نعم أو لا لكل بند، كما في درس الاختبار المبني على قوائم التحقق. شغّلها لكل مسار لا لكل صفحة. وهذه هي على مسار طلب الوجبة، مع ما وجدته:
- FLW-04: طلبان من نقر مزدوج على «تأكيد». حرج (Critical)، عيب وظيفي كشفه فحص تجربة المستخدم.
- FLW-02 وFRM-04: السلة تفرغ عند الرجوع من الدفع، ونموذج العنوان يُفرَّغ بعد الخطأ. رئيسي (Major)، فالمستخدم يفقد عمله مرتين.
- MSG-01: «حدث خطأ ما» عند رفض البطاقة. رئيسي، فالمستخدم لا يعرف هل يعيد المحاولة أم يغيّر البطاقة أم يتصل بالبنك؛ وأُرفق النص المقترح.
- NAV-01 وNAV-02 وFRM-02: لا مؤشر خطوات، و«موافق» بدلاً من «متابعة إلى وقت التوصيل»، ولوحة مفاتيح نصية لرقم البطاقة. ثانوي (Minor) لكل منها، وجُمعت في تقرير واحد.
قائمة تحقق تجربة المستخدم، لكل مسار النتيجة
FLW-01 يكتمل المسار السعيد من دون طريق مسدود ناجح
FLW-02 الرجوع من كل خطوة يعيدك ببيانات سالمة فشل: الدفع ← السلة تفرغ
FLW-03 تحديث الصفحة في أي خطوة يحفظ البيانات المدخلة ناجح
FLW-04 الإرسال المزدوج لا ينشئ طلبين فشل: الطلبان 1042 و1043
NAV-01 كل شاشة تُظهر أين المستخدم فشل: لا مؤشر خطوات
NAV-02 كل زر يسمّي فعله أو وجهته فشل: «موافق» في العنوان
NAV-03 القوائم وعناصر التحكم في الموضع نفسه في كل مكان ناجح
FRM-01 التسميات مرئية والحقول الإلزامية معلَّمة بالكلمات ناجح
FRM-02 التلميحات قبل الكتابة ولوحة مفاتيح الجوال تناسب الحقل فشل: لوحة نصية للبطاقة
FRM-03 لا يظهر خطأ والمستخدم ما زال يكتب ناجح
FRM-04 بعد الخطأ تبقى القيم المكتوبة فشل: نموذج العنوان فُرِّغ
MSG-01 الخطأ يسمّي الحقل والمشكلة والتصحيح فشل: «حدث خطأ ما»
MSG-02 التأكيد يقول ما حدث وما التالي ناجح
MSG-03 الحالات الفارغة تقول ما العمل لا ينطبقأخطاء شائعة
- الإبلاغ عن الذوق («ينبغي أن يكون الزر أزرق») على أنه عيب. كل نتيجة تسمّي التوقع الذي خالفته.
- سلوك المسار السعيد وحده، مع أن عيوباً كثيرة في تجربة المستخدم لا تظهر إلا عند الرجوع أو التحديث أو انتهاء الجلسة أو الدخول من جديد.
- اختبار النماذج ببيانات مريحة: أسماء لاتينية قصيرة، والدولة الافتراضية. استعمل بيانات واقعية بلغات المنتج.
- قبول «حدث خطأ ما» لأن الخادم أخفق فعلاً. إذا كان المستخدم لا يعرف ما العمل بعدها فالرسالة عيب.
- فحص الحقول واحداً واحداً من دون إرسال النموذج كله، فلا ترى أبداً ما يحدث للبيانات بعد الخطأ.
- الثقة بإحساسك أن المسار سهل: بدا لك بسيطاً لأنك تعرف المنتج. أبلغ عما لاحظته مقابل قائمة التحقق.
من منظور ضمان الجودة
نفّذ جولة تجربة المستخدم مرتين: على التصميم أو النموذج الأولي، حين لا تكلّف الخطوة المحيّرة سوى نقاش، وعلى الميزة المبنية ضمن اختبار القصة. اسلك المسار على الهاتف والحاسوب، وبكل لغة يصدر بها المنتج.
سجّل الشاشة والخطوة وما يراه المستخدم والتوقع الذي خولف والخطورة: الطلب المفقود حرج، والبيانات المفقودة رئيسي، والرسالة الغامضة رئيسي أو ثانوي بحسب قدرة المستخدم على التعافي. واسأل المصمم ومالك المنتج عن المسار المقصود والصياغة المعتمدة للرسائل، وأعد تشغيل قائمة التحقق كلما تغيّر مسار.
تمرين عملي
نفّذ جولة تجربة المستخدم على مسار إعادة تعيين كلمة المرور
فيما يلي مسار إعادة تعيين كلمة المرور في تطبيق ويب كما سجّله مختبِر. طبّق قائمة تحقق تجربة المستخدم: اكتب كل نتيجة مع معرّف البند، وما يراه المستخدم، والتوقع الذي خولف، والخطورة.
ثم أعد كتابة أسوأ رسالة.
الخطوة 1 صفحة الدخول: رابط «نسيت؟» تحت حقل كلمة المرور.
الخطوة 2 صفحة إعادة التعيين: حقل واحد بنص نائب «البريد الإلكتروني» بلا تسمية؛ زر «إرسال».
كتابة الحرف الأول تُظهر «بريد غير صالح» بالأحمر تحت الحقل.
إرسال بريد صالح يُظهر «تم.» ويبقى في الصفحة.
الخطوة 3 بريد «أعد تعيين كلمة المرور» فيه رابط يفتح الخطوة 4.
الخطوة 4 صفحة كلمة المرور الجديدة: حقلان «كلمة المرور» و«التكرار»؛ زر «إرسال».
قيمتان غير متطابقتين: Error: PWD_MISMATCH في أعلى الصفحة، والحقلان فُرِّغا.
زر الرجوع في المتصفح من هذه الصفحة يعود إلى الخطوة 2 وحقل البريد فارغ.
الخطوة 5 بعد النجاح: تحويل إلى صفحة الدخول بلا أي رسالة.- ارسم المسار: الشاشة والفعل والمخارج التي ستختبرها.
- اسأل عند كل خطوة: أين أنا، وإلى أين أذهب، وكيف أعود.
- افحص كل نموذج: التسميات والتلميحات وتوقيت التحقق وبقاء البيانات بعد الخطأ.
- افحص كل رسالة مقابل الأجزاء الأربعة للرسالة الجيدة.
- سجّل كل نتيجة بالمعرّف والدليل والتوقع والخطورة.
إظهار الإجابة النموذجية
NAV-02: «نسيت؟» لا يسمّي فعله؛ المتوقع «هل نسيت كلمة المرور؟». و«إرسال» في الخطوتين 2 و4؛ المتوقع «أرسل رابط إعادة التعيين» و«احفظ كلمة المرور الجديدة». ثانوي.
FRM-01: الخطوة 2 تستعمل النص النائب (Placeholder) بدلاً من التسمية، فيختفي الاسم أثناء الكتابة (ذو صلة: المعيار 3.3.2 التسميات أو التعليمات في WCAG). رئيسي. وFRM-03: «بريد غير صالح» ينطلق بعد الحرف الأول بدلاً من انتظار مغادرة الحقل. ثانوي.
MSG-02: «تم.» لا تقول ما حدث ولا ما العمل بعده؛ المتوقع «إذا كان لهذا البريد حساب فقد أرسلنا رابط إعادة التعيين. تفقّد بريدك الوارد ومجلد الرسائل غير المرغوبة». رئيسي. والخطوة 5 بلا تأكيد؛ المتوقع «تم تغيير كلمة المرور. سجّل الدخول بكلمة المرور الجديدة». ثانوي.
MSG-01، وهي الأسوأ: Error: PWD_MISMATCH لا تسمّي حقلاً ولا تقترح تصحيحاً (المعياران 3.3.1 و3.3.3)، وتظهر في أعلى الصفحة. رئيسي. البديل: «تكرار كلمة المرور: كلمتا المرور غير متطابقتين. اكتب كلمة المرور نفسها في الحقلين». وFRM-04: الحقلان يُفرَّغان بصمت؛ وإن كان ذلك مقصوداً فلتقل الرسالة ذلك. ثانوي. وFLW-02: الرجوع يفقد البريد. ثانوي.
أسئلة شائعة
هل اختبار تجربة المستخدم هو نفسه اختبار قابلية الاستخدام؟
لا. اختبار قابلية الاستخدام يراقب مشاركين حقيقيين يؤدون مهاماً ويقيس نجاحهم ووقتهم وأخطاءهم ورضاهم. أما اختبار تجربة المستخدم فهو فحص المختبِر بنفسه للمسارات والتنقل والنماذج والرسائل مقابل قائمة تحقق وتوقعات معروفة. نفّذ جولة تجربة المستخدم أولاً؛ فهي تزيل العوائق الواضحة لتكشف جلسة قابلية الاستخدام العوائق الدقيقة.
كيف أبلغ عن نتيجة تجربة مستخدم من دون أن تُرفض بوصفها رأياً؟
سمِّ التوقع. فعبارة «رسالة رفض البطاقة لا تقول ما العمل بعدها، مخالفةً للاستدلال التاسع، مساعدة المستخدم على التعافي من الأخطاء؛ النص المقترح مرفق» عيب معه تصحيح، أما «الرسالة غير ودودة» فرأي. أرفق لقطة شاشة، وللرسائل أرفق الصياغة البديلة.
هل يحل اختبار تجربة المستخدم محل اختبار إمكانية الوصول؟
لا. يتداخلان في النماذج والتنقل، ومعايير WCAG المذكورة هنا جزء من كليهما، لكن اختبار إمكانية الوصول يغطي أيضاً قارئات الشاشة والتشغيل بلوحة المفاتيح والتباين وحجم الهدف، وهي تُدرَّس في وحدة إمكانية الوصول.
هل يمكن أتمتة اختبار تجربة المستخدم؟
أجزاء منه: تستطيع الفحوص الآلية أن تؤكد أن المسار يكتمل، وأن النموذج يحتفظ بقيمه بعد الخطأ، وأن لكل صفحة عنواناً. أما الحكم على وضوح رسالة أو إرباك خطوة فما زال يحتاج إلى إنسان، فاحتفظ بقائمة التحقق خطوةً يدوية في اختبار الانحدار للمسارات التي تتغير.
المراجع
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelنموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.
- Web Content Accessibility Guidelines (WCAG) 2.2توصية W3C التي تحدد معايير النجاح القابلة للاختبار لإتاحة محتوى الويب، مرتّبةً تحت أربعة مبادئ وثلاثة مستويات مطابقة (A وAA وAAA).
- 10 Usability Heuristics for User Interface Design (Jakob Nielsen)قواعد Jakob Nielsen العامة العشر لتصميم الواجهات — مثل وضوح حالة النظام ومنع الأخطاء — التي وُضعت أصلاً للتقييم الاستدلالي.
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
تدرّب بأدوات متقن
اشتق سيناريوهات اختبار شاملة (end-to-end) من قصة مستخدم، بما فيها التدفقات البديلة والاستثنائية.
ولّد حالات اختبار للتحقق من حقول النماذج: الإلزامية والصيغة والطول والنطاق والنمط والقواعد المشتركة بين الحقول.
ولّد حمولات أخطاء تحقق على مستوى الحقل للنماذج وواجهات API، بالجملة، لاختبار حالات الخطأ في واجهة المستخدم.
ولّد أسماء أولى وأسماء عائلات عشوائية بالإنجليزية والعربية والهندية مع خيارات الجنس والصيغة.
ولّد سيناريوهات اختبار عالية المستوى تغطي الجوانب الوظيفية والسلبية والأمنية وسهولة الاستخدام والتوافق لأي ميزة.
ولّد قائمة تحقق QA مخصّصة (وظيفية وواجهة مستخدم وAPI وأمان وأداء وإمكانية وصول وإصدار) لأي ميزة باستخدام الذكاء الاصطناعي من متقن.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.