الأسئلة الشائعة حول الاختبار البصري: إجابات على أكثر 20 سؤالاً تكراراً

هل لديك أسئلة حول الاختبار البصري الآلي؟ إليك إجابات الأسئلة التي نتلقاها بشكل متكرر، مُنظّمة حسب الموضوع.

أسئلة عامة

1. ما هو الاختبار البصري الآلي؟

الاختبار البصري الآلي (أو visual regression testing) هو تقنية تقارن تلقائياً لقطات شاشة تطبيقك للكشف عن التغييرات البصرية غير المقصودة.

خطوات الاختبار البصري هي كالتالي: العملية المبسّطة:

التقاط صورة مرجعية (baseline)
التقاط صورة جديدة بعد تعديل الكود
مقارنة بكسل ببكسل
تنبيه في حال اكتشاف فرق

2. ما الفرق بين الاختبار البصري واختبارات E2E؟

اختبارات E2E	الاختبارات البصرية
تتحقق من السلوك الوظيفي	تتحقق من المظهر
"هل يُرسل الزر النموذج؟"	"هل الزر في موضعه الصحيح؟"
تأكيدات على البيانات	تأكيدات على البكسلات
قد تفوّت أخطاء بصرية	تكشف أي تغيير بصري

الخيار الأمثل: الجمع بين الاثنين لتغطية شاملة.

3. هل أحتاج إلى معرفة البرمجة لإجراء اختبارات بصرية؟

الإجابة تعتمد كلياً على الأداة المختارة. غالبية الحلول المتاحة في السوق تتطلب مهارات في التطوير، مما يُشكّل حاجزاً كبيراً أمام فِرق ضمان الجودة (QA).

الأداة	المهارات المطلوبة	سهولة الوصول
Playwright / Cypress	TypeScript أو JavaScript، إعداد المشروع، إدارة التبعيات	مخصصة للمطورين
Percy / Applitools	دمج في الكود الحالي، إعداد CI/CD	تتطلب ملفاً تقنياً
Delta-QA	لا تتطلب أي مهارات برمجية	متاحة لكامل الفريق

الأدوات المبنية على الكود (Playwright، Cypress) توفر مرونة كبيرة، لكنها تفرض أن تكون الاختبارات مكتوبة ومُصانة ومُصحّحة من قِبل المطورين. هذا يعني أن فريق QA يعتمد على المطورين لإنشاء أو تعديل أي سيناريو، مما يُحدث عنق زجاجة في عملية الاختبار.

الحلول السحابية مثل Percy أو Applitools تُبسّط بعض الخطوات، لكنها تتطلب أيضاً دمجاً في الكود المصدري وإعداداً تقنياً.

يتبنّى Delta-QA مقاربة مختلفة: واجهته الرسومية تتيح لأي عضو في الفريق — سواء كان مختبراً أو مدير منتج أو مصمماً — إنشاء الاختبارات البصرية وتنفيذها وصيانتها دون كتابة سطر واحد من الكود. يتم بناء السيناريوهات بصرياً، وإدارة الـ baselines بنقرات قليلة، والنتائج قابلة للقراءة فوراً. هذا يمنح فِرق QA الاستقلالية ويُغنيها عن الاعتماد على جدول المطورين لحملات الاختبار.

4. كم من الوقت يستغرق إعداد الاختبارات البصرية؟

المقاربة	الإعداد الأولي	أول 10 اختبارات	الوقت الإجمالي المقدّر
Playwright (كود)	1-2 يوم	يوم واحد	2-3 أيام
SaaS مع كود (Percy)	4-8 ساعات	4 ساعات	1-2 يوم
بدون كود (Delta-QA)	30 دقيقة	2-3 ساعات	3-4 ساعات

5. ما أنواع الأخطاء التي تكشفها الاختبارات البصرية؟

تكشف الاختبارات البصرية بشكل خاص:

تخطيط الصفحة المعطّل (CSS)
عناصر في مواضع خاطئة
نصوص مقطوعة أو متجاوزة للحدود
ألوان غير صحيحة
صور مفقودة أو بأبعاد خاطئة
مشاكل التصميم المتجاوب (responsive)
خطوط لم يتم تحميلها
مشاكل z-index (تداخل العناصر)
هوامش وحشوات (margins/paddings) خاطئة
انحدارات بعد تحديث التبعيات

أسئلة تقنية

6. ما هي الـ baseline؟

الـ baseline (أو المرجع) هي لقطة الشاشة "الصحيحة" التي ستُقارَن بها اللقطات المستقبلية.

دورة حياة الـ baseline تمر بأربع مراحل:

التنفيذ الأول — يتم إنشاء الـ baseline تلقائياً
التنفيذات التالية — تُقارَن كل لقطة بالـ baseline
تغيير مقصود — يتم تحديث الـ baseline لتعكس النسخة الجديدة
اكتشاف خطأ — يُصحَّح الكود وتبقى الـ baseline دون تغيير

