الإزاحة لليسار والإزاحة لليمين

لماذا يهم

العيب الذي يُكتشف في مراجعة القصة يكلّف محادثة. أما بعد الإصدار فيكلّف العيب نفسه إصلاحاً وإعادة نشر ووقتاً من فريق الدعم، وأحياناً مبالغ مستردة وشيئاً من ثقة المستخدمين. والإزاحة لليسار تمنع العيوب وتكشف ما تبقى منها والتغيير ما زال صغيراً.

لكن لا توجد بيئة اختبار تطابق بيئة الإنتاج تماماً: الحركة الحقيقية والبيانات الحقيقية وكل جهاز وكل خدمة خارجية. بعض الإخفاقات لا يظهر إلا هناك، ومن دون ممارسات الإزاحة لليمين يكون المستخدمون أول من يلاحظها. وبالنسبة إلى المختبِر، لم يعد الاختبار مرحلة في النهاية، بل صار عملاً يمتد على دورة الحياة كلها.

الإزاحة لليسار: اختبر قبل كتابة الكود وأثناءها

يصف منهج ISTQB للمستوى التأسيسي (CTFL الإصدار ⁦4.0⁩) الإزاحة لليسار بأنها اختبار في وقت أبكر، دون انتظار كتابة الكود أو دمج المكوّنات، ويؤكد أنها لا تعني إهمال الاختبار في المراحل اللاحقة. وهي الصورة العملية لمبدأ أن الاختبار المبكر يوفّر الوقت والمال. وإلى جانب الممارسات أدناه، يذكر المنهج التكامل المستمر (CI)، والأفضل منه التسليم المستمر (CD)، لما يوفّرانه من تغذية راجعة سريعة على كل تغيير كما في الدرس السابق، وبدء الاختبار غير الوظيفي، كاختبار الأداء، من مستوى المكوّن حيثما أمكن. ويذكر ثمنها أيضاً: تدريباً وجهداً إضافيين في البداية يُتوقع أن يُستردّا لاحقاً، وتحتاج الإزاحة لليسار إلى أصحاب مصلحة مقتنعين بها ومساندين لها.

• المراجعات المبكرة: يراجع المختبِرون قصص المستخدم ومعايير القبول والتصاميم من منظور الاختبار. وهذا اختبار ساكن يكشف الغموض والنقص والتناقض قبل أن يوجد أي كود.
• التطوير الموجَّه بالاختبار (TDD): يكتب المطوّر اختبار وحدة يفشل، ثم يكتب من الكود ما يكفي لنجاحه فقط، ثم يعيد هيكلة الاثنين (Refactoring)، أي يحسّن بنيتهما دون أن يغيّر ما يفعلانه.
• التطوير الموجَّه باختبارات القبول (ATDD): تُشتق اختبارات القبول من معايير القبول قبل بناء الميزة. وفي التطوير الموجَّه بالسلوك (BDD) تُكتب هذه الأمثلة بصيغة Given/When/Then، كالسيناريوهين أدناه.
• التحليل الساكن: أدوات تفحص الكود المصدري دون تشغيله، وتُبلغ عن المتغيرات غير المعرَّفة والكود الذي لا يمكن الوصول إليه ومخالفات معايير البرمجة وبعض الثغرات الأمنية، وتعمل عادةً على كل طلب دمج ضمن التكامل المستمر (CI).

Feature: رمز الخصم عند إتمام الشراء

  Scenario: رمز نسبة مئوية صالح يخفض الإجمالي قبل الضريبة
    Given سلة إجماليها 150.00 ريال قبل ضريبة القيمة المضافة
    And الرمز الفعال "SAVE10" يمنح خصم 10%
    When يطبّق المتسوق الرمز "save10"
    Then يكون الخصم 15.00 ريال
    And يكون الإجمالي قبل الضريبة 135.00 ريال

  Scenario: رمز منتهي الصلاحية يُرفض
    Given انتهت صلاحية الرمز "WINTER25" أمس
    When يطبّق المتسوق الرمز "WINTER25"
    Then تظهر الرسالة «انتهت صلاحية هذا الرمز»
    And لا يتغير الإجمالي

