मेंटेनेंस टेस्टिंग
Maintenance testing उन बदलावों की टेस्टिंग है जो पहले से operation में चल रहे system में किए जाते हैं, या बदले हुए environment का उस system पर असर। Software live होने के बाद उस पर ज़्यादातर काम maintenance होता है: defects ठीक होते हैं, features बेहतर होते हैं, platform upgrade होता है, और एक दिन system retire हो जाता है। शुरुआत असली users, सालों के असली data और आज के व्यवहार पर निर्भर दूसरे systems से होती है।
उदाहरण के लिए, चार साल से चल रहा एक clinic booking system नए database server पर जाता है। कोई feature नहीं बदलता, फिर भी team को जाँचना होता है कि हर record सही-सलामत पहुँचा और booking, reminders और invoices पहले जैसे काम करते हैं। Maintenance testing कोई अलग test level नहीं है: यह उन्हीं levels और types का इस्तेमाल करती है जो आप जानते हैं, जैसे confirmation testing और regression testing।
यह क्यों ज़रूरी है
ISTQB Foundation syllabus production में किसी बदलाव की टेस्टिंग को दो काम बताता है: यह आँकना कि बदलाव सफलता से लागू हुआ या नहीं, और उन हिस्सों में regression ढूँढना जो नहीं बदले — जो आम तौर पर system का ज़्यादातर हिस्सा होते हैं। पूरी तरह सही काम करने वाला बदलाव भी किसी अनछुई report या रात की job को तोड़ सकता है, और उस failure का सामना असली customers करते हैं। सब कुछ दोबारा टेस्ट करने का समय शायद ही होता है, इसलिए impact analysis और सोच-समझकर तय किया गया regression scope tester की मेहनत वहाँ लगाते हैं जहाँ बदलाव नुकसान कर सकता है, और team को दिखाते हैं कि क्या टेस्ट हुआ और क्या नहीं।
तीन triggers: modification, migration, retirement
ISTQB Foundation syllabus उन घटनाओं को, जिनसे maintenance testing शुरू होती है, तीन triggers में बाँटता है। Trigger कोई भी हो, टेस्टिंग दो सवालों का जवाब देती है — क्या बदलाव काम कर रहा है, और क्या कुछ और टूटा? — और trigger बताता है कि कहाँ देखना है।
- Modification: release में planned enhancements, defects ठीक करने वाले corrective changes, और hot fixes जो plan से बाहर release होते हैं क्योंकि production का failure इंतज़ार नहीं कर सकता।
- Operational environment का upgrade या migration, जैसे दूसरे platform या database server पर जाना। इसके लिए बदले हुए software के साथ नए environment के tests भी चाहिए हो सकते हैं, और data conversion के tests, जब किसी दूसरे application का data इस system में migrate किया जाता है।
- Retirement: कोई application अपने जीवन के अंत पर पहुँचता है, जैसे जब कोई दूसरा system उसकी जगह ले लेता है। जब उसका data लंबे retention period तक रखना ज़रूरी हो, तो archiving, और archive से data restore व retrieve करना टेस्ट करें; उन systems को भी जाँचें जो उसके साथ data का लेन-देन करते थे। चालू रहने वाले system से सिर्फ़ एक feature हटाना आम तौर पर modification माना जाता है, लेकिन उसके data और उसे call करने वालों पर उतना ही ध्यान चाहिए।
| Trigger | क्या बदलाव काम कर रहा है? | क्या कुछ और टूटा? | यह भी जाँचें |
|---|---|---|---|
| Modificationrelease में planned enhancement | बदले हुए व्यवहार के लिए नए और updated tests | बदले हिस्सों और उन पर निर्भर चीज़ों का regression, साथ में critical core | जिन पुराने tests का expected result जान-बूझकर बदला, वे update होते हैं, report नहीं |
| Modificationcorrective change या hot fix | Confirmation test: defect के steps अब pass होते हैं | Release से पहले छोटा तैयार regression pack, व्यापक run उसके कुछ ही बाद | जो टाला गया, residual risk के रूप में record |
| Upgrade या migrationनया platform या environment | नए environment में installation, configuration और connections | व्यापक regression: बिना बदला code अब बदले platform पर चलता है | Scheduled jobs, backups, पुरानी baseline की तुलना में response times |
| Upgrade या migrationdata conversion | हर record सही-सलामत पहुँचा: counts, totals और sample records source से मेल खाते हैं | Migrated records पढ़ने वाले features | अलग shapes और gaps वाले पुराने records, सिर्फ़ fresh test data नहीं |
| Retirementजीवन के अंत पर पहुँचा application | लंबे retention period तक रखा जाने वाला data archive होता है | जो कुछ अब भी service में है, उसके साथ data का लेन-देन करने वाले systems समेत | Archive से data restore व retrieve करना |
Rows ISTQB Foundation syllabus के तीन triggers के अनुसार हैं; cells इस lesson का सार हैं, कोई तय checklist नहीं।
Impact analysis: यह बदलाव किस पर असर डाल सकता है?
Confirmation और regression testing वाले lesson में आपने impact analysis को regression tests चुनने के तरीक़े के रूप में देखा था। ISTQB glossary इसे ज़्यादा व्यापक रूप में बताती है: बदलाव से प्रभावित सभी work products (code, documents, tests) की पहचान, बदलाव करने के लिए ज़रूरी resources के अनुमान समेत। व्यवहार में इसका मतलब है: जिन हिस्सों को बदलाव सीधे छूता है, जो हिस्से उन पर निर्भर हैं, और वे documents और tests जिन्हें उसके साथ बदलना होगा — संभावित side effects समेत। Syllabus बताता है कि यह बदलाव से पहले भी किया जा सकता है, ताकि दूसरे हिस्सों पर नतीजों को देखते हुए तय हो सके कि बदलाव करना है या नहीं। नतीजा लिखें: यही आपके regression scope का आधार है।
- बदलाव: ticket, बदले हुए modules या code diff, configuration के बदलाव, release notes।
- Dependencies: बदले हुए function या API को call करने वाले, integrations, बदला हुआ data पढ़ने वाली reports और exports, scheduled jobs।
- Traceability: requirements और tests के बीच के links दिखाते हैं कि प्रभावित requirements को कौन-से tests cover करते हैं। जहाँ ये links कभी रखे नहीं गए, वहाँ पूछें और अपनी assumptions record करें।
- Data: वे tables और fields जिन्हें बदलाव पढ़ता या लिखता है, पुराने versions द्वारा सालों पहले बनाए गए records समेत।
- Tests: कौन-से मौजूदा tests fail होंगे क्योंकि व्यवहार जान-बूझकर बदला गया (उन्हें update करें, defect report न करें), और कौन-से नए tests चाहिए।
Regression scope तय करना
Syllabus के अनुसार maintenance testing का scope आम तौर पर बदलाव के risk की मात्रा, मौजूदा system के आकार और बदलाव के आकार पर निर्भर करता है। किसी छोटे internal tool में एक line की wording ठीक करने के लिए confirmation check से ज़्यादा शायद ही कुछ चाहिए; बड़े ERP (enterprise resource planning) system की shared tax calculation में एक line के बदलाव के लिए व्यापक regression चाहिए, क्योंकि बदलाव छोटा होने पर भी risk ऊँचा है।
Confirmation और regression testing वाले lesson के तीन rings (बदला हुआ हिस्सा, उस पर निर्भर हिस्से, critical core) और smoke, sanity और regression वाले guide की selection strategies यहाँ भी लागू होती हैं। Live system इनमें दो layers जोड़ता है: environment और उसका data, और जो छोड़ा गया उसका लिखित record।
- बदलाव: बदले हुए व्यवहार के लिए नए और updated tests, और ठीक हुए defect का confirmation test।
- Direct impact: बदले हुए हिस्सों और उन पर निर्भर हर चीज़ के regression tests।
- Critical core: ऐसी journeys जो कुछ भी बदले, काम करनी ही चाहिए, जैसे login और payment।
- Migration और retirement में environment और data: installation, configuration, integrations, scheduled jobs, backups, पुरानी baseline से तुलना में response times, data reconciliation (counts, totals, sample records) और archive retrieval।
- कारण के साथ out of scope, ताकि team यह मानने के बजाय कि सब कुछ टेस्ट हुआ, residual risk देख सके।
आज़माएँ: रिग्रेशन सिनेरियो जनरेटर आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर
Worked example: live booking system में reminder fix
एक clinic group का booking system हर appointment से 24 घंटे पहले SMS reminder भेजता है, लेकिन दूसरे time zone की branches को यह ग़लत घंटे पर मिलता है, क्योंकि job server की घड़ी इस्तेमाल करती है। Corrective fix हर branch का time zone इस्तेमाल करता है और हर मौजूदा branch के लिए नया time_zone field भरता है; पुराने version द्वारा पहले से schedule किए गए reminders database में बने रहते हैं। Developer के साथ impact analysis से यह scope निकला:
- बदलाव: हर time zone की एक branch के लिए reminder local time में appointment से 24 घंटे पहले पहुँचता है, आधी रात के ठीक बाद वाले appointment समेत।
- Direct impact: SMS और e-mail reminders, rescheduling और cancelling, और reminder status report।
- Update होने वाले tests: दो tests server time में reminder times की उम्मीद करते थे; उन्हें दोबारा लिखा जाता है, defect के रूप में report नहीं किया जाता।
- Data: हर branch का time zone valid है, और पुराने version द्वारा पहले से schedule किए गए reminders team के फ़ैसले के अनुसार local time में दोबारा calculate होते हैं। Sample appointments के लिए reminders API के response की release से पहले और बाद में तुलना दिखाती है कि क्या खिसका।
- Critical core: login, booking और payment का छोटा smoke run।
- Out of scope: billing के detailed tests, क्योंकि billing reminder data नहीं पढ़ती — यह फ़ैसले के रूप में record हुआ, भूल के रूप में नहीं।
आम गलतियाँ
- सिर्फ़ बदलाव टेस्ट करना और बिना बदले हिस्सों में regression छोड़ देना, जबकि system का ज़्यादातर हिस्सा वहीं है।
- "कोई functional बदलाव नहीं" वाले migration को functional testing की ज़रूरत न समझना: बिना बदला code भी बदले हुए platform पर या converted data के साथ fail हो सकता है।
- सिर्फ़ नए version से बने fresh data से टेस्ट करना, जबकि production में अलग shapes और gaps वाले सालों पुराने records हैं।
- पुराने tests को तब तक बदलते रहना जब तक वे pass न हों, यह जाँचे बिना कि व्यवहार का बदलाव intended था — या जान-बूझकर किए गए बदलाव को defect के रूप में report करना।
- किसी application को retire करना, पर archive retrieval और उसके साथ अब भी data का लेन-देन करने वाले systems को टेस्ट न करना।
QA का नज़रिया
असली team में maintenance testing तब शुरू होती है जब बदलाव propose होता है, तब नहीं जब build आता है। Refinement या release planning में वे सवाल पूछें जो impact analysis को आगे बढ़ाते हैं: यह data और कौन पढ़ता है? बदलाव से पहले बने records का क्या होगा? Rollback कैसे करेंगे? Ticket या test plan में एक छोटा scope लिखें: क्या टेस्ट होगा, कितनी गहराई से, और क्या छोड़ा गया और क्यों।
Hot fixes के लिए critical journeys का एक छोटा regression pack तैयार रखें जो मिनटों में चल सके, ताकि कोई urgent fix बिना टेस्ट के release न हो। हर maintenance release के बाद regression suite, traceability links और test data update करें। Testing के बाकी work products के साथ इन्हें testware कहा जाता है, और testware को current रखना भी maintenance है।
अभ्यास
तीन हिस्सों वाले change request का testing scope तय करें
एक library system छह साल से production में है। नीचे दिए change request के हर item के लिए trigger का नाम लिखें, बताएँ कि impact analysis को क्या cover करना चाहिए, और testing scope प्रस्तावित करें। अंत में लिखें कि आप क्या कारण के साथ छोड़ेंगे, और team से आपके सवाल क्या हैं।
Change request CR-118 (library system, छह साल से production में)
1. देर से लौटाने का जुर्माना 1.00 SAR से बढ़कर 2.00 SAR प्रति दिन होगा,
उन loans के लिए जो 1 जनवरी या उसके बाद शुरू होते हैं।
2. Self-service kiosk application retire होगा; members अब front desk इस्तेमाल करेंगे।
पिछले पाँच साल के kiosk loan और payment records audits के लिए retrievable रहने चाहिए।
3. Application अपने application server के नए major version पर जाएगा।- हर item को classify करें: modification, environment का upgrade या migration, या retirement।
- लिखें कि हर बदलाव सीधे किसे छूता है, उस पर कौन निर्भर है, और testing focus क्या है: बदलाव खुद, regression, environment, data या archive।
- कुल scope, out of scope हिस्से और अपने खुले सवाल तय करें।
मॉडल उत्तर दिखाएँ
Item 1 fine calculation का modification है; overdue notices, member balances और fines report उस पर निर्भर हैं। Boundary टेस्ट करें: 31 दिसंबर को शुरू हुआ loan जनवरी में overdue होने पर भी 1.00 SAR प्रति दिन देता है; 1 जनवरी को शुरू हुआ loan 2.00 देता है। नए loans के लिए 1.00 की उम्मीद करने वाले tests update करने होंगे।
Item 2 एक retirement है: kiosk application अपने जीवन के अंत पर पहुँचता है। जाँचें कि उसके records archive हुए हैं और पिछले पाँच साल के kiosk loans और payments restore किए, ढूँढे और पढ़े जा सकते हैं; कि अब कुछ भी kiosks पर निर्भर नहीं है (integrations, scheduled jobs, kiosk loans गिनने वाली reports); और regression के तौर पर front desk पर loans और returns भी जाँचें, क्योंकि अब सारा traffic वहीं है।
Item 3 environment का upgrade है: installation, configuration, e-mail और payment connections, overdue notices की nightly job, और पुरानी baseline की तुलना में मुख्य response times टेस्ट करें।
Scope: तीन बदलाव, पैसा और नया server, इसलिए नए environment पर कम से कम एक बार पूरा regression suite चलाएँ, ऊपर के tests के साथ। Out of scope का उदाहरण: पूरा load test, अगर response times में कोई फ़र्क़ न दिखे — residual risk के रूप में record करें। सवाल: 1 जनवरी के बाद renew हुआ loan क्या नया माना जाएगा? Kiosk archive कहाँ और कितने समय तक रखा जाएगा, और audit के लिए उसे restore कौन करेगा? Rollback plan क्या है?
अक्सर पूछे जाने वाले सवाल
क्या maintenance testing और regression testing एक ही हैं?
नहीं। Regression testing उसका एक हिस्सा है। Maintenance testing बदलाव को खुद भी टेस्ट करती है — नया या बदला हुआ व्यवहार और ठीक हुए defects का confirmation — और migration व retirement में नया environment, converted data और archives भी। Regression testing maintenance के बाहर भी होती है, जैसे नया system बनते समय हर build पर।
Impact analysis कौन करता है, developers या testers?
दोनों, और बेहतर है कि business analyst या product owner भी साथ हो। Developers code dependencies देखते हैं; testers business flows, data और test coverage देखते हैं; business side जानती है कि feature असल में कैसे इस्तेमाल होता है। अकेला व्यक्ति अक्सर असर की एक पूरी category चूक जाता है।
क्या urgent hot fix को भी regression testing चाहिए?
हाँ, लेकिन छोटी और पहले से तैयार: release से पहले confirmation test और critical journeys का पहले से तय छोटा pack, फिर उसके कुछ ही समय बाद व्यापक regression run। जो टाला गया उसे record करें, ताकि वह run pass होने तक risk दिखता रहे।
अगर पुराने system का न documentation हो, न tests, तो क्या करें?
पहले exploratory testing से और users व support staff से बात करके उसका मौजूदा व्यवहार समझें। बदलाव से पहले ज़रूरी outputs record करें — API responses, reports, calculated values — और बदलाव के बाद के outputs से उनकी तुलना करें। कुछ teams ऐसे tests को characterization tests कहती हैं। काम करते-करते traceability धीरे-धीरे बनाएँ।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
Mutqan tools से अभ्यास करें
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।
दो API रिस्पॉन्स (जैसे staging बनाम production) की तुलना करें और हर संरचनात्मक तथा वैल्यू का अंतर देखें।
दो JSON डॉक्यूमेंट की सिमैंटिक तुलना करें और जोड़ी गई, हटाई गई तथा बदली गई वैल्यू हाइलाइट करें।
और गहराई से
- स्मोक, सैनिटी और रिग्रेशन टेस्टिंग में अंतरRegression चयन: क्या चलाएँ
- रिस्क-आधारित टेस्टिंगRegression टेस्ट चुनने में risk का उपयोग
- Transactions और DB migrations की टेस्टिंगMigration कैसे टेस्ट करें
- डिप्लॉयमेंट वेरिफ़िकेशन टेस्टिंगडिप्लॉयमेंट कैसे वेरिफ़ाई करें: पहले से लिखा प्लान, post-deploy smoke टेस्ट, synthetic checks, canary रिलीज़, feature flags, सिग्नल और rollback।
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।