تخط وانتقل إلى المحتوى الرئيسي

العيوب الوظيفية

ما هي الأخطاء الوظيفية، كيف نقيّم شدتها، وكيف نميزها عن مقترحات سهولة الاستخدام؟

Nikola Jonic avatar
بقلم: Nikola Jonic
تم إجراء التحديث أمس

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

كيفية تحديد ما إذا كان سلوك التطبيق خطأ وظيفيًا:

  • حاول معرفة ما إذا كانت الميزة مصممة بهذه الطريقة أم أنها معطلة فعلاً. اختبرها بمفردها وكذلك بالتزامن مع ميزات أخرى لتتمكن من تحديد الفروقات المحتملة.

  • ضع في اعتبارك نوايا العميل المحتملة، ولا تستبعد أن المنتج قد يعمل على النحو الصحيح والمقصود لتنفيذه

  • ابحث عن دليل يثبت أن شيئًا ما لا يعمل كما ينبغي. ادعم ادعاءك.

  • مثال: قد تجد وظيفة متجر إلكتروني تعمل بشكل مختلف عن المتاجر الإلكترونية الأخرى التي تعرفها. هذا لا يعني أن الوظيفة معطلة. يمكن للعميل تنفيذ منتجه كما يريد.

  • تدّعي أن حقل نموذج لا تتم عليه عملية التحقق (not validated) وهو خلل. هل هناك أي إشارة إلى أنهم قصدوا التحقق من هذا الحقل؟ قدّم دليلاً يوضح أن الحقل يتم التحقق منه في بعض الحالات وليس في أخرى. إذا لم تقدّم دليلاً، فهذا ادعاء غير مُثبت.

  • تصبح المشكلة البصرية أو مشكلة المحتوى مشكلة وظيفية عندما تعيق وظيفة ما، وبالتالي يجب الإبلاغ عنها كخلل وظيفي.

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

تقييم الشدة

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

النهج المباشر هو النظر إلى التأثير الوظيفي للخطأ. فكّر في مدى خطورة عدم توفر وظيفة ما. الوظائف الثانوية لن تمنع المستخدمين من متابعة هدفهم – على عكس الوظائف الرئيسية المعطلة. اسأل نفسك: ما مدى أهمية هذه الوظيفة في سياق المنتج ككل.

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

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

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

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

لدينا ثلاثة مستويات درجة خطورة للعيوب الوظيفية:

منخفض:

  • تأثير ضئيل على استخدام المنتج.

  • يُظهر المنتج سلوكاً غير مقصود، لكن الاستخدام العام لا يتأثر.

  • عدد قليل من المستخدمين أو المنتجات أو العناصر متأثر.

  • ميزة/وظيفة معطلة أو غير متوفرة، لكن حلًا بديلًا بسيطًا يحل المشكلة.

عالٍ:

  • تأثير خطير على استخدام المنتج، لكن الوظائف الأساسية سليمة.

  • عدد كبير من المستخدمين أو المنتجات أو العناصر متأثر.

  • وظيفة غير بسيطة معطلة أو غير متوفرة ولا يوجد حل بديل.

  • وظيفة مهمة معطلة أو غير متوفرة لكن يوجد حل بديل (وبالتالي ليست مشكلة توقف رئيسية).

حرج:

  • يمنع الخلل الوظيفة الأساسية للتطبيق/الموقع.

  • مشكلة توقف رئيسية تمنع المستخدم من متابعة عملية رئيسية، مثل عملية الدفع.

  • يسبب الخلل خسارة محتملة وملحوظة في المبيعات للعميل للشركة المالكة للتطبيق أو الموقع.

التقييمات الشائعة

لدينا قائمة بالحالات التي لها مستويات شدة ثابتة. نظام التقييم أعلاه لا ينطبق على تلك الحالات. وبما أن القائمة سيتم تحديثها بمرور الوقت، يرجى التحقق منها بانتظام.

عيوب الحالات الحدّية

تظهر عندما يتم استخدام خاصية بطريقة غير معتادة. الخاصية لا تتعطل عند استخدامها مع بيانات وإجراءات مستخدم معتادة. وإليك بعض الأمثلة:

  • تنفيذ إجراءات سريعة ومتلاحقة، مثل تصغير التطبيق مباشرة بعد النقر على زر.

  • التكرار المفرط لنفس الإجراء، كفتح وإغلاق القوائم بشكل متتابع وسريع.

  • أي خلل لا يحدث إلا بعد مجموعة غير شائعة من الإجراءات.

يجب تقييم كل حالة بشكل منفصل. يتم تمرير حالات العيوب الحدّية ذات الصلة بعملائنا على أنها مشاكل منخفضة الخطورة. أما الحالات غير ذات الصلة – والتي تشكل غالبية عيوب الحالات الحدّية – فيتم رفضها

العيوب المُفتعلة

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

  • النقر على عدة عناصر في الوقت نفسه.

  • الضغط العشوائي على الأزرار.

  • النقر المتسارع على زر عدة مرات.

  • تقليص حجم نافذتك إلى أحجام غير نموذجية أو التكبير أو التصغير على المحتوى.

  • امتلاء ذاكرة الوصول العشوائي (RAM) أو الذاكرة الداخلية مما يؤدي إلى سلوك غير متوقع.

  • استخدام إصدارات نظام تشغيل غير رسمية أو تجريبية (Beta) أو معدلة.

هل أجاب هذا عن سؤالك؟