CI/CD पाइपलाइन में टेस्टिंग

Continuous integration, continuous delivery और continuous deployment

Continuous integration (CI) हर डेवलपर के काम को साझा mainline में बार-बार — कम से कम रोज़ — merge करने की प्रैक्टिस है, जिसमें हर merge को एक ऑटोमेटेड, self-testing build से वेरिफ़ाई किया जाता है। Martin Fowler का व्यापक रूप से संदर्भित विवरण वे नियम जोड़ता है जिनसे यह काम करता है: build तेज़ रखें, टूटा build तुरंत ठीक करें, और लाल mainline को सबकी समस्या मानें। CI टीम की आदत है जिसे एक टूल सहारा देता है, ख़ुद टूल नहीं; लंबे समय तक चलने वाली branch पर हफ़्ते में एक बार चलने वाला CI सर्वर continuous integration नहीं है।

Continuous delivery CI को इस तरह बढ़ाती है कि pipeline पास करने वाला हर बदलाव रिलीज़ के लायक हो: वह एक बार build होता है, प्रोडक्शन जैसे एनवायरनमेंट में टेस्ट होता है और एक बटन दबाकर प्रोडक्शन में डिप्लॉय किया जा सकता है। डिप्लॉय का फ़ैसला इंसानी या बिज़नेस फ़ैसला रहता है। Continuous deployment यह फ़ैसला हटा देती है: सभी ऑटोमेटेड स्टेज पास करने वाला हर बदलाव अपने-आप प्रोडक्शन में जाता है। टेस्टर के लिए यह फ़र्क़ अहम है क्योंकि continuous deployment में कोई मैनुअल चेकपॉइंट नहीं बचता — जो pipeline नहीं जाँचती, उसे यूज़र के देखने से पहले कोई नहीं जाँचता।

• Continuous integration — mainline में बार-बार merge, हर merge ऑटोमेटेड build और टेस्ट से वेरिफ़ाई।
• Continuous delivery — हर पास होने वाला बदलाव डिप्लॉय-योग्य; रिलीज़ कब हो यह कोई व्यक्ति चुनता है।
• Continuous deployment — हर पास होने वाला बदलाव अपने-आप डिप्लॉय; डिप्लॉयमेंट के बाद का वेरिफ़िकेशन आख़िरी सुरक्षा-जाल बन जाता है।
• तीनों में ऑटोमेटेड टेस्ट ही सबूत हैं। Pipeline उतनी ही भरोसेमंद है जितने उसके टेस्ट और उसके लागू किए गेट।

Pipeline के टेस्ट स्टेज और उनका क्रम क्यों मायने रखता है

Pipeline जाँचों को ऐसे क्रम में रखती है कि सबसे सस्ती, सबसे तेज़ और सबसे ज़्यादा फ़ेल होने की संभावना वाली जाँचें पहले चलें, और धीमी, महँगी और एनवायरनमेंट-निर्भर जाँचें बाद में — सिर्फ़ उन बदलावों पर जो पिछले स्टेज पार कर चुके हैं। यह समय पर लागू किया गया test pyramid है: डेवलपर को टाइपो का पता मिनटों में चलना चाहिए, चालीस मिनट के ब्राउज़र सूट के बाद नहीं। तेज़ फ़ीडबैक सुविधा भर नहीं है; फ़ीडबैक धीमा हो तो लोग बदलावों को बैच में जोड़ते हैं, और बड़े बैच में फ़ेलियर को किसी एक कारण से जोड़ना मुश्किल होता है।

सटीक स्टेज टीम-दर-टीम अलग होते हैं, पर ज़्यादातर pipeline मिलते-जुलते क्रम पर आ जाती हैं। हर स्टेज का एक समय-बजट होना चाहिए; स्टेज उससे बढ़ जाए तो टीम उसे पैरलल करती है, धीमे टेस्ट बाद के स्टेज में ले जाती है, या दोहराई गई कवरेज हटाती है।

