मॉड्यूल 9 · डिफ़ेक्ट मैनेजमेंट

रिग्रेशन डिफ़ेक्ट

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

Regression defect वह defect है जो किसी change के बाद उस चीज़ को fail कर देता है जो पहले काम करती थी। ISTQB glossary इस नतीजे को regression कहती है: किसी change की वजह से component या system की quality में गिरावट। पहले वाले version में काम करता था, बाद वाले में fail होता है, और दोनों के बीच एक change है: नया code, कोई fix, library upgrade, configuration setting या data migration।

उदाहरण: एक developer नए courier के लिए postcode check जोड़ता है, और उसी build से checkout हर उस saved address को reject करने लगता है जिसमें postcode नहीं है। Checkout page को किसी ने छुआ तक नहीं, फिर भी वह टूट गया।

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

Users वह चीज़ खो देते हैं जिस पर वे पहले से निर्भर थे, अक्सर product के ऐसे हिस्से में जिसका release notes में ज़िक्र नहीं होता, इसलिए वहाँ कोई देख भी नहीं रहा था। अक्सर team से पहले support को इसकी ख़बर मिलती है।

Tester के लिए regression में एक ऐसा फ़ायदा है जो ज़्यादातर defects में नहीं होता: तुलना के लिए एक known good version। जो report आख़िरी काम करने वाला version और पहला fail होने वाला version बताती है, उससे developer पूरे code base की बजाय कुछ ही changes में खोजता है, और हर regression regression suite की एक ऐसी कमी दिखाता है जिसे team भर सकती है।

Defect को regression क्या बनाता है

दो तथ्य किसी defect को regression बनाते हैं: behaviour पहले वाले version में काम करता था, और किसी change ने उसे fail कर दिया। पहला तथ्य मानकर न चलें, जाँचें: वही test पिछले build या release पर चलाएँ। कई teams फिर regression label लगाती हैं और दोनों versions दर्ज करती हैं।

  • Introduced: change में ही गलती है, जैसे किसी एक caller के लिए बदला गया shared function जो दूसरे caller को तोड़ देता है।
  • Uncovered: change किसी पुराने, छिपे defect को सामने ले आता है, जैसे कोई fix input को ऐसे check तक पहुँचने देता है जो पहले कभी चला ही नहीं।
  • Reintroduced: fix हुआ defect लौट आता है, अक्सर किसी merge में fix खो जाने से। कुछ teams इसे recurring defect कहती हैं।
  • Regression नहीं: ऐसा behaviour जो कभी काम ही नहीं करता था, किसी नए feature में या देर से मिले पुराने defect के रूप में। यह पिछले version पर भी fail होता है।

Regression क्यों होते हैं

किसी change का review आम तौर पर उसके अपने मक़सद के लिए होता है, उस पर निर्भर हर जगह के लिए नहीं। ISTQB Foundation syllabus बताता है कि उसके बुरे असर बदले गए component में, उसी system के दूसरे components में या connected systems में दिख सकते हैं, और regression testing सिर्फ़ test object तक सीमित नहीं है: वह environment से भी जुड़ी हो सकती है। Regression users तक तब पहुँचता है जब टूटे behaviour को कोई test नहीं जाँचता, test चला ही नहीं, या fail हुआ और किसी ने कुछ नहीं किया। आम कारण:

  • Shared code: कई जगह इस्तेमाल होने वाला function, component, style rule या API सिर्फ़ उनमें से एक को ध्यान में रखकर बदला गया।
  • Fixes और refactoring: report हुए case के लिए सही, या कुछ न बदलने के इरादे से किए गए, फिर भी किसी edge case के लिए अलग।
  • Libraries, frameworks, browsers या database के upgrades; configuration और feature flags में बदलाव।
  • Data: कोई migration, या नया rule जो पुराने rule के तहत save हुए records से टकराता है।
  • Merges और connected systems: गलत तरीक़े से सुलझाया गया conflict, या कोई service जिसका contract बदल गया।

