الاختبار في خطوط CI/CD

التكامل المستمر والتسليم المستمر والنشر المستمر

التكامل المستمر (Continuous Integration) هو ممارسة دمج عمل كل مطوّر في الفرع الرئيسي المشترك بشكل متكرر — يومياً على الأقل — مع التحقق من كل دمج ببناء آلي يختبر نفسه. ويضيف وصف مارتن فاولر الأكثر استشهاداً القواعد التي تجعله ينجح: أبقِ البناء سريعاً، وأصلح البناء المكسور فوراً، واعتبر الفرع الرئيسي الأحمر مشكلة الجميع. التكامل المستمر عادة فريق تدعمها أداة، لا الأداة نفسها؛ فخادم CI يعمل مرة في الأسبوع على فرع طويل العمر ليس تكاملاً مستمراً.

التسليم المستمر (Continuous Delivery) يوسّع التكامل المستمر بحيث يكون كل تغيير يجتاز خط الأنابيب قابلاً للإصدار: يُبنى مرة واحدة، ويُختبر في بيئات شبيهة بالإنتاج، ويمكن نشره في الإنتاج بضغطة زر. ويبقى قرار النشر قراراً بشرياً أو تجارياً. أما النشر المستمر (Continuous Deployment) فيزيل هذا القرار: كل تغيير يجتاز جميع المراحل الآلية يذهب إلى الإنتاج تلقائياً. الفرق مهم للمختبِرين لأنه في النشر المستمر لا تبقى نقطة تفتيش يدوية — فكل ما لا يفحصه خط الأنابيب لا يفحصه أحد قبل أن يراه المستخدمون.

• التكامل المستمر — دمج متكرر في الفرع الرئيسي، يُتحقق من كل دمج ببناء واختبارات آلية.
• التسليم المستمر — كل تغيير ناجح قابل للنشر؛ وشخص ما يختار موعد الإصدار.
• النشر المستمر — كل تغيير ناجح يُنشر تلقائياً؛ ويصبح التحقق بعد النشر آخر شبكة أمان.
• في الثلاثة، الاختبارات الآلية هي الدليل. وخط الأنابيب جدير بالثقة بقدر الاختبارات التي يشغّلها والبوابات التي يفرضها.

مراحل الاختبار في خط الأنابيب ولماذا يهم ترتيبها

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

تختلف المراحل الدقيقة من فريق لآخر، لكن معظم خطوط الأنابيب تتقارب نحو ترتيب متشابه. وينبغي أن يكون لكل مرحلة ميزانية زمنية؛ وحين تتجاوزها المرحلة، إما أن يوازيها الفريق، أو ينقل الاختبارات البطيئة إلى مرحلة لاحقة، أو يزيل التغطية المكررة.

• مرحلة الإيداع (Commit stage، دقائق) — الفحوص الساكنة (التدقيق، وفحص الأنواع، والتنسيق، وفحص الاعتماديات والأسرار)، واختبارات الوحدة، واختبارات المكوّنات مع استبدال الاعتماديات ببدائل اختبار. تعمل عند كل دفع وكل طلب دمج.
• مرحلة التكامل والواجهة البرمجية — التطبيق مقابل قواعد بيانات وطوابير وحاويات خدمات حقيقية؛ واختبارات API تُفحص مقابل العقد (OpenAPI). هنا يُتحقق من معظم قواعد العمل بتكلفة معقولة.
• مرحلة الاختبار الشامل / الواجهة (E2E/UI) — مجموعة صغيرة من رحلات المستخدم الحرجة عبر متصفح أو جهاز حقيقي؛ وهي الأبطأ والأكثر عرضة للتذبذب، لذا تُبقى صغيرة عمداً.
• المرحلة غير الوظيفية — دخان أداء قصير (دقائق من الحمل على نقاط النهاية الأساسية مع عتبات لزمن الاستجابة ومعدل الخطأ)، وفحوص أمان (تحليل ساكن، وثغرات الاعتماديات، وفحص ديناميكي أساسي)، وفحوص إمكانية الوصول على الصفحات الرئيسية.
• مرحلة ما بعد النشر — اختبارات الدخان وفحوص الصحة على البيئة التي نُشرت للتو، ثم المراقبة الاصطناعية. يغطيها دليل التحقق من النشر بالتفصيل.
• المراحل المجدولة — حزمة الانحدار الكاملة، واختبارات الحمل الطويلة، وفحوص الأمان الكاملة تعمل ليلياً أو أسبوعياً بدلاً من كل تغيير، وتُبلغ مالكاً يتصرف حيال الإخفاقات.