• Commit stage (मिनट) — static जाँचें (lint, type check, formatting, dependency और secret scanning), यूनिट टेस्ट और component टेस्ट जिनमें dependencies की जगह test doubles हों। हर push और pull request पर चलता है।
• Integration और API स्टेज — असली डेटाबेस, queue और service containers के साथ एप्लिकेशन; API टेस्ट कॉन्ट्रैक्ट (OpenAPI) के विरुद्ध। यहीं ज़्यादातर बिज़नेस नियम उचित लागत पर वेरिफ़ाई होते हैं।
• End-to-end / UI स्टेज — असली ब्राउज़र या डिवाइस से अहम यूज़र यात्राओं का छोटा सेट; सबसे धीमा और flakiness के प्रति सबसे संवेदनशील, इसलिए जानबूझकर छोटा रखा जाता है।
• Non-functional स्टेज — छोटा performance smoke (मुख्य endpoints पर कुछ मिनट का लोड, latency और error rate की thresholds के साथ), security scans (static analysis, dependency vulnerabilities, बेसलाइन dynamic scan), मुख्य पेजों पर accessibility जाँच।
• Post-deployment स्टेज — अभी-अभी डिप्लॉय हुए एनवायरनमेंट पर smoke टेस्ट और health checks, फिर synthetic monitoring। डिप्लॉयमेंट वेरिफ़िकेशन गाइड में विस्तार से।
• Scheduled स्टेज — पूरा regression सूट, लंबे लोड टेस्ट और पूरे security scans हर बदलाव पर नहीं बल्कि रात में या हफ़्ते में चलते हैं, और उस owner को रिपोर्ट करते हैं जो फ़ेलियर पर कार्रवाई करता है।

आज़माएँ: OpenAPI → टेस्ट केस आज़माएँ: Concurrent रिक्वेस्ट टेस्ट जनरेटर आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र

उदाहरण: commit, API, E2E और deploy स्टेज वाली pipeline

नीचे दिया workflow GitHub Actions syntax में लिखा एक उदाहरण है। यह पहले static जाँचें और यूनिट टेस्ट चलाता है, फिर migrations और सिंथेटिक seed डेटा के साथ एक अस्थायी PostgreSQL service container के विरुद्ध API टेस्ट, फिर चार पैरलल shards में बँटा ब्राउज़र सूट, और main branch पर staging में डिप्लॉय करके smoke स्क्रिप्ट चलाता है। हर टेस्ट job फ़ेल होने पर भी अपनी रिपोर्ट और artifacts अपलोड करता है (`if: always()`), क्योंकि बिना सबूत वाला फ़ेलियर जाँचने में सबसे महँगा होता है। GitLab CI और Jenkins यही ढाँचा `.gitlab-ci.yml` या Jenkinsfile में stages और jobs से व्यक्त करते हैं।

• `needs` क्रम को स्पष्ट करता है: यूनिट या API टेस्ट फ़ेल हों तो E2E shards कभी शुरू नहीं होते।
• `concurrency` के साथ `cancel-in-progress` उसी pull request पर नए push से दूसरा run शुरू होने पर पहले से चल रहा run रोक देता है, जिससे runner का समय बचता है। main और nightly schedule refs/heads/main वाला एक ही group साझा करते हैं; उन पर चल रहा run कभी रद्द नहीं होता, ताकि कोई डिप्लॉयमेंट बीच में न टूटे; फिर भी, हर concurrency group के डिफ़ॉल्ट व्यवहार की तरह, group में इंतज़ार कर रहा (pending) run नया run queue होने पर रद्द हो जाता है।
• `timeout-minutes` अटके टेस्ट को घंटों इंतज़ार करते job की जगह दिखने वाले फ़ेलियर में बदल देता है।
• Deploy token प्लेटफ़ॉर्म के secret store से आता है; डेटाबेस पासवर्ड literal सिर्फ़ इसलिए है क्योंकि container एक ही job तक जीता है।
• Schedule डिफ़ॉल्ट branch पर चलता है; GitHub Actions में cron समय UTC में होते हैं, जब तक schedule में कोई time zone तय न किया गया हो।

# 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) पास/फ़ेल नियम वाली एक जाँच है जो तय करती है कि बदलाव अगले स्टेज — merge, staging पर डिप्लॉय, प्रोडक्शन में promotion — तक जा सकता है या नहीं। यह exit criteria का ऑटोमेटेड रूप है। गेट तब उपयोगी है जब वह वस्तुनिष्ठ हो, जल्दी जाँचा जा सके, किसी असली जोखिम से जुड़ा हो और बिना अपवाद लागू हो; जिस गेट को नियमित रूप से override किया जाए, वह सबको उसे अनदेखा करना सिखाता है।

