الاختبار المرئي للمكوّنات (component visual testing): طريقة تحقق آلية تقوم على عرض مكوّنات واجهة المستخدم بمعزل عن سياق الصفحة الكاملة، ومقارنة مظهرها بحالة مرجعية معتمدة، بهدف اكتشاف الانحدارات المرئية على مستوى نظام التصميم قبل أن تنتقل إلى صفحات الإنتاج.
ثمة سؤال تتجنب فرق الواجهات الأمامية طرحه بعناية: «مكوّناتنا مختبرة مرئياً في Storybook، لكن هل صفحاتنا في الإنتاج مختبرة أيضاً؟». والجواب في أغلب الحالات: لا. وهذه الثغرة مكلفة، لأن العيوب المرئية التي تصل إلى مستخدميكم لا تعيش في Storybook، بل في الصفحات الحقيقية، بالبيانات الحقيقية والتفاعلات الحقيقية وتركيبات المكوّنات الحقيقية.
Chromatic أداة ممتازة لاختبار المكوّنات المعزولة. أما Delta-QA فمصمم لاختبار الصفحات الكاملة. للتعرف على الاختبار المرئي عموماً، راجعوا دليل الانحدار المرئي. هما ليسا منافسين بالمعنى الدقيق، بل أداتان تنظران إلى المشكلة نفسها من ارتفاعين مختلفين. لكن إن كان عليكم اختيار واحدة فقط، أو أردتم فهم ما تقدمه كل منهما، فهذه المقارنة تدخل في الموضوع مباشرة.
جميع مقارناتنا، وفق معايير قابلة للتحقق: البدائل والمقارنات.
Chromatic يتحقق من مكوّنات معزولة، فمن يختبر صفحاتكم الحقيقية في الإنتاج؟ يغطيها Delta-QA بدون كتابة الشيفرة البرمجية، بحساب مجاني ودون بطاقة مصرفية. جرّب Delta-QA مجانًا ←
Chromatic: حارس نظام التصميم
Chromatic، الذي أنشأه القائمون على صيانة Storybook، هو الامتداد الطبيعي لمنظومة Storybook في الاختبار المرئي. ولنظرة شاملة على الاختبار المرئي المطبق على أنظمة التصميم، راجعوا دليلنا المخصص. فكرته بارعة في منطقها: لقد عرّفتم مكوّناتكم في Storybook بحالاتها المختلفة (stories). يلتقط Chromatic لقطة شاشة لكل story عند كل commit، ويقارنها بالخط المرجعي (baseline)، ثم ينبّه إلى التغيرات.
إنه سير عمل متكامل تماماً للفرق التي تعمل بأنظمة التصميم. يعرّف مصممكم زراً بأربعة أشكال (primary وsecondary وdisabled وloading). ينفذ مطورّكم هذه الأشكال وينشئ الـ stories المقابلة. وعند كل تغيير في الشيفرة البرمجية، يتحقق Chromatic من أن الأشكال الأربعة لم تتراجع بصرياً. فإذا تغيّر border-radius للزر عن غير قصد، يكتشفه Chromatic قبل أن يجري أحد مراجعة الشيفرة.
وتوفر الأداة أيضاً ميزة مراجعة الواجهة (UI Review) التي تتيح للمصممين والمطورين اعتماد التغييرات بصرياً قبل الدمج. إنها في جوهرها مراجعة شيفرة مرئية، وهي مفيدة فعلاً للحفاظ على اتساق نظام التصميم.
حتى 10/2026، لم يعد Chromatic مقتصراً على الـ stories: فهو ينفذ أيضاً اختبارات التفاعل وإمكانية الوصول، ويعتمد على اختبارات Playwright أو Cypress أو Vitest القائمة، ويعرض اللقطات في أربعة متصفحات (Chrome وFirefox وSafari وEdge). ويقدم نفسه كذلك حاجزاً وقائياً للواجهات التي تكتبها وكلاء الذكاء الاصطناعي، مع خادم MCP موثّق يمدّهم بسياق المكوّنات المعتمدة.
النقطة العمياء في Chromatic: العالم الحقيقي
هذه هي المشكلة التي لا يحلها Chromatic (لا لقصور في الجودة، بل بسبب خيار معماري): المكوّنات المعزولة لا تتصرف مثل الصفحات المجمّعة.
الزر المختبر بمعزل في Storybook يُعرض في بيئة مضبوطة: نافذة عرض (viewport) ثابتة، لا جيران، لا سياق CSS موروث، لا بيانات ديناميكية، لا تفاعل مع مكوّنات أخرى. وهذا بالضبط ما يجعل الاختبار موثوقاً على مستوى المكوّن. لكنه ما يجعله أعمى أيضاً عن مشكلات التجميع.
ما الذي ينكسر بصرياً في الإنتاج؟ نادراً ما يكون مكوّناً معزولاً. ما ينكسر هو التركيبة. مكوّن ترويسة يتداخل مع مكوّن التنقل لأن قيمة z-index تغيّرت. شبكة منتجات تختل محاذاتها لأن مكوّن البطاقة تلقى margin إضافياً. نموذج يفيض عن حاويته لأن تسمية (label) أطول من المتوقع في لغة أخرى. تذييل يصعد فوق المحتوى الرئيسي لأن قسماً وسيطاً فقد حده الأدنى للارتفاع.
هذه العيوب غير مرئية في Storybook. كل مكوّن، على حدة، سليم بصرياً. المشكلة في تجميعها. وChromatic، بحكم تصميمه، لا يختبر التجميع: إنه يختبر اللبنات لا البناء.
أما Delta-QA فيختبر البناء. تسجّلون مساراً على موقعكم بدون برمجة، وتعيد الأداة تشغيله في متصفح حقيقي عند كل إصدار، بجميع المكوّنات مجمّعة، بأنماطها الموروثة وتفاعلاتها وبياناتها. تُقارن كل صفحة بمرجعها كما تفعل العين البشرية: يذكر التقرير أي عنصر تغيّر (زر تحوّل من الأزرق إلى الأخضر، هامش تحرك). إنه اختبار الواقع، لا اختبار مخطط المهندس المعماري.
الفجوة بين Storybook والإنتاج
ثمة فرق بنيوي بين ما يعرضه Storybook وما يعرضه الإنتاج، ونادراً ما يُناقش هذا الفرق.
البيانات. في Storybook، تتلقى مكوّناتكم بيانات تجريبية (mock) تُنتقى بعناية لتكون تمثيلية وتناسب التصميم. أما في الإنتاج فتتلقى بيانات حقيقية: اسم منتج من 150 حرفاً لم يكن متوقعاً، صورة بنسبة أبعاد غير معتادة، سعر بعدد خانات عشرية متغير، قائمة تصنيفات تملأ ثلاثة أسطر بدل سطر واحد. هذه البيانات الحقيقية تخلق حالات مرئية لا يعيد Storybook إنتاجها أبداً.
الأنماط الموروثة. في Storybook يُعرض كل مكوّن في بيئة CSS معزولة نظيفة نسبياً. وفي الإنتاج ترث المكوّنات الأنماط العامة، وعمليات إعادة ضبط CSS (resets)، والسمات، والتجاوزات السياقية، وأحياناً أنماط أطراف ثالثة (أدوات التحليلات، روبوتات الدردشة، شريط ملفات تعريف الارتباط). قد يكون المكوّن مثالياً في Storybook ومكسوراً بصرياً في الإنتاج بسبب تعارض في الأنماط لا يعيد أي story إنتاجه.
الحالات الديناميكية. يختبر Storybook حالات محددة سلفاً، هي التي ارتأى المطور توثيقها. وفي الإنتاج تمر المكوّنات بحالات وسيطة، وحالات خطأ غير متوقعة، وتركيبات حالات لم يفكر أحد في اختبارها. النموذج الذي يجري التحقق منه، والزر داخل حاوية flex تتغير أبعادها، وبطاقة المنتج التي يضيف عرض ترويجي شارة إليها: كل تركيبة اختبار مرئي لا يغطيه Storybook.
يختبر Delta-QA ما يراه مستخدموكم فعلاً. لا ما يعدكم Storybook بأنهم سيرونه.
بدون برمجة مقابل Storybook: مسألة الجمهور
يتوجه Chromatic إلى مطوري الواجهات الأمامية الذين يعملون مع Storybook. وهذا جمهور مشروع ومهم. لكنه جمهور محدود.
لاستخدام Chromatic، يجب أن تكون لديكم اختبارات مكتوبة بالشيفرة البرمجية: stories في Storybook، أو اختبارات Playwright أو Cypress أو Vitest. ويجب أن تعرفوا كتابتها. ويجب أن تفهموا مفهومي الخط المرجعي واللقطة المرئية. ويجب أن تكونوا مرتاحين لسير عمل قائم على طلبات السحب (pull requests) والتكامل المستمر. باختصار: يجب أن تكونوا مطوري واجهات أمامية.
ماذا عن مدير الجودة الذي يريد التحقق من صفحة قبل الإصدار؟ لا يستطيع استخدام Chromatic مباشرة. وماذا عن مالك المنتج الذي يلاحظ مشكلة مرئية أثناء الاستلام؟ لا يستطيع إطلاق اختبار. والمصمم الذي يريد مقارنة التصميم بالنتيجة في الإنتاج؟ لا يملك وصولاً إلى سير عمل Chromatic دون المرور بمطور.
يفتح Delta-QA الاختبار المرئي لكل الفريق. لا حاجة إلى Storybook. لا شيفرة برمجية. ولا خط CI/CD يجب فهمه. تتصفحون موقعكم كما يفعل مستخدم، ويسجّل Delta-QA السيناريو، ويعيد تشغيله في النسخة التالية، وتقرؤون التقرير. يتحقق مسؤول الجودة من مسار الطلب قبل الإصدار. ويتأكد مالك المنتج من أن تعديلاً لم يكسر شيئاً في مكان آخر. وكل واحد مستقل.
وللمطورين الذين يريدون التحقق من صفحاتهم انطلاقاً من اختبارات Playwright في التكامل المستمر، لدى Delta-QA الآن SDK هو SDK Vision: سطر واحد لكل صفحة يُراد التحقق منها، وأي اختلاف لم يُحكَم فيه يُفشل الاختبار.
هذا ليس عداءً للتقنية. إنه إقرار بأن الجودة المرئية تعني الجميع، وبأن الأدوات ينبغي أن تعكس هذه الحقيقة.
المكوّنات مقابل الصفحات: مستويان متكاملان للاختبار
بدل أن نضع Chromatic وDelta-QA في مواجهة، من الأنسب اعتبارهما مستويين في استراتيجية اختبار مرئي متكاملة.
مستوى المكوّن (Chromatic): التحقق من أن كل لبنة في نظام التصميم مطابقة بصرياً لمواصفاتها. إنه اختبار الوحدة للجانب المرئي. يكتشف الانحدارات على أدق مستوى، وأبكر ما يمكن في دورة التطوير (حتى قبل الدمج).
مستوى الصفحة (Delta-QA): التحقق من أن الصفحات المجمّعة، ببياناتها الحقيقية وأنماطها المتتابعة، سليمة بصرياً. إنه اختبار التكامل للجانب المرئي. يكتشف مشكلات التجميع وتعارضات الأنماط والانحدارات التي لا توجد إلا في سياق الصفحة الكاملة.
الفريق الذي يجمع الاثنين يحصل على تغطية مرئية ممتازة. يكتشف Chromatic انحدارات المكوّنات مبكراً، ويكتشف Delta-QA انحدارات الصفحات. وتصبح شبكة الأمان مزدوجة.
لكن إن لم تستطيعوا اختيار سوى واحدة (لقيد في الميزانية أو الوقت أو الموارد)، يصبح السؤال: أي مستوى اختبار يحمي مستخدميكم أكثر؟ والجواب، دون لبس، هو مستوى الصفحة. لأن مستخدميكم لا يرون مكوّنات، بل يرون صفحات.
سحابي أم On-Premise: إلى أين تذهب لقطاتكم؟
إلى جانب نموذج المكوّنات/الصفحات، ثمة فرق معماري يثقل كثيراً لدى بعض المؤسسات: مكان وجود لقطات الشاشة.
Chromatic خدمة سحابية. تُرسل لقطاتكم وتُخزَّن على بنية Chromatic التحتية؛ وحتى 10/2026، لا تذكر قائمة أسعاره نشراً ذاتي الاستضافة، حتى في خطة Enterprise (التي تقدم SSO واتفاقية مستوى الخدمة وإعدادات الاحتفاظ بالبيانات). بالنسبة لمعظم المشاريع العامة، لا يمثل هذا مشكلة. لكن في تطبيق داخلي، أو واجهة إدارية تحتوي بيانات عملاء، أو مؤسسة تخضع لقيود تنظيمية صارمة، قد يكون مجرد خروج لقطات الواجهة من نطاق الشركة عائقاً.
يقدم Delta-QA عرض On-Premise يُثبَّت عبر Docker على بنيتكم التحتية: لا تغادر لقطاتكم شبكتكم، ويمكن تقييم العرض عبر POC مجاني لمدة شهر. إنه المنطق نفسه الخاص بسيادة البيانات المفصّل أدناه، لكن مصاغاً على مستوى المعمارية: البيانات تبقى مقابل البيانات تخرج.
النموذج الاقتصادي: الفوترة بحسب اللقطة
يفوتر Chromatic بحسب عدد اللقطات (snapshots) شهرياً. لقطة واحدة = story واحد، ومتصفح واحد، ودقة واحدة. مع 200 مكوّن بثلاثة stories لكل منها على متصفحين، يصبح لدينا 1 200 لقطة لكل build. وعشرون build يومياً (فريق نشط) تعني 720 000 شهرياً.
حتى 10/2026، تقدم الخطة المجانية 5 000 لقطة مفوترة شهرياً، وهي تكفي لتغطية نطاق أول، لكنها تنفد بسرعة عندما يكبر نظام التصميم. وهذه الخطة المجانية مقتصرة على Chrome: أما الاختبار عبر المتصفحات (Firefox وSafari وEdge) فيبدأ من خطة Starter بسعر 179 دولاراً شهرياً مقابل 35 000 لقطة. وتبلغ خطة Pro سعر 399 دولاراً شهرياً مقابل 85 000 لقطة، وتُفوتر كل لقطة إضافية بـ 0,008 دولار، وخطة Enterprise بعرض سعر. ويخفف TurboSnap الفاتورة: فلا يُعاد التقاط سوى الاختبارات التي مسّها تغيير في الملفات، وتُحتسب الأخرى بقدر أقل من الحصة. عملياً، 180 story × 3 دقة = 540 لقطة لكل build، أي 9 builds بالكاد قبل استنفاد الحصة المجانية. وهذا يخلق التوتر نفسه كما لدى Percy: تتناسب تغطية الاختبار عكسياً مع الميزانية. وبدون TurboSnap، ينتهي الأمر بالفرق إلى تقليص الـ stories المختبرة أو وتيرة الـ builds للبقاء ضمن حصتها.
يبدأ العمل مع Delta-QA بحساب مجاني، دون بطاقة مصرفية. وتُحسب تغطيته بالمسارات والخطوات المتحقق منها، لا بالـ stories مضروبة في المتصفحات والدقات.
Chromatic يختبر المكوّنات المعزولة، فماذا عن صفحاتكم الكاملة؟ يغطيها Delta-QA بدون برمجة ودون بطاقة مصرفية. جرّب Delta-QA مجانًا ←
ما يفعله Chromatic ولا يفعله Delta-QA
تقتضي الشفافية الاعتراف بنقاط القوة الفريدة في Chromatic.
المراجعة التعاونية للواجهة. يتيح سير عمل Chromatic للمطورين والمصممين اعتماد تغييرات المكوّنات بصرياً ضمن طلب السحب. إنها عملية مراجعة متكاملة لا يوجد لها مقابل مطابق تماماً في Delta-QA.
اختبار جميع حالات المكوّن. إن كان لزركم 12 شكلاً (الحجم، واللون، والحالة، والسمة)، فإن Chromatic يختبرها كلها بانتظام. أما اختبار هذه الأشكال الـ 12 على مستوى الصفحة فيتطلب إيجاد 12 صفحة مختلفة تظهر فيها، وهذا غير ممكن دائماً.
تعدد المتصفحات. يلتقط Chromatic اختباراتكم على Chrome وFirefox وSafari وEdge (ابتداءً من خطة Starter). أما Delta-QA فيقارن اليوم على Chromium؛ ودعم Firefox وWebKit مُخطَّط له.
التكامل الأصلي مع Storybook. Chromatic من صنع مبتكري Storybook. والتكامل بأعمق ما يكون: اكتشاف تلقائي للـ stories الجديدة، وإعداد أدنى، وسير عمل سلس. إنها ميزة حقيقية إن كان Storybook محور سير عمل تطوير الواجهات لديكم.
التوثيق المرئي الحي. يحتفظ Chromatic بسجل مرئي لكل مكوّن عبر الزمن. إنها مكتبة تصميم حية تعرض تطور كل مكوّن، وهي ميزة ثمينة لأنظمة التصميم.
ما يقدمه Delta-QA ولا يغطيه Chromatic
اختبار الواقع. صفحات الإنتاج، بالبيانات الحقيقية، والأنماط الموروثة الحقيقية، والتفاعلات الحقيقية بين المكوّنات. لا مثالية Storybook النظيفة، بل العالم كما هو.
سهولة الوصول للجميع. يستطيع أي عضو في الفريق إطلاق اختبار مرئي. لا حاجة إلى أن يكون مطوراً، ولا إلى معرفة Storybook، ولا إلى الوصول إلى خط CI. إنه إتاحة الاختبار المرئي للجميع.
الاستقلال التقني. يعمل Delta-QA أياً كانت حزمة الواجهة الأمامية لديكم. React أو Vue أو Angular أو Svelte أو WordPress أو Shopify أو موقع ساكن أو تطبيق قديم بـ jQuery، لا يهم. ما دام يُعرض في متصفح، يختبره Delta-QA. أما Chromatic فيعتمد على اختبارات مكتوبة بالشيفرة البرمجية (Storybook وPlaywright وCypress وVitest)، أي على مشروع واجهة أمامية مجهّز لذلك.
سيادة البيانات. مع عرض On-Premise، تجري المقارنة على بنيتكم التحتية ولا تُرسل أي لقطة إلى طرف ثالث. للتطبيقات الداخلية والبيانات الحساسة والمؤسسات الخاضعة لتنظيمات صارمة.
تقرير كما تراه العين البشرية. يُربط كل اختلاف بعنصر من الصفحة ويوصف بوضوح: اللون أو الهامش أو الخط أو الموضع. تعرفون ما ينبغي النظر إليه دون تفسير صورة فروقات.
السيناريو المثالي: الاثنان معاً
إن كان فريقكم يستخدم Storybook أصلاً ولديه ميزانية لـ Chromatic، فالجمع بين الأداتين هو الاستراتيجية الأمتن.
يراقب Chromatic مكوّناتكم على مستوى نظام التصميم. يُتحقق بصرياً من كل تغيير في النمط، وكل اختلاف، وكل حالة. وتُكتشف الانحدارات أثناء التطوير، قبل أن تصل الشيفرة البرمجية إلى الفرع الرئيسي.
ويراقب Delta-QA صفحاتكم في الإنتاج (أو في بيئة staging). وتُكتشف مشكلات التجميع وتعارضات الأنماط والعيوب التي لا تظهر إلا في السياق الحقيقي قبل أن يراها المستخدمون.
معاً، تحصلون على تغطية مزدوجة: اللبنات من جهة، والمسارات المجمّعة من جهة أخرى.
السيناريو العملي: أداة واحدة فقط
إن كان عليكم اختيار أداة واحدة (لأن الميزانية محدودة، أو لأن الفريق صغير، أو لأنكم تريدون البدء ببساطة)، فإن السؤال يؤول إلى هذا: ما الذي يحمي مستخدميكم أكثر؟
مستخدموكم لا يرون مكوّنات Storybook لديكم. إنهم يرون صفحاتكم. يتفاعلون مع صفحاتكم. ويكوّنون رأيهم في منتجكم وهم ينظرون إلى صفحاتكم. مكوّن مثالي في Storybook لكنه مكسور في الصفحة المجمّعة هو مكوّن مكسور من وجهة نظر المستخدم.
يختبر Delta-QA ما يراه مستخدموكم. الأمر بهذه البساطة.
هل أنتم مستعدون لاختبار الصفحات التي يراها مستخدموكم فعلاً؟ أطلقوا أول مقارنة لكم مع Delta-QA، بحساب مجاني ودون بطاقة مصرفية. جرّب Delta-QA مجانًا ←
الأسئلة الشائعة
هل يعمل Chromatic بدون Storybook؟
نعم. حتى 10/2026، يلتقط Chromatic أيضاً صفحات اختبارات Playwright أو Cypress أو Vitest لديكم، إضافة إلى stories في Storybook. لكن لا بد من اختبارات مكتوبة بالشيفرة البرمجية: فهي التي تحدد ما يُلتقط. أما Delta-QA فينطلق من سيناريو مسجَّل بدون برمجة، أياً كانت الحزمة التي تنتج صفحاتكم؛ ولاختبارات Playwright، يقترح SDK Vision.
هل يكفي اختبار المكوّنات في Storybook لضمان الجودة المرئية؟
لا. المكوّنات المختبرة بمعزل لا تعيد إنتاج الظروف الحقيقية لصفحة مجمّعة: وراثة الأنماط، والبيانات الديناميكية، والتفاعلات بين المكوّنات، وأنماط الأطراف الثالثة. يتحقق Chromatic من سلامة لبناتكم. ويتحقق Delta-QA من سلامة التجميع. والمستويان ضروريان لتغطية كاملة.
هل يكتشف Chromatic مشكلات التجاوب (responsive)؟
نعم، في حدود ما يعرضه Storybook. يمكنكم ضبط stories لأحجام نوافذ عرض مختلفة، وسيختبرها Chromatic. لكن مشكلات التجاوب الخاصة بصفحة مجمّعة (عنصر يفيض عند اجتماعه بعناصر أخرى، وتخطيط ينكسر مع بيانات حقيقية طويلة) لن تُكتشف. أما Delta-QA فيقارن الصفحة المجمّعة في متصفح حقيقي، ببياناتها الحقيقية.
ماذا تغطي الخطة المجانية في Chromatic؟
حتى 10/2026، تقدم الخطة المجانية في Chromatic 5 000 لقطة مفوترة شهرياً، على Chrome فقط، وهو ما يغطي بضع عشرات من المكوّنات مع builds متفرقة. وبمجرد أن يزداد عدد المكوّنات أو وتيرة الـ builds، تُستنفد الحصة سريعاً. مشروع بـ 100 مكوّن، و3 stories لكل مكوّن، وbuildين يومياً يستهلك نحو 18 000 لقطة شهرياً بدون TurboSnap.
هل يمكن استخدام Delta-QA لاختبار مكوّنات معزولة؟
Delta-QA مُحسَّن للصفحات الكاملة لا للمكوّنات المعزولة. إن كانت لديكم بيئة تُعرض فيها مكوّناتكم فرادى على عناوين URL يمكن الوصول إليها (مثل Storybook منشور)، فبإمكانكم من الناحية التقنية استخدام Delta-QA لمقارنتها. لكن هذه ليست حالة استخدامه الرئيسية. ولاختبار المكوّنات المعزولة، يبقى Chromatic الأداة المرجعية.
كيف يتعامل Delta-QA مع أنظمة التصميم إن لم يكن على مستوى المكوّن؟
يتحقق Delta-QA من الاتساق المرئي لنظام التصميم لديكم على المستوى الأهم: في الصفحات التي تستخدمه. فإذا كسر تغيير في نظام التصميم تخطيط عشر صفحات، يكتشفه Delta-QA مباشرة. إنه اختبار شامل (end-to-end) لنظام التصميم، يكمّل اختبار الوحدة في Chromatic.