मॉड्यूल 2 · Software development lifecycle

शिफ़्ट-लेफ़्ट और शिफ़्ट-राइट टेस्टिंग

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

Shift-left और shift-right बताते हैं कि किसी बदलाव की timeline पर testing कहाँ होती है। Shift-left testing को पहले ले आता है: user story का review, coding से पहले acceptance tests पर सहमति, और हर pull request पर static analysis। Shift-right इसे release के बाद तक बढ़ाता है: production के signals देखना, feature पहले 5% users को दिखाना, और नियंत्रित experiments चलाना।

Refinement में "discount VAT से पहले लगेगा या बाद में?" पूछने वाला tester shift-left कर रहा है। वही tester release के बाद canary का error rate बाकी users से मिलाते समय shift-right कर रहा है। दोनों में से कोई भी बीच वाली testing की जगह नहीं लेता।

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

Story review में पकड़ा गया defect सिर्फ़ एक बातचीत जितना महँगा है। Release के बाद वही defect fix, redeploy, support का समय, कभी-कभी refunds और users के भरोसे का कुछ हिस्सा माँगता है। Shift-left defects को रोकता है और बाकी को तब पकड़ता है जब बदलाव अभी छोटा है।

लेकिन कोई test environment पूरी तरह production जैसा नहीं होता: असली traffic, असली data, हर device और हर third-party service। कुछ failures सिर्फ़ वहीं दिखते हैं, और shift-right practices के बिना उन्हें सबसे पहले users देखते हैं। Tester के लिए testing अब आख़िर का एक phase नहीं, पूरे lifecycle में फैला काम बन जाती है।

Shift-left: code लिखने से पहले और उसके दौरान टेस्ट करें

ISTQB Foundation syllabus (CTFL v4.0) shift-left को पहले testing करना बताता है, code लिखे जाने या components integrate होने का इंतज़ार किए बिना, और ज़ोर देता है कि बाद की testing की अनदेखी नहीं होनी चाहिए। यह इस principle का व्यावहारिक रूप है कि early testing समय और पैसा बचाती है। नीचे की practices के अलावा syllabus दो और बातें गिनाता है: CI, और उससे भी बेहतर CD, ताकि हर बदलाव पर जल्दी feedback मिले, जैसा पिछले पाठ में देखा; और जहाँ संभव हो, performance जैसी non-functional testing component level से ही शुरू करना। Syllabus इसकी क़ीमत भी बताता है: शुरुआत में extra training और मेहनत, जो बाद में वसूल होने की उम्मीद है, और shift-left के लिए ऐसे stakeholders चाहिए जो इससे सहमत हों और इसका साथ दें।

Early reviews: testers stories, acceptance criteria और designs का testing के नज़रिए से review करते हैं। यह static testing है, जो कोई code बनने से पहले ही ambiguities, gaps और contradictions पकड़ती है।
TDD (test-driven development): developer पहले एक fail होने वाला unit test लिखता है, फिर उसे pass कराने लायक बस उतना code, फिर दोनों को refactor करता है, यानी उनका व्यवहार बदले बिना उनकी बनावट सुधारता है।
ATDD (acceptance test-driven development): feature बनने से पहले acceptance criteria से acceptance tests निकाले जाते हैं। BDD (behaviour-driven development) में ऐसे examples Given/When/Then में लिखे जाते हैं, जैसे नीचे के scenarios।
Static analysis: tools source code को चलाए बिना जाँचते हैं और undefined variables, unreachable code, coding standard के उल्लंघन और कुछ security कमज़ोरियाँ बताते हैं, आम तौर पर CI में हर pull request पर।

Feature: Checkout पर promo code

  Scenario: Valid percentage code VAT से पहले का total घटाता है
    Given cart का total VAT से पहले 150.00 SAR है
    And active code "SAVE10" 10% की छूट देता है
    When shopper code "save10" लगाता है
    Then discount 15.00 SAR है
    And VAT से पहले का total 135.00 SAR है

  Scenario: Expired code अस्वीकार होता है
    Given code "WINTER25" की validity कल ख़त्म हो गई
    When shopper code "WINTER25" लगाता है
    Then message "यह code expire हो चुका है" दिखता है
    And total नहीं बदलता

आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर आज़माएँ: Requirements → टेस्ट केस

Shift-right: release के बाद भी टेस्ट करते रहें

