कन्फ़र्मेशन और रिग्रेशन टेस्टिंग
Software में हर बदलाव दो सवाल खड़े करता है। Confirmation testing, जिसे re-testing भी कहते हैं, पहले सवाल का जवाब देती है: क्या report किया गया defect सच में ठीक हुआ? आप fix वाले build पर वही test दोहराते हैं जो fail हुआ था। Regression testing दूसरे सवाल का जवाब देती है: क्या fix ने, या किसी और बदलाव ने, कुछ ऐसा तोड़ा जो पहले काम करता था? आप पहले pass हुए tests उन हिस्सों में दोबारा चलाते हैं जिन्हें बदलना नहीं था।
उदाहरण: developer एक checkout form ठीक करता है जो +966 50 000 1234 की तरह लिखे mobile numbers reject करता था। Confirmation test वही number डालकर order place करता है, और regression tests sign-up, profile editing और one-time password (OTP) screen जाँचते हैं, क्योंकि ये वही validation code इस्तेमाल करते हैं।
यह क्यों ज़रूरी है
Regression किसी बदलाव से आई quality की गिरावट है: जो feature कल चलता था, वह आज fail होता है। Products code, data और services साझा करते हैं, इसलिए एक जगह की एक line का fix ऐसी screen तोड़ सकता है जिसे किसी ने छुआ नहीं, और जब टीम सिर्फ़ report हुआ bug जाँचती है तो ऐसा defect आसानी से production तक पहुँच जाता है।
दोनों activities अलग-अलग evidence देती हैं। Confirmation test के बिना defect close करना ऐसे fix की रिपोर्ट है जो शायद हो ही नहीं; regression testing के बिना fix confirm करना सुरक्षित release जताता है, जबकि किसी ने देखा ही नहीं। समय में फ़िट होने वाला regression scope चुनना और क्या automate करना है यह तय करना, लगभग हर fix के बाद का फ़ैसला है।
Confirmation testing: क्या defect सच में ठीक हुआ?
ISTQB Foundation syllabus confirmation testing को यह पुष्टि करना बताता है कि मूल defect सफलतापूर्वक ठीक हो गया है। Risk के हिसाब से, आप defect की वजह से fail हुए सभी test cases चलाते हैं और fix के लिए किए गए बदलावों को cover करने वाले नए tests जोड़ते हैं; समय या पैसा कम हो तो कम से कम failure reproduce करने वाले steps दोहराकर जाँचते हैं कि वह अब नहीं होता।
पहले मूल steps, data और environment इस्तेमाल करें, ताकि pass का सच में मतलब हो कि fix काम करता है। फिर एक बार में एक चीज़ बदलें — दूसरा input format, दूसरा role, पड़ोसी boundary value — क्योंकि fix अक्सर सिर्फ़ report हुआ case cover करता है। पिछले lesson के edge cases इन variants का अच्छा स्रोत हैं।
- पहले build जाँचें: defect के resolution में उस build का नाम होना चाहिए जिसमें fix है।
- Pass: build, data और result दर्ज करें, फिर defect close होने से पहले regression tests चलाएँ।
- Fail: दूसरा defect खोलने की बजाय नए evidence के साथ वही defect reopen करें।
Regression testing: क्या बदलाव ने कुछ और तोड़ा?
Regression testing पहले pass हुए tests दोबारा चलाती है, ताकि पता चले कि बदलाव ने उन हिस्सों में कोई defect introduce या uncover तो नहीं किया जिन्हें बदलना ही नहीं था। "Uncover" अहम है: fix कोई पुराना defect उजागर कर सकता है जिसे पहला defect छिपाए हुए था, जैसे एक दूसरी जाँच जो कभी चली ही नहीं क्योंकि पहली जाँच input को हमेशा reject कर देती थी।
Syllabus बताता है कि असर बदले गए component में, दूसरे components में या जुड़े हुए systems में दिख सकते हैं, और regression testing सिर्फ़ test object तक सीमित नहीं: यह environment से भी जुड़ी हो सकती है। Confirmation test pass कर चुके fix को भी regression testing चाहिए, क्योंकि fix ख़ुद एक बदलाव है, और जिस भी test level पर defect ठीक हो या बदलाव हो, वहाँ दोनों तरह की testing चाहिए। आम triggers:
- Defect fixes, नए features और refactoring (code का काम बदले बिना उसकी बनावट सुधारना)।
- Libraries, frameworks, database या operating system के upgrades।
- Configuration changes, feature flags (किसी feature को चालू या बंद करने वाले switches), database migrations और जुड़े हुए systems में बदलाव।
Impact analysis: क्या दोबारा चलाना है, यह चुनना
हर बदलाव के बाद हर test चलाना सबसे सुरक्षित विकल्प है, और छोटे suite के लिए सही भी। Syllabus पहले impact analysis की सलाह देता है, ताकि regression testing का दायरा तय हो: यह दिखाता है कि बदलाव software के किन हिस्सों पर असर डाल सकता है। इसकी अहमियत सबसे ज़्यादा तब है जब पूरा suite उपलब्ध समय में न समाए। याददाश्त से चुनने की बजाय बदलाव पढ़ें और developer से पूछें।
नीचे के सवालों के जवाब तीन rings में scope देते हैं: बदला हुआ हिस्सा, उस पर सीधे निर्भर हिस्से, और critical journeys का एक छोटा core जो हर बदलाव के बाद चलता है। जो छोड़ रहे हैं वह और उसकी वजह दर्ज करें; scheduled full run वह पकड़ लेता है जो selection से छूट गया।
- ठीक-ठीक क्या बदला: code, data structure, configuration या कोई dependency? Pull request (review के लिए developer का भेजा हुआ बदलाव) और उसका diff, यानी बदली हुई lines, यह बताते हैं।
- और कौन इसका इस्तेमाल करता है: screens, APIs, reports, jobs या services जो वही function call करती हैं या वही table पढ़ती हैं। Traceability matrix दिखाता है कि बदली हुई requirement को कौन-से tests cover करते हैं।
- यह कौन-सा stored data छूता है: बदलाव से पहले save हुए records बदलाव के बाद भी काम करने चाहिए।
- हर हाल में क्या high risk है: payments, login, data export, और वे हिस्से जो पहले ऐसे ही बदलावों के बाद टूटे थे।
- 1Fix deliver हुआDefect में उस build का नाम है जिसमें fix है
- 2Confirmation testइसे re-testing भी कहते हैंपहले मूल steps और data, फिर नज़दीकी variants
शाखा: अब भी fail: नए evidence के साथ defect reopen करेंफ़ेल
गेट: report हुआ failure अब नहीं होता
- 3Impact analysisक्या बदला, कौन इस्तेमाल करता है, कौन-सा stored data छूता है, क्या high risk है
- 4चुने हुए regression testsबदला हुआ हिस्सा, सीधे निर्भर हिस्से, हमेशा चलने वाला core
शाखा: कहीं और नया failure: fix से linked नया defect report करेंफ़ेल
गेट: कोई नया failure नहीं
- 5Close करें, test रखेंDefect close करें; confirmation test को automated regression suite में जोड़ें
- Scheduled full regression runरात में या release से पहले: selection से जो छूटा उसे पकड़ता है
दो तरह के failure, दो अलग कदम: confirmation test fail हो तो वही defect reopen होता है; regression testing में मिला नया failure fix से linked नया defect बनता है।
आज़माएँ: रिग्रेशन सिनेरियो जनरेटर आज़माएँ: Requirements → टेस्ट केस आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर
Worked example: shared validation code में एक fix
Defect BUG-2143: checkout पर international format के mobile numbers, जैसे +966 50 000 1234, "Invalid phone number" message के साथ reject होते हैं। Build 3.4.2 shared function normalizePhone() ठीक करता है। "और कौन इसे इस्तेमाल करता है?" पूछने पर पता चलता है कि sign-up, profile editing और OTP SMS service भी इसे call करती हैं।
Confirmation test pass हुआ: report हुआ number और उसके variants accept होकर एक format में save होते हैं, और बहुत छोटा number अब भी reject होता है। फिर regression testing में नया failure मिला: जिन customers के numbers fix से पहले save हुए थे, उन्हें अब OTP नहीं मिलता, क्योंकि SMS service अब numbers को नए format में ढूँढती है। यह fix से पैदा हुआ नया defect है, इसलिए इसे अलग से report करके BUG-2143 से link किया जाता है, original को reopen नहीं किया जाता।
- इसे impact analysis के stored data वाले सवाल ने पकड़ा: नए numbers ठीक चले; सिर्फ़ बदलाव से पहले save हुए records fail हुए।
- किसी एक पुराने customer के profile API response की old और new build पर तुलना format का बदलाव तुरंत दिखा देती है।
- नीचे का note plan दर्ज करता है, जानबूझकर छोड़े गए हिस्सों समेत।
BUG-2143 | build 3.4.2 | changed: normalizePhone() in shared validation
1. CONFIRMATION (original steps, data and environment first)
[ ] checkout with +966 50 000 1234 -> accepted, order placed
[ ] 0500001234, 966500001234, with spaces -> accepted, saved as +966500001234
[ ] +966 50 000 12 (too short) -> still rejected
2. REGRESSION (selected by impact analysis)
changed area phone field at checkout: all existing test cases
dependents sign-up, profile edit, OTP by SMS: same stored format
stored data customers saved before 3.4.2 still receive their OTP
core log in, search, card payment (critical journeys)
left out wishlist and reviews: they do not use phone numbers
safety net full regression suite in the scheduled nightly runRegression tests सबसे पहले automate क्यों होते हैं
Regression tests बार-बार चलते हैं और हर release के साथ suite बढ़ता है, इसलिए syllabus regression testing को automation का मज़बूत उम्मीदवार कहता है और इसे जल्दी शुरू करने की सलाह देता है। Continuous integration में ये tests हर बदलाव पर चलते हैं, अक्सर कई levels पर: logic के लिए component tests, services के लिए API tests और कुछ end-to-end journeys।
Confirmation test अक्सर एक बार, हाथ से चलता है। उसे सबसे निचले संभव level पर automated regression test बनाकर रखें — यहाँ, report हुए number और उसके variants के साथ normalizePhone() का component test — ताकि वही defect चुपचाप वापस न आए।
- अच्छे उम्मीदवार: stable features, deterministic expected results, critical journeys और कई data values से जाँचे जाने वाले rules।
- कमज़ोर उम्मीदवार: हर sprint में बदलते features, एक बार की जाँचें, और layout या ease of use पर फ़ैसले।
- Automation tests चलाता है, उन्हें चुनता नहीं, और suite को किसी भी दूसरे code की तरह maintenance चाहिए।
आम गलतियाँ
- Developer के कहने भर पर defect close करना, fix वाले build पर confirmation test किए बिना।
- सिर्फ़ report हुई exact value re-test करना और वे variants छोड़ देना जिन्हें fix नहीं संभालता।
- Pass हुए confirmation test को release के सुरक्षित होने का सबूत मानकर regression testing छोड़ देना।
- Regression tests याददाश्त से चुनना, न कि बदलाव, उस पर निर्भर हिस्सों और उसके data से।
- Regression testing में मिले किसी अलग failure के लिए original defect reopen करना, जिससे दो histories एक record में मिल जाती हैं।
- Regression suite को सिर्फ़ बढ़ने देना, जिससे पुराने, duplicate और skip होने वाले tests हर run को धीमा करते हैं।
QA का नज़रिया
टीम में यह काम तब शुरू होता है जब defect resolved mark होता है। Developer से पूछें: किस build में fix है, ठीक-ठीक क्या बदला, और बदले हुए code का और कौन इस्तेमाल करता है; जवाब और अपना चुना हुआ scope defect या test run में दर्ज करें, ताकि बाद में फ़ैसले की समीक्षा हो सके।
दोनों results अलग report करें, जैसे: "BUG-2143 build 3.4.2 पर fixed confirm हुआ। Regression: 46 में से 45 चुने हुए tests pass, एक नए defect (BUG-2150) के साथ fail, wishlist और reviews नहीं चले, full suite आज रात।" Release के फ़ैसले ऐसे ही वाक्य पर टिकते हैं, इसलिए उसमें साफ़ हो कि क्या टेस्ट हुआ और क्या नहीं।
अभ्यास
Shipping fix के लिए re-test और regression scope plan करें
Defect BUG-3310: "200.00 SAR या उससे ज़्यादा के orders free ship होते हैं, लेकिन check coupons को नज़रअंदाज़ करता है: 20.00 SAR coupon वाली 210.00 SAR की cart अब भी free ship होती है।" Build 5.2.0 pricing service का calculateShipping() ठीक करता है, जिसे cart page, checkout summary, mobile app का order preview और nightly invoice export भी इस्तेमाल करते हैं।
Confirmation tests और rings में regression scope लिखें, बताएँ क्या छोड़ रहे हैं, और automate करने के लिए एक test चुनें।
- Defect के मूल data से confirmation test लिखें।
- Discount के बाद 200.00 की limit के दोनों तरफ़ variants जोड़ें; prices 0.01 के step से चलती हैं, जैसे पिछले lesson की boundary values में।
- Impact analysis के सवालों के जवाब दें और regression rings लिखें, छोड़े गए हिस्सों समेत।
- Automate करने के लिए एक test चुनें और उसका level बताएँ।
मॉडल उत्तर दिखाएँ
Confirmation: 210.00 में से 20.00 coupon घटाकर 190.00 बचता है, इसलिए shipping fee लगती है। Variants: discount के बाद 199.99 → fee लगती है; ठीक 200.00 (220.00 minus 20.00) → free; 25% coupon के साथ 250.00 (187.50) → fee लगती है; बिना coupon 210.00 → अब भी free।
Impact analysis: calculateShipping() में shipping check बदला; cart page, checkout summary, mobile order preview और invoice export इसे इस्तेमाल करते हैं; 5.2.0 से पहले बने orders stored data हैं; payment totals high risk हैं।
Rings: बदला हुआ हिस्सा — सभी shipping और coupon test cases; निर्भर हिस्से — cart, checkout summary और mobile preview वही fee दिखाते हैं जो pricing API देता है, और invoice export 5.2.0 से पहले और बाद के orders के लिए सही है; core — login, add to cart, card payment। छोड़े गए: profile, search और reviews, क्योंकि ये calculateShipping() call नहीं करते। Safety net: scheduled full run।
Automate: calculateShipping() का data-driven component या API test (एक test जो values की हर row के लिए एक बार चलता है), 199.99, 200.00 और मूल case के साथ, pipeline के regression suite में जोड़ा गया।
अक्सर पूछे जाने वाले सवाल
क्या re-testing और regression testing एक ही हैं?
नहीं। Re-testing, जिसे ISTQB confirmation testing कहता है, fail हुए tests दोहराकर जाँचती है कि एक ख़ास defect ठीक हुआ। Regression testing जाँचती है कि fix ने, या किसी और बदलाव ने, ऐसे दूसरे हिस्से नहीं तोड़े जो पहले काम करते थे। Fix के बाद आम तौर पर दोनों चाहिए।
अगर code की सिर्फ़ एक line बदली हो, तो क्या regression testing चाहिए?
हाँ, लेकिन उसका आकार impact के हिसाब से हो। किसी shared function में एक line उसके हर caller पर असर डाल सकती है, जबकि एक screen पर एक text बदलने के लिए confirmation test और हमेशा चलने वाले core से ज़्यादा की ज़रूरत शायद न हो। Impact analysis बताता है कि आप किस स्थिति में हैं।
क्या confirmation tests automate करने चाहिए?
पहला confirmation अक्सर हाथ से होता है, क्योंकि वह defect report के पीछे चलता है और उसमें इंसानी समझ चाहिए। उसके बाद, उसे सबसे निचले संभव level पर automated regression suite में जोड़ना उसी defect के लौटने से बचाता है।
Regression scope कौन तय करता है?
आम तौर पर tester impact analysis और risk list से इसे propose करता है, developer पुष्टि करता है कि बदलाव क्या-क्या छूता है, और समय कम हो तो test lead या टीम उस पर सहमत होती है। जो भी तय हो, उसे दर्ज करें ताकि उसकी समीक्षा हो सके।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
- ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsसॉफ़्टवेयर टेस्टिंग का अंतरराष्ट्रीय मानक: अवधारणाएँ, प्रक्रियाएँ, दस्तावेज़ीकरण और तकनीकें।
Mutqan tools से अभ्यास करें
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।
क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
दो API रिस्पॉन्स (जैसे staging बनाम production) की तुलना करें और हर संरचनात्मक तथा वैल्यू का अंतर देखें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।