मॉड्यूल 25 · प्रोफ़ेशनल QA और टेस्ट मैनेजमेंट

प्रोडक्शन क्वालिटी और मॉनिटरिंग

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

Production quality वह quality है जो software live होने के बाद users असल में महसूस करते हैं: क्या वे sign in और payment कर पाते हैं, क्या results सही हैं, pages कितनी जल्दी खुलते हैं और क्या उनका data सुरक्षित रहता है। Monitoring वह तरीका है जिससे team इसे देखती है: चलता हुआ system signals record करता है, और लोग व alert rules उन पर नज़र रखते हैं, ताकि कोई failure ज़्यादातर users पर असर पड़ने से पहले पकड़ा और समझा जा सके।

उदाहरण के लिए, एक online store अपने order requests और उनमें से fail होने वालों को गिनता है। अगर किसी release के ठीक बाद failures 0.2% से 3% हो जाएँ, तो on-call developer तक alert पहुँचता है, जो logs और एक fail हुए request का trace खोलकर देखता है कि किस service की वजह से ऐसा हुआ।

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

Release से पहले की testing product का एक sample ही देखती है। Seven testing principles में से एक कहता है कि exhaustive testing असंभव है, और कोई भी test environment असली इस्तेमाल के हर device, data combination, third-party response और traffic peak को दोहरा नहीं सकता, इसलिए कुछ defects production तक पहुँचते हैं। Monitoring के बिना पहला संकेत घंटों बाद किसी customer की शिकायत होती है, और हर घंटा failed orders, गलत data या support का काम बढ़ाता है।

Tester के लिए production दिखाता है कि कौन-से risks असली थे और कौन-से tests छूट गए थे। जो tester इसके signals पढ़ सकता है, वह यह परखने में मदद करता है कि release ठीक है या नहीं, production failures की सटीक reports लिखता है और हर escaped defect को नए test या check में बदलता है।

Production quality: पहले से तय targets

Shift-left और shift-right वाले lesson में आपने चार golden signals देखे। Production quality परखने के लिए उन्हें targets में बदलें। Google की Site Reliability Engineering (SRE) book तीन terms इस्तेमाल करती है। Service level indicator (SLI) users को मिलने वाली service का ध्यान से परिभाषित माप है, जैसे 2 seconds के अंदर सफल होने वाले order requests का हिस्सा। Service level objective (SLO) उसका target है, जैसे 30 दिनों में 99.5%। Service level agreement (SLA) customers के साथ एक contract है जो बताता है कि objectives पूरे न होने पर क्या होगा, जैसे आंशिक refund।

SLO से एक error budget भी तय होता है: वह failure जिसकी वह छूट देता है, यानी 100% में से objective घटाकर। 99.5% पर और महीने में लगभग 200,000 order requests के साथ यह लगभग 1,000 fail या धीमे requests है। SRE book जिस तरीके का वर्णन करती है, उसमें जिस team का budget ख़त्म हो जाए, वह releases कुछ समय के लिए रोककर reliability और testing पर ध्यान लगाती है, और "क्या production ठीक है?" का जवाब एक ऐसा number बन जाता है जिस पर सब सहमत हैं।

उन journeys को मापें जो users महसूस करते हैं, जैसे sign-in, search और checkout, न कि server का CPU।
Business correctness भी जोड़ें: orders प्रति घंटा, orders से मिलान किए गए payments, सच में भेजे गए confirmations। कुछ defects कोई error नहीं देते।

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

Monitoring signals के पाँच प्रकार

SRE book के अनुसार monitoring को दो सवालों का जवाब देना चाहिए: क्या टूटा है, और क्यों? White-box monitoring उस पर टिकी है जो system अपने बारे में record करता है; black-box monitoring बाहर से, user की नज़र से, व्यवहार टेस्ट करती है। हर तरह का signal अलग सवाल का जवाब देता है, और सब मिलकर एक chain की तरह काम करते हैं: symptom alert चलाता है, और details cause तक ले जाती हैं।