Shift-right industry का शब्द है, ISTQB Foundation का नहीं; कुछ teams इसके एक हिस्से को "testing in production" कहती हैं। असली traffic, असली data और हर device सिर्फ़ production में होते हैं, इसलिए लक्ष्य है निकल आए defects का नुक़सान सीमित करना और यह सीखना कि पहले की testing से क्या छूटा, न कि पहले की testing छोड़कर users पर testing करना।

Monitoring: users के अनुभव पर dashboards और alerts। टेस्टर्स के लिए DevOps वाले lesson में आए चार golden signals, जो Google की SRE book से हैं, ये हैं: latency (request में कितना समय लगता है), traffic (system तक कितनी माँग पहुँचती है), errors (fail होने वाले requests की दर) और saturation (system के resources कितने भरे हैं)। Orders प्रति घंटा जैसे business signals भी जोड़ें, क्योंकि कुछ defects कोई error नहीं देते।
Canary release: बदलाव पहले users के छोटे हिस्से तक पहुँचता है, और उसके signals को उसी अवधि में पुराने version वाले control group से मिलाया जाता है। अगर canary ख़राब हो, तो ज़्यादातर users के देखने से पहले rollback हो जाता है।
Feature flags: नया code बंद हालत में deploy होता है, फिर बिना redeploy किसी group या users के percentage के लिए on किया जाता है। Flag की दोनों states और उनके बीच का बदलाव टेस्ट करें।
A/B tests: दो सही चलने वाले variants randomly बँटे users पर साथ-साथ चलते हैं, और पहले से तय metric से उनका फ़ैसला होता है। Tester experiment की wiring जाँचता है; नतीजे का फ़ैसला product owner और analysts करते हैं।
Chaos experiments: team जान-बूझकर एक realistic fault डालती है, जैसे किसी dependency का धीमा होना, ताकि इस hypothesis को परखे कि system सामान्य व्यवहार बनाए रखता है। Experiments छोटे से शुरू होते हैं और तुरंत रोके जा सकते हैं।

आज़माएँ: API हेल्थ चेकर आज़माएँ: API रिस्पॉन्स कम्पेरेटर

Worked example: story से production तक promo-code field

एक online store checkout में promo-code field जोड़ता है; prices SAR में दो decimals के साथ हैं। Figure इस feature को release के दोनों तरफ़ दिखाता है।

Promo-code field अपनी release के दोनों तरफ़: पहले review, ATDD, TDD, static analysis और CI; बाद में staff के लिए flag, 5% canary, monitoring, एक A/B test और एक chaos experiment।

Release से पहले: shift-left
Defects रोकें और तब पकड़ें जब उन्हें ठीक करना सस्ता हो
1. 1Story reviewCoding से पहले stacking, case, VAT और rounding के सवाल हल
2. 2पहले acceptance testsATDDतय किए गए Given/When/Then examples
3. 3पहले unit testsTDD99.99 SAR का 10% = 10.00 होना चाहिए
4. 4Static analysis और reviewTyped promo code से बनी query → parameterised
5. 5CI pipelineUnit, API और acceptance tests pass
  गेट: Deploy: production में, promo_codes बंद
Release के बाद: shift-right
नुक़सान सीमित करें और असली इस्तेमाल से सीखें
1. 6Staff के लिए flag onUsers के लिए release शुरू (पहले staff, फिर 5%); test account से smoke check
2. 7Canary: 5% shoppersErrors, latency और checkouts के rates बाकी 95% से तुलना
  गेट: कोई rollback मानदंड नहीं टूटा
3. 8MonitoringEscape: एक platform का keyboard code के बाद space जोड़ता हैसावधानी
4. 9A/B testदिखता field बनाम “Have a code?” link
5. 10Chaos experimentPromo service धीमी: साफ़ message, और भुगतान फिर भी संभव

चरण 2 पर वापस Escape एक नया acceptance test बनता है: spaces वाला code स्वीकार होता है

उदाहरण वाला क्रम: release के बाद monitoring लगातार चलती है, और feature स्थिर होने पर experiments तय किए जाते हैं।

Review: tester पूछता है कि क्या code free delivery के साथ जुड़ सकता है, क्या codes case-sensitive हैं, और क्या discount VAT से पहले लगता है और कैसे round होता है। जवाब acceptance criteria में जाते हैं।
ATDD और TDD: तय किए गए examples ऊपर वाले scenarios जैसे acceptance tests बनते हैं (ध्यान दें, save10 छोटे अक्षरों में है: team ने तय किया कि codes case-sensitive नहीं हैं)। Developer पहले unit tests लिखता है, जिनमें 99.99 SAR का 10% भी है, जिसका नतीजा तय rounding (nearest 0.01) के हिसाब से 10.00 होना चाहिए, 9.99 नहीं।
Static analysis: tool एक ऐसी query पकड़ता है जो shopper के टाइप किए promo code को सीधे SQL text में चिपकाकर बनाई गई है, जिससे ख़ास तौर पर गढ़ा गया promo code query को ही बदल सकता है (SQL injection)। Reviewer merge से पहले parameterised query माँगता है, जो promo code को data की तरह भेजती है।
Flag और canary: code promo_codes बंद रखकर deploy होता है, staff के लिए on होता है, जो test accounts से smoke check करते हैं, फिर 5% shoppers के लिए। Promo errors, latency और पूरे हुए checkouts की तुलना बाकी 95% से raw counts में नहीं, rates में होती है, पहले से लिखे rollback मानदंडों के सामने।
Escape: monitoring दिखाती है कि एक mobile platform पर "invalid code" errors बढ़ रहे हैं, जिसका keyboard code के बाद space जोड़ देता है। अब fix code के शुरू और आख़िर की spaces हटा देता है, और tester spaces वाले codes के लिए acceptance test जोड़ता है: finding बाईं ओर चली जाती है।
Experiments: एक A/B test दिखते field की तुलना "Have a code?" link से पूरे हुए checkouts पर करता है, जो पहले से तय metric है। एक chaos experiment promo service को धीमा करके इस hypothesis को परखता है कि checkout अटकने के बजाय बताता है कि code अभी जाँचा नहीं जा सकता, और फिर भी shopper को भुगतान करने देता है।

आज़माएँ: प्रतिशत कैलकुलेटर

दोनों तरफ़ का संतुलन

दोनों पक्ष एक-दूसरे के पूरक हैं, विकल्प नहीं। बाईं ओर का काम सस्ता है और defects रोकता है, लेकिन team के assumptions को ही परखता है; दाईं ओर का काम असलियत देखता है, लेकिन जो वह पकड़ता है वह किसी तक पहुँच चुका होता है। हर बदलाव के लिए risk के हिसाब से वज़न तय करें।

Left को ज़्यादा वज़न दें जब failure गंभीर या अपरिवर्तनीय हो: payments, data migrations, privacy, security। Rollback ग़लत तरीके से काटी गई रक़म वापस नहीं करता।
Right को ज़्यादा वज़न दें जब सवाल का जवाब सिर्फ़ असली इस्तेमाल दे सके: असली load, devices की पूरी रेंज, और users कौन-सा design पसंद करते हैं।
Loop बंद करें: हर escaped defect के लिए वह test, review सवाल या static-analysis rule जोड़ें जो छूट गया था।
Production में testing सिर्फ़ उन systems पर करें जो आपकी team के हों या जिन्हें टेस्ट करने की लिखित अनुमति हो, test accounts के साथ, बिना असली personal data, और तुरंत रोकने के तरीके के साथ।

आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर

आम गलतियाँ

सिर्फ़ नाम का shift-left: story पहले मिल जाना लेकिन test scripts फिर भी आख़िर में लिखना, बजाय coding से पहले ऐसे सवाल पूछने के जो story बदल दें।
Shift-right को बिना टेस्ट किया code release करने की इजाज़त समझना। Production वह पकड़ता है जो pre-release testing देख नहीं सकती थी, वह नहीं जो उसने छोड़ दिया।
Feature flag को सिर्फ़ एक state में टेस्ट करना, या पुराने flags code में छोड़ देना, जहाँ हर flag टेस्ट करने लायक combinations दोगुने कर देता है।
Canary को उसी time window के control group के बजाय कल के numbers से परखना, या rollback मानदंड तय किए बिना rollout शुरू करना।
Static analysis को ज़्यादा warnings की वजह से बंद कर देना, बजाय rules को tune करने और build को सिर्फ़ तय rules पर fail करने के।
बिना अनुमति, असली customer data के साथ, या रोकने के तरीके के बिना production tests या chaos experiments चलाना।

QA का नज़रिया

Refinement में product owner और एक developer के साथ बैठें (कुछ teams इसे three amigos कहती हैं), सवाल पूछें, ठोस examples सुझाएँ और तय हुए examples को acceptance tests में बदलें। Pull requests पर static-analysis के नतीजे पढ़ें और देखें कि unit tests examples को cover करते हैं। Release से पहले rollout plan लिखने में मदद करें: flag states, canary के क़दम, देखने वाले signals, rollback मानदंड और फ़ैसला कौन करेगा।

Rollout के दौरान developers के साथ dashboards देखें; अगले दिनों में support tickets और error logs पढ़ें। जो flag states आपने टेस्ट कीं, rollback मानदंड, और production की हर finding के साथ उसके लिए जोड़ा गया test दर्ज करें। यही रिकॉर्ड team को बताता है कि उसकी testing को आगे किस तरफ़ खिसकना चाहिए।

अभ्यास

Delivery slots के लिए release के दोनों तरफ़ की planning करें

आपका काम

एक grocery app delivery time slots जोड़ रहा है। नीचे दी गई user story पढ़ें और release के दोनों तरफ़ उसकी testing की planning करें: code merge होने से पहले आप क्या करेंगे, और production तक पहुँचने के बाद क्या करेंगे।

Plan एक पन्ने में रखें। दाईं ओर की हर activity के लिए बताएँ कि आप क्या मापेंगे और कौन-सा नतीजा rollout रोक देगा।

सामग्री

User story:
एक shopper के रूप में, मैं checkout पर delivery का time slot चुनना चाहता हूँ
ताकि order आने पर मैं घर पर रहूँ।

Rules:
- हर slot 2 घंटे का है, 09:00 से 21:00 तक।
- Slot उसके शुरू होने से 3 घंटे पहले तक book हो सकता है।
- हर slot में अधिकतम 20 orders।

चरण

Story review के लिए तीन सवाल लिखें।
Given/When/Then रूप में दो acceptance tests लिखें, जिनमें एक negative हो।
Rollout लिखें: flag, canary group, monitor करने के तीन signals और एक rollback मानदंड।
एक chaos-experiment hypothesis लिखें, और बताएँ कि इस feature के लिए आप release के किस तरफ़ ज़्यादा वज़न देंगे और क्यों।

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

मॉडल उत्तर

Review के सवाल: slot के समय और 3 घंटे की cut-off कौन-सी घड़ी तय करती है, store का time zone या shopper का device? अगर दो shoppers एक ही पल में slot की आख़िरी जगह लें तो क्या होगा? अगर payment के दौरान slot भर जाए तो shopper को क्या दिखेगा?

Acceptance tests: Given 15:00–17:00 slot में 19 orders हैं और समय 11:59 है, when कोई shopper उसे book करता है, then booking सफल होती है और slot full दिखता है। Given समय 12:01 है, when shopper slot list खोलता है, then 15:00–17:00 slot नहीं दिखता (negative)। ठीक 12:00 पर booking की अनुमति है या नहीं, यह review का एक और सवाल है; जवाब मिलने पर developer इस cut-off को पहले unit test (TDD) के रूप में लिख सकता है।

Rollout: flag delivery_slots बंद रखकर deploy करें, staff के लिए on करें, फिर 5% shoppers के लिए। Booking errors, हर slot के orders (कभी 20 से ज़्यादा नहीं) और control group की तुलना में पूरे हुए checkouts monitor करें। अगर कोई slot 20 orders पार करे या पूरे हुए checkouts control group से plan में तय threshold से ज़्यादा गिरें, तो flag बंद करें।

Chaos hypothesis: अगर slot service उपलब्ध न हो, तो checkout standard delivery और साफ़ message के साथ फिर भी पूरा होता है, और कोई order नहीं खोता। Experiment के दौरान पूरे हुए checkouts और खोए orders मापें, और एक भी order खोए तो उसे तुरंत रोक दें। पहले staging में आज़माएँ, फिर production traffic के छोटे हिस्से पर।

वज़न: overbooking और time-zone errors महँगे हैं और उन्हें पलटना मुश्किल है, इसलिए capacity और cut-off rules के लिए left side को ज़्यादा वज़न दें। Shoppers slots इस्तेमाल करते भी हैं या नहीं, और कौन-सा slot layout सबसे अच्छा है, ये right side के सवाल हैं।

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

क्या shift-right सिर्फ़ testing in production का दूसरा नाम है?

Testing in production उसका एक हिस्सा है, लेकिन shift-right में monitoring, canary releases, feature flags, A/B tests और chaos experiments भी आते हैं, जो test scripts चलाने से ज़्यादा निगरानी करते हैं और risk सीमित करते हैं। यह हमेशा pre-release testing में जुड़ता है, कभी उसकी जगह नहीं लेता।

क्या shift-left का मतलब है कि testers को unit tests लिखने होंगे?

नहीं। TDD developers की practice है। Shift-left का मतलब है कि testing activities पहले शुरू होती हैं: tester सवाल, examples, acceptance tests और risk analysis देता है, और static-analysis व unit-test के नतीजे पढ़ता है। Code लिखने वाले testers tests पर developers के साथ pair कर सकते हैं, लेकिन यह bonus है, परिभाषा नहीं।

Canary release और A/B test में क्या फ़र्क है?

दोनों एक ही अवधि में दो groups की तुलना करते हैं (Google की SRE workbook तो canarying को असल में एक A/B testing process ही बताती है), लेकिन वे अलग-अलग सवालों के जवाब देते हैं। Canary पूछता है कि नया version सुरक्षित है या नहीं: वह errors और latency जैसे health signals की तुलना control group से करता है, उतनी अवधि तक जो team की release की रफ़्तार से मेल खाए, और उसका अंत पूरे rollout या rollback में होता है। A/B test पूछता है कि दो सही चलने वाले variants में से कौन-सा लक्ष्य को बेहतर पूरा करता है: वह पहले से चुने business metric की तुलना करता है और आम तौर पर ज़्यादा समय चलता है ताकि पर्याप्त users शामिल हों।

क्या बिना operations विभाग वाली छोटी team shift-right कर सकती है?

हाँ, छोटे क़दमों में: हर deploy के तुरंत बाद smoke check, errors पर alerts, मुख्य endpoints का health check, और risky बदलावों के लिए feature flag या आज़माया हुआ rollback। Canary routing और chaos experiments के लिए ज़्यादा infrastructure चाहिए और वे बाद में आ सकते हैं।

संदर्भ

ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
Canarying Releases — The Site Reliability WorkbookGoogle / O'Reilly Mediaबदलाव को पहले ट्रैफ़िक के छोटे हिस्से पर रिलीज़ करना और पूरी तरह फैलाने से पहले baseline से तुलना करना — SRE में deployment verification।
Monitoring Distributed Systems — Site Reliability Engineering (Rob Ewaschuk)Google / O'Reilly Media · 2016monitoring पर Google की SRE गाइडेंस: black-box बनाम white-box monitoring और चार golden signals — latency, traffic, errors और saturation।
Release It! Second Edition: Design and Deploy Production-Ready Software (Michael T. Nygard)The Pragmatic Bookshelf · 2018स्थिरता पैटर्न — टाइमआउट, सर्किट ब्रेकर, बल्कहेड, बैक-प्रेशर — और वे विफलता के तरीके जिन्हें लोड टेस्टिंग खोजने के लिए है।

टूल्स

और गहराई से

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

इस topic से पहले

कंटीन्यूअस इंटीग्रेशन, डिलीवरी और डिप्लॉयमेंट

शिफ़्ट-लेफ़्ट और शिफ़्ट-राइट टेस्टिंग

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

Shift-left: code लिखने से पहले और उसके दौरान टेस्ट करें

Shift-right: release के बाद भी टेस्ट करते रहें

Worked example: story से production तक promo-code field

दोनों तरफ़ का संतुलन

आम गलतियाँ

QA का नज़रिया

अभ्यास

Delivery slots के लिए release के दोनों तरफ़ की planning करें

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

संदर्भ

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

एक्सेप्टेंस क्राइटेरिया जनरेटर

Requirements → टेस्ट केस

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

API हेल्थ चेकर

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

प्रतिशत कैलकुलेटर

और गहराई से

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

इस topic से पहले

अगले topics

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

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

Shift-left: code लिखने से पहले और उसके दौरान टेस्ट करें

Shift-right: release के बाद भी टेस्ट करते रहें

Worked example: story से production तक promo-code field

दोनों तरफ़ का संतुलन

आम गलतियाँ

QA का नज़रिया

अभ्यास

Delivery slots के लिए release के दोनों तरफ़ की planning करें

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

संदर्भ

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

और गहराई से

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

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

इस topic से पहले

अगले topics

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