क्वालिटी गेट्स

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 19 मिनट · शुरुआती

Quality gate delivery के दो stages के बीच का एक checkpoint है, जहाँ किसी change या release के evidence की तुलना पहले से तय criteria से की जाती है, और नतीजा तय करता है कि काम आगे बढ़ सकता है या नहीं। उदाहरण: pull request merge होने से पहले build सफल होना चाहिए, सभी unit और API tests pass होने चाहिए, और dependency scan, जो code में इस्तेमाल होने वाली third-party libraries में known security vulnerabilities ढूँढता है, कोई नई critical vulnerability न दिखाए। कोई भी check fail हो, तो merge तब तक रुका रहता है जब तक समस्या ठीक न हो जाए।

Entry और exit criteria वाले lesson में आपने तय किया था कि कोई activity कब शुरू हो सकती है और कब पूरी मानी जाती है। Gate वह जगह है जहाँ ऐसे criteria जाँचे और लागू किए जाते हैं: एक stage के exit criteria अक्सर अगले stage के entry criteria भी होते हैं, और gate उनके बीच बैठता है। कुछ gates pipeline में automated checks होते हैं, कुछ release process में किसी नामित व्यक्ति का फ़ैसला। ISTQB glossary quality gate को project की उन phases के बीच एक milestone बताता है जो पिछली phase के नतीजे पर बहुत निर्भर करती हैं, और जिसमें पिछली phase ने जो बनाया उसकी formal जाँच होती है। Teams इन्हें stage gate या checkpoint भी कहती हैं, और production से ठीक पहले वाले gate को अक्सर release gate कहा जाता है।

यह क्यों ज़रूरी है

Gate के बिना "ready" का फ़ैसला वह करता है जिस पर उस दिन सबसे ज़्यादा दबाव होता है। Merge के समय नज़रअंदाज़ किया गया failing test पूरी team के लिए main branch तोड़ देता है; छूट गया known critical defect users के लिए incident बन जाता है। Gate इस बहस को पहले से शांति से तय किए गए rules की जाँच से बदल देता है, और known problems को तब रोकता है जब उन्हें ठीक करना अभी सस्ता है।

Tester के लिए gates वह जगह हैं जहाँ quality की जानकारी सच में कुछ तय करती है: test results, coverage और defect counts तभी मायने रखते हैं जब वे किसी फ़ैसले में काम आते हैं। Gate फ़ैसले को दिखने लायक भी बनाता है। अगर कोई criterion पूरा न होने के बावजूद release निकलता है, तो record बताता है कि risk किसने और क्यों स्वीकार किया, बजाय इसके कि बाद में समस्या "QA से छूट गया" बन जाए।

Gates कहाँ होते हैं: pipeline और release process

हर gate के हिस्से एक जैसे होते हैं: दो stages के बीच एक position, pass/fail वाले criteria, हर criterion का evidence कहाँ से पढ़ा जाता है (pipeline report, test report या defect tracker), एक owner, और fail होने पर action। फ़र्क़ बस इतना है कि फ़ैसला कौन करता है।

Pipeline gates automated होते हैं और हर change पर चलते हैं; GitHub और GitLab जैसे platforms pipeline के नतीजे को required check बना सकते हैं, ताकि लाल रहते pull request merge न हो सके। Release process के gates कम होते हैं: कोई व्यक्ति पूरे release का evidence देखकर फ़ैसला करता है। ज़्यादातर teams दोनों को मिलाती हैं:

Merge gate (automated): हर pull request पर build, static checks, unit और API tests; कोई भी लाल check merge रोक देता है।
Test exit gate: system और regression testing के बाद test plan के exit criteria को test report से मिलाकर जाँचा जाता है।
Release gate (व्यक्ति फ़ैसला करता है): production से पहले gate owner evidence देखकर go या no-go तय करता है, या एक recorded exception approve करता है।
Post-deploy gate: deployment के तुरंत बाद smoke tests और health checks चलते हैं; fail होने पर rollback होता है।

Pull request से live release तक चार gates: merge पर automated checks, testing के बाद exit criteria, release के लिए owner का go/no-go, और deploy के तुरंत बाद smoke और health checks।

1Pull requestहर change पर build, static checks, unit और API testsAutomated
शाखा: कोई check लाल → merge रुकाफ़ेल
गेट: Merge gate: सभी required checks हरे
2Test environmentMerged build की system और regression testing
शाखा: Exit criteria पूरे नहीं → testing जारी रखें या fix करेंफ़ेल
गेट: Test exit gate: test report में exit criteria पूरे
3Staging पर release candidateGate owner पूरे release का evidence देखता हैव्यक्ति तय करता है
शाखा: No-go → fix, re-test, नया candidateफ़ेल
गेट: Release gate: go, या recorded exception
4Production: post-deploy gateDeploy के तुरंत बाद smoke tests और health checksAutomated
शाखा: कोई check fail → rollbackफ़ेल