Metrics: समय के साथ numbers, जैसे requests प्रति मिनट, error rate, p95 latency (वह समय जिसके अंदर 95% requests पूरे हो जाते हैं) या orders प्रति घंटा। इन्हें महीनों तक रखना सस्ता है और ये trends व अचानक बदलाव दिखाते हैं, लेकिन यह नहीं बताते कि कौन-सा user प्रभावित हुआ या क्यों।
Logs: अलग-अलग events के timestamp वाले records। Structured logs, यानी हर line में एक JSON object जिसमें time, level, service, route और request id जैसे fields हों, filter किए जा सकते हैं। Time UTC में लिखें, ताकि अलग-अलग time zones के servers के events की तुलना हो सके। OWASP Logging Cheat Sheet की सलाह के अनुसार passwords, session ids, access tokens, card data या संवेदनशील personal data logs में दर्ज न करें।
Traces: एक request का वह रास्ता जो वह हर service से होकर तय करता है, spans कहलाने वाले nested और timed steps के रूप में। Trace दिखाता है कि समय कहाँ गया और कौन-सी call fail हुई। Services trace id को request header में आगे भेजती हैं (W3C Trace Context standard इसे traceparent कहता है); वही id logs में लिखने से दोनों जुड़ जाते हैं।
Alerts: rules जो signals पर नज़र रखते हैं और किसी व्यक्ति को सूचना देते हैं। On-call व्यक्ति (जो उस shift में alerts का जवाब देता है) को भेजा गया urgent alert page कहलाता है। हर संभव cause पर नहीं, बल्कि users को महसूस होने वाले symptoms पर page करें, जैसे SLI का गिरना; हर page ऐसा हो जिस पर तुरंत और सोच-समझकर कार्रवाई चाहिए, और कई teams उसके साथ runbook जोड़ती हैं, यानी उसे संभालने के लिखे हुए steps। कम urgent समस्याएँ tickets बनती हैं। बहुत ज़्यादा pages लोगों को उन्हें अनदेखा करना सिखा देते हैं।
Synthetic checks: बाहर से हर कुछ मिनट में चलने वाली scripted journeys, जैसे कोई monitoring account login करके search करे। ये शांत रास्तों पर और रात में outages पकड़ते हैं, लेकिन सिर्फ़ वही cover करते हैं जो किसी ने script किया हो।

Monitoring signals एक chain की तरह: असली users और synthetic checks से metrics, logs और traces बनते हैं; user को महसूस होने वाले symptom पर alert किसी व्यक्ति को page करता है, जो कार्रवाई से पहले metrics से logs और फिर trace तक जाता है। वैचारिक मॉडल

1असली usersअसली इस्तेमाल का हर request
साथ-साथ
- 2Synthetic checksबाहर से हर कुछ मिनट में scripted journeysBlack-box
3Metricsसमय के साथ numbers: क्या कुछ गड़बड़ है?White-box
System इन्हें record करता है
- 4Logsहर event का record: क्या हुआ?White-box
- 5TracesServices के पार एक request: कहाँ fail हुआ?White-box
6Alert ruleUsers को महसूस होने वाला symptom: SLI अपनी threshold से नीचे
शाखा: कम urgent → page नहीं, ticket
गेट: Urgent: अभी किसी व्यक्ति की ज़रूरत
7व्यक्ति को pageOn-call developer, अक्सर runbook के साथ
8निदानSymptom metrics में; logs और trace दिखाते हैं कि कहाँ और क्यों
9कार्रवाईRollback, फिर alert तभी बंद जब SLI फिर सामान्य हो

चरण 1 पर वापस हर escaped defect एक नया test या check बनता है

सरल रूप: tools, dashboards और team roles हर team में अलग होते हैं।

आज़माएँ: JSON Lines वैलिडेटर आज़माएँ: टाइमस्टैम्प कन्वर्टर आज़माएँ: Cron एक्सप्रेशन एक्सप्लेनर

Monitoring को भी टेस्ट करें

Monitoring भी code और configuration है, इसलिए उसमें भी defects होते हैं: ऐसा alert जो कभी चल ही नहीं सकता, request id के बिना log line, या हफ़्ते भर से चुपचाप fail होता synthetic check। हर risky बदलाव के लिए पूछें कि production में उसके टूटने को कौन-सा signal दिखाएगा और किसे बताया जाएगा, फिर test environment में इसकी जाँच करें।