दिखावटी गेट (vanity gates) से सावधान रहें। "लाइन कवरेज कम से कम 80% हो" जैसा नियम मापना आसान है और ऐसे टेस्ट से पूरा करना भी आसान जो कोड चलाते हैं पर कुछ उपयोगी assert नहीं करते। कवरेज ट्रेंड के रूप में और अनटेस्टेड कोड खोजने के लिए उपयोगी है; बिना संदर्भ के कच्ची threshold के रूप में यह ग़लत व्यवहार को इनाम देती है। ज़्यादा उपयोगी रूप है बदली गई लाइनों की कवरेज, जिसकी समीक्षा टेस्ट के साथ हो। यही बात "टेस्ट की संख्या" या "retry के बाद 100% pass rate" पर लागू होती है: ये गतिविधि बताती हैं, जोखिम नहीं।

• सभी ज़रूरी जाँचें हरी: build, lint, type check, यूनिट, API और E2E टेस्ट — quarantine सूची के बाहर कोई टेस्ट skip नहीं।
• Dependencies या static analysis में कोई नई critical या high vulnerability नहीं, या दर्ज किया गया समय-सीमित अपवाद।
• API कॉन्ट्रैक्ट अपरिवर्तित, या बदलाव backward compatible (कोई फ़ील्ड हटाया नहीं, कोई नया अनिवार्य इनपुट नहीं) जब तक नया version न हो।
• Performance smoke thresholds के भीतर, जैसे smoke लोड पर p95 latency 400 ms से कम और error rate 1% से कम, पिछली main-branch बेसलाइन की तुलना में।
• डेटाबेस migrations मौजूदा schema की कॉपी पर साफ़ लागू हुईं और, जहाँ प्रक्रिया माँगे, टेस्ट किया हुआ rollback या forward-fix प्लान।
• प्रोडक्शन promotion के लिए: staging पर post-deployment smoke पास और रिलीज़ पर कोई खुला blocker दोष नहीं।

टेस्ट रिपोर्ट और artifacts

Pipeline का नतीजा उतना ही उपयोगी है जितना वह पीछे छोड़ती है। JUnit XML टेस्ट नतीजों का आम interchange फ़ॉर्मेट है: ज़्यादातर test runner इसे लिख सकते हैं और ज़्यादातर CI सिस्टम इसे पढ़ सकते हैं। यह औपचारिक मानक नहीं बल्कि de facto फ़ॉर्मेट है, इसलिए टूल्स के बीच attributes थोड़े बदलते हैं, पर मूल ढाँचा — test suites जिनमें test cases हों, हर एक में वैकल्पिक failure, error या skipped element और अवधि — व्यापक रूप से समर्थित है। उदाहरण के लिए GitLab इसे `artifacts:reports:junit` से पढ़ता है और merge request में नए और ठीक हुए फ़ेलियर दिखाता है; Jenkins इसे हर टेस्ट के इतिहास के साथ test results के रूप में प्रकाशित करता है।

पास/फ़ेल सारांश के अलावा वे artifacts रखें जिनसे कोई व्यक्ति दोबारा चलाए बिना फ़ेलियर का निदान कर सके: एप्लिकेशन और test runner के लॉग, UI फ़ेलियर के लिए स्क्रीनशॉट और वीडियो, traces (Playwright trace actions, नेटवर्क और DOM snapshots रिकॉर्ड करता है और run के बाद खोला जा सकता है), API फ़ेलियर के लिए HTTP request/response कैप्चर, और कवरेज रिपोर्ट। Retention अवधि तय करें ताकि पिछले runs से तुलना हो सके पर artifacts हमेशा जमा न होते रहें, और सुनिश्चित करें कि उनमें असली व्यक्तिगत डेटा या secrets न हों।

<?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>

एनवायरनमेंट, टेस्ट डेटा और secrets

