الاختبار البصري: طريقة تحقّق آلية تقارن المظهر بكسلًا ببكسل لواجهة المستخدم بين حالة مرجعية (baseline) وحالة حالية، لغرض اكتشاف أي انحدار بصري — في الألوان، أو الطباعة، أو التباعد، أو التخطيط — قبل وصوله إلى بيئة الإنتاج.
لنبدأ برأي قد يُفاجئك: مقارنة Delta-QA وPlaywright تشبه إلى حدّ كبير مقارنة سماعة الطبيب بجهاز التصوير بالرنين المغناطيسي. كلاهما يخدم تشخيص المشاكل الصحية، لكنهما لا ينظران إلى نفس الأشياء، ولا يتوجّهان إلى نفس الممارسين، ولا يجيبان على نفس الأسئلة. وضعهما في منافسة مباشرة يعني صياغة المشكلة بشكل خاطئ. أما فهمهما كأداتين متكاملتين فهو الذي يفتح تغطية اختبار لا يستطيع أيّ منهما تقديمها بمفرده.
ومع ذلك، فإن سؤال "Delta-QA أم Playwright؟" يُطرح باستمرار في فرق ضمان الجودة. وهذا أمر طبيعي: عندما تكون ميزانيتك محدودة وقائمة الديون التقنية تفيض، ترغب في معرفة أين تستثمر وقتك. هذا المقال هو الإجابة الصادقة التي تبحث عنها — مع نقاط القوة والقيود، وخصوصًا الحالات التي يتألّق فيها كلّ أداة.
Playwright: رولز رويس الاختبار الوظيفي مفتوح المصدر
Playwright، الذي طوّرته Microsoft، أصبح في بضع سنوات فقط المرجع بلا منازع في الاختبار الشامل end-to-end لفرق التطوير. ويستحق ذلك بجدارة. بنيته متعدّدة المتصفّحات (Chromium وFirefox وWebKit) أصلية، وليست مُلحقة لاحقًا. واجهة TypeScript الخاصة به أنيقة، ومحدّداته قوية، وإدارة الانتظار التلقائي تزيل جزءًا كبيرًا من الاختبارات غير المستقرة التي أثقلت حياة المطورين منذ عصر Selenium. وقد وضعت Microsoft ثقلها خلف هذه الأداة والنتيجة واضحة.
عندما يكتب مطوّر اختبارًا بـ Playwright، فإنه يصف سيناريو وظيفيًا: "انتقل إلى هذه الصفحة، انقر على هذا الزر، تحقّق من ظهور هذا النص". هذا تحقّق سلوكي — هل التطبيق يفعل ما يُفترض أن يفعله؟ وفي هذا المجال، Playwright ممتاز ببساطة. التوثيق شامل، والمجتمع ضخم، والتحديثات متكررة، والتكامل مع CI/CD سلس. لقد أصبح المعيار الذهبي للاختبار الشامل.
يقدّم Playwright أيضًا ميزة مقارنة لقطات الشاشة. يمكنك التقاط screenshot ومقارنته بـ baseline. هذا اختبار بصري من الناحية التقنية. لكنه اختبار بصري كما أنّ الذكاء الاصطناعي الذي يولّد صورًا "يصنع فنًا" — صحيح تقنيًا، محدود جوهريًا.
الاختبار البصري في Playwright: قادر لكنّه أساسي
لنكن دقيقين بشأن ما يقدّمه Playwright في مجال الاختبار البصري. الطريقة toHaveScreenshot() تلتقط screenshot وتقارنه بكسلًا ببكسل مع ملف مرجعي. إذا تجاوز الفرق عتبة قابلة للتهيئة، يفشل الاختبار. إنها تعمل. وهي أيضًا الحد الأدنى الممكن.
تظهر القيود بسرعة بمجرّد محاولة نشر هذا النهج على نطاق واسع.
إدارة الـ baselines يدوية ومُجهدة. كلّ baseline هو ملف صورة مخزّن في مستودع Git. عندما يكون التغيير البصري مقصودًا — لون زر جديد، أو تباعد مُعدَّل في نظام التصميم — يجب تحديث ملفات المرجع يدويًا. في تطبيق يضمّ 50 صفحة و3 دقات عرض، يعني ذلك احتماليًا 150 baseline لإدارتها. وبدون واجهة بصرية لمقارنتها، وبدون سير عمل موافقة رسمي، وبدون سجلّ تاريخي للتغييرات البصرية. كلّ تحديث مقصود يتطلّب تدخلًا يدويًا مرهقًا.
العرض يعتمد على بيئة التنفيذ. لقطات Playwright تختلف باختلاف نظام التشغيل، وإصدار المتصفّح، والخطوط المثبتة، وحتّى دقة الشاشة الافتراضية. اختبار ينجح على Mac المطوّر قد يفشل في حاوية Docker خاصّة بـ CI. الحلّ الرسمي المقترح من فريق Playwright؟ زيادة عتبة التسامح. ما يُعادل إغلاق العينين عن الانحدارات الدقيقة — بالضبط تلك التي يُفترض بالاختبار البصري أن يكشفها. أنت تختار بين كثرة الإيجابيات الكاذبة وتغييرات حقيقية تمرّ دون اكتشاف. كلا الخيارين سيّئ.
لا يوجد سير عمل للموافقة. عندما يفشل اختبار بصري في Playwright، ترى صورة diff في تقرير HTML. لا يوجد زر "الموافقة على هذا التغيير"، ولا إمكانية لمصمم أو لأخصائي ضمان جودة غير تقني للتحقّق من التغيير. الأمر ثنائي: الاختبار ينجح أو يفشل. بالنسبة لمطوّر يعمل بمفرده، قد يكون هذا كافيًا. أمّا بالنسبة لفريق متعدّد التخصّصات يشمل مصممين ومديري منتج ومختبرين يدويين، فهذا عنق زجاجة حقيقي يُعطّل التعاون.
الاختبار عبر المتصفّحات محدود عمليًا. Playwright يدعم Chromium وFirefox وWebKit. لكنّ كلّ متصفّح يولّد لقطات مختلفة قليلًا — تنعيم نص هنا، وعرض تحت البكسل هناك. الحفاظ على baselines منفصلة لكلّ متصفّح يُضاعف عبء الصيانة ثلاث مرّات على الأقلّ بدون أداة مخصّصة لإدارة المقارنة والتحديث. ما يبدأ كمشروع بسيط يتحوّل سريعًا إلى كابوس صيانة.
Delta-QA: الاختبار البصري كتخصّص، وليس كميزة جانبية
صُمِّم Delta-QA من البداية لحلّ مشكلة واحدة، وحلّها جيدًا فحسب: اكتشاف الانحدارات البصرية في واجهات الويب. ليس أداة اختبار وظيفي تقوم أيضًا بالاختبار البصري على الهامش. إنها أداة اختبار بصري متخصّصة بالكامل. نقطة.
هذا التخصّص التام يُغيّر التجربة جذريًا لكلّ من يتعامل مع الأداة.
النهج بدون كود يُزيل الحاجز التقني. مع Delta-QA، تُهيّئ صفحاتك ودقات العرض ومتصفّحاتك، والأداة تلتقط تلقائيًا لقطات الشاشة، وتقارنها بالـ baselines، وتُشير إلى الفروقات. بدون TypeScript، بدون محدّدات CSS، بدون سكربتات للصيانة، بدون أوامر طرفية. بإمكان مختبر ضمان جودة، أو مالك منتج، أو مصمم إطلاق مقارنة بصرية كاملة بنقرات قليلة فقط.
هذه نقطة حاسمة يستهين بها المطوّرون غالبًا. في كثير من المؤسسات، الأشخاص الأكثر تأهيلًا للحكم على الجودة البصرية — المصممون وأخصائيو ضمان الجودة اليدوي — هم من لا يملكون وصولًا إلى أدوات الاختبار الآلي. لا يتقنون TypeScript. لا يعرفون تهيئة مسار CI. هذا ليس نقصًا في الكفاءة، بل هو نقص في الأدوات المساندة. Delta-QA يُصحح هذا النقص ويمنحهم الاستقلالية.
إدارة الـ baselines مدمجة وبصرية. عندما يكشف Delta-QA فرقًا، ترى النسختين جنبًا إلى جنب مع طبقة diff. يمكنك الموافقة على التغيير (baseline جديد)، أو رفضه (انحدار مؤكّد)، أو وسمه للمراجعة. إنه سير عمل مُصمَّم للفرق، وليس لمطوّر معزول في طرفيته.
المقارنة ذكية. Delta-QA لا يكتفي بمقارنة بكسل ببكسل خام. الأداة تتعامل مع المحتوى الديناميكي — التواريخ، والعدّادات، والإعلانات — بالسماح بتحديد مناطق استبعاد. وتتعامل مع تنوّعات تنعيم الحواف بين المتصفّحات دون أن تطلب منك زيادة عتبة التسامح الشاملة. الإيجابيات الكاذبة، تلك الآفة التي تدفع الفرق إلى التخلي عن الاختبار البصري، تتقلّص بشكل جذري.
ما يُتقنه Playwright أفضل من Delta-QA
لنكن صادقين. إذا كانت حاجتك هي الاختبار الوظيفي الشامل end-to-end، فإنّ Playwright متفوّق على Delta-QA، وليست هناك منافسة حتى.
سيناريوهات المستخدم المعقّدة. Playwright يتفوّق في محاكاة رحلات المستخدم الكاملة: تسجيل الدخول، وملء نموذج متعدّد الخطوات، والتنقّل في لوحة تحكّم، والتحقّق من الحسابات المعقّدة. Delta-QA لا يفعل ذلك. ليس دوره، ولم يُصمَّم لهذا الغرض.
التفاعل مع واجهات API. Playwright يمكنه اعتراض طلبات الشبكة، ومحاكاة استجابات API، وتقليد ظروف شبكة متردّية مع تأخيرات عالية. إنها أداة اختبار تكامل قوية وشاملة. أمّا Delta-QA فيقارن صورًا. الأهداف مختلفة جذريًا ولا يتقاطعان إلا في الحدود.
اختبار منطق الأعمال. التحقّق من أنّ سلة التسوق تحسب الضرائب بشكل صحيح، وأنّ نموذج الاشتراك يتحقّق من أرقام IBAN، وأنّ سير عمل الموافقة يتبع قواعد التوجيه الصحيحة — هذا المجال الطبيعي لـ Playwright. أن تطلب من أداة اختبار بصري التحقّق من منطق الأعمال يشبه أن تطلب من مصمّم ديكور داخلي فحص السباكة. يمكنه أن يلاحظ التسريب، لكنّ هذا ليس عمله ولا مجال خبرته.
منظومة المطوّر. Playwright يتكامل بشكل طبيعي في سير عمل المطوّر: VS Code، وGit، وCI/CD، وnpm، وسائر أدوات النظام البيئي للمطوّر. بالنسبة لمطوّر TypeScript، هي أداة تناسب سلسلة أدواته الحالية بدون أي احتكاك. أمّا Delta-QA فيتوجّه إلى جمهور أوسع، ما يعني أنّ تجربة المطوّر البحتة أقلّ تحسينًا — وهذا خيار واعٍ ومتعمّد.
ما يُتقنه Delta-QA أفضل من Playwright
التغطية البصرية على نطاق واسع. تهيئة 50 صفحة × 5 دقات عرض × 3 متصفّحات في Delta-QA تستغرق دقائق. أمّا تحقيق نفس التغطية مع Playwright فيتطلّب كتابة وصيانة عشرات سكربتات الاختبار، وإدارة 750 ملف baseline في Git، وبناء مسار CI ينفّذ كلّ هذا في وقت معقول. الفرق في العبء التشغيلي هائل.
التعاون بين الفرق والتخصّصات. بإمكان مصمم مراجعة نتائج Delta-QA مباشرة في واجهة الأداة، والموافقة على التغييرات البصرية، والإشارة إلى الانحدارات المشبوهة — كلّ ذلك دون الحاجة لفتح سطر أوامر واحد أو طلب المساعدة من مطوّر. مع Playwright، على نفس المصمم أن يطلب من مطوّر استخراج لقطات الشاشة من تقرير الاختبار. حلقة التغذية الراجعة أطول وأكثر هشاشة، وتعتمد كليًا على توفر المطوّر وجدوله الزمني. في الممارسة العملية، هذا يعني تأخيرات تتراوح بين ساعات وأيام.
اكتشاف الانحدارات الدقيقة. Delta-QA مُعايَر لاكتشاف التغييرات البصرية الدقيقة — تباعد يتغيّر ببضع بكسلات، أو ظلّ يختفي، أو border-radius يتطوّر. أمّا Playwright مع toHaveScreenshot() وعتبة تسامح مرتفعة لتجنّب الإيجابيات الكاذبة فيسمح لهذه الانحدارات بالمرور بالضبط.
الوقت حتى تحقيق القيمة. يمكنك الحصول على تغطية بصرية كاملة لتطبيقك مع Delta-QA في أقلّ من ساعة. ليس في يوم. ليس في سبرنت. أقلّ من ساعة. هذا ليس مبالغة تسويقية — بل أمر قابل للقياس. مع Playwright، إعداد مجموعة اختبار بصري متينة يتطلّب عدّة أيام من التطوير، ثمّ جهد صيانة مستمر أسبوعيًا. النسبة بين الاستثمار الأولي والقيمة المحصّلة مختلفة جذريًا لصالح Delta-QA.
المقارنة الحقيقية: متى تستخدم ماذا
بدلًا من جدول تصنيف بالنجوم يُبسّط الواقع بإفراط، إليك المواقف الملموسة والأداة المناسبة لكلّ منها.
أنت فريق مطوّري TypeScript وتريد إضافة اختبار بصري خفيف إلى مجموعة Playwright الحالية. استخدم toHaveScreenshot() من Playwright للصفحات الأكثر أهمية. إنه مجاني، وفي الأداة التي تعرفها بالفعل، وكافٍ لتغطية أساسية. لكن كن واعيًا بالقيود: صيانة الـ baselines ستصبح موضوعًا مع نموّ التطبيق.
لديك فريق ضمان جودة مختلط (تقني وغير تقني) وتريد تغطية بصرية كاملة. Delta-QA هو الخيار الصحيح. بإمكان أعضاء فريق الضمان غير التقنيين المشاركة في عملية التحقّق البصري، والتغطية أوسع، والصيانة مركزية في أداة مُصمَّمة لهذا الغرض.
لديك نظام تصميم وتريد ضمان اتساقه عبر التطبيق بأكمله. Delta-QA. المراقبة البصرية المستمرّة مع baselines مُدارة مركزيًا هي بالضبط حالة الاستخدام التي بُنيت الأداة من أجلها. أيّ تعديل غير مقصود لمتغيّر CSS سيُكتشف في جميع الصفحات المتأثرة، وليس فقط تلك المغطاة بسكربتات Playwright.
تختبر رحلات وظيفية معقّدة مع تحقّق بصري عرضي. Playwright. إذا كانت حاجتك الأساسية التحقّق من أنّ قمع التحويل يعمل بشكل صحيح وتريد أيضًا التأكّد من مظهر الصفحات، فإنّ Playwright مع بعض لقطات الشاشة الاستراتيجية هو الحلّ الأكثر كفاءة.
تريد كليهما. وهذا الجواب الأكثر صدقًا لمعظم الفرق الناضجة. Playwright للاختبار الوظيفي. Delta-QA للاختبار البصري. كلاهما في CI/CD. التغطية كاملة، وكلّ أداة تقوم بما تجيده، ولا أحد يجبر مطرقة على القيام بعمل مفكّ البراغي.
الحجّة الاقتصادية: الاستثمار والعائد
Playwright مجاني ومفتوح المصدر. هذه حجّة قوية لا يمكن دحضها، وسيكون من غير الأمانة التقليل من قيمتها. لكنّ "مجاني" لا يعني "بدون تكلفة". تكلفة Playwright الحقيقية هي تكلفة هندسية خفية: الوقت الذي يقضيه مطوّروك — وخصوصًا الأكثر خبرة بينهم — في كتابة الاختبارات البصرية وصيانتها وإدارة الـ baselines وحلّ الإيجابيات الكاذبة. هذه التكلفة غير مرئية في معظم الميزانيات لأنّها مدفونة في وقت التطوير العام. لكنّها حقيقية جدًا وملموسة — خاصّة عندما تتراكم على مدى أشهر وسنوات.
Delta-QA له تكلفة ترخيص. لكنّه يُزيل التكلفة الهندسية المرتبطة بالاختبار البصري. لا سكربتات للكتابة، ولا baselines لإدارتها يدويًا في Git، ولا إيجابيات كاذبة لفرزها من قبل مطوّر خبير. الحساب الاقتصادي يعتمد على وضعك: إذا كان لدى مطوّريك وقت فراغ — وهو إلى حدّ كبير خيال في معظم الفرق — فإنّ تكلفة Playwright الهندسية قابلة للاستيعاب. وإذا كان فريقك مشبعًا بالفعل — وهو واقع معظم المؤسسات — فإنّ تكلفة Playwright الهندسية هي تكلفة فرصة حقيقية.
احسبها لسياقك الفعلي. مطوّر خبير يقضي ساعتين أسبوعيًا في صيانة سكربتات الاختبار البصري في Playwright — وهو تقدير متحفّظ جدًا — يُكلِّف على مدار سنة أكثر من ترخيص Delta-QA لفريقك بأكمله. وهاتان الساعتان أسبوعيًا هما وقت ثمين لا يُنفق في تطوير الميزات الجديدة التي ينتظرها عملاؤك والتي تُدرّ إيرادات.
التكامل في الممارسة العملية
الفرق الأكثر فعالية التي نُلاحظها تستخدم كلتا الأداتين، كلّ واحدة في مجال تفوّقها.
Playwright يغطّي الرحلات الوظيفية الحرجة: قمع التسجيل، وقمع الشراء، وسير عمل الأعمال، وتفاعلات API. هذه الاختبارات تتحقّق من أنّ التطبيق يعمل كما ينبغي. تعمل عند كلّ commit، وفي CI، وتمنع الدمج إذا انكسر شيء ما.
Delta-QA يغطّي السطح البصري الكامل: جميع الصفحات، جميع دقات العرض، جميع المتصفّحات. هذه الاختبارات تتحقّق من أنّ التطبيق يبدو صحيحًا. تعمل عند كلّ نشر في staging وتُشير إلى الانحدارات البصرية قبل الوصول إلى الإنتاج.
الطبقتان تتكاملان. اختبار Playwright يمكن أن ينجح — زرّ الدفع يعمل من الناحية الوظيفية — بينما Delta-QA يكشف أنّ نفس الزرّ أصبح غير مرئي لأنّ انحدارًا بصريًا جعل نصّه أبيض على خلفية بيضاء. أحدهما بدون الآخر يترك ثغرات في شبكة أمان الاختبار.
لماذا الاختيار الحصري هو فخّ
صناعة التكنولوجيا لديها ميل مُزعج لعرض كلّ قرار كخيار ثنائي حادّ. React أم Vue؟ AWS أم GCP؟ Playwright أم Delta-QA؟ تفكير "أو" يتجاهل حقيقة أنّ أفضل النتائج غالبًا ما تأتي من "و". نظام مراقبة جيد يجمع بين تنبيهات آلية وإشراف بشري دقيق. عملية مراجعة كود جيدة تجمع بين أدوات فحص آلية ومراجعات أقران معمّقة. عملية اختبار جيدة تجمع بين اختبارات وظيفية آلية واختبارات بصرية آلية — لكلّ منها مجالها وأداتها.
سؤال "Delta-QA أم Playwright؟" هو قبول لمعضلة زائفة. السؤال الحقيقي هو: "هل تغطية اختباري تشمل البُعد البصري، وهل أدواتي الحالية تغطّيه بفعالية؟" إذا كان الجواب لا، فإنّ Delta-QA هو الطريقة الأسرع والأكثر سهولة لسدّ تلك الفجوة — سواء كنت تستخدم Playwright أو Cypress أو Selenium أو لا تملك إطار اختبار على الإطلاق.
الأسئلة الشائعة
هل يمكن لـ Delta-QA أن يحلّ محلّ Playwright بالكامل؟
لا، ولا ينبغي له ذلك أبدًا. Playwright يختبر السلوك الوظيفي لتطبيقك — النقرات والنماذج والتنقّل ومنطق الأعمال. Delta-QA يختبر المظهر البصري والعناصر الهيكلية. هذان بُعدان مختلفان ومتكاملان لجودة البرمجيات. إزالة أحدهما لصالح الآخر تشبه التوقف عن تحاليل الدم لأنّك تجري أشعة سينية — كلا الفحصين ضروريان لتكوين صورة كاملة.
أليس Playwright مع toHaveScreenshot() كافيًا للاختبار البصري؟
للاستخدام الأساسي على بضع صفحات حرجة فقط، نعم. لكن بمجرّد أن تحتاج إلى تغطية عشرات الصفحات، وعدّة دقات عرض، وعدّة متصفّحات، مع سير عمل موافقة رسمي يشمل غير المطوّرين من مصممين ومديري منتج، تصبح قيود toHaveScreenshot() واضحة وضوح الشمس. إنها سكّين سويسري تحتوي على مفكّ براغي — مفيدة في الحالات الطارئة، لكنّها غير كافية إطلاقًا لتجميع أثاث كامل أو لبناء عملية اختبار بصري جادّة.
هل تحتاج مهارات تقنية لاستخدام Delta-QA؟
لا. إنها إحدى المزايا الأساسية للأداة. بإمكان مختبر ضمان جودة، أو مالك منتج، أو مصمم تهيئة Delta-QA واستخدامه دون كتابة سطر كود واحد. الواجهة مُصمَّمة لأشخاص يعرفون كيف يحكمون على الجودة البصرية لواجهة، وليس لمن يعرفون كتابة TypeScript.
كيف يتعامل Delta-QA مع المحتوى الديناميكي (التواريخ، والعدّادات، والإعلانات)؟
يمكنك تحديد مناطق استبعاد في تهيئاتك. تُتجاهل هذه المناطق أثناء المقارنة، ممّا يُزيل الإيجابيات الكاذبة الناتجة عن محتوى يتغيّر بشكل مشروع بين اللقطات. هذه ميزة أساسية لا يقدّمها Playwright toHaveScreenshot() بشكل أصلي — يجب إخفاء العناصر عبر الكود قبل الالتقاط.
هل يتكامل Delta-QA في مسار CI/CD مع Playwright؟
نعم. Delta-QA يمكنه العمل في مسار CI/CD بالتوازي مع Playwright. كلتا الأداتين تُولّدان تقارير مستقلة. يمكنك تهيئة مسارك لمنع النشر إذا اكتشف أيّ منهما مشكلة. هذا هو النهج الذي نوصي به لتحقيق أقصى تغطية.
ما هو وقت الإعداد لـ Delta-QA مقابل Playwright للاختبار البصري؟
Delta-QA: أقلّ من ساعة لتغطية تطبيقك بالكامل بصريًا. اختبار Playwright البصري: عدّة أيام لكتابة السكربتات، وتهيئة الـ baselines، وحلّ الإيجابيات الكاذبة الأولية، وتثبيت مجموعة الاختبار. الفرق كبير، خاصّة إذا لم يكن لدى فريقك مطوّر متاح لكتابة وصيانة سكربتات الاختبار.
هل يمكن الانتقال تدريجيًا من اختبار Playwright البصري إلى Delta-QA؟
بالتأكيد. يمكنك البدء بإضافة Delta-QA على صفحاتك الأكثر أهمية مع الحفاظ على اختبارات Playwright الحالية. مع توسّع تغطية Delta-QA، يمكنك إزالة تأكيدات toHaveScreenshot() من سكربتات Playwright وتركها تركّز على ما تُتقنه أفضل: الاختبار الوظيفي.
الخاتمة: حلفاء، وليسوا منافسين
إذا استوعبت شيئًا واحدًا فقط من هذا المقال، فليكن هذا: Playwright وDelta-QA لا يتنافسان على الإطلاق. Playwright أفضل أداة مفتوحة المصدر للاختبار الوظيفي الشامل end-to-end — ولا منافس حقيقي في هذا المجال. Delta-QA هو الوسيلة الأكثر سهولة وشمولًا لتغطية البُعد البصري لتطبيقك بالكامل. دمجهما معًا يُزيل النقطتين العمياوتين الأكثر شيوعًا في عمليات ضمان الجودة: الأخطاء الوظيفية من جهة، والأخطاء البصرية من جهة أخرى. تغطية كاملة، وفريق متكامل، ونتائج موثوقة.
إذا كنت تستخدم بالفعل Playwright وتعتمد تغطيتك البصرية على بعض استدعاءات toHaveScreenshot() المبعثرة هنا وهناك في اختباراتك، فثمّة ثغرة واضحة في عمليتك. Delta-QA يسدّها في أقلّ من ساعة، دون تعبئة مطوّريك، ومع سير عمل تحقّق متاح لفريقك بأكمله — تقنيين وغير تقنيين.