किसी dependency को fail करवाएँ, जैसे 503 लौटाने वाले stub से, और पक्का करें कि error metrics, logs और traces में एक ही request id के साथ दिखे और alert किसी व्यक्ति तक पहुँचे।
Sample log lines पढ़ें: सही structure, UTC time, कार्रवाई के लिए काफ़ी context, और कोई personal या secret data नहीं।

आज़माएँ: API स्टेटस कोड सिम्युलेटर आज़माएँ: JSON Lines वैलिडेटर

Production में सुरक्षित testing

कुछ checks का मतलब सिर्फ़ production में ही है: deployment के बाद का smoke test, synthetic checks, customers से पहले staff के साथ feature flag आज़माना, या canary की उसके control group से तुलना। ये release से पहले की testing में जुड़ते हैं, उसकी जगह कभी नहीं लेते, और सिर्फ़ पहले से तय guardrails के साथ ही सुरक्षित हैं।

Permission: सिर्फ़ वे systems टेस्ट करें जो आपकी team के हैं या जिन्हें टेस्ट करने की लिखित अनुमति है; activity, समय और owner तय करें और on-call engineer को बताएँ।
Test identities: dedicated accounts इस्तेमाल करें, ऐसे mark किए हुए कि analytics, billing, reports और customer messages उन्हें बाहर रखें; असली customer accounts या data कभी इस्तेमाल न करें।
कोई असली side effect नहीं: read-only checks को प्राथमिकता दें, जो कुछ बनाएँ उसे cancel करके साफ़ करें, और असली payments, deliveries या customers को messages कभी trigger न करें।
छोटा blast radius: flags को staff या test accounts के लिए target करें, canary का हिस्सा छोटा रखें, और पहले से आज़माया हुआ एक stop switch रखें।
स्पष्ट और scheduled सहमति के बिना production पर load tests नहीं: असली users उन्हीं servers को share करते हैं।

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

Worked example: order service पर एक alert

Riyadh (UTC+3) के एक online store का POST /orders के लिए SLO है: 30 दिनों में 99.5% requests 2 seconds के अंदर सफल हों, यानी महीने में लगभग 1,000 failures का error budget। Release 4.2 सुबह 10:20 पर जाती है। 10:31 पर नीचे वाला alert on-call developer को page करता है, और release टेस्ट करने वाला tester भी साथ जुड़ता है।

Synthetic checkout check अब भी green है, क्योंकि वह card से pay करता है। Success rate को payment method के हिसाब से बाँटने पर दिखता है कि सिर्फ़ wallet payments fail हो रहे हैं, जो लगभग 30% orders हैं। Logs को route और level से filter करने पर नीचे वाली line मिलती है, और उसका trace id एक ऐसा trace खोलता है जिसमें payment service wallet provider का 10 seconds इंतज़ार करके हार मान लेती है।

Cause: release ने staging की एक setting copy कर ली थी, इसलिए production ऐसे wallet host को call कर रहा था जिस तक वह पहुँच ही नहीं सकता। provider_host field ने यह एक line में दिखा दिया।
Action: release plan का एक rollback criterion पूरा हुआ, इसलिए team 10:52 पर 4.1 पर rollback करती है और alert तभी बंद करती है जब SLI फिर सामान्य हो जाए। लगभग 90 orders fail हुए, यानी महीने के error budget का क़रीब दसवाँ हिस्सा।
Follow-up review के लिए gaps, जो अगले lesson का विषय है: synthetic check सिर्फ़ card से pay करता है, किसी ने production configuration की expected values से तुलना नहीं की, और किसी alert ने हर payment method की success पर नज़र नहीं रखी।

ALERT 10:31 (UTC+3)  orders-api  page: developer on call
  POST /orders succeeded within 2 s: 72% over the last 10 min (SLO 99.5%)