جرّبها: مولّد معايير القبول جرّبها: المتطلبات ← حالات اختبار

الإزاحة لليمين: واصل الاختبار بعد الإصدار

الإزاحة لليمين مصطلح شائع في الصناعة وليس من مصطلحات المستوى التأسيسي في ISTQB، وبعض الفرق تسمّي جزءاً منه «الاختبار في الإنتاج». فبيئة الإنتاج وحدها فيها الحركة الحقيقية والبيانات الحقيقية وكل الأجهزة، لذا فالهدف هو الحدّ من ضرر العيوب التي تتسرّب ومعرفة ما فات الاختبار المبكر، لا الاختبار على المستخدمين بدلاً من الاختبار قبل وصول التغيير إليهم.

• المراقبة (Monitoring): لوحات متابعة وتنبيهات تعكس تجربة المستخدمين الفعلية. والإشارات الذهبية الأربع التي مرّت بك في درس DevOps للمختبِرين، وهي من كتاب SRE من Google، هي: زمن الاستجابة (Latency) أي المدة التي يستغرقها الطلب، والحركة (Traffic) أي مقدار ما يصل إلى النظام من طلبات، والأخطاء (Errors) أي معدل الطلبات الفاشلة، والتشبّع (Saturation) أي مدى امتلاء موارد النظام. وأضف إشارات الأعمال مثل عدد الطلبات في الساعة، لأن بعض العيوب لا يُطلق أي خطأ.
• الإطلاق الكناري (Canary release): يصل التغيير أولاً إلى نسبة صغيرة من المستخدمين، وتُقارن إشاراته بمجموعة ضابطة تعمل على الإصدار القديم خلال الفترة نفسها. فإن كان أسوأ، يُتراجع عنه قبل أن يراه أغلب المستخدمين.
• أعلام الميزات (Feature flags): يُنشر الكود الجديد مطفأً، ثم يُفعَّل لمجموعة أو لنسبة من المستخدمين دون إعادة نشر. اختبر حالتي العلم كلتيهما والانتقال بينهما.
• تجارب A/B (A/B testing): يُشغَّل بديلان يعمل كلاهما بشكل صحيح جنباً إلى جنب على مستخدمين موزَّعين عشوائياً، ويُحكم بينهما بمقياس متفق عليه مسبقاً. يتحقق المختبِر من صحة إعداد التجربة، ويحكم مالك المنتج والمحللون على النتيجة.
• تجارب الفوضى (Chaos experiments): يحقن الفريق عطلاً واقعياً، كتباطؤ خدمة يعتمد عليها النظام، ليختبر فرضية أن النظام يحافظ على سلوكه الطبيعي. وتبدأ التجارب صغيرة ويمكن إيقافها فوراً.

جرّبها: فاحص صحة API جرّبها: مقارنة استجابات API

مثال تطبيقي: حقل رمز الخصم من القصة إلى الإنتاج

يضيف متجر إلكتروني حقلاً لرمز الخصم في صفحة إتمام الشراء، والأسعار بالريال بمنزلتين عشريتين. ويعرض الشكل الميزة على جانبي الإصدار.