Pipeline टेस्ट को चलने की जगह चाहिए। Ephemeral एनवायरनमेंट — एक pipeline run या एक pull request के लिए बनाए और बाद में नष्ट किए जाने वाले — हर बदलाव को साफ़, अलग-थलग stack देते हैं: डेटाबेस और queues के लिए service containers, या हर branch के लिए अल्पकालिक preview deployment। ये झूठे फ़ेलियर के एक बड़े कारण को हटाते हैं: साझा डेटा के ज़रिए टेस्ट का आपस में टकराना। लंबे समय तक चलने वाले साझा एनवायरनमेंट (प्रोडक्शन जैसा staging) असली third parties के साथ integration और रिलीज़ रिहर्सल के लिए अब भी ज़रूरी हैं, पर वे drift करते हैं, इसलिए pipeline में उनके versions और कॉन्फ़िगरेशन जाँचें।

टेस्ट डेटा pipeline को ख़ुद बनाना चाहिए: migrations schema बनाती हैं, seed स्क्रिप्ट ज्ञात सिंथेटिक बेसलाइन लोड करती हैं, और हर टेस्ट अपने ज़रूरी रिकॉर्ड unique identifiers के साथ बनाता है ताकि पैरलल runs न टकराएँ। प्रोडक्शन का व्यक्तिगत डेटा कभी CI में कॉपी न करें। Secrets — API keys, deploy tokens, साझा एनवायरनमेंट के डेटाबेस पासवर्ड — CI प्लेटफ़ॉर्म के secret store या बाहरी vault में रहें, सिर्फ़ ज़रूरी एनवायरनमेंट तक सीमित, लॉग में masked और rotate किए जाते हुए। GitHub Actions में forks से आए pull requests से शुरू हुए workflows को डिफ़ॉल्ट रूप से repository secrets नहीं मिलते — यह रखने लायक सुरक्षा फ़ीचर है, इससे बचने का रास्ता ढूँढने लायक समस्या नहीं।

• जहाँ संभव हो हर run के लिए एक एनवायरनमेंट; साझा एनवायरनमेंट सिर्फ़ वहाँ जहाँ वे ऐसी वास्तविकता जोड़ें जो और तरीक़े से न मिले।
• Schema migrations से, बेसलाइन seed स्क्रिप्ट से, हर टेस्ट का डेटा unique ids के साथ।
• शुरुआती स्टेज में third parties को उनकी सीमा पर mock या stub करें; असली integration बाद के छोटे स्टेज में टेस्ट करें।
• Secrets कभी repository में नहीं, कभी प्रिंट नहीं, कभी artifacts में नहीं।

आज़माएँ: टेस्ट डेटा फ़ैक्टरी

पैरलल execution और sharding

जब सूट अपने समय-बजट से बड़ा हो जाए, उसे पैरलल चलाएँ। एक मशीन के भीतर runners कई workers इस्तेमाल करते हैं; मशीनों के पार सूट को shards में बाँटा जाता है, हर shard अपने runner पर एक उपसमूह चलाता है, जैसा ऊपर के उदाहरण में है। Shards संतुलित हों तो sharding wall-clock समय को लगभग shards की संख्या के अनुपात में घटाती है; रिकॉर्ड की गई टेस्ट अवधि के आधार पर बाँटना फ़ाइलों की गिनती के आधार पर बाँटने से बेहतर संतुलन देता है।

पैरलल चलाना टेस्ट के बीच छिपी निर्भरताएँ उजागर करता है: एक ही यूज़र को बदलने वाले दो टेस्ट, ऐसा टेस्ट जो किसी दूसरे के पहले चलने पर निर्भर हो, कोई fixed port या file path। ये टेस्ट डिज़ाइन के दोष हैं, और intermittent फ़ेलियर के रूप में दिखते हैं। हर worker का डेटा अलग रखें, क्रम-निर्भरता से बचें, और हर shard की रिपोर्ट को एक नतीजे में merge करें ताकि गेट पूरे सूट का मूल्यांकन करे।

Pipeline में flaky टेस्ट से निपटना

