بوابات الجودة

لماذا يهم

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

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

أين تقع البوابات: خط الأنابيب وعملية الإصدار

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

بوابات خط الأنابيب آلية وتعمل عند كل تغيير؛ وتتيح منصات مثل GitHub وGitLab جعل نتيجة خط الأنابيب فحصاً إلزامياً، فلا يمكن دمج طلب الدمج ما دامت النتيجة حمراء. أما بوابات عملية الإصدار فأقل عدداً: يراجع شخصٌ أدلة إصدار كامل ثم يقرّر. ومعظم الفرق تجمع بين النوعين:

• بوابة الدمج (آلية): البناء والفحوص الساكنة واختبارات الوحدة والواجهة البرمجية عند كل طلب دمج؛ وأي فحص أحمر يحجب الدمج.
• بوابة الخروج من الاختبار: بعد اختبار النظام واختبار الانحدار تُفحص معايير الخروج الواردة في خطة الاختبار مقابل تقرير الاختبار.
• بوابة الإصدار (يقرّر فيها شخص): قبل بيئة الإنتاج يراجع مالك البوابة الأدلة ويقرّر المضي أو التوقف (Go/No-Go)، أو يعتمد استثناءً مسجلاً.
• بوابة ما بعد النشر: تعمل اختبارات الدخان وفحوص الصحة فور النشر، وأي فشل يؤدي إلى التراجع (Rollback).

جرّبها: فاحص صحة API

معايير بوابة تؤدي الغرض

المعيار المفيد قابل للقياس، ومرتبط بمخاطرة حقيقية، وسريع التقييم بما يناسب مرحلته، ومتفق عليه قبل بدء العمل. فعبارة «الجودة مقبولة» تسقط في الشرط الأول، لأن أحداً لا يستطيع القول هل تحققت، أما «لا عيوب مفتوحة بدرجة حاجب (Blocker) أو حرج (Critical)» فيمكن أن تستوفي الشروط الأربعة. السياسة أدناه توضيحية وليست صيغة أي أداة CI، وأرقامها أمثلة: استمدّ أرقامك من خط الأساس الخاص بك.

تجنّب المعايير الشكلية (Vanity Criteria). فشرط «تغطية الأسطر ⁦80%⁩ على الأقل» وشرط «نجاح ⁦95%⁩ من الاختبارات» يمكن تحقيقهما معاً وإتمام الشراء معطل: الأول يكافئ اختبارات لا تتحقق من شيء، والثاني يخفي أيّ ⁦5%⁩ هي التي فشلت. فالتغطية تُظهر ما لم يُختبر ولا تثبت الجودة. فضّل «لكل معيار قبول ضمن النطاق اختبار ناجح» و«لا اختبار فاشلاً في حزمة الرحلات الحرجة».

gates:
  - name: merge
    owner: engineering-lead
    on_failure: block
    criteria:
      build: passed
      failed_unit_and_api_tests: 0
      skipped_tests_without_ticket: 0
      breaking_api_contract_changes: 0
      new_critical_or_high_vulnerabilities: 0
  - name: release-to-production
    owner: product-owner
    on_failure: no-go-unless-approved-exception
    criteria:
      failed_regression_tests: 0
      acceptance_criteria_without_passing_test: 0
      open_blocker_or_critical_defects: 0
      checkout_api_p95_ms_max: 800
  - name: post-deploy
    owner: release-engineer-on-call
    on_failure: roll-back
    criteria:
      failed_smoke_tests: 0
      failing_health_checks: 0

جرّبها: منسّق YAML جرّبها: المتطلبات ← حالات اختبار جرّبها: مقارنة عقود الاستجابات

من يملك البوابة، وكيف تُدار الاستثناءات

تحتاج كل بوابة إلى مالك محدد بالاسم يحافظ على معاييرها ويقرّر في الاستثناءات: عادةً قائد الفريق الهندسي لبوابة الدمج، وفريق الأمن لمعايير الأمان، ومالك المنتج (Product Owner) أو مدير الإصدار لبوابة الإصدار. ونادراً ما يملك المختبِر بوابة وحده؛ فهو يقدّم الأدلة وتوصية واضحة، والمالك يقرّر ويتحمل مسؤولية قراره.

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

