تخيل أن اختبارات برامجك تنجح تمامًا، لكن المستخدمين لا يستطيعون رؤية نصف الصفحة! نستعرض هنا حادثة حديثة حيث تفاعلت الاختبارات الآلية بنجاح مع زر كان غير قابل للوصول على الإطلاق للمستخدمين البشريين.
هل سبق لك أن رأيت اختباراتك الآلية تنجح، ومع ذلك يبلغ مستخدموك عن تجربة معطلة؟ هذه مشكلة شائعة تعني أن اختباراتك لا تعكس تفاعل المستخدم الحقيقي بشكل كامل. واجهنا مؤخرًا لغزًا محيرًا مع محرر مدونة جديد في لوحة التحكم. كانت اختباراتنا الشاملة للمحرر كلها خضراء، مؤكدة ملء النموذج ونشر المشاركة. لكن بعد ذلك قام مستخدم - أحدنا في الواقع - بفتحه ووجد مشكلة كبيرة: النصف السفلي من النموذج، بما في ذلك زر «إضافة سؤال» المهم وخيارات النشر، كان قد اختفى تمامًا! لقد تم اقتطاعه من الشاشة، ولم يتمكن أي قدر من التمرير بعجلة الماوس أو لوحة المفاتيح من إعادته. لقد نقر الاختبار على زر لم يتمكن أي إنسان من رؤيته.
إذن، كيف حدث هذا، وماذا يعني لك كمطور أو مستخدم؟ تحتوي لوحة التحكم لدينا على وضع عرض خاص «عرض البريد»، مصمم ليناسب الشاشة تمامًا دون أي تمرير خارجي. يحقق ذلك بقاعدة CSS بسيطة: `overflow: hidden`. يتم عرض معظم الصفحات في حاوية تمرير عادية، لكن الصفحات الجديدة مثل محرر المدونة تحتاج إلى استبعادها تحديدًا من وضع البريد بملء الشاشة هذا. في عجلتنا، أضفنا محرر المدونة الجديد لكننا نسينا إضافته إلى قائمة الاستثناءات هذه. النتيجة؟ فتح المحرر في وضع البريد `overflow: hidden`، وبما أن محتواه كان أطول من الشاشة، فقد تم اقتطاع الجزء السفلي منه ببساطة، مما جعله غير قابل للوصول للمستخدمين البشريين.
الرؤية الحاسمة هي أن `overflow: hidden` لا يعني أن النص البرمجي الآلي لا يمكنه 'التمرير' أو التفاعل مع العناصر المخفية. بينما يخفي أشرطة التمرير ويتجاهل مدخلات المستخدم مثل عجلات الماوس، لا يزال المتصفح يحتفظ بموضع التمرير الداخلي للعنصر (`scrollTop`). كان اختبارنا الآلي قادرًا بشكل أساسي على تجاوز الاقتطاع المرئي عن طريق معالجة العناصر مباشرة، وإيجاد زر «إضافة سؤال» والنقر عليه حتى لو لم يكن مرئيًا على الشاشة.
كان الحل بسيطًا للغاية: كلمتان، `&& !blog`، تمت إضافتهما إلى الشرط الذي يحدد ما إذا كانت الصفحة تستخدم وضع البريد `overflow: hidden`. يضمن هذا التغيير البسيط أن محرر المدونة يفتح الآن في حاوية تمرير مناسبة. الدرس هنا واضح: الاختبارات الآلية قوية، ولكنها تحتاج إلى محاكاة سلوك المستخدم بشكل حقيقي، بما في ذلك الفحوصات البصرية والتمرير الذي يقوده المستخدم، لالتقاط مشكلات مثل هذه. مجرد قدرة الاختبار على التفاعل برمجيًا مع عنصر لا يعني أن المستخدم البشري يستطيع ذلك.
إذن، كيف حدث هذا، وماذا يعني لك كمطور أو مستخدم؟ تحتوي لوحة التحكم لدينا على وضع عرض خاص «عرض البريد»، مصمم ليناسب الشاشة تمامًا دون أي تمرير خارجي. يحقق ذلك بقاعدة CSS بسيطة: `overflow: hidden`. يتم عرض معظم الصفحات في حاوية تمرير عادية، لكن الصفحات الجديدة مثل محرر المدونة تحتاج إلى استبعادها تحديدًا من وضع البريد بملء الشاشة هذا. في عجلتنا، أضفنا محرر المدونة الجديد لكننا نسينا إضافته إلى قائمة الاستثناءات هذه. النتيجة؟ فتح المحرر في وضع البريد `overflow: hidden`، وبما أن محتواه كان أطول من الشاشة، فقد تم اقتطاع الجزء السفلي منه ببساطة، مما جعله غير قابل للوصول للمستخدمين البشريين.
الرؤية الحاسمة هي أن `overflow: hidden` لا يعني أن النص البرمجي الآلي لا يمكنه 'التمرير' أو التفاعل مع العناصر المخفية. بينما يخفي أشرطة التمرير ويتجاهل مدخلات المستخدم مثل عجلات الماوس، لا يزال المتصفح يحتفظ بموضع التمرير الداخلي للعنصر (`scrollTop`). كان اختبارنا الآلي قادرًا بشكل أساسي على تجاوز الاقتطاع المرئي عن طريق معالجة العناصر مباشرة، وإيجاد زر «إضافة سؤال» والنقر عليه حتى لو لم يكن مرئيًا على الشاشة.
كان الحل بسيطًا للغاية: كلمتان، `&& !blog`، تمت إضافتهما إلى الشرط الذي يحدد ما إذا كانت الصفحة تستخدم وضع البريد `overflow: hidden`. يضمن هذا التغيير البسيط أن محرر المدونة يفتح الآن في حاوية تمرير مناسبة. الدرس هنا واضح: الاختبارات الآلية قوية، ولكنها تحتاج إلى محاكاة سلوك المستخدم بشكل حقيقي، بما في ذلك الفحوصات البصرية والتمرير الذي يقوده المستخدم، لالتقاط مشكلات مثل هذه. مجرد قدرة الاختبار على التفاعل برمجيًا مع عنصر لا يعني أن المستخدم البشري يستطيع ذلك.