Regression पकड़ना: suites, baselines और bisecting

Regression suite regressions पकड़ने के लिए ही होता है: पहले से काम कर रहे behaviour के tests, जो changes के बाद दोबारा चलाए जाते हैं। क्योंकि यह बार-बार चलता है और हर release के साथ बढ़ता है, ISTQB syllabus regression testing को automation के लिए एक मज़बूत candidate मानता है। जो test पिछले build पर pass हुआ और इस build पर fail होता है, वह regression का सबसे साफ़ संकेत है। पहले flaky test, environment या data की समस्या, या जान-बूझकर बदले गए behaviour से पुराना पड़ा test ख़ारिज करें, जैसा failed और blocked tests वाले lesson में है। फिर वही test उसी environment में आख़िरी उस version पर चलाएँ जो good होना चाहिए (baseline)। दोनों versions के outputs की तुलना, जैसे दो API responses, अक्सर ठीक-ठीक दिखा देती है कि क्या बदला।

Bisecting आख़िरी good और पहले bad version के बीच की range को एक change तक छोटा कर देती है। यह binary search है: बीच वाला version टेस्ट करें, वह आधा हिस्सा रखें जिसमें result pass से fail में बदलता है, और दोहराएँ। 16 candidate builds के लिए ज़्यादा से ज़्यादा 4 tests चाहिए; लगभग 1,000 commits (Git में save किए गए changes) के लिए 10। Commits पर git bisect यह हिसाब रखता है; source code के बिना आप test environment में build numbers या releases को इसी तरह bisect कर सकते हैं।

  • भरोसेमंद check इस्तेमाल करें: flaky test खोज को गलत आधे में भेज देता है।
  • सिर्फ़ version बदलें; environment, configuration और data वही रखें।
  • जो step टेस्ट न हो सके उसे अंदाज़ा लगाने की बजाय skip करें (git bisect skip)।
  • Result वह पहला change है जहाँ failure दिखता है। हो सकता है उसने कोई पुराना defect सिर्फ़ सामने ला दिया हो, इसलिए यह developer के लिए evidence है, दोष नहीं।
git bisect start
git bisect bad                # the version you are on fails
git bisect good v2.7.0        # the last version known to pass
# Git checks out a commit halfway: build it, run the test, then mark it
git bisect good               # or: git bisect bad
# repeat until Git prints "<commit> is the first bad commit"
git bisect reset              # return to where you started

आज़माएँ: API रिस्पॉन्स कम्पेरेटर आज़माएँ: JSON डिफ़ आज़माएँ: टेक्स्ट डिफ़

Worked example: checkout regression को bisect करना

Nightly regression run सोमवार को build 140 पर pass होता है और मंगलवार को build 156 पर fail: TC-311, यानी बिना postcode वाले saved address से checkout, अब payment पर "Address is incomplete" के साथ रुक जाता है। Build 156 पर दोबारा चलाने पर TC-311 उसी तरह fail होता है; build 140 पर, उसी environment में और उसी customer के साथ, pass होता है। तो यह regression है, जो builds 141 से 156 में से किसी एक में आया, और हर build में एक merged change है।

चार tests काफ़ी हैं। Build 147 में सिर्फ़ PR-882 है, जिसने नए courier के लिए shared function validateAddress() में postcode को required बनाने वाला check जोड़ा: नए addresses के लिए सही, उससे पहले save हुए हर address के लिए गलत। Pull-request checks pass हो गए थे क्योंकि उनके test data में सिर्फ़ नए addresses थे।

Saved-address checkout regression का bisect: TC-311 के चार runs builds 141 से 156 को build 147 तक छोटा कर देते हैं, पहला build जिसमें यह fail होता है।

Build number, test TC-311

