الاختبارات البصرية غير المستقرة (Flaky): لماذا تدمر الـ QA وكيف تُثبّتها
الاختبار الـ flaky (أو الاختبار غير المستقر) هو اختبار يُنتج نتائج مختلفة — نجاح أو فشل — لنفس الكود ونفس التهيئة، دون أي تعديل على النظام المُختبَر.
إليك رأيًا قد يزعجك: اختبار بصري flaky أسوأ من عدم وجود اختبار أصلاً. اختبار غائب لا يكلّف شيئًا يوميًا. لا يعرقل pipeline. لا يستهلك وقت فريقك. لا يدمر الثقة في بنية الاختبار. اختبار flaky يفعل كل ذلك، كل يوم، بخبث.
بيانات Google عن أنظمة الاختبار الخاصة بها بليغة: حوالي 1,5% من اختباراتها flaky في أي وقت، لكن هذه الاختبارات تستهلك حصة غير متناسبة من وقت الهندسة.
لماذا الاختبارات البصرية معرّضة بشكل خاص لعدم الاستقرار
يُدخل الاختبار البصري الآلي طبقة من عدم الحتمية لا تعرفها الاختبارات الوحدوية أو الوظيفية. عرض صفحة ويب هو نتيجة سلسلة معقدة من العمليات، كل منها يُدخل تباينه الخاص.
الأسباب الأربعة الرئيسية للاختبارات البصرية الـ flaky
التوقيت: المشكلة التي لا يمكنك تجاهلها
الويب غير متزامن بطبيعته. تحميل صفحة ليس حدثًا واحدًا — إنه سلسلة من الأحداث. لا إشارة تضمن اكتمال العرض البصري.
الرسوم المتحركة: حركة في وسط ثابت
لقطة الشاشة صورة ثابتة. الرسوم المتحركة تغيير مستمر. الاثنان غير متوافقين أساسًا للمقارنة الآلية.
المحتوى الديناميكي: كل ما يتغير بدونك
التواريخ، الأوقات، الإعلانات، الصور الرمزية المولّدة — كلها تتغير بين تنفيذات الاختبار.
الشبكة والبنية التحتية: المتغيرات التي لا تتحكم بها
اختبارك يعمل في بيئة تعتمد على موارد خارجية. الكمون يتغير بين التنفيذات.
التكلفة الحقيقية للاختبارات الـ flaky
التكلفة الأكثر تدميرًا هي فقدان الثقة. عندما يتعلم فريق أن الاختبارات البصرية تفشل "طوال الوقت" بدون سبب، يطوّرون رد فعل إعادة تشغيل تلقائي. ويمر الخطأ إلى الإنتاج.
استراتيجيات التثبيت الناجحة
التحكم في بيئة العرض
متصفح headless في حاوية مُتحكَّم بها بدقة شاشة ثابتة وخطوط مُثبّتة مسبقًا وتهيئة شبكة حتمية.
تحييد الرسوم المتحركة
حقن ورقة أنماط تُجبر جميع الرسوم المتحركة والانتقالات على مدة صفر.
تثبيت المحتوى الديناميكي
تجميد التواريخ والأوقات، تعطيل أدوات الطرف الثالث، محاكاة بيانات API.
الانتظار الذكي
استراتيجيات انتظار مبنية على الحالة الفعلية للصفحة، وليس تأخيرات ثابتة.
تبني مقارنة تتحمل الضوضاء
النهج الهيكلي — مقارنة DOM وخصائص CSS المحسوبة — الأكثر مقاومة لضوضاء العرض.
الاختبار البصري no-code كحل لمشكلة الصيانة
أدوات no-code مثل Delta-QA تزيل طبقة هشاشة البرامج النصية. لا تكتب برامج نصية — تُهيّئ اختباراتك بصريًا.
متى تحذف اختبارًا flaky
إذا فشل اختبار بصري بشكل متقطع رغم جميع محاولات التثبيت، فالقرار الأشجع — والأحكم غالبًا — هو حذفه. الهدف ليس أكبر عدد من الاختبارات — بل اختبارات يثق بها فريقك.
الأسئلة الشائعة
ما الفرق بين اختبار flaky وإيجابية كاذبة؟
الإيجابية الكاذبة تشير إلى مشكلة غير موجودة. الاختبار الـ flaky يُنتج نتائج غير متسقة من تنفيذ لآخر لنفس الكود.
كيف تقيس معدل الـ flakiness؟
شغّل نفس مجموعة الاختبارات عدة مرات دون تغيير الكود وعُد الاختبارات التي تتغير نتائجها.
هل الاختبارات البصرية no-code أقل flakiness؟
تزيل فئة من الـ flakiness — تلك المتعلقة بالبرامج النصية. لكنها تظل خاضعة لنفس قيود عرض المتصفح.
هل يجب إعادة تشغيل الاختبارات الفاشلة تلقائيًا؟
الـ retry ضمادة، ليس حلاً. إذا فعّلته، اقصره على محاولة واحدة وحدد الاختبارات للتحقيق.
ما عتبة الـ flakiness المقبولة في CI/CD؟
استهدف أقل من 1%. فوق 5%، فريقك على الأرجح يعيد تشغيل pipelines الفاشلة بشكل منهجي.
هل يساعد Delta-QA في تثبيت الاختبارات البصرية؟
Delta-QA يُقلّل الـ flakiness من المصدر باستخدام نهج هيكلي. تغيرات sub-pixel rendering وantialiasing والتوقيت تُتجاهل بشكل أصلي. مع النهج no-code، يُنتج نتائج موثوقة وقابلة للتكرار دون تهيئة معقدة.
الاختبار البصري له قيمة فقط إذا كان فريقك يثق به. الاختبارات الـ flaky تدمر تلك الثقة يومًا بعد يوم.