इसके बाद:सभी checks pass: release live रहता है

Exception (waiver)सिर्फ़ gate owner या नामित deputy approve करता है; पूरा न हुआ criterion, कारण, risk, mitigation और expiry record होते हैं

उदाहरण के तौर पर: gates की संख्या और जगह हर team में अलग होती है।

आज़माएँ: API हेल्थ चेकर

Gate criteria जो सच में काम करते हैं

उपयोगी criterion measurable होता है, किसी असली risk से जुड़ा होता है, अपने stage के हिसाब से जल्दी जाँचा जा सकता है, और काम शुरू होने से पहले तय होता है। "Quality ठीक है" पहली शर्त पर ही fail हो जाता है, क्योंकि कोई नहीं बता सकता कि यह पूरा हुआ या नहीं; "कोई open blocker या critical defect नहीं" चारों शर्तें पूरी कर सकता है। नीचे की policy सिर्फ़ उदाहरण है, किसी CI tool का syntax नहीं, और उसके numbers भी उदाहरण हैं: अपने numbers अपनी baseline से लें।

Vanity criteria से बचें। "Line coverage कम से कम 80%" और "95% tests pass" दोनों पूरे हो सकते हैं जबकि checkout टूटा हुआ हो: पहला ऐसे tests को इनाम देता है जो कुछ जाँचते नहीं, दूसरा छिपा देता है कि कौन-से 5% fail हुए। Coverage बताती है कि क्या untested है; यह quality साबित नहीं करती। "Scope के हर acceptance criterion का एक passing test है" और "critical-journey suite में कोई failing test नहीं" जैसे criteria बेहतर हैं।

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 फ़ॉर्मेटर आज़माएँ: Requirements → टेस्ट केस आज़माएँ: रिस्पॉन्स कॉन्ट्रैक्ट कम्पेरेटर

Gate का owner कौन है, और exceptions कैसे संभाले जाते हैं

हर gate का एक नामित owner होना चाहिए जो उसके criteria संभाले और exceptions पर फ़ैसला करे: आम तौर पर merge gate के लिए engineering lead, security criteria के लिए security function, और release gate के लिए product owner या release manager। Tester शायद ही कभी अकेले किसी gate का owner होता है; tester evidence और साफ़ recommendation देता है, owner फ़ैसला करता है और उसकी ज़िम्मेदारी लेता है।

Exceptions होंगे ही, जैसे जब कोई urgent fix ship करना हो और कोई असंबंधित check लाल हो, और जिस gate में exception process नहीं होता उसे अनौपचारिक तरीके से bypass किया जाता है। ISTQB Foundation syllabus exit criteria के बारे में मिलती-जुलती बात कहता है: जब समय या budget ख़त्म हो जाए, तो सभी criteria पूरे किए बिना testing ख़त्म करना स्वीकार्य हो सकता है, अगर stakeholders ने risk की समीक्षा करके उसे स्वीकार किया हो। इसलिए exceptions को स्पष्ट बनाएँ:

Approve सिर्फ़ gate owner या कोई नामित deputy करे, exception माँगने वाला व्यक्ति कभी नहीं।
Record में पूरा न हुआ criterion, कारण, user की भाषा में risk, mitigation और approver लिखा हो।
हर exception की एक expiry हो और owner के साथ एक follow-up ticket हो।
Flaky test को ticket के साथ quarantine करें: उसे blocking suite से निकालकर एक अलग run में रखें जिस पर नज़र रखी जाती है; delete या चुपचाप skip कभी नहीं।
जिस criterion को बार-बार छूट मिलती है वह या तो गलत है या नज़रअंदाज़ हो रहा है; उसे खुले तौर पर बदलें।

Worked example: एक criterion पर अटका release

एक online store release 3.4 की योजना बना रहा है जिसमें नया discount-code feature है। Release gate का owner product owner है और उसके चार criteria हैं: regression suite pass; scope के हर acceptance criterion का passing test; कोई open blocker या critical defect नहीं; smoke load पर checkout API की p95 latency अधिकतम 800 ms। Evidence QA lead देता है।

Release के दिन 412 में से 412 regression tests pass हैं, सभी 38 acceptance criteria के passing tests हैं और p95 latency 640 ms है। लेकिन एक critical defect open है: DEF-1182, धीमे connection पर user "Apply" पर double-click करे तो discount दो बार लग जाता है। Gate fail होता है: या तो release confirmed fix का इंतज़ार करे, या owner exception approve करे।