Log line, pretty-printed (times in UTC):
{ "ts": "2026-10-04T07:29:12.418Z", "level": "error",
  "service": "payment-service", "route": "POST /orders",
  "trace_id": "7d2a91c4e0b54f3a9b18c6e2f4a05d71",
  "method": "wallet", "error": "provider_timeout",
  "elapsed_ms": 10001, "provider_host": "wallet.staging.internal" }

Trace 7d2a91c4...  total 10.05 s, failed
  api-gateway           POST /orders        10.05 s
    orders-service      create order        10.04 s
      payment-service   charge wallet       10.01 s   timeout
        wallet provider (no response)       10.00 s

आज़माएँ: टाइमस्टैम्प कन्वर्टर

आम गलतियाँ

Release पर रुक जाना और monitoring दूसरों पर छोड़ देना, जिससे production failures customers के ज़रिए team तक पहुँचते हैं।
Users को महसूस होने वाले symptoms के बजाय हर cause और हर अकेले error पर alert लगाना, जब तक लोग alerts mute न कर दें।
सिर्फ़ averages देखना: 300 ms का average response time 4 seconds के p95 को छिपा सकता है।
"Debugging के लिए" personal data, passwords या tokens log करना, जिससे logs data leak बन जाते हैं।
Green synthetic check को इस बात का सबूत मानना कि सब कुछ काम कर रहा है, जबकि वह सिर्फ़ अपना scripted रास्ता cover करता है।
असली customer accounts, असली payments या बिना बताए load के साथ production में testing करना।

QA का नज़रिया

Monitoring को refinement और release planning में लाएँ: हर risky story के लिए पूछें कि वह किस SLI पर असर डालती है, उसे कौन-से log fields या metrics चाहिए और team को कैसे पता चलेगा कि वह production में काम कर रही है। Release के बाद तय अवधि तक on-call developer के साथ dashboards देखें।

Production में failure हो तो अंदाज़ों से नहीं, signals से काम करें: bug report में alert का समय, version, प्रभावित SLI, trace या request id और संबंधित log lines डालें। Personal data छिपाकर logs और dashboards का read access माँगें। उन failures की list रखें जिन्हें monitoring ने देर से पकड़ा या पकड़ा ही नहीं; वह अगले lesson के incident reviews का input है।

अभ्यास

Appointment booking की monitoring plan करें

आपका काम

एक clinic app में patients 15 मिनट का appointment book करते हैं, जिसके बाद SMS confirmation जाता है। नीचे दी गई test environment की चार log lines की मदद से plan करें कि production में इस feature की quality कैसे मापी जाएगी, उस पर नज़र कैसे रखी जाएगी और उसे सुरक्षित रूप से कैसे check किया जाएगा।

सामग्री

{"ts":"2026-11-02T09:14:03Z","level":"info","req":"r-51c","msg":"booking created"}
{"ts":"2026-11-02 12:14:05","level":"info","msg":"SMS sent to +966500000001"}
{"ts":"2026-11-02T09:15:40Z","level":"error","req":"r-52d","msg":"Error"}
{"ts":"2026-11-02T09:16:02Z","level":"debug","req":"r-53e","token":"eyJhbGciOi..."}

चरण

Booking के लिए एक SLI और उसका SLO, और एक business signal लिखें।
चारों log lines में मिली हर समस्या लिखें।
एक alert और एक synthetic check उसके schedule के साथ लिखें।
उस check को production में चलाने के guardrails लिखें।

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

मॉडल उत्तर

SLI: POST /bookings requests का वह हिस्सा जो 2 seconds के अंदर booking बना दे; SLO, उदाहरण के लिए, 30 दिनों में 99.5%, product owner के साथ तय। Business signal: उन bookings का हिस्सा जिनका SMS confirmation 5 मिनट के अंदर भेजा गया।

Logs: line 2 बिना time zone के local time इस्तेमाल करती है (अगर server UTC+3 पर चलता है तो 12:14:05 का मतलब 09:14:05 UTC है, लेकिन line में ऐसा कुछ नहीं लिखा), पूरा phone number log करती है (personal data) और उसमें request id नहीं है; line 3 सिर्फ़ "Error" कहती है, बिना route, cause या error code के; line 4 debug output है, जिसे production में बंद होना चाहिए, और उसमें access token है, यह security defect है जिसे high severity के साथ report करें। Line 1 ठीक है, हालाँकि service और route fields होने पर चारों lines को filter करना आसान होता।

