मॉड्यूल 4 · टेस्ट प्रोसेस (STLC)

टेस्ट मॉनिटरिंग और टेस्ट कंट्रोल

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

Test monitoring और test control, test management की वे activities हैं जो testing को सही रास्ते पर रखती हैं। Test monitoring का मतलब है सभी test activities के बारे में लगातार जानकारी इकट्ठा करना और असली progress की तुलना test plan और उसके exit criteria से करना। Test control उस जानकारी से corrective actions तय करता और लागू करता है, जिन्हें ISTQB syllabus control directives कहता है।

उदाहरण: plan के अनुसार day 4 के अंत तक 120 में से 48 tests चल जाने चाहिए थे, लेकिन सिर्फ़ 26 चले, क्योंकि test environment दो दिन देर से मिला। Monitoring यह variance दिखाती है; control तय करता है कि क्या करना है: high-risk tests पहले चलाना, ज़्यादा समय माँगना, या कुछ low-risk tests छोड़ने पर सहमति बनाना। Action के बिना जानकारी कुछ नहीं बदलती, और जानकारी के बिना action सिर्फ़ अंदाज़ा है।

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

हर test plan एक अनुमान है जो facts सामने आने से पहले बनता है: environments देर से आते हैं, builds टूटते हैं, defects एक module में इकट्ठा हो जाते हैं। Monitoring के बिना ये समस्याएँ आख़िरी दिन दिखती हैं, जब सिर्फ़ अनजाने risk के साथ release करना या सबसे बुरे समय पर release टालना ही बचता है।

Monitoring और control के साथ, समय कम पड़ने पर low-risk tests एक साफ़ फ़ैसले से छोड़े जाते हैं, payment tests ग़लती से नहीं छूटते। और tester "मैं व्यस्त हूँ" की जगह कह पाता है "हम 22 tests पीछे हैं, वजह यह है, और विकल्प ये हैं" — ऐसा संदेश जिससे blocked environments ठीक होते हैं।

Test monitoring: plan के मुक़ाबले जानकारी इकट्ठा करना

Monitoring को एक baseline चाहिए: अपने schedule और exit criteria के साथ test plan, और test implementation वाले lesson का test execution schedule। अकेला number ज़्यादा कुछ नहीं बताता; "26 tests execute हुए" तभी जानकारी बनता है जब बगल में "आज तक 48 planned" लिखा हो: यानी plan का 54%।

ISTQB CTFL v4.0 में test monitoring सिर्फ़ execution को नहीं, सभी test activities को cover करती है, और जाँचती है कि exit criteria पूरे हो रहे हैं या नहीं, जैसे risks या acceptance criteria के coverage targets। Data वहीं से लें जहाँ काम दर्ज होता है — test management tool, defect tracker, CI results — और definitions स्थिर रखें ताकि आज की तुलना कल से हो सके। आम जानकारी:

  • Test progress: implement हुए tests, environment की तैयारी, और executed, passed, failed व blocked tests (जो किसी ज़रूरी चीज़ के उपलब्ध न होने से चल ही नहीं सकते)।
  • Defects: found, fixed और open, severity के हिसाब से, और वे कहाँ इकट्ठा हो रहे हैं।
  • Coverage: requirements, acceptance criteria या product risks का कितना हिस्सा चल चुके tests से cover हुआ है, और उनमें से कितने tests pass हुए।
  • Risk और effort: अभी untested product risks, और estimate के मुक़ाबले लगी effort।

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

Test control: सुधारात्मक कदम

Test control, monitoring की जानकारी से testing का रास्ता सुधारता है। एक अच्छा control decision तीन सवालों का जवाब देता है: variance क्या है, यह किस exit criterion या test objective को ख़तरे में डालता है, और सबसे छोटा action कौन-सा है जो testing को वापस track पर ला दे? "कोई action ज़रूरी नहीं" तय करना भी control decision है, अगर वह सोच-समझकर लिया गया हो।