Release 3.4 का बाकी हिस्सा, जिसमें customers के इंतज़ार वाले fixes भी हैं, तैयार है, और नया feature एक feature flag के पीछे है, इसलिए team flag बंद रखकर release करने का प्रस्ताव देती है। Product owner approve करता है, और exception record होता है:

Gate और पूरा न हुआ criterion: release 3.4 का release gate; "कोई open blocker या critical defect नहीं" (DEF-1182 open है)।
कारण और risk: 3.4 के बाकी changes तय तारीख़ पर चाहिए; अगर flag चालू हो जाए, तो customers को discount दो बार मिल सकता है।
Mitigation: production में flag बंद रहता है; QA lead ने staging पर जाँच लिया है कि तब discount field तक पहुँचा नहीं जा सकता और checkout release 3.3 की तरह चलता है।
Approved by: product owner, QA lead और engineering lead के साथ समीक्षा के बाद।
Expiry और follow-up: DEF-1182 ही follow-up ticket है, जिसका owner engineering lead है; flag तब तक बंद रहेगा जब तक इसका fix confirmation testing और regression testing pass न कर ले, और exception ज़्यादा से ज़्यादा release 3.5 तक बंद हो जाएगा।

आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र

आम गलतियाँ

"Quality काफ़ी अच्छी है" या "ज़्यादातर tests pass हैं" जैसे criteria, जिन्हें मापा नहीं जा सकता।
80% line coverage जैसे raw vanity thresholds, जो critical journeys टूटी होने पर भी पूरे हो सकते हैं।
Gate को हरा करने के लिए failing test को skip या delete कर देना, बजाय उसे ticket के साथ quarantine करने के।
ज़ुबानी exceptions, बिना record, approver और expiry के, जिनका follow-up कोई नहीं करता।
लंबे suites जोड़-जोड़कर merge gate को इतना धीमा कर देना कि लोग उससे बचने के रास्ते निकालने लगें; लंबे suites बाद के gates या scheduled runs में होने चाहिए।
Tester को अकेला gatekeeper मानना: tester evidence और recommendation देता है, नामित owner फ़ैसला करता है।

QA का नज़रिया

Gates design होते समय शामिल हों, आम तौर पर test planning के दौरान। अपनी पहचानी हुई product risks से जुड़े criteria सुझाएँ, देखें कि हर criterion का data source हो (pipeline report, test management tool या defect tracker), और पूछें कि हर gate का owner कौन है और exception कौन, कितने समय के लिए approve कर सकता है। फिर जवाब test plan या team के working agreement में लिखें।

Gate पर आपका काम evidence है: हर criterion, उसकी actual value, pass या fail, और report कहाँ है। कोई criterion पूरा न हो तो risk को user की भाषा में बताएँ, अपनी recommendation दें और फ़ैसला owner पर छोड़ें; अगर risk स्वीकार हो, तो पक्का करें कि exception record हुआ और उसका follow-up ticket assign हुआ। Retrospective में exceptions की समीक्षा करें: जिस gate को हमेशा छूट मिलती है वह gate नहीं रह जाता।

अभ्यास

एक छोटी product team के लिए gates design करें

आपका काम

छह लोगों की एक team food-ordering web app बनाती है, रोज़ लगभग पंद्रह pull requests merge करती है और हर दो हफ़्ते में release करती है। पिछले महीने एक pull request failing unit test के साथ merge हो गया क्योंकि "वह test तो वैसे भी flaky है"; refunds में एक known critical defect के साथ release निकल गया, और कोई नहीं जानता कि यह किसने तय किया; और एक deployment के बाद order-tracking page 40 मिनट तक HTTP 500 लौटाता रहा, जब तक किसी customer ने report नहीं किया।

ऐसे gates सुझाएँ जो हर समस्या को रोक देते, और एक exception rule जिसके साथ team काम कर सके।

चरण

हर incident के लिए वह gate बताएँ जिसे उसे पकड़ना चाहिए था, और वह कहाँ है।
हर gate के लिए दो-तीन measurable criteria लिखें, और हर criterion का evidence कहाँ से पढ़ा जाएगा।
हर gate का owner और fail होने पर action बताएँ।
Exception rule लिखें: कौन approve करेगा, क्या record होगा, वह कब expire होगा।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

Merge gate, जो पहला incident रोकता (automated, हर pull request पर; owner: engineering lead): build pass, शून्य failed unit और API tests, कोई test बिना ticket के skip नहीं; evidence: pipeline report। Fail होने पर merge रुकता है; flaky test को नज़रअंदाज़ नहीं, ticket के साथ quarantine किया जाता है।