अक्ष 140 से 156 तक
  • 140–146Good: TC-311 pass होता है
  • 147–156Bad: build 147 से TC-311 fail होता है
  1. 1140 सोमवार का nightly run: last known goodउसी environment में दोबारा चलाने पर: passपास
  2. 2156 मंगलवार का nightly run: known badदोबारा चलाने पर: उसी तरह failफ़ेल
  3. 3148 Bisect test 1अगली range: 141–148फ़ेल
  4. 4144 Bisect test 2अगली range: 145–148पास
  5. 5146 Bisect test 3अगली range: 147–148पास
  6. 6147 Bisect test 4: पहला bad buildइसमें एक ही change है: PR-882फ़ेल
  • Report title: "Checkout बिना postcode वाले saved addresses reject करता है (build 147 से regression)"।
  • Evidence: आख़िरी good build 146, पहला bad build 147, संदिग्ध change PR-882, nightly run में TC-311 ने पकड़ा।
  • Fix check को सिर्फ़ नए courier पर लागू करता है, और TC-311 pull-request checks में जुड़ जाता है।
पाठ संस्करण
Known good: build 140   Monday nightly run, TC-311 passed
Known bad:  build 156   Tuesday nightly run, TC-311 failed
Candidates: builds 141..156, one merged change each (16 builds)

Test  Build  TC-311  First bad build is in
1     148    fail    141..148
2     144    pass    145..148
3     146    pass    147..148
4     147    fail    147  -> first bad build

Build 147 contains one change: PR-882 "Require postcode for new courier"

Regression रोकना

कोई team हर regression नहीं रोक सकती, पर हर regression को कम संभावित बनाया जा सकता है और उसके कारण के ज़्यादा क़रीब पकड़ा जा सकता है। Regression जितना जल्दी पकड़ा जाए, आख़िरी good और पहले bad result के बीच उतने कम changes होते हैं: pull-request check पर एक change, nightly run में एक दिन के changes, exploratory testing के साथ release regression में release के changes, और production में फिर वही release के changes, पर users पर असर पड़ने के बाद।

Regression कहाँ पकड़ा गया, यह तय करता है कि कितना खोजना होगा: pull-request check पर एक change, nightly run में एक दिन के changes, users के report करने पर पूरा release। वैचारिक मॉडल
  1. 1Change लिखा गयाcode, configuration, dependency या dataMerge से पहले impact analysis करें
  2. 2Pull-request checksRelevant regression tests · खोजने को एक change

    गेट: merge हुआ

  3. 3Main branch पर nightly runपूरा regression suite · खोजने को एक दिन के changes
  4. 4Release regressionRegression tests और exploratory testing · users के देखने से पहले release के changes

    गेट: release हुआ

  5. 5ProductionUsers report करते हैं · users पर असर पड़ने के बाद release के changes

पहले: last good और first bad के बीच कम changesबाद में: खोजने को ज़्यादा changes, users पर असर

उदाहरण भर: teams इन runs को अलग नाम देती हैं और अलग तरह से जोड़ती हैं।

  • Merge से पहले एक छोटा impact analysis करें: यह code और कौन इस्तेमाल करता है, और कौन-सा stored data नए rule से टकराता है?
  • हर pull request पर change से जुड़े regression tests, impact और risk के आधार पर चुने हुए, और main branch पर पूरा suite चलाएँ, ऐसे quality gate की तरह जो change रोक सके।
  • ऐसा test data रखें जो production के इतिहास जैसा दिखे: पुराने records, ख़ाली optional fields, पुराने rules के तहत save हुआ data।
  • हर fix हुए regression के लिए वह test जोड़ें जो उसे पकड़ लेता, सबसे निचले level पर जहाँ वह लिखा जा सके।
  • Flaky tests ठीक करें या quarantine करें, ताकि red run का हमेशा कोई मतलब हो।
  • छोटे changes चुनें, और libraries को अलग change में regression run के साथ upgrade करें; छोटे changes का review और bisect आसान होता है।

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