Flaky टेस्ट एक ही कोड पर कभी पास और कभी फ़ेल होता है। Pipeline में यह दोहरा नुक़सान करता है: अच्छे बदलावों को रोकता है, और लोगों को हरा होने तक "re-run" दबाना सिखाता है, जिसके बाद असली फ़ेलियर भी अनदेखे होने लगते हैं। Non-determinism पर Martin Fowler का लेख quarantine को जवाब के रूप में बताता है: flaky टेस्ट को gating सूट से हटाकर एक अलग, फिर भी चलने वाले सेट में रखें, ताकि टेस्ट ठीक होने तक pipeline भरोसेमंद रहे। कारण और समाधान flaky टेस्ट गाइड में हैं; pipeline को एक नीति चाहिए।

• Retries: अधिकतम एक ऑटोमैटिक retry की अनुमति दें, जो टेस्ट सिर्फ़ retry पर पास हो उसे passed नहीं बल्कि flaky रिपोर्ट करें, और पूरे job को चुपचाप कभी retry न करें।
• Quarantine: quarantined टेस्ट अब भी चलता और रिपोर्ट करता है, gate नहीं करता, उसका owner और ticket होता है, और ठीक करने या हटाने की डेडलाइन होती है।
• Tracking: हर flaky घटना दर्ज करें (test id, commit, error, run का लिंक) ताकि टीम सबसे बुरे टेस्ट की रैंकिंग कर सके; हर टेस्ट का flake rate देखने लायक संख्या है।
• सीमाएँ: quarantine सूची के आकार की सीमा रखें; बढ़ती quarantine संकेत है कि टेस्ट डिज़ाइन पर ध्यान चाहिए, समस्याएँ पार्क करने की जगह नहीं।

Pipeline फ़ेलियर विश्लेषण: एक ट्राइएज फ़्लो

लाल pipeline के चार आम कारण होते हैं: बदलाव से आया प्रोडक्ट दोष, ग़लत या पुराना टेस्ट, एनवायरनमेंट या इन्फ़्रास्ट्रक्चर की समस्या, या flaky टेस्ट। हर लाल build को प्रोडक्ट बग मानना डेवलपर का समय बर्बाद करता है; हर लाल build को flakiness मानना दोषों को निकल जाने देता है। एक छोटा, साझा ट्राइएज फ़्लो मिनटों में सही वर्गीकरण तक पहुँचाता है। पहला सवाल हमेशा वही है: ठीक-ठीक क्या फ़ेल हुआ, और artifacts ने क्या दर्ज किया?

नीचे का ट्राइएज फ़्लो पाँच सवाल क्रम से पूछता है। (1) क्या job किसी भी टेस्ट के चलने से पहले फ़ेल हुआ (dependency install, build, image pull, runner का खो जाना)? हाँ, तो यह pipeline या इन्फ़्रास्ट्रक्चर की समस्या है, जिसकी owner platform टीम है: इसे ठीक करें, फिर re-run करें। (2) क्या यह setup के दौरान फ़ेल हुआ (DB तैयार नहीं, migration error, unhealthy सर्विस, expired secret)? हाँ, तो यह एनवायरनमेंट की समस्या है: एनवायरनमेंट ठीक करें, टेस्ट को न छुएँ। (3) फ़ेल हुए टेस्ट उसी commit पर एक बार दोबारा चलाएँ: अब पास हों तो यह flaky होने का उम्मीदवार है — इसे दर्ज करें (test id, commit, error, run का लिंक), इसका ticket खोलें या अपडेट करें, और फिर से हो तो quarantine करें; हरा re-run यह साबित नहीं करता कि बदलाव सुरक्षित है। फिर भी फ़ेल हों तो फ़ेलियर deterministic है, अगले सवाल पर जाएँ। (4) क्या वही टेस्ट इस बदलाव के बिना main पर भी फ़ेल होता है? हाँ, तो यह पहले से मौजूद टूट या एनवायरनमेंट drift है: main के owner को बताएँ; नहीं, तो कारण यही बदलाव है, आख़िरी सवाल पर जाएँ। (5) क्या प्रोडक्ट का व्यवहार ग़लत है, या टेस्ट की अपेक्षा पुरानी हो गई है? प्रोडक्ट ग़लत है तो यह प्रोडक्ट दोष है: बग रिपोर्ट बने और merge रुका रहे; नया व्यवहार जानबूझकर है तो उसी बदलाव में टेस्ट अपडेट करें, जिसकी समीक्षा कोड की तरह हो।