हर action tester के हाथ में नहीं होता। Tests का क्रम बदलना या exploratory session जोड़ना आम तौर पर test team के अधिकार में होता है; release date खिसकाना, scope घटाना या residual risk (वह risk जो बचा रह जाता है, जैसे कुछ tests न चलने की वजह से) स्वीकार करना product owner जैसे stakeholders का फ़ैसला है, और tester उन्हें facts और विकल्प देता है। दोनों हालात में decision दर्ज होता है, plan update होता है, और monitoring का अगला दौर जाँचता है कि वह काम आया या नहीं। ISO/IEC/IEEE 29119-2 इस loop को test management की एक process मानता है, test planning और test completion के साथ।

Control decisions के उदाहरण

CTFL v4.0 आम control directives गिनाता है: किसी पहचाने गए risk के issue बनने पर (यानी जिसकी आशंका थी वह सच में हो जाए) tests की priority बदलना, rework के बाद दोबारा आँकना कि test item अब भी entry या exit criteria पूरे करता है या नहीं, test environment देर से मिलने पर schedule बदलना, और जहाँ ज़रूरत हो resources जोड़ना। व्यवहार में ये उन signals के जवाब हैं जो लगभग हर project में बार-बार आते हैं:

  • कोई risk issue बन जाए (payment provider cycle के बीच अपना API बदल दे): payment और checkout tests पहले चलाएँ।
  • Defects एक module में इकट्ठा हों: उसे ज़्यादा गहराई से टेस्ट करें, जैसे exploratory session से, और पूछें कि क्या defects का कोई साझा root cause है।
  • Environment या test data देर से मिले: schedule बदलें, जो उस पर निर्भर नहीं वह चलाएँ, और नामित owner व तारीख़ के साथ escalate करें।
  • किसी tested हिस्से में rework आए: confirmation और regression tests चलाएँ, और नया build तभी स्वीकार करें जब वह entry criteria पूरे करे, जैसे smoke test pass होना।
  • Build smoke test में fail हो: एक ही वजह वाले दर्जनों failures log करने की बजाय उस पर execution रोकें।
  • Forecast दिखाए कि सारे tests नहीं चलेंगे: stakeholders को विकल्प दें — ज़्यादा समय, ज़्यादा लोग, या low-risk tests न चलाना और residual risk दर्ज करना।

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

Worked example: 10 दिन की test cycle का चौथा दिन

एक online shop release 4.2 टेस्ट कर रही है, जिसमें coupons और नया checkout जुड़ा है। Plan: 10 working days में 120 system tests, रोज़ 12, feature-by-feature schedule के साथ। Exit criteria: सभी 30 high-risk tests pass, और कोई open Blocker या Critical defect नहीं। Test environment दो दिन देर से, day 3 की शुरुआत में मिला।

Day 4 के अंत में test lead data की plan से तुलना करता है। कुल मिलाकर 22 tests पीछे हैं, लेकिन high-risk वाली line ज़्यादा अहम है: 30 में से 8 चले हैं और 9 payment sandbox बंद होने से blocked हैं। सात में से पाँच defects coupons में हैं, जिनमें एक Critical है। रोज़ 13 tests की रफ़्तार से day 10 तक लगभग 16 tests नहीं चलेंगे।

Release 4.2 - system test status, end of day 4 of 10

                          Planned by day 4   Actual   Variance
Tests executed                   48            26        -22
High-risk tests executed         20             8        -12
Tests blocked                     0             9         +9
Defects found                     -             7    (5 in coupons)
Open Critical defects             0             1         +1

Pace since the environment arrived (day 3): 13 tests a day
Forecast: 94 tests left, 6 days x 13 = 78, so about 16 will not run

Worked example: control decisions

Test lead, test team के हाथ वाले काम तुरंत करता है और schedule का सवाल उसी दिन product owner के सामने रखता है:

  • Priority बदलना: 13 unblocked high-risk tests day 5 पर सबसे पहले चलेंगे; low-risk cosmetic checks आख़िर में जाएँगे।
  • जहाँ defects इकट्ठा हैं वहाँ गहरी testing: coupon combinations पर एक time-boxed exploratory session।
  • Unblock करना: DevOps sandbox के लिए owner और तारीख़ तय करता है; day 6 तक sandbox वापस न आए, तो stakeholders को बताया जाएगा कि high-risk exit criterion ख़तरे में है।
  • Rework की तैयारी: Critical fix आते ही confirmation testing और coupon regression tests चलेंगे।
  • Escalate करना: product owner चुनता है — दो extra दिन, उधार का tester, या 16 low-risk tests न चलाना और residual risk दर्ज करना।
  • दर्ज करना और दोबारा जाँचना: plan में हर decision, उसका owner और वजह update होती है; day 5 का checkpoint जाँचता है कि actions काम आए या नहीं।