جرّبها: مولّد حالات اختبار من OpenAPI جرّبها: مولّد اختبارات الطلبات المتزامنة جرّبها: محلّل زمن الاستجابة

مثال: خط أنابيب بمراحل الإيداع وAPI والاختبار الشامل والنشر

مسار العمل أدناه مثال مكتوب بصيغة GitHub Actions. يشغّل الفحوص الساكنة واختبارات الوحدة أولاً، ثم اختبارات API مقابل حاوية خدمة PostgreSQL مؤقتة مع الترحيلات وبيانات بذر اصطناعية، ثم حزمة المتصفح مقسّمة إلى أربعة أجزاء متوازية (shards)، وعلى الفرع الرئيسي ينشر إلى بيئة staging ويشغّل سكربت دخان. كل مهمة اختبار ترفع تقاريرها ومخرجاتها حتى عند الفشل (`if: always()`)، لأن الإخفاق بلا أدلته هو أغلى أنواع الإخفاق تحقيقاً. ويعبّر GitLab CI وJenkins عن البنية نفسها بمراحل ومهام في `.gitlab-ci.yml` أو ملف Jenkinsfile.

• `needs` يجعل الترتيب صريحاً: أجزاء الاختبار الشامل لا تبدأ أبداً إن فشلت اختبارات الوحدة أو API.
• `concurrency` مع `cancel-in-progress` يوقف التشغيل الجاري لطلب دمج حين يبدأ تشغيل أحدث بسبب دفع جديد إلى طلب الدمج نفسه، فيوفّر وقت المشغّلات. أما على الفرع الرئيسي والجدولة الليلية، وهما تشتركان في مجموعة refs/heads/main، فلا يُلغى تشغيل جارٍ أبداً، فلا يُقطع نشرٌ في منتصفه؛ لكن التشغيل الذي ما زال منتظراً (pending) في المجموعة يُلغى حين يدخل الطابور تشغيل أحدث، وهذا هو السلوك الافتراضي لكل مجموعة تزامن.
• `timeout-minutes` يحوّل الاختبار المعلّق إلى إخفاق ظاهر بدلاً من مهمة تنتظر ساعات.
• رمز النشر يأتي من مخزن الأسرار في المنصة؛ وكلمة مرور قاعدة البيانات مكتوبة حرفياً فقط لأن الحاوية تعيش مهمة واحدة.
• الجدولة تعمل على الفرع الافتراضي؛ وأوقات cron في GitHub Actions بتوقيت UTC ما لم تحدد الجدولة منطقة زمنية.

# Example pipeline (GitHub Actions syntax). Adapt job names, scripts and versions to your project.
name: ci

on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: "0 1 * * *"   # nightly full regression, 01:00 UTC

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

jobs:
  commit-stage:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm run test:unit          # writes reports/junit-unit.xml
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: unit-reports
          path: reports/

  api-tests:
    needs: commit-stage
    runs-on: ubuntu-latest
    timeout-minutes: 20
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: ci-only-password   # throwaway container, not a real secret
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    env:
      DATABASE_URL: postgres://postgres:ci-only-password@localhost:5432/postgres
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run db:migrate
      - run: npm run db:seed            # synthetic test data only
      - run: npm run test:api           # writes reports/junit-api.xml
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: api-reports
          path: reports/

  e2e:
    needs: api-tests
    runs-on: ubuntu-latest
    timeout-minutes: 30
    strategy:
      fail-fast: false
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --shard=${{ matrix.shard }}/4   # config starts the app
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: e2e-results-${{ matrix.shard }}
          path: |
            playwright-report/
            test-results/

  deploy-staging:
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    needs: e2e
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v7
      - run: ./scripts/deploy.sh staging
        env:
          DEPLOY_TOKEN: ${{ secrets.STAGING_DEPLOY_TOKEN }}
      - run: ./scripts/smoke.sh https://staging.example.com

جرّبها: منسّق YAML جرّبها: مولّد تعابير cron جرّبها: شارح تعابير cron