आम गलतियाँ

  • यह जाँचे बिना किसी defect को regression कहना कि वह पहले वाले version में काम करता था।
  • आख़िरी good और पहले bad version के बिना regression report करना।
  • Flaky test से bisect करना, या steps के बीच environment या data बदल देना।
  • Bisecting से मिले change को दोषारोपण मानना; हो सकता है उसने कोई पुराना defect सिर्फ़ सामने ला दिया हो।
  • वह test जोड़े बिना regression fix करना जो उसे पकड़ लेता।
  • Red regression run की आदत डाल लेना, जहाँ नए regressions जाने-पहचाने failures के बीच छिप जाते हैं।

QA का नज़रिया

जब कोई regression test fail हो, तो पहले failure को भरोसेमंद बनाएँ: दोबारा चलाएँ, environment और data जाँचें, और test को आख़िरी good version पर चलाएँ। फिर regression evidence के साथ report करें: आख़िरी good और पहला bad version, पकड़ने वाला test और, अगर bisect किया हो, तो संदिग्ध change। अगर पुराने versions build नहीं कर सकते, तो किसी developer के साथ bisect करें: आपका भरोसेमंद test और history तक उसकी पहुँच एक मज़बूत जोड़ी है।

Triage में दो अतिरिक्त सवाल पूछें: किस change ने इसे पैदा किया, और हमारे tests से यह क्यों छूटा? दूसरे सवाल का जवाब एक action बनता है, जैसे नया test, missing test data, या pipeline में किसी test को पहले ले जाना। Regression होने से severity नहीं बदलती, जो impact पर निर्भर है, पर अक्सर priority बढ़ जाती है, क्योंकि users ने कुछ ऐसा खोया जिस पर वे निर्भर थे और कारण एक हालिया, पहचाना हुआ change है।

अभ्यास

Release regression को classify, bisect और report करें

आपका काम

Release 3.1 को production में चल रहे release 3.0 (build 200) के मुक़ाबले टेस्ट किया जा रहा है। Builds 201 से 232 में से हर एक में एक merged change है। Test cycle से नीचे दी गई तीन reports मिलीं।

तय करें कि कौन-सी regression हैं, bisect की योजना बनाएँ, bug report के regression fields लिखें, और रोकथाम के दो actions सुझाएँ।

सामग्री
Release 3.1 candidate: build 232। Production में release 3.0: build 200।
Builds 201..232 में से हर एक में एक merged change है।

A  TC-540  "cafe" search करने पर product "Café Latte" मिलता है
           build 200: pass     build 232: fail
B  3.1 में नया: "Filter by brand" brands को random क्रम में दिखाता है
C  Profile में 29/02/2000 की date of birth save नहीं होती
           build 232: fail     production में release 3.0: fail
चरण
  1. A, B और C को classify करें, और हर एक के लिए निर्णायक evidence बताएँ।
  2. ज़्यादा से ज़्यादा कितने bisect tests चाहिए? पहले कौन-सा build, और pass या fail के बाद अगला कौन-सा?
  3. Bisect build 219 पर ख़त्म होता है, जिसमें सिर्फ़ search library का upgrade है। Title, आख़िरी good और पहला bad build, संदिग्ध change और पकड़ने वाला test लिखें।
  4. रोकथाम के दो actions सुझाएँ।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

A regression है: TC-540 build 200 पर pass और 232 पर fail होता है। B नहीं: feature 3.1 में नया है और कभी काम नहीं करता था। C भी नहीं: यह release 3.0 में भी fail होता है, यानी देर से मिला पुराना defect है। B और C regression label के बिना report होते हैं।

32 builds के लिए ज़्यादा से ज़्यादा 5 tests चाहिए। पहले 216 टेस्ट करें; pass हो तो अगला 224 (range 217 से 232), fail हो तो 208 (range 201 से 216)। Environment और data वही रखें।