7. كيف نتعامل مع المحتوى الديناميكي؟

المحتوى الديناميكي (التواريخ، الصور الرمزية، الإعلانات) يتسبب في نتائج إيجابية كاذبة. هناك ثلاثة حلول رئيسية:

مناطق الاستثناء: إخفاء المناطق الديناميكية (التواريخ، العدّادات) أثناء المقارنة ليتم تجاهلها
محاكاة المحتوى (Mock): تثبيت البيانات الديناميكية (تاريخ ثابت، صورة رمزية افتراضية) للحصول على لقطات متطابقة في كل تنفيذ
إخفاء عبر CSS: جعل العناصر الديناميكية غير مرئية أثناء الالتقاط عبر ورقة أنماط مُحقَنة

8. ما نسبة التسامح الموصى بها؟

السياق	نسبة التسامح الموصى بها
صفحات حرجة (الدفع، السلة)	0-0.5%
صفحات عادية	1-2%
مقارنة بين متصفحات (Chrome مقابل Firefox)	2-3%
مع anti-aliasing	تفعيل خيار antialiasing، ثم 1%

9. كيف تعمل المقارنة بكسل ببكسل؟

الخوارزمية الأساسية تعمل في خمس خطوات:

تحميل صورة الـ baseline (المرجع)
تحميل الصورة الحالية (الاختبار)
لكل بكسل، مقارنة قيم اللون (R، G، B، A) وتحديده كمختلف إذا تجاوز الفرق العتبة المحددة
حساب نسبة البكسلات المختلفة
إذا تجاوزت هذه النسبة حد التسامح المحدد، يفشل الاختبار

تضيف الخوارزميات المتقدمة (pHash، SSIM) تسامحاً إدراكياً يقترب من الرؤية البشرية. لمزيد من التفاصيل حول هذه المفاهيم، يمكنك الرجوع إلى مسرد مصطلحات الاختبار البصري.

10. هل يمكنني الاختبار على عدة متصفحات؟

نعم، معظم الأدوات تتيح الاختبار على عدة متصفحات في وقت واحد. يكفي إعداد المتصفحات المستهدفة (Chrome، Firefox، Safari) في تكوين الأداة.

تنبيه: كل متصفح يُنتج عرضاً مختلفاً بشكل طفيف، لذا يجب الاحتفاظ بـ baselines منفصلة لكل متصفح. يُنصح بالاطلاع على الاختبار البصري عبر المتصفحات لاستراتيجيات التعامل مع هذه الاختلافات.

11. كيف نختبر التصميم المتجاوب (responsive)؟

يكفي تحديد أحجام العرض (viewports) المطلوب اختبارها وتنفيذ اللقطات لكل منها:

Viewport	الدقة	الاستخدام
سطح المكتب	1920×1080	شاشة قياسية
الجهاز اللوحي	768×1024	iPad، أجهزة لوحية
الهاتف المحمول	375×812	iPhone، هواتف ذكية

كل viewport يُولّد baselines خاصة به، مما يسمح باكتشاف المشاكل الخاصة بكل حجم شاشة.

أسئلة حول الأدوات

12. ما هي أبرز أدوات الاختبار البصري؟

الأداة	النوع	التخصص
Percy (BrowserStack)	SaaS	موجّه لـ CI، شائع جداً
Applitools	SaaS	ذكاء اصطناعي متقدم، عرض مؤسسي
Chromatic	SaaS	متخصص في Storybook
Delta-QA	SaaS/Desktop وOn-premise	بدون كود
Playwright	مفتوح المصدر	مدمج في إطار العمل، مجاني
Cypress	مفتوح المصدر	عبر إضافة مخصصة
BackstopJS	مفتوح المصدر	متخصص في الاختبار البصري
reg-suit	مفتوح المصدر	خفيف وبسيط

13. كيف تختار الأداة المناسبة؟

الحالة	الأداة الموصى بها
ميزانية صفرية + مطورون ذوو خبرة	Playwright أو BackstopJS
ميزانية محدودة + فريق مختلط (مطورون وغير مطورين)	Delta-QA
ميزانية مؤسسية + حاجة للذكاء الاصطناعي	Applitools
فريق يعتمد 100% على Storybook	Chromatic
CI/CD متقدم + مطورون تقنيون	Percy

14. كم عدد الاختبارات البصرية المطلوبة؟

نوع التطبيق	عدد السيناريوهات الموصى به
موقع تعريفي (10-20 صفحة)	15-30 سيناريو
متجر إلكتروني متوسط	40-60 سيناريو
تطبيق SaaS	50-100 سيناريو

القاعدة الذهبية: ابدأ بتغطية المسارات الحرجة — الصفحات التي يراها 80% من مستخدميك، ومسارات التحويل (الدفع، التسجيل)، والوظائف ذات القيمة التجارية العالية.

