एनवायरनमेंट और टेस्ट डेटा की समस्याएँ
जब कोई test fail हो, तो पहले पूछें कि fail क्या हुआ: product, या वह setup जिस पर test चला। Environment problem, build under test के आसपास की किसी चीज़ में खराबी है: बंद पड़ी service, पुराना build, बदली हुई setting, expire हो चुका certificate। Test data problem का मतलब है कि test को जिस record की ज़रूरत है वह missing है, गलत state में है, पुराना है या किसी और ने उसे बदल दिया है।
Example: refund का एक test "Order already refunded" के साथ fail होता है। Product सही है: एक दूसरे tester ने घंटे भर पहले उसी order का refund कर दिया था, और defect report developer को ऐसे defect की खोज में भेज देती जो है ही नहीं। यह lesson failed और blocked tests वाले lesson के triage की environment और data वाली शाखाओं को आगे ले जाता है।
यह क्यों ज़रूरी है
ISTQB Foundation syllabus के अनुसार test execution में हर anomaly का analysis शामिल है ताकि उसका संभावित cause पता चले, और report की गई anomaly असली defect की जगह false-positive result भी निकल सकती है। Environment और test data की समस्याएँ ऐसे false positives के आम causes हैं, और वे false negatives भी पैदा कर सकती हैं, जब defect मौजूद होते हुए भी test pass हो जाता है।
बार-बार की setup failures results पर भरोसा भी घटाती हैं: जिस team के runs setup की वजह से अक्सर red रहते हैं, वह red को नज़रअंदाज़ करना सीख जाती है।
Environment problems और उनके संकेत
Test environments वाले lesson में बताई environment की कोई भी layer execution के दौरान टूट सकती है, और हर खराबी के अपने आम संकेत होते हैं।
- गलत build: पुराना या अधूरा deployment; fix हो चुका defect लौट आता है, या बताया गया version run के build से अलग है।
- Dependency down: database, queue, payment sandbox या SMS stub उपलब्ध नहीं। असंबंधित features में connection errors, timeouts या HTTP status codes 502 (bad gateway), 503 (service unavailable) और 504 (gateway timeout) दिखते हैं; इन codes से server बताता है कि वह, या उसके पीछे की कोई service, अभी ठीक से जवाब नहीं दे पा रही।
- Configuration drift: कोई feature flag, environment variable या service address tests की मान्यता से अलग है, इसलिए कोई feature ग़ायब है या गलत system को call करता है।
- Expired access: test account का password, API token (वह key जिससे एक system दूसरे को call करता है) या environment का TLS certificate (जिससे browsers HTTPS पर connect करते हैं); कल तक चलने वाली requests 401 (not authenticated) के साथ reject होती हैं, login fail होता है, या browsers certificate warning के साथ connection से मना कर देते हैं।
- Resources और दख़ल: भरी हुई disk, ख़त्म हुए database connections, या कोई आपके run के बीच shared environment redeploy कर देता है; failures run के बीच में शुरू होते हैं, या कुछ मिनट सब कुछ fail होता है और फिर ठीक हो जाता है।
आज़माएँ: API हेल्थ चेकर आज़माएँ: HTTP स्टेटस कोड लुकअप आज़माएँ: JWT एक्सपायरेशन चेकर
Test data problems और उनके संकेत
Test case की कई preconditions data के बारे में होती हैं: customer C-101 मौजूद है, order paid है और ship नहीं हुआ। Data problem का मतलब है कि test चलते समय ऐसी कोई precondition सच नहीं थी, जबकि product ने शायद सही व्यवहार किया।
Data defect को छिपा भी सकता है: first login का test, जिसमें user से email verify करने को कहा जाना चाहिए, ऐसे account पर चलता है जो पिछले run में verify हो चुका है, इसलिए verification step कभी आता ही नहीं और verification टूटा होने पर भी test pass हो जाता है। ऐसे false negatives की जाँच शायद ही होती है, क्योंकि result green है।
- Missing: seed script नहीं चला, या refresh के बाद baseline restore नहीं हुई।
- गलत state: किसी दूसरे test या tester ने record इस्तेमाल कर लिया, इसलिए order पहले से refunded है या account locked है।
- Collisions: parallel runs एक ही account share करते हैं, या "email already registered" आता है क्योंकि पिछला run अपना user छोड़ गया।
- पुराना data: hard-coded date, coupon या test card expire हो चुका है, या महीनों पहले ली गई data की copy अब मौजूदा prices या settings से मेल नहीं खाती।
Product defects से इन्हें अलग पहचानना
सिर्फ़ error message देखकर फ़ैसला न करें। कुछ facts जुटाएँ, सबसे सस्ते पहले; साथ मिलकर वे आम तौर पर एक cause की ओर इशारा करते हैं।
एक trap: गलत precondition गलत व्यवहार का बहाना नहीं है। अगर पहले से refunded order पर साफ़ message की जगह server error आता है, तो उस test के लिए data गलत था, और फिर भी product में defect है: उसे उस state को सुरक्षित तरीके से handle करना चाहिए। Data ठीक करें और error handling को अलग से report करें।
- Pattern: कई असंबंधित tests का एक साथ fail होना environment की ओर इशारा करता है; एक test या feature उसके data या product की ओर।
- Timing: क्या failures किसी deployment, configuration change या data refresh के साथ शुरू हुए, न कि test हो रहे change के साथ?
- Message: gateway और connection errors environment की ओर इशारा करते हैं; "already refunded" जैसा business message कहता है: पहले data जाँचें।
- Baseline: क्या build सही है, dependencies healthy हैं, और record उसी state में है जो test case माँगता है?
- Clean rerun: fresh data के साथ या दूसरे environment में दोहराएँ। जो failure healthy environment में सही data के साथ भी बना रहे, वह environment या data problem नहीं है: पिछले lesson की तरह test case जाँचें, और अगर वह सही है तो product defect report करें।
| Symptom | आम तौर पर किस ओर इशारा | पहले जाँचें | Record कैसे करें |
|---|---|---|---|
| कई असंबंधित tests एक साथ failconnection errors, timeouts, 502, 503, 504 | Environment: कोई dependency या पूरा environment down | Health checks; हाल के deployments और restarts | Environment issue; tests blocked |
| Fix हुआ defect लौट आया, या पुरानी screens दिखती हैं | Environment: गलत या पुराना build | Environment जो version बताता है, बनाम run का build | Environment issue; redeploy के बाद rerun |
| कोई feature ग़ायब है या गलत system को call करता है | Environment: configuration drift | Feature flags और settings, बनाम environment record | Environment issue; fix के बाद rerun |
| अकेले pass, पूरे या parallel run में fail | Test data: shared या बचे हुए records | Record और कौन इस्तेमाल करता है, और step से पहले उसकी state | हर test का अपना data; rerun |
| "Already exists", "already refunded", "account locked" | Test data: record गलत state में | Record की state, बनाम test case की precondition | Data fix और rerun; defect तभी जब product उस state को गलत handle करे |
| किसी तारीख़ से fail होने लगा, बिना किसी change के | Test data या access: कुछ expire हो गया | Fixed dates, coupon codes, test cards, tokens, certificates | Data या access renew करें; आगे से run के relative dates |
| एक rule गलत result देता हैhealthy environment, सही data | Product defect | Fresh data के साथ reproduce करें; requirement से तुलना करें | Defect report |
- Outlined: अकेली row जो सीधे product के ख़िलाफ़ defect report बनती है
ये संभावित causes हैं, फ़ैसले नहीं: record करने से पहले हर एक को उसकी check से confirm करें।
Worked example: एक सुबह में 14 failures
09:40 तक build 4.1.0 पर checkout regression run के 40 में से 14 tests fail हो चुके हैं। 14 defect reports लिखने की बजाय tester failures को symptom और समय के हिसाब से group करता है और हर group जाँचता है।
नौ API failures असंबंधित endpoints पर हैं, और 09:00 की पहली request से सब में वही 401 (not authenticated) है, जो किसी एक feature की नहीं, access की ओर इशारा करता है। Test client के API token को decode करने पर दिखता है कि वह आधी रात को expire हो गया: एक environment issue, और environment owner के token renew करने के बाद नौ के नौ reruns pass हुए। Coupon tests ने ऐसा coupon इस्तेमाल किया जिसकी fixed end date निकल चुकी है। Refund test वाले order का refund किसी दूसरे run ने पहले ही कर दिया था, जिससे failure समझ आता है पर server error (HTTP 500) नहीं: वह अपने आप में एक defect है। सिर्फ़ VAT वाला failure healthy environment में fresh data के साथ दोबारा होता है।
नतीजा: एक environment issue जिसके नौ reruns token renew होने के बाद pass हुए, दो data fixes जिनके बाद rerun pass हुए, और 14 की जगह दो defect reports।
Run: Checkout regression / build 4.1.0 / test environment / 09:00-09:40
Not passed: 14 of 40 (before triage)
API-01..09 401 Unauthorized from cart, address and order endpoints alike
test client's API token expired at 00:00 -> ENV-31, renewed, reruns passed
CPN-01..03 "Coupon expired"
coupon in the data has a fixed end date -> data fixed, rerun passed
RFD-04 500 error when refunding order O-7781
O-7781 refunded by another run at 08:50 -> data reset, rerun passed
a refunded order needs a clear message -> defect DEF-436
TOT-02 VAT calculated on the price before discount
same result on a fresh order, healthy env -> defect DEF-437Prevention: tests से पहले setup जाँचें
ISTQB Foundation syllabus में execution से पहले, test implementation के दौरान, test environment बनाया जाता है और जाँचा जाता है कि वह सही set up है; syllabus environments और test data की उपलब्धता को typical entry criteria में भी गिनता है, और ISO/IEC/IEEE 29119-3 दोनों के लिए readiness reports बताता है। Tests में non-determinism पर Martin Fowler का article lack of isolation, remote services और time को unreliable results के आम causes में गिनता है। नीचे की आदतें इन्हीं को निशाना बनाती हैं।
- पहले smoke: dependencies की health जाँचें और हर deployment के बाद, planned testing से पहले, एक छोटा smoke test चलाएँ।
- Build जाँचें: environment जो version बताता है उसकी तुलना run के build से करें।
- अपना data: हर tester और parallel run के लिए unique records, जिन्हें test या script बनाए।
- Repeatable data: एक known baseline restore करें, और dates run date के relative लिखें।
- Changes announce करें: किसी के run के बीच कोई deployment, restart या data refresh नहीं।
- Environment issues को owner के साथ log करें, और हर हफ़्ते लौटने वाले cause को ठीक करने लायक risk मानें, टालने लायक परेशानी नहीं।
आम गलतियाँ
- जब product ने गलत state पर server error दिया हो या record corrupt किया हो, तब data reset करके आगे बढ़ जाना।
- Environment या data problems को चुपचाप ठीक करना, जिससे वही problem अगले run में लौटती है और गँवाया समय किसी को नहीं दिखता।
- Testers और parallel runs के बीच accounts share करना, और expire होने वाली dates व codes hard-code करना।
QA का नज़रिया
Testers आम तौर पर environments या seed scripts के owner नहीं होते, पर अक्सर उन्हें टूटते हुए सबसे पहले वही देखते हैं। आपका काम है evidence पर आधारित तेज़ पहली diagnosis, और problem को सही owner तक पहुँचाना: product defect के लिए developer, environment के लिए DevOps या environment owner, और data के लिए जो test data संभालता है। Shared environment टूटा लगे तो तुरंत team channel में बताएँ।
सिर्फ़ status नहीं, जो मिला वह record करें: environment issue का id, time window, build और प्रभावित tests, या data record, उसकी state और fix। कुछ teams अपने tracker में उन reports के लिए "Environment" या "Test data" जैसा issue type या resolution जोड़ती हैं जो product defect नहीं निकलतीं; report delete करने की बजाय उसका इस्तेमाल करें। गँवाया समय और बार-बार लौटने वाले causes execution report में जाते हैं, जो अगले lesson का विषय है।
अभ्यास
पाँच failures को cause के हिसाब से छाँटें
नीचे staging पर एक run का snapshot है। हर failure के लिए तय करें कि वह सबसे ज़्यादा संभावना से environment problem है, test data problem है या product defect, फिर बताएँ कि आप क्या record करेंगे और test को कौन-सा status मिलेगा।
Run: Orders regression / build 2.7.0 / staging / 10:30 से
ID Tester ने क्या देखा
ORD-03 Rider R-12 से log in: "Account locked. Try again in 30 minutes."
ORD-07 Order track करना: map खाली; console में maps-proxy से 504, 10:31-10:44
ORD-08 Order track करना: map खाली; console में maps-proxy से 504, 10:31-10:44
ORD-11 Receipt: 5.00 SAR की tip total में दो बार जुड़ी है
ORD-12 Order O-5521 cancel करना: "Order already delivered"- एक ही symptom और time window वाले failures को group करें।
- हर group के लिए संभावित cause और उसे confirm करने वाली check लिखें।
- Environment issue, rerun के साथ data fix, या defect report record करें, और हर test का status तय करें।
मॉडल उत्तर दिखाएँ
ORD-07 और ORD-08 (environment): उन्हीं 13 मिनटों में maps proxy से वही 504। Maps service की health जाँचें, time window के साथ एक environment issue record करें, दोनों tests को blocked करें और fix के बाद rerun करें।
ORD-03 (test data): यह message जान-बूझकर किया गया lockout है, जो आम तौर पर बार-बार failed logins के बाद होता है, यानी R-12 इस्तेमाल करने वाले किसी और ने, जैसे दूसरे tester या lockout test ने, attempts ख़त्म कर दिए। जाँचें कि R-12 और कौन इस्तेमाल करता है, फिर उसे unlock करवाएँ या अपना rider account लें और rerun करें; पहले result पर data cause लिखें और rerun को नए execution के रूप में record करें। हर tester के लिए अलग rider account का सुझाव दें।
ORD-12 (test data): delivered order के लिए "Order already delivered" सही जवाब है; किसी दूसरे test या delivery simulator ने O-5521 को आगे बढ़ा दिया। Data cause note करें और test द्वारा बनाए गए, preparing state वाले fresh order के साथ rerun करें; result rerun से तय होता है।
ORD-11 (संभावित product defect): calculation error। Healthy environment में fresh order के साथ reproduce करें; अगर tip फिर से दो बार जुड़ती है, तो test को failed record करें और order, amounts और expected total के साथ defect report file करें।
नतीजा: एक defect report, दो blocked tests वाला एक environment issue और दो data fixes, पाँच defect reports की जगह।
अक्सर पूछे जाने वाले सवाल
क्या environment problem के लिए bug report लिखूँ?
Product defect report नहीं। उसे वहाँ record करें जहाँ environment owner काम करता है, अक्सर उसी tracker में अलग type या component वाले environment issue के रूप में, और blocked tests उससे link करें। अगर cause कोई script या configuration है जो production में भी इस्तेमाल होगी, जैसे कोई deployment step जो एक setting भूल जाता है, तो यह बताएँ: वह भी defect है, बस application code में नहीं।
Report करने से पहले कितनी देर जाँच करूँ?
सिर्फ़ उतनी जितनी सस्ते checks में लगे: build, dependencies की health, data की state और fresh data के साथ एक rerun। अपनी team के साथ एक छोटा time box तय करें। अगर cause फिर भी साफ़ न हो, तो evidence के साथ जो पता है वह report करें, कौन-से checks किए यह बताएँ, और किसी developer से साथ में देखने को कहें; जानकारी रोककर न रखें।
क्या intermittent failures environment problems होते हैं?
कभी-कभी, पर default रूप से नहीं। कभी-कभार fail होने वाले test का cause धीमी dependency, दूसरे runs के साथ shared data, ख़ुद test, जैसे कोई missing wait, या product में असली race condition हो सकता है, जहाँ result इस पर निर्भर करता है कि एक साथ चल रहे दो operations में से कौन पहले ख़त्म होता है। Reproducing failures वाला lesson दिखाता है कि इसे कैसे narrow करें; उसे environment problem तभी कहें जब evidence यही कहे।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
- ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationटेस्ट दस्तावेज़ों के टेम्पलेट और सामग्री — test policy, strategy, plan, status व completion रिपोर्ट, incident रिपोर्ट।
- Eradicating Non-Determinism in Tests (Martin Fowler)flaky टेस्ट सूट का मूल्य क्यों नष्ट करते हैं, उनके आम कारण (isolation, asynchrony, remote services, समय, resource leak) और जवाब के रूप में quarantine।
Mutqan tools से अभ्यास करें
एक साथ कई API health endpoint जाँचें और स्टेटस, latency तथा pass/fail सारांश पाएँ।
किसी भी HTTP स्टेटस कोड का अर्थ, RFC संदर्भ और उसे कब इस्तेमाल करना है — सब एक जगह देखें।
जाँचें कि कोई JWT एक्सपायर हो चुका है, अभी वैध नहीं है, या एक्सपायरी में कितना समय बचा है।
दो API रिस्पॉन्स (जैसे staging बनाम production) की तुलना करें और हर संरचनात्मक तथा वैल्यू का अंतर देखें।
UUID v4 (रैंडम) और v7 (समय-क्रमित) पहचानकर्ता थोक में बनाएँ और मौजूदा UUID वैलिडेट करें।
सिंथेटिक टेस्ट डेटा की एक ही जगह पर फ़ैक्टरी: users, customers, companies, पते, संख्याएँ, तारीख़ें और स्ट्रिंग — JSON, CSV, SQL या XML में।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।