Title: "Search अब accent वाले product names से match नहीं करता (build 219 से regression)"। आख़िरी good 218, पहला bad 219, संदिग्ध change search library का upgrade, पकड़ा TC-540 ने। हो सकता है upgrade ने कोई default बदला हो, जैसे accents की तुलना का तरीक़ा, न कि उसमें कोई fault हो; यह developer तय करता है।

रोकथाम (कोई दो): search या उसकी dependencies को छूने वाले हर pull request पर search tests चलाना; libraries को अलग change में upgrade करना और बदले हुए defaults के लिए उनके release notes पढ़ना; test data में accent वाले, Arabic और mixed-script product names जोड़ना।

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

क्या regression testing में मिला हर defect regression defect होता है?

नहीं। Regression run किसी पुराने defect पर भी fail हो सकता है, जैसे जब suite में नया test या नया test data जोड़ा जाए, और regression किसी भी activity से मिल सकता है, exploratory testing और user reports समेत। Defect को regression उसका यह evidence बनाता है कि वह किसी change से पहले काम करता था, न कि वह activity जिसने उसे पकड़ा।

क्या bisect करने के लिए Git आना ज़रूरी है?

नहीं। Bisecting एक method है, command नहीं: इसे test environment में build numbers पर, releases पर, या feature flags से चालू होने वाले changes के set पर लगाया जा सकता है। git bisect इसे commits पर automate करता है, और git bisect run एक script के साथ steps दोहराता है जिसका exit code फ़ैसला करता है: 0 मतलब good, 125 मतलब skip, और 1 से 127 तक के बाक़ी codes मतलब bad।

क्या regression को हमेशा ज़्यादा priority मिलनी चाहिए?

अपने-आप नहीं। Severity और priority triage में impact और urgency के आधार पर तय होती हैं, किसी भी defect की तरह। Regressions अक्सर ऊपर आते हैं क्योंकि users ने कुछ ऐसा खोया जिस पर वे निर्भर थे और कारण एक हालिया change है, पर कम इस्तेमाल होने वाली report screen का regression इंतज़ार कर सकता है।

जब fix हुआ bug लौट आए, तो क्या पुराना defect reopen करूँ?

हाँ, जब fix वाले build में वही failure लौटे तो उसे reopen करें; अलग लक्षण के लिए नया defect बनता है जो पुराने से link हो। कुछ teams के workflow में इसके बजाय हमेशा नया, link किया record बनता है, इसलिए अपनी team का तय तरीका मानें। दोनों हालात में दर्ज करें कि वह लौटा, और पता करें कि जिस test को उसकी रखवाली करनी थी उसने उसे क्यों नहीं पकड़ा।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • Reference — GitGit projectहर Git command और उसके options का आधिकारिक reference, काम के अनुसार समूहित — setup, branching, sharing, patching, inspection और debugging।
  • Continuous Integration (Martin Fowler)martinfowler.com · 2024continuous integration का व्यापक रूप से संदर्भित विवरण: बार-बार integrate करें, build को self-testing और तेज़ रखें, टूटा build तुरंत ठीक करें।
टूल्स

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

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

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

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

API रिस्पॉन्स कम्पेरेटर

दो API रिस्पॉन्स (जैसे staging बनाम production) की तुलना करें और हर संरचनात्मक तथा वैल्यू का अंतर देखें।

API टेस्टिंग

JSON डिफ़

दो JSON डॉक्यूमेंट की सिमैंटिक तुलना करें और जोड़ी गई, हटाई गई तथा बदली गई वैल्यू हाइलाइट करें।

JSON और डेटा

टेक्स्ट डिफ़

दो टेक्स्ट की लाइन-दर-लाइन या शब्द-दर-शब्द तुलना करें और अंतर हाइलाइट करें।

फ़ॉर्मेटिंग

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

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

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

और गहराई से

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

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