15. من يجب أن يدير الاختبارات البصرية؟

حجم الفريق	توزيع المهام
شركة ناشئة (فريق صغير)	المطورون يديرون كل شيء، من الإنشاء إلى الصيانة
شركة متوسعة (فريق متوسط)	فريق QA يُنشئ الاختبارات ويصونها، والمطورون يُصلحون الأخطاء المكتشفة
مؤسسة كبيرة (فريق كبير)	قائد QA يحدد الاستراتيجية، مهندسو QA يُنشئون الاختبارات، المطورون يدمجونها في سير عملهم، ومدير المنتج يُصادق على التغييرات المقصودة

أسئلة عملية

16. كيف يتم تحديث الـ baselines؟

تحديث الـ baselines يختلف حسب الأداة:

بواجهة رسومية (Delta-QA): يكفي النقر على "قبول كـ baseline جديدة" لكل تغيير
بأداة سطر الأوامر: أمر مخصص يسمح بإعادة توليد جميع الـ baselines في تنفيذ واحد

مهم: يجب دائماً مراجعة التغييرات البصرية قبل قبول baseline جديدة، لتجنّب اعتماد خطأ عن غير قصد.

17. كيف تُدار الـ baselines ضمن فريق عمل؟

أربع ممارسات جيدة لإدارة الـ baselines ضمن فريق:

إدراج الـ baselines مع الكود في نظام التحكم بالإصدارات — إيداعها في نفس المستودع للحفاظ على التناسق بين الكود ومراجعه البصرية
العمل بالفروع — كل فرع ميزة يمتلك baselines خاصة به، مما يتجنّب التعارض مع الفرع الرئيسي
مراجعة تغييرات الـ baselines — التعامل مع تعديلات الـ baselines كالكود: تضمينها في طلبات السحب (pull requests) للمصادقة عليها
تعيين مسؤول لكل منطقة — تخصيص مالك لكل مجموعة اختبارات لتجنّب تعارضات التحديث

18. هل يمكنني اختبار تطبيقات تتطلب مصادقة؟

نعم، هناك عدة مقاربات ممكنة:

تسجيل دخول برمجي — يقوم الاختبار بتسجيل الدخول تلقائياً قبل كل لقطة عبر ملء نموذج تسجيل الدخول
حفظ حالة المصادقة — يتم تسجيل حالة الجلسة مرة واحدة، ثم إعادة استخدامها لجميع الاختبارات اللاحقة، مما يُسرّع التنفيذ بشكل كبير
رمز اختبار في بيئة الاختبار — في بيئة الاختبار (staging)، يسمح رمز مصادقة مخصص بتجاوز تسجيل الدخول دون المساس بالأمان

19. هل تحلّ الاختبارات البصرية محل الاختبارات اليدوية؟

لا، إنها تُكمّلها:

الاختبارات البصرية الآلية تتفوق في اكتشاف الانحدارات، والمقارنة مع مرجع معروف، وتوفير فحوصات سريعة وقابلة للتكرار. لكنها لا تكشف مشاكل تجربة المستخدم ولا تتحقق مما إذا كان التصميم يتوافق مع "نية" المصمم.

لذلك تظل الاختبارات اليدوية ضرورية لاستكشاف الميزات الجديدة، واختبارات سهولة الاستخدام، والحالات الحدّية المعقدة، والتحقق من الانطباع العام للتطبيق.

20. ما هي التوجهات المستقبلية للاختبار البصري؟

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

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

التوجه الحقيقي، في رأينا، هو استخدام الذكاء الاصطناعي في المراحل الأولى: ليس لتنفيذ الاختبارات، بل لتحسين خوارزميات الأدوات المتاحة للمهندسين. بمعنى آخر، يجب أن يخدم الذكاء الاصطناعي في تصميم برمجيات اختبار أكثر حتمية وأكثر موثوقية، تُرافق فِرق QA بضمان أن البرنامج المنشور سيكون عالي الجودة.

هذه بالضبط فلسفة Delta-QA. بدلاً من دمج الذكاء الاصطناعي في حلقة الاختبار، يستثمر Delta-QA في متانة خوارزميات المقارنة الخاصة به. يتم اختبار آلاف التوليفات من تكوينات صفحات HTML — هياكل معقدة، تداخلات عميقة، محتوى ديناميكي، اختلافات العرض بين المتصفحات — بشكل منهجي لتعزيز موثوقية الكشف. كل إصدار من الخوارزمية يُصادَق عليه من خلال مصفوفة اختبارات إجهاد تغطي أكثر من 425 صفحة حقيقية، بهدف واضح: صفر نتائج إيجابية كاذبة، صفر نتائج سلبية كاذبة.

هذا النهج يضمن لمهندسي QA أداةً يمكنهم الاعتماد عليها في كل عملية نشر، بلا مفاجآت وبلا شكوك.

جرّب Delta-QA مجاناً →