بوابات الجودة: معايير تستطيع إيقاف التغيير

بوابة الجودة (Quality gate) فحص بقاعدة نجاح/فشل يقرر ما إذا كان يجوز للتغيير الانتقال إلى المرحلة التالية — الدمج، أو النشر إلى staging، أو الترقية إلى الإنتاج. إنها الشكل الآلي لمعايير الخروج. وتكون البوابة مفيدة حين تكون موضوعية، وسريعة التقييم، ومرتبطة بخطر حقيقي، ومطبّقة دون استثناءات؛ أما البوابة التي تُتجاوز بشكل روتيني فتعلّم الجميع تجاهلها.

احذر بوابات المظاهر (vanity gates). قاعدة مثل «يجب ألا تقل تغطية الأسطر عن 80%» سهلة القياس وسهلة الإرضاء باختبارات تنفّذ الكود دون أن تتحقق من شيء مفيد. التغطية مفيدة كاتجاه وكوسيلة لإيجاد الكود غير المختبَر؛ أما كعتبة خام بلا سياق فتكافئ السلوك الخاطئ. والصيغة الأنفع هي تغطية الأسطر المتغيرة، تُراجع مع الاختبارات نفسها. وينطبق الأمر نفسه على «عدد الاختبارات» أو «نسبة نجاح 100% بعد إعادة المحاولة»: فهي تصف النشاط لا المخاطر.

• جميع الفحوص المطلوبة خضراء: البناء والتدقيق وفحص الأنواع واختبارات الوحدة وAPI والاختبار الشامل — دون تخطّي أي اختبار خارج قائمة الحجر.
• لا ثغرات جديدة حرجة أو عالية في الاعتماديات أو التحليل الساكن، أو استثناء مسجّل ومحدود المدة.
• عقد API لم يتغير، أو التغيير متوافق مع الإصدارات السابقة (لا حقول محذوفة ولا مدخلات إلزامية جديدة) ما لم يكن ذا إصدار جديد.
• دخان الأداء ضمن العتبات، مثلاً زمن استجابة p95 أقل من 400 ms ومعدل خطأ أقل من 1% عند حمل الدخان، مقارنةً بآخر خط أساس من الفرع الرئيسي.
• ترحيلات قاعدة البيانات طُبّقت بنظافة على نسخة من المخطط الحالي، ومع خطة تراجع أو إصلاح أمامي مختبَرة حيث تتطلب العملية ذلك.
• للترقية إلى الإنتاج: اجتياز دخان ما بعد النشر على staging وعدم وجود عيوب حاجبة مفتوحة على الإصدار.

تقارير الاختبار والمخرجات

نتيجة خط الأنابيب مفيدة بقدر ما يتركه خلفه. صيغة JUnit XML هي صيغة التبادل الشائعة لنتائج الاختبار: معظم مشغّلات الاختبار تستطيع كتابتها ومعظم أنظمة CI تستطيع قراءتها. وهي صيغة متعارف عليها فعلياً لا معيار رسمي، لذا تختلف السمات قليلاً بين الأدوات، لكن البنية الأساسية — حزم اختبار تحتوي حالات اختبار، لكل منها عنصر اختياري للإخفاق أو الخطأ أو التخطي، ومدة — مدعومة على نطاق واسع. فمثلاً يقرؤها GitLab عبر `artifacts:reports:junit` ويعرض الإخفاقات الجديدة والمُصلحة في طلب الدمج؛ وينشرها Jenkins كنتائج اختبار مع سجل تاريخي لكل اختبار.

وإلى جانب ملخص النجاح/الفشل، احتفظ بالمخرجات (artifacts) التي يحتاجها شخص لتشخيص الإخفاق دون إعادة التشغيل: سجلات التطبيق ومشغّل الاختبار، ولقطات الشاشة والفيديو لإخفاقات الواجهة، والتتبعات (trace في Playwright يسجّل الإجراءات والشبكة ولقطات DOM ويمكن فتحه بعد التشغيل)، والتقاطات طلبات HTTP واستجاباتها لإخفاقات API، وتقارير التغطية. حدّد فترة احتفاظ تكفي للمقارنة مع التشغيلات السابقة دون تراكم لا نهائي، وتأكد أنها لا تحتوي بيانات شخصية حقيقية أو أسراراً.