Worked example का day 4, loop के एक चक्कर के रूप में: monitoring दिखाती है कि 48 planned में से 26 tests चले, control risk के हिसाब से क्रम बदलता है, समय या scope का फ़ैसला escalate करता है और plan update करता है।
  1. 1PlanTest planningBaseline: day 4 तक 120 में से 48 tests; exit criteria तय
  2. 2Monitor करेंTest monitoringDay 4: 26 चले, 30 में से 8 high-risk, 9 blocked, 7 में से 5 defects coupons में
  3. 3Plan से तुलनाTest monitoring22 tests पीछे; रोज़ 13 की रफ़्तार से day 10 तक लगभग 16 नहीं चलेंगे

    शाखा: कोई ख़ास variance नहीं: कोई action नहीं, monitoring जारी

  4. 4Test team के actionsTest controlHigh-risk tests पहले, coupons पर exploratory session, sandbox का owner और तारीख़
  5. 5समय या scope escalate करेंTest controlदो extra दिन, उधार का tester, या 16 low-risk tests न चलानाStakeholder का फ़ैसला
  6. 6Plan update करें, सबको बताएँTest controlहर decision उसके owner और वजह के साथ दर्ज

चरण 2 पर वापस अगला checkpoint, day 5: क्या actions काम आए?

आम गलतियाँ

  • Plan को बगल में रखे बिना raw numbers report करना: "26 executed" का "48 planned" के बिना कोई मतलब नहीं।
  • सिर्फ़ कुल आँकड़ा देखना, जो छिपा सकता है कि high-risk हिस्सा बहुत पीछे है। आँकड़ों को risk के हिसाब से बाँटें।
  • सिर्फ़ test execution monitor करना और test design, environment व test data को नज़रअंदाज़ करना, जिससे देरी execution शुरू होने पर ही दिखती है।
  • Variance देखकर उसे उठाने की बजाय चुपचाप catch up करने की उम्मीद करना, जबकि विकल्प अभी बचे हैं।
  • Stakeholders के फ़ैसले अकेले ले लेना: बिना सहमति चुपचाप tests छोड़ देना या exit criteria ढीले कर देना।
  • Loop बंद न करना: team को बताए बिना plan बदलना, या कभी न जाँचना कि action काम आया या नहीं।

QA का नज़रिया

ज़्यादातर teams में monitoring और control वह व्यक्ति चलाता है जिसके पास test management role है — test lead या test manager — या agile team में खुद team, stand-ups और sprint reviews में। हर tester इन्हें data देता है: results उसी दिन दर्ज करें, blocked tests पर वजह लिखें, और defects को उन tests और risks से link करें जिन पर उनका असर है। पुराना data monitoring को अंधा बना देता है।

Variance को activity नहीं, variance की तरह report करें: "Payment tests 9 पीछे हैं क्योंकि sandbox बंद है; गुरुवार तक वापस न आया तो high-risk exit criterion ख़तरे में है।" पूछें कि कौन-सा exit criterion ख़तरे में है, फ़ैसला कौन ले सकता है, और कुछ न करें तो क्या होगा। हर control decision उसके owner, तारीख़ और वजह के साथ लिखें: यही decisions वे deviations बनते हैं जिन्हें test reports समझाती हैं, जो अगले lesson का विषय है।

अभ्यास

Regression cycle का status पढ़ें और control decisions सुझाएँ

आपका काम

आप एक mobile banking app release टेस्ट कर रहे हैं। 5 दिन की regression cycle के day 3 के अंत में test management tool नीचे दिया data दिखाता है। कुल number ठीक लगता है; तय करें कि क्या सच में ऐसा है।

Variances और ख़तरे में पड़े exit criteria पहचानें, control actions सुझाएँ, और बताएँ कि हर action का फ़ैसला किसे करना चाहिए।

सामग्री
Mobile banking app 3.8 - regression cycle, end of day 3 of 5
Plan: 150 tests, 30 a day; the 45 high-risk tests (login, transfers) run first
Exit criteria: all high-risk tests passed; no open Blocker or Critical defect

                          Planned by day 3   Actual
