الاختبار المرئي (Visual testing): طريقة تحقق آلية تقارن مظهر واجهة المستخدم بين حالة مرجعية (baseline) وحالة راهنة، بهدف اكتشاف أي انحدار مرئي (الألوان، والخطوط، والمسافات، والتخطيط) قبل وصوله إلى الإنتاج.
لنبدأ برأي قد يفاجئكم: مقارنة Delta-QA بـ Playwright أشبه بمقارنة سماعة طبية بجهاز رنين مغناطيسي. كلاهما يُستخدم لتشخيص المشكلات، لكنهما لا ينظران إلى الشيء نفسه ولا يتوجهان إلى الممارسين أنفسهم. ومنذ ظهور SDK Vision من Delta-QA، لم يعودا حتى منفصلين: يستطيع Delta-QA التحقق من صفحات اختبارات Playwright لديكم، سطراً واحداً لكل صفحة.
ومع ذلك، يتكرر سؤال «Delta-QA أم Playwright؟» باستمرار في فرق الجودة. وهذا طبيعي: حين تكون ميزانيتكم محدودة ويفيض سجل الدين التقني لديكم، تريدون معرفة أين تستثمرون وقتكم. هذا المقال هو الجواب الذي تبحثون عنه: بنقاط القوة والحدود، وخصوصاً الحالات التي تتألق فيها كل أداة.
جميع مقارناتنا، وفق معايير قابلة للتحقق: البدائل والمقارنات.
الاختبار المرئي دون كتابة أو صيانة سطر واحد من Playwright. يسجّل Delta-QA مساراتكم بدون برمجة ويخبركم أي عنصر تغيّر، بحساب مجاني ودون بطاقة مصرفية. جرّب Delta-QA مجانًا ←
Playwright: المرجع المفتوح المصدر للاختبار الوظيفي
أصبح Playwright، الذي تطوره Microsoft، في بضع سنوات المرجع في الاختبار الشامل (end-to-end) لفرق التطوير. وهو يستحق ذلك. فمعماريته متعددة المتصفحات (Chromium وFirefox وWebKit) أصلية لا مرقَّعة لاحقاً. وواجهته البرمجية بـ TypeScript أنيقة، ومحدِّداته (selectors) متينة، وتتيح إدارته للانتظار التلقائي (auto-wait) التخلص من جزء كبير من الاختبارات غير المستقرة (flaky) التي تسمّم حياة المطورين منذ عصر Selenium. حين يكتب مطور اختبار Playwright، فإنه يصف سيناريو وظيفياً: «انتقل إلى هذه الصفحة، انقر هذا الزر، تحقق من ظهور هذا النص». إنه تحقق سلوكي: هل يفعل التطبيق ما يُفترض أن يفعله؟ وفي هذا المجال، Playwright ببساطة ممتاز. التوثيق شامل، والمجتمع ضخم، والتحديثات متكررة (الإصدار 1.64 في أكتوبر 2026)، والتكامل مع CI/CD سلس. وتنشر Microsoft أيضاً خادم MCP لـ Playwright يتيح لمساعد الشيفرة البرمجية قيادة متصفح.
ويقدم Playwright كذلك ميزة مقارنة لقطات الشاشة. يمكنكم التقاط لقطة ومقارنتها بخط مرجعي. إنه اختبار مرئي، وهو مفيد. لكنه اختبار مرئي على مستوى البكسل، بما يصاحب ذلك من حدود.
الاختبار المرئي في Playwright: قادر لكنه أساسي
لنكن دقيقين فيما يقدمه Playwright في الاختبار المرئي. تلتقط الدالة toHaveScreenshot() لقطة وتقارنها بكسلاً ببكسل بملف مرجعي. وإن تجاوز الفرق عتبة قابلة للضبط، يفشل الاختبار. ويتيح الخيار mask إخفاء مناطق ديناميكية. إنه وظيفي ومجاني. وهو أيضاً حد أدنى فقط.
تظهر الحدود سريعاً بمجرد محاولتكم تطبيق هذه المقاربة على نطاق واسع.
إدارة الخطوط المرجعية يدوية ومرهقة. كل خط مرجعي ملف صورة مخزَّن في مستودع Git لديكم. وعندما يكون تغيير مرئي مقصوداً: لون زر جديد، أو مسافة معدَّلة في نظام التصميم، عليكم تحديث ملفات المرجع يدوياً. في تطبيق بـ 50 صفحة و3 دقات، قد يعني ذلك 150 خطاً مرجعياً لإدارتها. بلا واجهة مرئية لمقارنتها، وبلا سير عمل اعتماد، وبلا سجل للتغيّرات المرئية.
يتوقف العرض على بيئة التنفيذ. تتفاوت لقطات Playwright بحسب نظام التشغيل، وإصدار المتصفح، والخطوط المثبتة، وحتى دقة الشاشة الافتراضية. اختبار ينجح على جهاز Mac لدى المطور يفشل في حاوية Docker في CI. والحل الرسمي؟ رفع عتبة التسامح. وهذا يعني إغماض العين عن الانحدارات الدقيقة، بالضبط تلك التي يُفترض أن يلتقطها الاختبار المرئي.
لا يوجد سير عمل اعتماد مشترك. عندما يفشل اختبار Playwright المرئي، ترون صورة فرق في تقرير HTML. ولقبول التغيير، يعيد المطور تشغيل الاختبارات بالخيار --update-snapshots ويثبّت الصور الجديدة (commit). ولا إمكانية لمصمم أو لمسؤول جودة غير تقني أن يعتمد التغيير. بالنسبة لمطور يعمل منفرداً، هذا يكفي. أما لفريق متعدد التخصصات فهو عنق زجاجة.
تعدد المتصفحات محدود عملياً. يدعم Playwright كلاً من Chromium وFirefox وWebKit. لكن كل متصفح يولّد لقطات مختلفة قليلاً: تنعيم نص هنا، وعرض دون البكسل هناك. إن صيانة خطوط مرجعية منفصلة لكل متصفح تضاعف عبء الصيانة ثلاث مرات دون أداة مخصصة لإدارة المقارنة.
Delta-QA: الاختبار المرئي كتخصص، لا كميزة جانبية
صُمم Delta-QA منذ البداية لحل مشكلة محددة وحلها جيداً: اكتشاف انحدارات الواجهة في تطبيقات الويب، مع كل إصدار. إنه ليس إطار اختبار وظيفي يفعل المرئي أيضاً.
وهذا التخصص يغيّر التجربة جذرياً.
مقاربة بدون برمجة تزيل الحاجز التقني. مع Delta-QA، تفتحون موقعكم وتتصفحون سيناريوهاتكم كما يفعل مستخدم؛ وتسجّلها الأداة، وتعيد تشغيلها في متصفح حقيقي مع كل إصدار، وتقارن كل صفحة بمرجعها. لا TypeScript، ولا محدِّدات، ولا سكربتات تُصان. يستطيع مختبر جودة أو مالك منتج أو مصمم تغطية مسار في دقائق.
وهذه نقطة جوهرية يستهين بها المطورون غالباً. في مؤسسات كثيرة، الأشخاص الأكفأ للحكم على الجودة المرئية، المصممون ومختبرو الجودة اليدويون، هم من لا يملكون وصولاً إلى أدوات الاختبار الآلي. لا يتقنون TypeScript. ولا يعرفون ضبط خط CI. وليس هذا عيباً في الكفاءة، بل في الأدوات. ويصحح Delta-QA هذا العيب.
إدارة المراجع مدمجة. عندما يكتشف Delta-QA اختلافاً، يخبركم التقرير أي عنصر تغيّر وكيف. تحكمون على كل اختلاف: مقصود، فيتقدم المرجع؛ عيب، فيُبلَّغ عنه. إنه سير عمل مصمم للفرق، لا لمطور معزول في طرفيته.
يقارن Delta-QA الصفحة كما تفعل العين البشرية. لا يقارن البكسلات: بل يرصد العناصر التي تغيّرت ويسمّيها في التقرير. تباين في التنعيم أو في دون البكسل لا يغير لون عنصر ولا حجمه ولا موضعه: فلا مبرر للإبلاغ عنه، دون أن تضطروا إلى رفع عتبة تسامح عامة. والإيجابيات الكاذبة، هذه الآفة التي تدفع الفرق إلى التخلي عن الاختبار المرئي، تتراجع بوضوح.
ما يفعله Playwright بشكل أفضل من Delta-QA
لنقلها دون مواربة. إن كانت حاجتكم هي الاختبار الوظيفي الشامل، فإن Playwright أفضل من Delta-QA، وليست المنافسة متقاربة حتى.
سيناريوهات المستخدم المعقدة. يتفوق Playwright في محاكاة مسارات مستخدم كاملة والتحقق من منطقها: تسجيل الدخول، وملء نموذج متعدد الخطوات، والتحقق من حسابات، وربط خطوة بنتيجة أخرى. يسجّل Delta-QA المسارات ويعيد تشغيلها، لكنه لا يحل محل التأكيدات الوظيفية المكتوبة بالشيفرة البرمجية.
التفاعل مع واجهات API. يستطيع Playwright اعتراض طلبات الشبكة، ومحاكاة ردود API، وتقليد ظروف شبكة متدهورة. إنه أداة قوية لاختبار التكامل. أما Delta-QA فيقارن مظهر الصفحات. والأهداف مختلفة جوهرياً.
اختبار المنطق التجاري. التحقق من أن سلة تحسب الضرائب بشكل صحيح، وأن نموذج اشتراك يتحقق من أرقام IBAN، وأن مسار اعتماد يتبع قواعد التوجيه الصحيحة، هو الميدان الطبيعي لـ Playwright. مطالبة أداة اختبار مرئي بالتحقق من المنطق التجاري أشبه بمطالبة مصمم ديكور داخلي بفحص السباكة. يستطيع أن يلاحظ وجود تسرب، لكن ليس هذا مهنته.
منظومة المطورين. يندمج Playwright بطبيعة الحال في سير عمل المطور: VS Code وGit وCI/CD وnpm. ويغطي أصلاً Chromium وFirefox وWebKit، بينما يقارن Delta-QA اليوم على Chromium (ودعم Firefox وWebKit مُخطَّط له).
ما يفعله Delta-QA بشكل أفضل من Playwright
تغطية مرئية بلا سكربتات. تغطية مساراتكم الرئيسية في Delta-QA تستغرق وقت تصفحها. أما الحصول على التغطية نفسها مع Playwright فيتطلب كتابة اختبار لكل مسار وصيانته، وإدارة ملفات الخطوط المرجعية في Git، وتثبيت اللقطات بين جهاز المطور وCI.
التعاون بين الفرق. يستطيع مصمم الاطلاع على نتائج Delta-QA، واعتماد التغييرات المرئية، والإبلاغ عن الانحدارات. أما مع Playwright فعلى هذا المصمم نفسه أن يطلب من مطور استخراج اللقطات من تقرير الاختبار. حلقة التغذية الراجعة أطول وأهش، وتتوقف على توفر المطور.
اكتشاف الانحدارات الدقيقة. لأنه يقارن عناصر، يُبرز Delta-QA التغييرات الدقيقة مع قيمتها: مسافة تنتقل من 16px إلى 12px، وظل يختفي، وborder-radius يتغير. أما Playwright مع toHaveScreenshot() وعتبة تسامح مرفوعة لتفادي الإيجابيات الكاذبة فيترك هذه الانحدارات بالذات تمر.
زمن الوصول إلى القيمة. يُغطى أول مسار في دقائق مع Delta-QA، دون مطور. أما مع Playwright، فإعداد حزمة اختبار مرئي متينة يتطلب عدة أيام من التطوير، ثم جهد صيانة مستمراً.
مساراتكم مغطاة دون مئات الخطوط المرجعية لإدارتها في Git. يسجّل Delta-QA سيناريوهاتكم بدون برمجة ويخبركم أي عنصر تغيّر. جرّب Delta-QA مجانًا ←
المقارنة الحقيقية: متى نستخدم ماذا
بدل جدول بالنجوم يبسّط الواقع أكثر من اللازم، إليكم الحالات الملموسة والأداة المناسبة.
أنتم فريق مطورين بـ TypeScript تريدون إضافة اختبار مرئي إلى حزمة Playwright القائمة. خياران. toHaveScreenshot() لتغطية أساسية مجانية في الأداة التي تعرفونها أصلاً، مع قبول صيانة الخطوط المرجعية. أو SDK Vision من Delta-QA: تضيفون vision.check("Payment") حيث يجب التحقق من صفحة، فيقارنها Delta-QA بمرجعها كما تفعل العين البشرية ويسمّي في التقرير العنصر الذي تغيّر، وأي اختلاف لم يُحكَم فيه يُفشل الاختبار، ويعطي سجل CI رابط التقرير.
لديكم فريق جودة مختلط (تقني وغير تقني) وتريدون تغطية مرئية كاملة. Delta-QA هو الخيار الصائب. يستطيع مسؤولو الجودة غير التقنيين المشاركة في عملية التحقق المرئي، والتغطية أوسع، والصيانة مركزية في أداة مخصصة لذلك.
لديكم نظام تصميم وتريدون ضمان اتساقه عبر التطبيق. Delta-QA. يظهر أي تعديل غير مقصود لمتغير CSS على كل صفحات مساراتكم، مع العنصر المتأثر وقيمته الجديدة.
تختبرون مسارات وظيفية معقدة مع تحقق مرئي عند نقاط محددة. Playwright، وربما مع بضعة toHaveScreenshot() استراتيجية، أو مع vision.check() في الخطوات الرئيسية بواسطة SDK Vision.
تريدون الاثنين. وهو الجواب الأكثر واقعية لمعظم الفرق الناضجة. Playwright للوظيفي، وDelta-QA للمظهر. ومع SDK Vision، تعيش اختبارات Playwright لدى مطوريكم وسيناريوهات فريق الجودة بدون برمجة في فضاء Delta-QA نفسه: المراجع نفسها، والتقرير نفسه، والحكم نفسه.
الحجة الاقتصادية: الاستثمار والعائد
Playwright مجاني ومفتوح المصدر. وهي حجة ضخمة، والتقليل من شأنها خطأ. تكلفة Playwright تكلفة هندسية: وقت مطوريكم لكتابة الاختبارات وصيانتها وإدارة الخطوط المرجعية وحل الإيجابيات الكاذبة. وهذه التكلفة غير مرئية في معظم الميزانيات لأنها غارقة في وقت التطوير العام. لكنها حقيقية.
يبدأ العمل مع Delta-QA بحساب مجاني، ثم بخطط مدفوعة مع نمو الاستخدام. وفي المقابل، يقلل التكلفة الهندسية المرتبطة بالاختبار المرئي: لا خطوط مرجعية تُدار في Git، ولا إيجابيات كاذبة في العرض يفرزها مطور كبير. ويتوقف الحساب الاقتصادي على وضعكم: إن كان لدى مطوريكم وقت فراغ، وهو أمر أقرب إلى الوهم في معظم الفرق، فيمكن استيعاب التكلفة الهندسية لـ Playwright. وإن كان فريقكم مشبعاً أصلاً، فهي تكلفة فرصة بديلة حقيقية.
احسبوا لسياقكم: كم ساعة أسبوعياً يقضيها مطوروكم في تحديث الخطوط المرجعية وفرز الإيجابيات الكاذبة؟ هذا الوقت لا يُقضى في تطوير الميزات التي ينتظرها عملاؤكم.
التكامل عملياً
الفرق الأكثر كفاءة التي نلاحظها تستخدم الأداتين، كلاً في مجال تميزها.
يغطي Playwright المسارات الوظيفية الحرجة: مسار التسجيل، ومسار الشراء، ومسارات الأعمال، وتفاعلات API. تتحقق هذه الاختبارات من أن التطبيق يعمل. وتعمل مع كل commit، في CI، وتمنع الدمج إن انكسر شيء.
ويغطي Delta-QA المظهر: المسارات التي يسجّلها مسؤولو الجودة، ومع SDK Vision، الصفحات التي تجعل اختبارات Playwright تتحقق منها. تقول هذه التحققات إن كان التطبيق يبدو سليماً، وتُبلّغ عن انحدارات الواجهة قبل النشر في الإنتاج.
تتكامل الطبقتان. قد ينجح اختبار Playwright، فزر الدفع يعمل، بينما يكتشف Delta-QA أن هذا الزر نفسه صار غير مرئي لأن انحدار CSS جعل نصه أبيض على خلفية بيضاء. أحدهما دون الآخر يترك ثغرات في شبكة الاختبار لديكم.
لماذا الاختيار الحصري فخ
لدى صناعة التقنية ميل مزعج إلى عرض كل قرار كاختيار ثنائي. React أم Vue؟ AWS أم GCP؟ Playwright أم Delta-QA؟ هذا التفكير بمنطق «أو» يتجاهل أن أفضل النتائج تأتي غالباً من «و». عملية مراجعة شيفرة جيدة تجمع بين أدوات تحليل آلية (linters) ومراجعات الأقران. وعملية اختبار جيدة تجمع بين الاختبارات الوظيفية واختبارات الانحدار المرئي.
طرح السؤال «Delta-QA أم Playwright؟» هو قبول لمعضلة زائفة. السؤال الحقيقي: «هل تشمل تغطية اختباراتي البعد المرئي، وهل تغطيه أدواتي الحالية بكفاءة؟» فإن كان الجواب لا، فإن Delta-QA يسدها بطريقتين: بدون برمجة للفريق كله، وداخل اختبارات Playwright لديكم بواسطة SDK Vision.
الأسئلة الشائعة
هل يمكن لـ Delta-QA أن يحل محل Playwright بالكامل؟ لا، ولا ينبغي. يختبر Playwright السلوك الوظيفي لتطبيقكم: النقرات، والنماذج، والتنقلات، والمنطق التجاري. ويختبر Delta-QA المظهر المرئي. إنهما بعدان مختلفان من جودة البرمجيات. إلغاء أحدهما لصالح الآخر كإيقاف تحاليل الدم لأنكم تجرون أشعة سينية.
ألا يكفي Playwright مع toHaveScreenshot() للاختبار المرئي؟
للاستخدام الأساسي على بضع صفحات حرجة، نعم. لكن بمجرد حاجتكم إلى تغطية عشرات الصفحات، مع سير عمل اعتماد يشمل غير المطورين واختلافات يُسمّى فيها كل عنصر تغيّر، تصبح حدود toHaveScreenshot() جلية. وهنا يتولى vision.check() من SDK Vision المهمة، في الاختبار نفسه.
هل تلزم مهارات تقنية لاستخدام Delta-QA؟ لا. وهذه من المزايا الجوهرية للأداة. يستطيع مختبر جودة أو مالك منتج أو مصمم تسجيل سيناريوهاته والحكم عليها دون كتابة سطر واحد من الشيفرة البرمجية. وحده SDK Vision، المخصص لاختبارات Playwright، موجه للمطورين.
كيف يتعامل Delta-QA مع المحتوى الديناميكي (التواريخ، والعدّادات، والإعلانات)؟
يقارن Delta-QA عناصر الصفحة: عدّاد تتغير قيمته يبقى العنصر نفسه، في المكان نفسه، بالنمط نفسه، ويُحكم على فرق المحتوى في التقرير. وفي جانب Playwright، يقترح toHaveScreenshot() الخيار mask لإخفاء مناطق قبل المقارنة.
هل يندمج Delta-QA في خط CI/CD مع Playwright؟
نعم، وهذا دور SDK Vision، لـ Playwright بلغتي TypeScript وJavaScript. تضيفون تحققاً حيث يجب فحص صفحة. يعطي الاختبار فرعه وفرعه الأساسي: فرع جديد يُقارَن بفرعه الأساسي، main مثلاً. وأي اختلاف لم يُحكَم فيه يُفشل اختبار Playwright، ويعطي سجل CI رابط التقرير.
ما زمن إعداد Delta-QA مقابل Playwright للاختبار المرئي؟ Delta-QA: بضع دقائق لتسجيل أول مسار، دون مطور. Playwright visual testing: عدة أيام لكتابة السكربتات وضبط الخطوط المرجعية وحل أولى الإيجابيات الكاذبة وتثبيت حزمة الاختبار. ومع SDK Vision، تتم الإضافة داخل اختباراتكم القائمة، سطراً واحداً لكل صفحة يُراد التحقق منها.
هل يمكن الانتقال تدريجياً من Playwright visual testing إلى Delta-QA؟
نعم. يمكنكم البدء بإضافة vision.check() على صفحاتكم الأكثر حرجاً، إلى جانب toHaveScreenshot() القائمة لديكم، بواسطة SDK Vision. ومع اتساع تغطية Delta-QA، تزيلون تأكيدات toHaveScreenshot() وتدعون اختباراتكم تركز على ما تجيده: الوظيفي.
الخلاصة: حلفاء لا خصوم
إن لم تحتفظوا إلا بشيء واحد من هذا المقال، فليكن هذا: Playwright وDelta-QA ليسا متنافسين. Playwright مرجع مفتوح المصدر للاختبار الوظيفي الشامل. وDelta-QA يغطي البعد المرئي، بدون برمجة للفريق كله، والآن داخل اختبارات Playwright لديكم بواسطة SDK Vision. والجمع بينهما يسد أشيع نقطتين عميائين: العيوب الوظيفية والعيوب المرئية.
إن كنتم تستخدمون Playwright أصلاً وكانت تغطيتكم المرئية تقوم على بضعة toHaveScreenshot() مبعثرة في اختباراتكم، فلديكم ثغرة في عمليتكم. يسدها Delta-QA بسير عمل تحقق في متناول فريقكم كله.
هل أنتم مستعدون لسد النقطة العمياء المرئية في حزمة اختباراتكم؟ أطلقوا أول مقارنة لكم مع Delta-QA، بحساب مجاني ودون بطاقة مصرفية. جرّب Delta-QA مجانًا ←