Release gate, जो दूसरा incident रोकता (production से पहले; owner: product owner; evidence QA lead से): regression suite pass, scope के हर acceptance criterion का passing test, कोई open blocker या critical defect नहीं; evidence: test report और defect tracker। Fail होने पर जवाब no-go है जब तक exception approve न हो, यानी refund defect या तो ठीक होगा या कोई नामित व्यक्ति उसे जानते-बूझते स्वीकार करेगा।

Post-deploy gate, जो तीसरा incident रोकता (हर deployment के बाद; owner: on-call release engineer): production पर order tracking समेत critical journeys के smoke tests और मुख्य APIs के health checks pass हों; evidence: deployment pipeline report। Fail होने पर rollback, ताकि टूटा हुआ page customer से पहले team पकड़ ले।

Exception rule: approve सिर्फ़ gate owner या नामित deputy करे; record में पूरा न हुआ criterion, कारण, risk, mitigation और approver हो; हर exception का follow-up ticket हो, वह ज़्यादा से ज़्यादा अगले release पर expire हो और retrospective में उसकी समीक्षा हो।

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

क्या quality gate और exit criteria एक ही चीज़ हैं?

पूरी तरह नहीं। Exit criteria वे शर्तें हैं जो बताती हैं कि कोई activity पूरी हो गई। Quality gate process का वह point है जहाँ ऐसी शर्तें जाँची जाती हैं और फ़ैसला लागू होता है। दो stages के बीच का gate आम तौर पर पहले stage के exit criteria जाँचता है, जो अक्सर दूसरे stage के entry criteria भी होते हैं।

क्या release रोकने का फ़ैसला tester को करना चाहिए?

Tester evidence और recommendation देता है, और जब कोई criterion पूरा न हो तो साफ़ कहता है। फ़ैसला gate owner का होता है, अक्सर product owner या release manager, क्योंकि business risk उनका है। अगर evidence को गलत तरीके से पेश किया जाए या gate बिना record के bypass हो, तो tester को escalate करना चाहिए।

क्या कोई gate ज़रूरत से ज़्यादा सख़्त हो सकता है?

हाँ। धीमा gate, flaky tests की वजह से शोर करने वाला gate, या vanity numbers पर बना gate लोगों को उससे बचने के रास्ते निकालना सिखा देता है। तेज़ checks merge gate में रखें और धीमे suites बाद के gates या scheduled runs में, यह track करें कि gate कितनी बार गलत तरीके से रोकता है या उसे छूट मिलती है, और गलत साबित होने पर criteria खुले तौर पर बदलें।

संदर्भ

ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
Continuous Integration (Martin Fowler)martinfowler.com · 2024continuous integration का व्यापक रूप से संदर्भित विवरण: बार-बार integrate करें, build को self-testing और तेज़ रखें, टूटा build तुरंत ठीक करें।
Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011flaky टेस्ट सूट का मूल्य क्यों नष्ट करते हैं, उनके आम कारण (isolation, asynchrony, remote services, समय, resource leak) और जवाब के रूप में quarantine।

टूल्स

और गहराई से

इस topic में आपकी प्रगति

इस topic से पहले

टेस्ट मेट्रिक्स जो फ़ैसले तय करें

अगले topics

रिलीज़ रेडीनेस और Go/No-Go फ़ैसला

क्वालिटी गेट्स

यह क्यों ज़रूरी है

Gates कहाँ होते हैं: pipeline और release process

Gate criteria जो सच में काम करते हैं

Gate का owner कौन है, और exceptions कैसे संभाले जाते हैं

Worked example: एक criterion पर अटका release

आम गलतियाँ

QA का नज़रिया

अभ्यास

एक छोटी product team के लिए gates design करें

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

संदर्भ

Mutqan tools से अभ्यास करें

API हेल्थ चेकर

Requirements → टेस्ट केस

रिस्पॉन्स कॉन्ट्रैक्ट कम्पेरेटर

रिस्पॉन्स टाइम एनालाइज़र

YAML फ़ॉर्मेटर

रिस्क-बेस्ड टेस्ट जनरेटर

और गहराई से

इस topic में आपकी प्रगति

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

यह क्यों ज़रूरी है

Gates कहाँ होते हैं: pipeline और release process

Gate criteria जो सच में काम करते हैं

Gate का owner कौन है, और exceptions कैसे संभाले जाते हैं

Worked example: एक criterion पर अटका release

आम गलतियाँ

QA का नज़रिया

अभ्यास

एक छोटी product team के लिए gates design करें

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

संदर्भ

Mutqan tools से अभ्यास करें

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics