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

टेस्टर्स के लिए DevOps

Mutqan Soft QA टीम द्वारा · · 18 मिनट · शुरुआती

DevOps काम करने का एक तरीका है जिसमें development (testing समेत) और operations एक ही लक्ष्य साझा करते हैं: बदलावों को users तक तेज़ी और सुरक्षा से पहुँचाना, और live होने के बाद product को सही हालत में रखना। ISTQB Foundation syllabus v4.0 इसे एक organisational approach बताता है जिसके लिए cultural shift चाहिए, और जिसे team autonomy, fast feedback, integrated toolchains और continuous integration व continuous delivery जैसी practices सहारा देती हैं।

उदाहरण के लिए, testers के एक हफ़्ते बाद पूरा feature जाँचने और operations team के release की रात उसे install करने की बजाय, DevOps team feature को छोटे बदलावों में ship करती है। हर बदलाव commit के कुछ ही मिनटों में अपने-आप build और test होता है, health check के साथ deploy होता है और production में उस पर नज़र रखी जाती है।

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

जब product बनाने, टेस्ट करने और चलाने वाले लोग अलग-अलग खानों में काम करते हैं, तो बदलाव जमा होकर बड़े और जोखिम भरे releases बन जाते हैं, defect पर feedback code लिखे जाने के कई दिन बाद आता है, और production की समस्याएँ team तक नाराज़ users के ज़रिए पहुँचती हैं।

Tester के लिए DevOps काम को ख़त्म नहीं करता, बदल देता है। Releases इतनी बार होते हैं कि हर बार पूरा manual regression pass संभव नहीं, इसलिए दोहराए जाने वाले checks automated और भरोसेमंद होने चाहिए, जबकि exploratory testing और risk analysis और ज़रूरी हो जाते हैं, क्योंकि automated checks वही पकड़ते हैं जिसके बारे में किसी ने पहले सोचा हो। जो tester pipeline, production signals और delivery metrics समझता है, वह दिखा सकता है कि quality कहाँ खो रही है और data के साथ fix की वकालत कर सकता है।

पहले culture, फिर practices

यह शब्द development और operations को जोड़ता है। मकसद कोई job title या tool नहीं, बल्कि system बदलने वालों और उसे चलाए रखने वालों के बीच की दीवार हटाना है। पूरी team production में product की ज़िम्मेदारी साझा करती है, failures को दोष देने की बजाय सीखने का मौका मानती है, और अपने काम करने के तरीके को छोटे कदमों में सुधारती है, जैसा आपने Kanban lesson में देखा। कुछ teams इस विचार को CALMS में समेटती हैं: culture, automation, lean thinking, measurement और sharing।

  • हर चीज़ के लिए version control: code, tests, pipeline definitions, configuration और infrastructure।
  • छोटे batches: कुछ बड़े releases की बजाय बहुत से छोटे बदलाव, जिनमें से हर एक को test और roll back करना आसान हो।
  • Continuous integration और delivery: एक automated pipeline हर बदलाव को build, test और release के लिए तैयार करती है (यह अगले lesson का विषय है)।
  • Infrastructure as code: environments scripts से बनते हैं, इसलिए test environment production जैसा हो सकता है।
  • Monitoring और blameless post-incident reviews: हर incident एक सुधार बन जाता है।

DevOps loop: हर stage में testing

Teams अक्सर DevOps को एक अंतहीन loop की तरह बनाती हैं: plan, code, build, test, release, deploy, operate, monitor। यह एक आम तस्वीर है, कोई standard नहीं, लेकिन यह दिखाती है कि "test" सिर्फ़ एक stage है, जबकि testing की activities हर stage में होती हैं।

Plan में आप acceptance criteria पर सवाल उठाते हैं और तय करते हैं कि हर बदलाव कैसे test और monitor होगा। Code और build में developers के लिखे unit tests और static analysis कुछ ही मिनटों में feedback देते हैं। Test में automated regression और API tests चलते हैं, जबकि आप नए हिस्से को explore करते हैं। Release में test results और ज्ञात risks quality gate को जानकारी देते हैं (एक checkpoint जहाँ change को आगे बढ़ने से पहले तय criteria पूरे करने होते हैं)। Deploy में smoke tests (deployment के बाद main functions काम कर रहे हैं या नहीं, इसकी तेज़ जाँच) और health checks तय किए गए rollback criteria के सामने नए version की पुष्टि करते हैं। Operate और monitor में incidents और production signals दिखाते हैं कि testing से क्या छूटा, और हर finding अगले plan में एक नए test के रूप में लौटती है।

Plan से monitor तक DevOps loop: आठों stages में से हर एक में testing activity, और production की findings नए tests बनकर अगले plan में लौटती हुईं। वैचारिक मॉडल
  1. 1PlanAcceptance criteria पर सवाल; तय करें कि हर बदलाव कैसे test और monitor होगा
  2. 2CodeDevelopers code के साथ unit tests लिखते हैं
  3. 3BuildUnit tests और static analysis मिनटों में feedback देते हैं
  4. 4TestAutomated regression और API tests चलते हैं, tester नया हिस्सा explore करता है
  5. 5ReleaseTest results और ज्ञात risks quality gate को जानकारी देते हैं
  6. 6Deployतय rollback criteria के सामने smoke tests और health checks
  7. 7OperateIncidents दिखाते हैं कि testing से क्या छूटा
  8. 8MonitorLatency और error rates जैसे production signals

चरण 1–8 के दौरान Testing activities हर stage में होती हैं, सिर्फ़ Test में नहीं।

चरण 1 पर वापस हर finding अगले plan में नए test के रूप में लौटती है

DevOps दिखाने का एक आम तरीका, कोई standard नहीं: teams stages के नाम और बँटवारा अलग-अलग रखती हैं।

QA की जगह: automation, तेज़ feedback और monitoring

ISTQB syllabus बताता है कि DevOps testing को क्या देता है, जैसे code quality और regressions पर fast feedback, stable test environments, performance और reliability पर ज़्यादा ध्यान, और कम repetitive manual testing। यह risks और challenges भी गिनाता है: delivery pipeline को define और set up करना पड़ता है, CI/CD tools लाने और maintain करने पड़ते हैं, और test automation के लिए अतिरिक्त resources चाहिए और उसे बनाना व maintain करना मुश्किल हो सकता है। Manual testing, ख़ासकर user के नज़रिए से, अब भी ज़रूरी है। Tester का योगदान तीन क्षेत्रों में बँटता है।

  • Automation: team के साथ तय करें कि कौन-से checks हर बदलाव पर और किस level पर चलें (ज़्यादातर unit और API tests, कुछ ही end-to-end journeys), और उन्हें भरोसेमंद रखें। Flaky test, यानी जो एक ही code पर बेतरतीब ढंग से कभी pass और कभी fail होता है, team को red builds नज़रअंदाज़ करना सिखा देता है।
  • तेज़ feedback: commit के पाँच मिनट बाद fail होने वाला check वही developer ठीक कर देता है जिसने अभी code लिखा है; वही defect दो हफ़्ते बाद मिले तो context switch, bug report और retest की कीमत लगती है। Martin Fowler का continuous integration का विवरण build को तेज़ रखने पर ज़ोर देता है।
  • Monitoring: असली users, data और load सिर्फ़ production में होते हैं। जानें कि team क्या monitor करती है (Google की SRE book चार golden signals सुझाती है: latency, traffic, errors और saturation), और ऐसे checks माँगें जो हाल के incidents पकड़ लेते, जैसे हर कुछ मिनट पर synthetic login।

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

DORA metrics: delivery quality के signals

DORA (DevOps Research and Assessment), एक research programme जिसे Google Cloud चलाता है, delivery performance को पाँच metrics से बताता है: तीन throughput के लिए, यानी बदलाव users तक कितनी जल्दी पहुँचते हैं, और दो instability के लिए, यानी वे users को कितनी बार नुकसान पहुँचाते हैं। धीमा या flaky test suite lead time बढ़ाता है; testing की कमियाँ failed deployments के रूप में दिखती हैं। इन metrics को पूरे delivery system के signals की तरह पढ़ें, testers के scores की तरह कभी नहीं, और एक समय में एक ही application या service को मापकर उसकी तुलना उसके अपने trend से करें।

  • Change lead time (throughput): commit से production में चलने तक का समय। यह commit से शुरू होता है, इसलिए यह उस request-से-delivery वाले lead time से छोटा होता है जिसे कई Kanban teams track करती हैं।
  • Deployment frequency (throughput): बदलाव कितनी बार production तक पहुँचते हैं।
  • Failed deployment recovery time (throughput): fail होकर तुरंत intervention माँगने वाले deployment के बाद recover होने में कितना समय लगता है।
  • Change fail rate (instability): उन deployments का हिस्सा जिनके बाद तुरंत intervention चाहिए, जैसे rollback या hotfix; delivery level पर escaped defects का सबसे नज़दीकी signal।
  • Deployment rework rate (instability): उन deployments का हिस्सा जो unplanned हैं और production के किसी incident की वजह से होते हैं।

Worked example: एक महीने का delivery data

एक online shop चलाने वाली team मासिक retrospective में अपना delivery data लाती है और weeks 5–8 की तुलना उससे पहले के चार हफ़्तों से करती है।

एक online shop के weeks 5–8 बनाम weeks 1–4: deployments 12 से 16 हुए, लेकिन lead time, recovery time, change fail rate और rework rate चारों बिगड़े।
DORA metricWeeks 1–4Weeks 5–8बदलाव
Deployment frequencythroughput1216ज़्यादा बार
Change lead time (median)throughput2 दिन3 दिनधीमा
Failed deployment recovery time (median)throughput45 मिनट3 घंटेधीमा
Change fail rateinstability12 में से 1 (8%)16 में से 4 (25%)बदतर
Deployment rework rateinstability12 में से 1 (8%)16 में से 3 (19%)बदतर
  • बिगड़ा

Team अब ज़्यादा बार deploy करती है, लेकिन instability बढ़ी है और recovery धीमी हुई है, इसलिए यह अतिरिक्त speed सुधार नहीं है। Metric बताता है कि कहाँ देखना है, यह नहीं कि क्यों, इसलिए tester चारों failed deployments और बढ़े हुए lead time की जाँच करता है।

  • दो payment failures: pipeline सिर्फ़ payment provider के mock के सामने test करती थी, और provider ने अपनी API में एक field बदल दिया था। Action: provider के sandbox के सामने nightly API test।
  • एक database migration production जितने data पर timeout हो गया। Action: staging में उतनी ही बड़ी anonymised copy पर migrations का अभ्यास।
  • एक गलत discount, जिसे customers ने घंटों बाद report किया; इसी तरह पता चले failures ने recovery time बढ़ाया। Action: post-deployment smoke test जो एक test order देकर उसका total जाँचे।
  • Lead time इसलिए बढ़ा क्योंकि बदलाव हफ़्ते में दो बार होने वाले manual regression pass की queue में रुके रहे। Action: stable checks automate करना और exploratory sessions बदले हुए हिस्सों के लिए रखना, वही wait-time वाली सोच जो Kanban में थी।
पाठ संस्करण
Online shop, production deployments   Weeks 1-4       Weeks 5-8

Deployment frequency                   12              16
Change lead time (median)              2 days          3 days
Failed deployment recovery (median)    45 min          3 h
Change fail rate                       1 of 12 (8%)    4 of 16 (25%)
Deployment rework rate                 1 of 12 (8%)    3 of 16 (19%)

आज़माएँ: REST API टेस्टर आज़माएँ: API एंडपॉइंट टेस्टर

आम गलतियाँ

  • DevOps को tool या job title मानना, जबकि testers, developers और operations अब भी दीवार के ऊपर से काम एक-दूसरे को थमा रहे हों।
  • यह मानना कि automation testers की जगह ले लेता है, जबकि automated checks सिर्फ़ वही पुष्ट करते हैं जिसके बारे में किसी ने पहले सोचा हो।
  • Red builds को pass होने तक बार-बार re-run करना। हर बिना-समझाया failure या तो defect है या flaky test, और दोनों का owner होना चाहिए।
  • Deployment पर रुक जाना, यह पूछे बिना कि क्या monitor होता है और release fail होने पर आपको कैसे पता चलेगा।
  • DORA metrics से teams या लोगों की ranking करना, या सिर्फ़ एक metric के पीछे भागना: बढ़ते change fail rate के साथ ज़्यादा deployments प्रगति नहीं है।

QA का नज़रिया

DevOps team में आपका काम पूरे loop में फैला होता है। Refinement में आप पूछते हैं कि story कैसे test होगी और team को कैसे पता चलेगा कि वह production में काम कर रही है। Development के दौरान आप तय करते हैं कि कौन-से checks pipeline में होंगे, और test phase का इंतज़ार करने की बजाय हर बदलाव के results review करते हैं। Release से पहले, gate green हो लेकिन कोई risk untested हो, तो आप आवाज़ उठाते हैं; release के बाद smoke results और dashboards जाँचते हैं।

हर failed deployment या incident के लिए लिखें कि क्या fail हुआ, कैसे पता चला, recovery में कितना समय लगा और कौन-सा test या monitor उसे पहले पकड़ लेता, और यह सूची DORA trend के साथ retrospectives में लाएँ। Logs और dashboards का access माँगें: जो आप देख नहीं सकते, उसे test नहीं कर सकते।

अभ्यास

एक हफ़्ते के deployments पढ़ें

आपका काम

एक team food-ordering API deploy करती है। नीचे दिए एक हफ़्ते के log से पाँचों DORA metrics निकालें, हर failed deployment के लिए एक test या monitor सुझाएँ जो उसे रोक देता या recovery छोटी कर देता, और बताएँ कि एक हफ़्ते का data आपको क्या नहीं बता सकता।

सामग्री
Food-ordering API: production deployments, one week
Lead time = from commit to production

#  Deployed    Lead time  Result
1  Sun 10:00   20 h       OK
2  Mon 11:00   18 h       OK
3  Mon 16:00   75 h       Login returns 500 when two-factor sign-in is on;
                          rolled back at 16:50
4  Tue 12:00   26 h       OK
5  Wed 09:30   16 h       Receipts show prices without the currency;
                          a customer reports it at 12:00
6  Wed 13:30    1 h       Hotfix for #5 (unplanned); receipts correct
7  Thu 14:00   28 h       OK
8  Thu 18:00   55 h       OK
चरण
  1. Deployments गिनें और change lead time का median निकालें।
  2. तुरंत intervention माँगने वाले deployments और उनके recovery times पहचानें।
  3. Unplanned deployments पहचानें।
  4. हर failure के लिए एक check या monitor सुझाएँ और loop में उसका stage बताएँ।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Deployment frequency: हफ़्ते में 8 (7 planned, 1 hotfix)। Change lead time: क्रम से 1, 16, 18, 20, 26, 28, 55, 75 घंटे; median (20 + 26) / 2 = 23 घंटे। पूछें कि #3 और #8 में इतना समय क्यों लगा।

Change fail rate: #3 (rollback) और #5 (hotfix), 8 में से 2 = 25%। Recovery: #3 के लिए 50 मिनट और #5 के लिए 4 घंटे (09:30 से 13:30 के hotfix तक); सिर्फ़ दो failures हैं, इसलिए दोनों values बताएँ। Deployment rework rate: #6, 8 में से 1 = 12.5%।

#3: two-factor sign-in on और off दोनों के साथ login का automated API test (test stage), और login errors पर alert के साथ synthetic login (monitor stage)। 50 मिनट की recovery दिखाती है कि rollback ने काम किया।

#5: regression suite में receipt format का check, currency समेत (test stage), और deployment के बाद एक smoke order जो receipt जाँचे (deploy stage)। Customer को यह 2.5 घंटे बाद मिला, यानी monitoring इसे नहीं पकड़ पाई।

एक हफ़्ता और 8 deployments trend के लिए बहुत कम हैं, numbers यह नहीं बताते कि दोष किसका है, और वे ऐसे defects नहीं दिखा सकते जिन्हें अब तक किसी user ने नोटिस नहीं किया।

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

क्या DevOps team में काम करने के लिए programming सीखनी होगी?

इतनी कि आप automated tests पढ़ और maintain कर सकें, pipeline के results और logs पढ़ सकें और simple scripts चला सकें; full-time developer होना ज़रूरी नहीं। Teams ऐसे tester को महत्व देती हैं जो test code पर developers के साथ काम कर सके और समझे कि pipeline का हर stage क्या जाँचता है। Roadmap के आगे के automation modules ये skills बनाते हैं।

क्या DevOps और CI/CD एक ही चीज़ हैं?

नहीं। CI/CD practices और tools का एक set है जिस पर DevOps teams निर्भर करती हैं; DevOps काम करने का व्यापक तरीका है जिसमें culture, साझा ज़िम्मेदारी, monitoring और incidents से सीखना भी शामिल है। अगला lesson continuous integration, continuous delivery और continuous deployment समझाता है।

क्या DORA metrics test metrics हैं?

सीधे तौर पर नहीं। ये test team को नहीं, पूरे delivery system को मापते हैं। फिर भी testing इन पर गहरा असर डालती है: test suite की अवधि change lead time का हिस्सा है, और testing से निकल भागे defects change fail rate बढ़ाते हैं। इन्हें defect escape rate जैसे test metrics के साथ इस्तेमाल करें, उनकी जगह नहीं।

क्या DevOps का मतलब release से पहले की बजाय production में testing है?

नहीं। Release से पहले testing ज़रूरी बनी रहती है; DevOps production में monitoring और checks जोड़ता है क्योंकि कुछ समस्याएँ असली users, data और load के साथ ही दिखती हैं। Canary releases जैसी shift-right practices shift-left और shift-right testing वाले lesson में आती हैं।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • DORA's software delivery performance metricsDORA (Google Cloud)DORA के डिलीवरी मेट्रिक्स — change lead time, deployment frequency, failed deployment recovery time, change fail rate आदि — throughput और instability में समूहित।
  • 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।
  • Continuous Integration (Martin Fowler)martinfowler.com · 2024continuous integration का व्यापक रूप से संदर्भित विवरण: बार-बार integrate करें, build को self-testing और तेज़ रखें, टूटा build तुरंत ठीक करें।
टूल्स

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

API हेल्थ चेकर

एक साथ कई API health endpoint जाँचें और स्टेटस, latency तथा pass/fail सारांश पाएँ।

API टेस्टिंग

REST API टेस्टर

method, हेडर और JSON बॉडी पर पूरे नियंत्रण के साथ REST endpoint टेस्ट करें, फिर स्टेटस, हेडर और JSON path पर assertion लगाएँ।

API टेस्टिंग

API एंडपॉइंट टेस्टर

तुरंत जाँचें कि कोई API endpoint पहुँच में है या नहीं: स्टेटस, रिस्पॉन्स टाइम, साइज़, content type और TLS।

API टेस्टिंग

रिग्रेशन सिनेरियो जनरेटर

बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।

टेस्ट डिज़ाइन

और गहराई से

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

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