• المراجعة: يسأل المختبِر هل يُجمع الرمز مع التوصيل المجاني، وهل الرموز حساسة لحالة الأحرف، وهل يُحسب الخصم قبل الضريبة وكيف يُقرَّب. وتُضاف الإجابات إلى معايير القبول.
• ATDD وTDD: تصبح الأمثلة المتفق عليها اختبارات قبول كالسيناريوهين أعلاه (لاحظ save10 بأحرف صغيرة: اتفق الفريق على أن الرموز غير حساسة لحالة الأحرف). ويكتب المطوّر اختبارات الوحدة أولاً، ومنها اختبار يحسب ⁦10%⁩ من ⁦99.99⁩ ريال، ويجب أن تكون النتيجة ⁦10.00⁩ لا ⁦9.99⁩ وفق التقريب المتفق عليه إلى أقرب ⁦0.01⁩.
• التحليل الساكن: تنبّه الأداة إلى استعلام يُبنى بلصق رمز الخصم الذي كتبه المتسوق مباشرةً في نص جملة SQL، مما قد يسمح لرمز خصم مصوغ بعناية بتغيير الاستعلام نفسه (حقن SQL). فيطلب المراجِع قبل الدمج استعلاماً بمعاملات (Parameterised query) يمرّر رمز الخصم بوصفه بيانات.
• العلم والكناري: يُنشر الكود والعلم promo_codes مطفأ، ثم يُفعَّل للموظفين الذين يجرون عليه فحص دخان بحسابات اختبار، ثم لـ⁦5%⁩ من المتسوقين. وتُقارن أخطاء الخصم وزمن الاستجابة وعمليات الشراء المكتملة بالـ⁦95%⁩ الباقين بوصفها نسباً لا أعداداً خاماً، وفق معايير تراجع مكتوبة مسبقاً.
• العيب المتسرّب: تُظهر المراقبة ارتفاع أخطاء «رمز غير صالح» على منصة جوال واحدة تضيف لوحة مفاتيحها مسافة بعد الرمز. صار الإصلاح يحذف المسافات من بداية الرمز ونهايته، وأضاف المختبِر اختبار قبول للرموز المحاطة بمسافات، فانتقلت الملاحظة إلى اليسار.
• التجارب: تقارن تجربة A/B حقلاً ظاهراً برابط «لديك رمز؟» بعدد عمليات الشراء المكتملة، وهو المقياس المتفق عليه مسبقاً. وتُبطئ تجربة فوضى خدمة الخصم لتختبر فرضية أن صفحة الشراء، بدلاً من أن تتعلّق، تُبلغ المتسوق بتعذّر التحقق من الرمز الآن وتتيح له الدفع رغم ذلك.

جرّبها: حاسبة النسبة المئوية

الموازنة بين الجانبين

الجانبان متكاملان لا بديلان. عمل اليسار رخيص ويمنع العيوب لكنه يختبر افتراضات الفريق، وعمل اليمين يرى الواقع لكن ما يكتشفه قد وصل بالفعل إلى أحد ما. حدّد الوزن لكل تغيير بحسب المخاطر.

• رجّح اليسار حين يكون الإخفاق خطيراً أو لا رجعة فيه: المدفوعات وترحيل البيانات والخصوصية والأمان. فالتراجع لا يعيد مبلغاً حُصِّل من العميل خطأً.
• رجّح اليمين حين لا يجيب عن السؤال إلا الاستخدام الحقيقي: الحمل الحقيقي، والطيف الكامل من الأجهزة، والتصميم الذي يفضّله المستخدمون.
• أغلق الحلقة: لكل عيب متسرّب، أضف الاختبار أو سؤال المراجعة أو قاعدة التحليل الساكن التي كانت ناقصة.
• لا تختبر في الإنتاج إلا على أنظمة يملكها فريقك أو لديك إذن مكتوب باختبارها، وبحسابات اختبار، ودون بيانات شخصية حقيقية، ومع وسيلة للإيقاف فوراً.

جرّبها: مولّد الاختبار المبني على المخاطر

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• Canarying Releases — The Site Reliability WorkbookGoogle / O'Reilly Mediaإطلاق التغيير لنسبة صغيرة من الحركة أولاً ومقارنته بخط الأساس قبل التعميم — التحقق من النشر كما يُمارس في هندسة موثوقية المواقع.
• Monitoring Distributed Systems — Site Reliability Engineering (Rob Ewaschuk)Google / O'Reilly Media · 2016إرشادات SRE من Google في المراقبة: المراقبة من الخارج (black-box) مقابل المراقبة من الداخل (white-box)، والإشارات الذهبية الأربع — زمن الاستجابة والحركة والأخطاء والتشبّع.
• Release It! Second Edition: Design and Deploy Production-Ready Software (Michael T. Nygard)The Pragmatic Bookshelf · 2018أنماط الاستقرار — المهل الزمنية وقواطع الدائرة والحواجز والضغط العكسي — وأنماط الفشل التي يُفترض أن يكشفها اختبار الحمل.