फ़ेलियर रिप्रोड्यूस करना
किसी failure को reproduce करने का मतलब है उसे जानबूझकर दोबारा होते दिखाना, यानी वे conditions फिर से बनाना जिनमें वह पहली बार दिखा था। उदाहरण: test run के दौरान "Place order" चुनने पर "Something went wrong" दिखता है। आपने failure reproduce कर लिया है जब आप जानते हैं कि कौन-सा account, data, environment और कौन-से steps उसे फिर से दिखाते हैं, और बेहतर है कि हर बार।
ISTQB Foundation syllabus debugging को failure reproduce करना, उसका diagnosis (यानी cause ढूँढना) और cause को fix करना बताता है। Diagnosis और fix आम तौर पर developer का काम है; reproduction वह जगह है जहाँ tester सबसे ज़्यादा योगदान देता है, क्योंकि उसने failure देखा है और उसकी conditions जानता है। यह test evidence वाले lesson पर बनता है: आपके capture किए screenshots, logs और timestamps बताते हैं कि शुरुआत कहाँ से करें।
यह क्यों ज़रूरी है
जिस failure को कोई दोबारा नहीं करा सकता, उसे fix करना मुश्किल है, और उसके fix को retest से confirm नहीं किया जा सकता। अगर developer उसे reproduce नहीं कर पाता, तो report अक्सर "cannot reproduce" के साथ लौट आती है और defect product में रह जाता है, जहाँ users उससे टकरा सकते हैं। सटीक conditions diagnosis छोटा कर देती हैं: "जिस भी customer के saved address में postal code नहीं है, उसके लिए fail होता है" पूरे checkout की बजाय code के एक हिस्से की ओर इशारा करता है।
Tester के लिए reproduction अपने observation की जाँच भी है: controlled conditions में दोबारा कोशिश दिखाती है कि failure असली है या आपकी अपनी किसी चूक से आया। और उसे reproduce करने वाले steps ही fix के बाद confirmation testing का आधार हैं; भरोसेमंद steps के बिना pass हुआ retest ज़्यादा कुछ साबित नहीं करता।
पहले failure की conditions से शुरू करें
जब कोई test fail हो, तो चीज़ें बदलना शुरू न करें। पहले उस पल की सारी conditions लिखें, फिर failure को ठीक वैसे ही दोहराएँ जैसे वह हुआ था: वही build, environment, account, data और steps। अगर वह फिर fail हो, तो आपके पास reproducible failure और तुलना के लिए baseline है। अगर न हो, तो पहली बार से कुछ अलग है, और वही अंतर आपका पहला सुराग है।
Test case के steps से ज़्यादा दर्ज करें:
- Build और environment: build number, environment, configuration और feature flags (ऐसे switches जो नए build के बिना किसी feature को on या off करते हैं)।
- Client: browser और version, operating system, device, screen size, language और direction; Arabic right-to-left page वहाँ fail हो सकता है जहाँ English page pass होता है।
- User: role, permissions और account की state, जैसे नया, locked या expired subscription वाला account।
- Data: exact input values, files और संबंधित records, जैसे cart का content और coupon।
- State: session में पहले क्या हुआ, cookies और cache।
- समय, time zone के साथ, ताकि failure को server logs से मिलाया जा सके।
Variables isolate करें: एक बार में एक चीज़ बदलें
जब failure reproduce होने लगे, तो पता करें कि कौन-सी conditions मायने रखती हैं। हर condition को एक variable मानें और दो attempts के बीच ठीक एक बदलें, बाकी सब वैसा ही रखें। अगर browser बदलने पर failure गायब हो जाए, तो browser trigger का हिस्सा है; अगर बना रहे, तो browser factor नहीं है: उसे steps से हटाएँ और report में लिखें कि आपने उसे rule out किया। दो चीज़ें एक साथ बदलेंगे तो पता नहीं चलेगा कि फ़र्क किससे पड़ा।
Candidates ढूँढने के लिए failing case की तुलना working case से करें: दो accounts, दो requests या data के दो sets साथ-साथ। अंतर अक्सर एक ही field होता है, जैसे खाली address line, लंबा नाम या दूसरी currency। उन variables से शुरू करें जिनका असर होने की संभावना सबसे ज़्यादा है और जिन्हें बदलना सबसे सस्ता है: data, user, browser, environment।
उत्तर: हर बार
प्रश्न 2: एक variable बदलें। क्या failure गायब हो जाता है?Browser, user, data या environment: हर attempt में एकउत्तर: हाँ
परिणाम: Trigger का हिस्साइसे report में रखें; failing और working value की तुलना करेंउत्तर: नहीं, अब भी fail
परिणाम: Factor नहींइसे steps से हटाएँ, rule out लिखें, अगला variable बदलें
उत्तर: कभी-कभी
प्रश्न 3: तय संख्या में दोहराएँ। क्या एक condition बदलने से rate 0 या हर attempt तक पहुँचता है?जैसे बदलाव से पहले 20 में से 3, बाद में 20 में से 0उत्तर: हाँ
परिणाम: छिपा variable मिल गयाTrigger का हिस्सा: इसे conditions में जोड़ें, फिर rate दोबारा मापेंउत्तर: नहीं
परिणाम: अब भी intermittentअगली condition आज़माएँ, या rate, timestamps और evidence के साथ report करें
उत्तर: कभी नहीं
प्रश्न 4: क्या आज की conditions evidence से अलग हैं?Build, account state, data, समयउत्तर: हाँ
परिणाम: Original conditions फिर से बनाएँपहले failure का data, state या build वापस लाएँ, फिर दोहराएँउत्तर: नहीं
परिणाम: Reproduce नहीं हुआEvidence और किए गए attempts के साथ report करें
Trigger पता चलने के बाद, minimal reproduction तक पहुँचने के लिए एक-एक करके steps हटाएँ।
- सिर्फ़ एक user के लिए fail: उस user का data, role और settings किसी ऐसे user से मिलाएँ जिसके लिए सब ठीक चलता है।
- सिर्फ़ एक browser में fail: उस browser का console पढ़ें और उसी browser के दूसरे version में दोहराएँ।
- किसी पिछले action के बाद ही fail: उस action से बनी state भी एक variable है।
इसे minimal reproduction तक छोटा करें
पहले reproduction में आम तौर पर ऐसे steps होते हैं जिनका failure से कोई लेना-देना नहीं: आप एक लंबे test case के step 17 पर थे। Minimal reproduction preconditions और steps का सबसे छोटा set है जो अब भी failure पैदा करता है। एक बार में एक step या precondition हटाएँ और फिर चलाएँ: failure फिर भी हो तो उसे हटा रहने दें, रुक जाए तो वापस जोड़ें। तब रुकें जब बचा हुआ हर step ज़रूरी हो।
नतीजा: ऐसी report जिसे developer एक मिनट में follow कर सके, और fix के लिए तैयार confirmation test, जो अक्सर आगे regression test case भी बनता है। इसकी reliability "always" नहीं, number में लिखें, जैसे "5 में से 5 attempts"।
Worked example: एक customer के लिए fail होता order
Staging पर regression run के दौरान test case TC-214 "Saved card से order place करें" fail होता है: "Place order" के बाद page "Something went wrong" दिखाता है और network panel में POST /api/orders 500 लौटाता दिखता है। Tester build 4.12.0, account cust-07, coupon के साथ तीन items वाला cart, browser और समय दर्ज करता है, फिर हर attempt में एक चीज़ बदलता है। नीचे हर line attempts का एक round है और उसने क्या दिखाया; उनके बाद की report नतीजा है।
- वही conditions, दो बार: दोनों बार fail। Failure reproducible है।
- Chrome की जगह Firefox: fail। Browser factor नहीं है।
- cust-07 की जगह account cust-09: order बन जाता है। Account मायने रखता है, और दोनों की तुलना एक अंतर दिखाती है: cust-07 के saved address में postal code खाली है।
- cust-07 में postal code जोड़ा: pass। cust-09 से हटाया: fail। खाली postal code ही trigger है।
- एक-एक करके steps हटाए: coupon, तीन में से दो items और saved card, सब हट सकते हैं; एक item के साथ cash on delivery भी fail होता है।
- Minimal steps, 5 बार चलाए: 5 failures; postal code के साथ: 5 में से 0। Requirement यह नहीं बताती कि postal code खाली हो तो क्या होना चाहिए, इसलिए report दोनों स्वीकार्य results बताती है और tester product owner से पूछता है कि कौन-सा intended है।
Title: Saved address में postal code न हो तो order place करने पर 500 आता है
Build: 4.12.0, staging Browsers: Chrome और Firefox (दोनों में fail)
Precondition: signed-in customer, जिसके saved address में postal code खाली है
Steps: 1. Cart में कोई भी in-stock product जोड़ें।
2. Cart खोलें और "Checkout" चुनें।
3. Saved address रखें, "Cash on delivery" चुनें, "Place order" चुनें।
Expected: order बन जाए, या form postal code माँगे
Actual: "Something went wrong"; POST /api/orders 500 लौटाता है
Rate: 5 में से 5 attempts; postal code के साथ: 5 में से 0
Ruled out: browser, coupon, items की संख्या, payment method (saved card से भी fail)Intermittent failures: repetition से reproduce करें
कुछ failures वही steps दोहराने पर सिर्फ़ कुछ attempts में दिखते हैं। Intermittent failure का भी cause होता है, कोई variable जो आपने अभी नहीं पहचाना या जिसे अभी control नहीं कर सकते: timing, दो users का एक ही data एक साथ बदलना, किसी पिछले test की छोड़ी हुई state, cache, दिन का समय, या कई servers में से किसने request संभाली।
ऐसा व्यवहार करने वाले automated test को flaky test कहते हैं; cause test, environment या product में हो सकता है, और यही तरीका लागू होता है। इसे "random" न कहें, इसे मापें:
- वही steps एक तय संख्या में दोहराएँ, जैसे 20 बार, और failures गिनें: "20 में से 3" एक reproduction rate है।
- हर failing attempt का समय लिखें ताकि उसे server logs से मिलाया जा सके, और किसी failing attempt के log की तुलना passing attempt के log से करें।
- एक condition बदलें और उतनी ही बार दोहराएँ। जो condition rate को 20 में से 0 या 20 में से 20 तक ले जाए, वह बहुत संभवतः trigger का हिस्सा है।
- अगर यह भरोसेमंद न बने, तो evidence, conditions और rate के साथ इसे intermittent लिखकर report करें, और एक pass हुए run को कभी fix का सबूत न मानें।
आम गलतियाँ
- Attempts के बीच कई चीज़ें बदलना, जिससे पता नहीं चलता कि किस बदलाव का असर हुआ।
- पहली लंबी steps की sequence को जैसी है वैसी report करना, उन steps समेत जिनका failure से कोई संबंध नहीं।
- देखे गए rate की जगह "always" या "random" लिखना, या सिर्फ़ एक attempt के बाद failure को intermittent कहना।
- पहले failure की conditions दर्ज न करना, जिससे उन्हें बाद में दोबारा बनाना असंभव हो जाता है।
- एक-दो pass हुए attempts के बाद intermittent failure को "cannot reproduce" कहकर बंद करना।
- Test environment में उसी shape का data बनाने की बजाय, बिना सहमति असली customer data से या production पर reproduce करना।
QA का नज़रिया
असली team में reproduction उसी पल शुरू होता है जब आप कोई unexpected result देखते हैं: evidence capture करें, conditions लिखें और आगे बढ़ने से पहले एक बार फिर कोशिश करें। अपने lead से तय करें कि run के दौरान किसी failure को isolate करने में कितना समय लगाना है; समय पूरा होने पर जो है उसे report करें और आगे बढ़ें। बताएँ कि आपने क्या rule out किया ("Chrome और Firefox में fail, हर उस user के लिए जिसके address में postal code नहीं"), ताकि developer आपके attempts न दोहराए।
Developer के लिए उपलब्ध रहें: वह आपके minimal steps से शुरू करके failure को निचले level पर, API से या unit test में, reproduce कर सकता है; server logs ढूँढने के लिए उसे request IDs और timestamps दें। Minimal reproduction को report के साथ रखें: यह fix के बाद confirmation test है और regression suite के लिए candidate भी।
अभ्यास
Profile photo upload का failure isolate करें
एक report के अनुसार profile photo बदलना "Upload failed" message के साथ fail होता है। Requirement 5 MB तक की JPG या PNG files की अनुमति देती है। अब तक के attempts table में हैं, सभी एक ही build और एक ही test environment पर।
पता करें कि attempts क्या दिखाते हैं और क्या नहीं, तय करें कि आगे क्या आज़माना है, और minimal reproduction लिखें।
# User Browser File Format Size Network Result
1 sara01 Chrome team.png PNG 4.8 MB office Upload failed
2 sara01 Chrome team.png PNG 4.8 MB office Upload failed
3 sara01 Firefox team.png PNG 4.8 MB office Upload failed
4 omar02 Chrome team.png PNG 4.8 MB office Upload failed
5 sara01 Chrome team.jpg JPG 4.8 MB office Upload failed
6 sara01 Chrome team.png PNG 1.9 MB office photo saved
7 omar02 Firefox badge.jpg JPG 0.2 MB office photo saved- वे attempts ढूँढें जो वही conditions दोहराते हैं, और बताएँ कि वे क्या साबित करते हैं।
- ठीक एक चीज़ बदलने वाले हर attempt के लिए variable का नाम लिखें और बताएँ कि वह मायने रखता है या नहीं।
- वह attempt ढूँढें जिसका अर्थ नहीं निकाला जा सकता, और कारण बताएँ।
- ऐसी condition बताएँ जो कभी नहीं बदली, फिर अगले attempts की योजना बनाएँ और minimal reproduction लिखें।
मॉडल उत्तर दिखाएँ
Attempts 1 और 2 वही conditions दोहराते हैं और दोनों fail होते हैं: failure reproducible है।
Attempts 3, 4 और 5 हर एक सिर्फ़ एक चीज़ बदलते हैं (browser, user, format) और सब अब भी fail होते हैं, इसलिए इनमें से कोई factor नहीं है। Attempt 6 सिर्फ़ file size बदलता है (वही picture दोबारा छोटे size में export की गई) और सफल होता है: size एक factor है, जबकि 4.8 MB, 5 MB की limit के अंदर लगता है।
Attempt 7 पाँच चीज़ें एक साथ बदलता है। वह pass होता है, लेकिन आप नहीं बता सकते कि किस बदलाव से फ़र्क पड़ा, इसलिए वह कुछ नहीं जोड़ता।
Network कभी नहीं बदला, इसलिए उसे rule out नहीं किया गया। आगे: वही picture 1.9 और 4.8 MB के बीच (जैसे 3 और 4 MB) ताकि पता चले failure कहाँ से शुरू होता है, ठीक 5 MB की file और उससे थोड़ी बड़ी file, और दूसरे network से एक 4.8 MB upload। हर file का exact size bytes में लिखें: tools 1 MB को कभी 1,000,000 और कभी 1,048,576 bytes मानते हैं, इसलिए "4.8 MB" वाली file 5,000,000 bytes की limit से पहले ही बड़ी हो सकती है।
Minimal reproduction, जिसे उन attempts के बाद update करना है: office network पर कोई भी signed-in user; profile page खोलें, "Change photo" चुनें, 4.8 MB की PNG या JPG file चुनें (उसका size bytes में लिखें) और "Save" चुनें। Expected: photo save हो जाए, क्योंकि requirement 5 MB तक की अनुमति देती है। Actual: "Upload failed"। Rate: 4.8 MB files के साथ 5 में से 5 attempts, दो browsers, दो users और दोनों formats में; 1.9 MB और 0.2 MB की files save हो जाती हैं।
अक्सर पूछे जाने वाले सवाल
Failure reproduce करना tester का काम है या developer का?
दोनों योगदान देते हैं। ISTQB syllabus debugging को reproduction, diagnosis और fixing के रूप में बताता है। Practice में tester भरोसेमंद reproduction और उसकी conditions देता है, क्योंकि उसने failure देखा है, और developer अक्सर उसे debugger में या निचले level पर फिर से reproduce करता है। Code में defect ढूँढना और उसे fix करना आम तौर पर developer का काम है।
अगर मैं failure बिल्कुल reproduce न कर पाऊँ तो क्या करूँ?
अगर evidence दिखाता है कि वह हुआ था, तो फिर भी report करें: evidence, conditions और किए गए attempts जोड़ें, और साफ़ लिखें कि आप उसे reproduce नहीं कर पाए। कुछ teams reports को "cannot reproduce" resolution से बंद करती हैं, लेकिन इससे report बंद होती है, यह साबित नहीं होता कि product सही है। संबंधित tests और logs पर नज़र रखें: दूसरी बार होने पर तुलना के लिए नई conditions मिलती हैं।
Intermittent failure को कितनी बार दोहराऊँ?
कोई तय संख्या नहीं है। इतनी बार दोहराएँ कि failure जितनी बार होता है उसके हिसाब से rate का मतलब निकले: अगर वह लगभग दस में से एक बार fail होता है, तो तीन pass हुए attempts ज़्यादा कुछ साबित नहीं करते। किसी बदलाव से पहले और बाद में उतनी ही repetitions रखें ताकि rates की तुलना हो सके; automated tests में test runner आपके लिए test दोहरा सकता है।
क्या intermittent failure और flaky test एक ही हैं?
पूरी तरह नहीं। "Flaky" आम तौर पर ऐसे automated test को कहते हैं जिसका result बिना code change के runs के बीच बदलता है; cause test, environment या product में हो सकता है। Intermittent failure product का व्यवहार है जो किसी भी तरीके से, manual या automated, देखा गया हो। दोनों में diagnosis एक जैसा है: repetition, rate, और एक बार में एक condition बदलना।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
- Eradicating Non-Determinism in Tests (Martin Fowler)flaky टेस्ट सूट का मूल्य क्यों नष्ट करते हैं, उनके आम कारण (isolation, asynchrony, remote services, समय, resource leak) और जवाब के रूप में quarantine।
Mutqan tools से अभ्यास करें
दो JSON डॉक्यूमेंट की सिमैंटिक तुलना करें और जोड़ी गई, हटाई गई तथा बदली गई वैल्यू हाइलाइट करें।
दो API रिस्पॉन्स (जैसे staging बनाम production) की तुलना करें और हर संरचनात्मक तथा वैल्यू का अंतर देखें।
दो टेक्स्ट की लाइन-दर-लाइन या शब्द-दर-शब्द तुलना करें और अंतर हाइलाइट करें।
User-Agent स्ट्रिंग से ब्राउज़र, वर्शन, इंजन, OS, डिवाइस टाइप और बॉट की पहचान करें।
टाइमस्टैम्प (सेकंड, मिलीसेकंड, माइक्रोसेकंड) को पढ़ने योग्य तारीख़ में और वापस बदलें, किसी भी timezone में।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।