Tests executed                   90            84
High-risk tests executed         45            27
Tests blocked                     0            12  (transfers: test accounts locked)
Tests failed                      -             6  (4 of them on Android 12)
Open defects                      -   Critical 1 (transfer limit not enforced), Major 3

Fix for the Critical defect: promised for day 4
चरण
  1. हर row की plan से तुलना करें।
  2. हर exit criterion को पूरा, track पर या ख़तरे में चिह्नित करें।
  3. Control actions लिखें, हर एक पर "test team" या "stakeholder decision" लिखकर।
  4. लिखें कि day 4 के अंत में आप क्या जाँचेंगे।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Variances: कुल मिलाकर 90 में से 84 tests चले, सिर्फ़ 6 पीछे। Risk के हिसाब से 45 में से 27 high-risk tests चले: 18 पीछे, जिनमें से 12 locked test accounts की वजह से blocked हैं। बाकी 6 blocked नहीं हैं, फिर भी नहीं चले, जबकि plan high-risk tests पहले चलाने को कहता है: वजह पता करें। छह में से चार failures Android 12 पर हैं, शायद platform-specific समस्या।

Exit criteria: "सभी high-risk tests pass" ख़तरे में है; "कोई open Critical defect नहीं" तब तक ख़तरे में रहेगा जब तक day 4 का fix confirmation testing में pass न हो।

Test team: नामित owner के साथ आज ही accounts unlock करवाना; 6 unblocked high-risk tests पहले चलाना; fix का confirmation test करना और transfer regression tests दोबारा चलाना; Android 12 पर छोटा exploratory session जोड़ना; low-risk tests आख़िर में ले जाना।

Stakeholders: रोज़ 30 की रफ़्तार से बचे 66 में से 60 tests ही समा पाएँगे, fix की retesting से पहले। Product owner या release manager चुनते हैं: अधिकतम एक और दिन, या कम से कम 6 low-risk tests न चलाना और residual risk दर्ज करना। Critical fix देर से आए, तो release का फ़ैसला भी उन्हीं का है।

Day 4 checkpoint: blocked tests वापस 0, सभी 45 high-risk tests चले, Critical fix confirm हुआ, Android 12 failures triage हुए — और plan में दर्ज हो कि क्या तय हुआ और किसने तय किया।

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

क्या test monitoring और test reporting एक ही हैं?

नहीं, पर दोनों जुड़े हैं। Monitoring जानकारी इकट्ठा करके plan से तुलना करती है; control उस पर action लेता है। Reporting नतीजा बताती है: testing के दौरान test progress reports और अंत में test completion report, जो अगले lesson का विषय है।

Test control की ज़िम्मेदारी किसकी है?

आम तौर पर test management role वाले व्यक्ति की, जैसे test lead या test manager; agile teams में इनमें से कुछ काम team खुद संभालती है। Testers data देते हैं और actions सुझाते हैं। Release dates, scope और residual risk स्वीकार करने के फ़ैसले product owner जैसे stakeholders के होते हैं।

Testing को कितनी बार monitor करना चाहिए?

Test plan में तय checkpoints पर: अक्सर test execution के दौरान रोज़ (agile teams में daily stand-up में), और हर iteration के अंत में। Events पर भी monitor करें: Critical defect, environment outage या scope में बदलाव होने पर इंतज़ार किए बिना तुरंत जाँच होनी चाहिए।

क्या test monitoring और production monitoring एक ही हैं?

नहीं। Test monitoring, test plan के मुक़ाबले testing की progress और results को track करती है। Production monitoring चलते हुए system पर नज़र रखती है: availability, errors, response times। Production data testing को दिशा दे सकता है, पर ये अलग activities हैं।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021टेस्ट प्रक्रिया मॉडल: संगठनात्मक, टेस्ट प्रबंधन और dynamic टेस्ट प्रक्रियाएँ, उनकी गतिविधियों और परिणामों के साथ।
टूल्स

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

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

प्रतिशत, प्रतिशत परिवर्तन, वृद्धि/कमी और X, Y का कितना प्रतिशत है — सब गिनें।

यूटिलिटीज़

Requirements → टेस्ट केस

क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।

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

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

फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।

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

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

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

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

और गहराई से

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

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