• पहली error पढ़ें, आख़िरी नहीं; बाद के फ़ेलियर अक्सर उसी के परिणाम होते हैं।
• उसी job के आख़िरी हरे run से तुलना करें: बदली dependencies, runner image, डेटा या कॉन्फ़िगरेशन।
• हर लाल build के वर्गीकरण के साथ failure log रखें; एक महीने में यह दिखा देता है कि pipeline मुख्यतः दोषों, flakiness या एनवायरनमेंट से पीड़ित है।
• Pipeline द्वारा पकड़े गए प्रोडक्ट दोषों की सामान्य बग रिपोर्ट बनती है, जिसमें फ़ेल टेस्ट, commit और artifacts अटैच हों।

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.

आज़माएँ: AI एरर मैसेज एनालाइज़र

CI/CD में टेस्टर क्या करता है

Pipeline वाली टीमों में टेस्टर scripted जाँचें हाथ से चलाने में कम समय लगाते हैं, और यह तय करने में ज़्यादा कि pipeline क्या जाँचे, उसे भरोसेमंद बनाए रखने में, और उसे टेस्ट करने में जो pipeline नहीं जाँच सकती। नीचे का काम एक व्यावहारिक सारांश है; किस स्तर पर कौन-से टेस्ट ऑटोमेट हों, यह manual बनाम automated testing गाइड में है, और delivery की सेहत दिखाने वाली मेट्रिक्स — DORA मेट्रिक्स में change fail rate और failed deployment recovery time — हर रिलीज़ पर टीम के साथ समीक्षा के लायक हैं।

• जोखिमों को स्टेज से जोड़ें: कौन-सी जाँच, किस स्टेज पर, किस फ़ेलियर से बचाती है।
• Regression सूट डिज़ाइन और रिव्यू करें, जिसमें pull requests बनाम nightly runs के लिए चयन नियम शामिल हों।
• टीम के साथ क्वालिटी गेट परिभाषित करें और दिखावटी गेट पर सवाल उठाएँ।
• Flaky टेस्ट नीति और failure log के owner बनें; डेवलपर के साथ लाल builds का ट्राइएज करें।
• Post-deployment smoke जाँचें लिखें और रिलीज़ से पहले rollback मानदंड तय करें।
• नए फ़ीचर्स के लिए exploratory testing रखें — कोई pipeline उस व्यक्ति की जगह नहीं लेती जो वह खोजता है जिसे ऑटोमेट करने की किसी ने सोची ही नहीं।

आज़माएँ: रिग्रेशन सिनेरियो जनरेटर आज़माएँ: API हेल्थ चेकर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Continuous Integration (Martin Fowler)martinfowler.com · 2024continuous integration का व्यापक रूप से संदर्भित विवरण: बार-बार integrate करें, build को self-testing और तेज़ रखें, टूटा build तुरंत ठीक करें।
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• GitHub Actions documentationGitHubGitHub Actions में workflows, jobs, runners और artifacts कैसे परिभाषित होते हैं — जहाँ हर push या pull request पर ऑटोमेटेड टेस्ट चलते हैं।
• GitLab CI/CDGitLabपाइपलाइन, जॉब और आर्टिफ़ैक्ट कैसे परिभाषित होते हैं — जहाँ हर बदलाव पर ऑटोमेटेड रिग्रेशन सूट चलता है।
• Unit test reports — GitLab CI/CDGitLabJUnit XML नतीजों को pipeline artifact के रूप में प्रकाशित करना ताकि फ़ेल टेस्ट merge request में दिखें और रनों के बीच तुलना हो सके।
• Pipeline — Jenkins User HandbookJenkins ProjectJenkinsfile में कोड के रूप में परिभाषित Jenkins pipeline: stages, steps, parallel execution और टेस्ट नतीजों का प्रकाशन।
• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011flaky टेस्ट सूट का मूल्य क्यों नष्ट करते हैं, उनके आम कारण (isolation, asynchrony, remote services, समय, resource leak) और जवाब के रूप में quarantine।
• DORA's software delivery performance metricsDORA (Google Cloud)DORA के डिलीवरी मेट्रिक्स — change lead time, deployment frequency, failed deployment recovery time, change fail rate आदि — throughput और instability में समूहित।