<?xml version="1.0" encoding="UTF-8"?>
<testsuites tests="3" failures="1" skipped="1" time="4.21">
  <testsuite name="orders-api" tests="3" failures="1" skipped="1" time="4.21">
    <testcase classname="orders.create" name="returns 201 for a valid order" time="0.84"/>
    <testcase classname="orders.create" name="rejects a negative quantity with 400" time="0.31">
      <failure message="expected status 400, received 500">AssertionError: expected 400, received 500
    at tests/orders.spec.ts:42</failure>
    </testcase>
    <testcase classname="orders.refund" name="refunds a captured payment" time="0">
      <skipped message="quarantined: FLAKY-112"/>
    </testcase>
  </testsuite>
</testsuites>

البيئات وبيانات الاختبار والأسرار

تحتاج اختبارات خط الأنابيب إلى مكان تعمل فيه. البيئات المؤقتة (Ephemeral environments) — تُنشأ لتشغيل واحد أو لطلب دمج واحد وتُدمَّر بعده — تمنح كل تغيير بنية نظيفة ومعزولة: حاويات خدمات لقواعد البيانات والطوابير، أو نشر معاينة قصير العمر لكل فرع. وهي تزيل سبباً رئيسياً للإخفاقات الكاذبة: تداخل الاختبارات عبر بيانات مشتركة. وما زالت البيئات المشتركة طويلة العمر (staging يحاكي الإنتاج) لازمة للتكامل مع أطراف ثالثة حقيقية ولتجربة الإصدار، لكنها تنحرف، لذا افحص إصداراتها وإعداداتها ضمن خط الأنابيب.

ينبغي أن ينشئ خط الأنابيب بيانات الاختبار بنفسه: الترحيلات تبني المخطط، وسكربتات البذر تحمّل خط أساس اصطناعياً معروفاً، وكل اختبار ينشئ السجلات المحددة التي يحتاجها بمعرّفات فريدة حتى لا تتصادم التشغيلات المتوازية. لا تنسخ أبداً بيانات شخصية من الإنتاج إلى CI. أما الأسرار — مفاتيح API ورموز النشر وكلمات مرور قواعد بيانات البيئات المشتركة — فمكانها مخزن الأسرار في منصة CI أو خزنة خارجية، محصورة في البيئات التي تحتاجها، ومحجوبة في السجلات، ومدوَّرة دورياً. وفي GitHub Actions لا تتلقى مسارات العمل التي تطلقها طلبات الدمج من المستودعات المتفرعة (forks) أسرار المستودع افتراضياً، وهذه ميزة أمان يجب الإبقاء عليها لا مشكلة يُلتف عليها.

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

جرّبها: مصنع بيانات الاختبار

التنفيذ المتوازي والتقسيم

حين تتجاوز الحزمة ميزانيتها الزمنية، شغّلها بالتوازي. داخل جهاز واحد تستخدم المشغّلات عدة عمّال (workers)؛ وعبر الأجهزة تُقسَّم الحزمة إلى أجزاء (sharding)، يشغّل كل جزء مجموعة فرعية على مشغّله الخاص، كما في المثال أعلاه. يقلّص التقسيم الزمن الفعلي بما يتناسب تقريباً مع عدد الأجزاء إن كانت متوازنة؛ والتقسيم حسب مدة الاختبار المسجّلة يوازن أفضل من التقسيم حسب عدد الملفات.

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

التعامل مع الاختبارات المتذبذبة في خط الأنابيب

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

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

تحليل إخفاقات خط الأنابيب: مسار للفرز

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