Alert: जब 10 मिनट में booking success 98% से नीचे जाए, तो runbook के साथ on-call developer को page करें; जब SMS confirmations 30 मिनट तक bookings से पीछे रहें, तो ticket खोलें। Synthetic check: हर 5 मिनट (*/5 * * * *) एक monitoring account patients से छिपे test doctor के साथ slot book करता है, confirmation जाँचता है और booking cancel करता है।

Guardrails: clinic system का owner check के लिए सहमत हो; test doctor और test patient schedules, reports और statistics से बाहर रहें; हर booking cancel हो; SMS सिर्फ़ team के अपने number पर जाए; check fail हो तो किसी असली व्यक्ति को alert मिले।

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

Monitoring testers का काम है या operations team का?

यह साझा ज़िम्मेदारी है। आम तौर पर developers, operations या SRE engineers monitoring बनाते हैं और on-call रहते हैं। Testers हर बदलाव के लिए पूछते हैं कि क्या monitor होगा, alerts, logs और synthetic checks review करते हैं, टेस्ट करते हैं कि वे काम करते हैं, और production से मिली जानकारी से अपने tests बेहतर बनाते हैं। छोटी teams में अक्सर tester ख़ुद synthetic checks set up करता है।

Monitoring और observability में क्या फ़र्क है?

इन शब्दों का इस्तेमाल अलग-अलग होता है। Monitoring का मतलब आम तौर पर जाने-पहचाने signals इकट्ठा करना और उन पर alert करना है। Observability का मतलब आम तौर पर यह है कि team system के अंदर क्या हो रहा है, उसे उसके signals से कितनी अच्छी तरह समझ पाती है, उन failures के लिए भी जिनकी किसी ने उम्मीद नहीं की थी। Logs, metrics और traces दोनों के काम आते हैं।

क्या green dashboard का मतलब है कि production quality अच्छी है?

नहीं। Dashboard सिर्फ़ वही दिखाता है जिसे किसी ने मापना चुना। Success status के साथ लौटे गलत totals, बिना monitoring वाले रास्तों की समस्याएँ और धीमी गिरावट, सब green रह सकते हैं। Technical signals को business signals, support tickets और user feedback के साथ मिलाएँ।

संदर्भ

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।
Site Reliability Engineering: How Google Runs Production SystemsGoogle / O'Reilly Media · 2016सर्विस लेवल ऑब्जेक्टिव, एरर बजट, "चार गोल्डन सिग्नल" की निगरानी और ओवरलोड संभालना — लचीलेपन का परिचालन पक्ष।
OWASP Cheat Sheet Series: LoggingOWASP Foundationक्या लॉग करें और क्या कभी न करें (पासवर्ड, टोकन, निजी डेटा), और लॉग को छेड़छाड़-प्रकट कैसे रखें।
ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।

प्रोडक्शन क्वालिटी और मॉनिटरिंग

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

Production quality: पहले से तय targets

Monitoring signals के पाँच प्रकार

Monitoring को भी टेस्ट करें

Production में सुरक्षित testing

Worked example: order service पर एक alert

आम गलतियाँ

QA का नज़रिया

अभ्यास

Appointment booking की monitoring plan करें

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

संदर्भ

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

API हेल्थ चेकर

JSON Lines वैलिडेटर

टाइमस्टैम्प कन्वर्टर

API स्टेटस कोड सिम्युलेटर

Cron एक्सप्रेशन एक्सप्लेनर

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

और गहराई से

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

इस topic से पहले

अगले topics

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

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

Production quality: पहले से तय targets

Monitoring signals के पाँच प्रकार

Monitoring को भी टेस्ट करें

Production में सुरक्षित testing

Worked example: order service पर एक alert

आम गलतियाँ

QA का नज़रिया

अभ्यास

Appointment booking की monitoring plan करें

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

संदर्भ

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

और गहराई से

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

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

इस topic से पहले

अगले topics

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