• لا يعتمد الاستثناء إلا مالك البوابة أو نائب محدد بالاسم، وليس الشخص الذي يطلبه أبداً.
• يذكر السجل المعيار الذي لم يتحقق، والسبب، والمخاطرة بلغة المستخدم، وإجراء التخفيف، ومن اعتمده.
• لكل استثناء تاريخ انتهاء وتذكرة متابعة لها مالك.
• الاختبار المتذبذب (Flaky) يُحجَر (Quarantine) بتذكرة: يُنقل من الحزمة التي تحجب الدمج إلى تشغيل منفصل تبقى نتائجه متابَعة، ولا يُحذف ولا يُتخطى بصمت أبداً.
• المعيار الذي يُعفى منه مرة بعد مرة إما خاطئ وإما متجاهَل؛ فغيّره علناً.

مثال تطبيقي: إصدار لم يستوفِ معياراً واحداً

يخطط متجر إلكتروني للإصدار ⁦3.4⁩ الذي يضيف ميزة رموز الخصم. ولبوابة الإصدار، التي يملكها مالك المنتج، أربعة معايير: نجاح حزمة الانحدار؛ ولكل معيار قبول ضمن النطاق اختبار ناجح؛ ولا عيوب مفتوحة بدرجة حاجب أو حرج؛ وزمن الاستجابة p95 لواجهة إتمام الشراء البرمجية لا يتجاوز ⁦800⁩ ملّي ثانية عند حمل اختبار الدخان. ويقدّم قائد فريق الجودة الأدلة.

في يوم الإصدار تنجح ⁦412⁩ من أصل ⁦412⁩ اختبار انحدار، ولجميع معايير القبول وعددها ⁦38⁩ اختبارات ناجحة، وتبلغ قيمة p95 ⁦640⁩ ملّي ثانية. لكن عيباً حرجاً ما زال مفتوحاً: DEF-1182، إذ يُطبَّق الخصم مرتين حين ينقر المستخدم نقراً مزدوجاً على «تطبيق» في اتصال بطيء. فالبوابة لم تُجتز: إما أن ينتظر الإصدار إصلاحاً مؤكداً، وإما أن يعتمد المالك استثناءً.

بقية الإصدار ⁦3.4⁩، ومنها إصلاحات ينتظرها العملاء، جاهزة، والميزة الجديدة موجودة خلف علم ميزة (Feature Flag)، فيقترح الفريق الإصدار مع إبقاء العلم معطّلاً. يعتمد مالك المنتج القرار، ويُسجَّل الاستثناء:

• البوابة والمعيار الذي لم يتحقق: بوابة الإصدار ⁦3.4⁩؛ «لا عيوب مفتوحة بدرجة حاجب أو حرج» (العيب DEF-1182 مفتوح).
• السبب والمخاطرة: بقية تغييرات الإصدار ⁦3.4⁩ مطلوبة في الموعد المخطط؛ ولو فُعِّل العلم لأمكن أن يحصل العملاء على الخصم مرتين.
• التخفيف: يبقى العلم معطّلاً في بيئة الإنتاج؛ وقد تحقق قائد فريق الجودة في بيئة Staging من أن حقل الخصم لا يمكن الوصول إليه عندئذ، وأن إتمام الشراء يعمل كما في الإصدار ⁦3.3⁩.
• اعتمده: مالك المنتج، بعد مراجعة مع قائد فريق الجودة وقائد الفريق الهندسي.
• الانتهاء والمتابعة: العيب DEF-1182 هو تذكرة المتابعة، ومالكها قائد الفريق الهندسي؛ ويبقى العلم معطّلاً حتى يجتاز إصلاحه اختبار التأكيد واختبار الانحدار، ويُغلق الاستثناء في موعد أقصاه الإصدار ⁦3.5⁩.

جرّبها: محلّل زمن الاستجابة

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Continuous Integration (Martin Fowler)martinfowler.com · 2024الوصف الأكثر استشهاداً للتكامل المستمر: ادمج كثيراً، واجعل البناء يختبر نفسه وسريعاً، وأصلح البناء المكسور فوراً.
• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011لماذا تُفقد الاختبارات المتذبذبة الحزمةَ قيمتها، وأسبابها الشائعة (العزل وعدم التزامن والخدمات البعيدة والوقت وتسرّب الموارد)، والحجر كاستجابة.