يطرح مسار الفرز أدناه خمسة أسئلة بالترتيب. (1) هل فشلت المهمة قبل تشغيل أي اختبار (تثبيت الاعتماديات، أو البناء، أو سحب الصورة، أو فقدان المشغّل)؟ إن كان كذلك فهي مشكلة في خط الأنابيب أو البنية التحتية يملكها فريق المنصة: أصلحها ثم أعد التشغيل. (2) هل فشلت أثناء الإعداد (قاعدة بيانات غير جاهزة، أو خطأ ترحيل، أو خدمة غير سليمة، أو سر منتهي الصلاحية)؟ إن كان كذلك فهي مشكلة بيئة: أصلح البيئة ولا تلمس الاختبارات. (3) أعد تشغيل الاختبارات الفاشلة مرة واحدة على الإيداع نفسه: إن نجحت فهو اختبار مرشح للتذبذب — سجّله (معرّف الاختبار، والإيداع، والخطأ، ورابط التشغيل)، وافتح تذكرته أو حدّثها، واحجره إن تكرر؛ والإعادة الخضراء لا تثبت أن التغيير آمن. وإن فشلت مجدداً فالإخفاق حتمي، فانتقل إلى السؤال التالي. (4) هل يفشل الاختبار نفسه على الفرع الرئيسي دون هذا التغيير؟ إن كان كذلك فهو كسر سابق أو انحراف في البيئة: أبلغ مالك الفرع الرئيسي؛ وإلا فالتغيير هو السبب، فانتقل إلى السؤال الأخير. (5) هل سلوك المنتج خاطئ، أم أن توقع الاختبار قديم؟ إن كان المنتج خاطئاً فهو عيب في المنتج: تقرير خطأ ويبقى الدمج محجوباً؛ وإن كان السلوك الجديد مقصوداً فهو تحديث للاختبار ضمن التغيير نفسه، يُراجع كما يُراجع الكود.

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

Pipeline failed
|
|-- 1. Did the job fail before any test ran? (dependency install, build, image pull, runner lost)
|      yes -> PIPELINE / INFRASTRUCTURE problem. Owner: platform. Fix, then re-run.
|
|-- 2. Did it fail during setup? (DB not ready, migration error, service unhealthy, expired secret)
|      yes -> ENVIRONMENT problem. Fix the environment; do not touch the tests.
|
|-- 3. Re-run the failed tests once on the SAME commit. Do they pass now?
|      yes -> FLAKY candidate. Log it (test id, commit, error, run link), open or update its ticket,
|             quarantine if it repeats. The change is not proven safe by the green re-run.
|      no  -> deterministic failure, continue.
|
|-- 4. Does the same test fail on main without this change?
|      yes -> PRE-EXISTING break or environment drift. Notify whoever owns main.
|      no  -> caused by this change, continue.
|
`-- 5. Is the product behaviour wrong, or is the test's expectation out of date?
       product wrong       -> PRODUCT DEFECT. Bug report, merge blocked.
       intended new change -> TEST UPDATE in the same change, reviewed like code.

جرّبها: محلّل رسائل الأخطاء بالذكاء الاصطناعي

ماذا يفعل المختبِر في CI/CD

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

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

جرّبها: مولّد سيناريوهات الانحدار جرّبها: فاحص صحة API

الأسئلة الشائعة

المراجع

• Continuous Integration (Martin Fowler)martinfowler.com · 2024الوصف الأكثر استشهاداً للتكامل المستمر: ادمج كثيراً، واجعل البناء يختبر نفسه وسريعاً، وأصلح البناء المكسور فوراً.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• GitHub Actions documentationGitHubكيف تُعرَّف مسارات العمل والمهام والمشغّلات والمخرجات في GitHub Actions — حيث تعمل الاختبارات الآلية عند كل دفع أو طلب دمج.
• GitLab CI/CDGitLabكيف تُعرَّف خطوط الأنابيب والمهام والمخرجات — حيث تعمل حزمة الانحدار الآلية عند كل تغيير.
• Unit test reports — GitLab CI/CDGitLabنشر نتائج JUnit XML كمخرجات لخط الأنابيب لتظهر الاختبارات الفاشلة في طلب الدمج ويمكن مقارنتها بين التشغيلات.
• Pipeline — Jenkins User HandbookJenkins Projectخطوط Jenkins المعرّفة ككود في ملف Jenkinsfile: المراحل والخطوات والتنفيذ المتوازي ونشر نتائج الاختبار.
• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011لماذا تُفقد الاختبارات المتذبذبة الحزمةَ قيمتها، وأسبابها الشائعة (العزل وعدم التزامن والخدمات البعيدة والوقت وتسرّب الموارد)، والحجر كاستجابة.
• DORA's software delivery performance metricsDORA (Google Cloud)مقاييس DORA للتسليم — زمن تنفيذ التغيير وتكرار النشر وزمن التعافي من النشر الفاشل ونسبة فشل التغييرات وما يتصل بها — مجمّعة حسب الإنتاجية وعدم الاستقرار.