मॉड्यूल 6 · टेस्ट सिनेरियो और टेस्ट केस

टेस्ट डेटा

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

Test data वह data है जो tests execute करने के लिए ज़रूरी है: वे values जो test डालता है, और वे records जो test शुरू होने से पहले मौजूद होने चाहिए — accounts, products, orders और settings, हर एक किसी तय state में। "Customer shipping से पहले order cancel कर सकता है" को टेस्ट करने के लिए Cancel पर click करना action है, लेकिन login कर सकने वाले customer और ऐसे order के बिना जिसका payment हो चुका है पर जो अभी ship नहीं हुआ, test शुरू ही नहीं हो सकता।

हर test case को अपना test data बताना चाहिए; यह lesson उसे चुनने, सुरक्षित source से लेने और manage करने के बारे में है, ताकि tests दोहराए जा सकें।

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

Data तय करता है कि test क्या पकड़ सकता है। सिर्फ़ साफ़-सुथरे records — "Test User", एक order, एक छोटा address — से चलने वाले tests happy path साबित करते हैं और लगभग कुछ नहीं; defects खाली field में, apostrophe वाले नाम में, ठीक 14 दिन पहले deliver हुए order में इंतज़ार करते हैं। Data यह भी तय करता है कि result पर भरोसा हो सकता है या नहीं: जो test इसलिए fail हो कि किसी साथी ने shared account बदल दिया, या किसी बचे हुए record की वजह से pass हो, वह समय बर्बाद करता है और असली problems छिपाता है।

Data के साथ कानूनी जोखिम भी आता है। Test environment में production की copy असली customers का personal data हर उस व्यक्ति के सामने रख देती है जिसके पास test access है, आम तौर पर production से कमज़ोर controls के साथ। सऊदी अरब में यह Personal Data Protection Law (PDPL) के तहत personal data की processing है।

Test data के चार प्रकार

हर test condition के लिए पूछें: कौन-सा data दिखाएगा कि behaviour सही है या नहीं? चार प्रकार ज़्यादातर ज़रूरतें पूरी करते हैं; एक अच्छा test set इन्हें सोच-समझकर मिलाता है, positive और negative testing तथा edge cases वाले lessons के आधार पर।

  • Valid: data जिसे system को स्वीकार करके process करना चाहिए — registered customer, stock में मौजूद product, sara.k@example.com जैसा email।
  • Invalid: data जिसे system को सुरक्षित तरीके से reject करना चाहिए — खाली required field, गलत format, expired card, या गलत state वाला record, जैसे पहले से cancel हुआ order।
  • Boundary: जो allowed है उसके किनारों पर values — सबसे लंबा नाम, शून्य, अवधि का आख़िरी दिन। Test design module की boundary value analysis इन्हें सटीक रूप से चुनती है।
  • Production-like: shape और volume में असली इस्तेमाल जैसा data — Arabic और Devanagari नाम, लंबे addresses, सैकड़ों orders वाला customer — बिना किसी असली व्यक्ति का हुए।

आज़माएँ: स्पेशल कैरेक्टर डेटासेट जनरेटर आज़माएँ: Unicode डेटासेट जनरेटर

Test data कहाँ से आता है

नीचे के पहले दो sources synthetic हैं: गढ़ा हुआ data, जो किसी असली व्यक्ति के बारे में नहीं होता। Synthetic data default है क्योंकि हर value पर आपका नियंत्रण होता है, boundaries, invalid values और दुर्लभ states समेत।

  • हाथ से बना (hand-made): tester वे कुछ exact records जो test को चाहिए, spreadsheet, fixture file या seed script में लिखता है। सटीक, पर volume चाहिए तो धीमा।
  • Generated: कोई tool या script rules से records बनाता है, या test उन्हें product की API से बनाता है ताकि वे business rules मानें। दोहराने योग्य, दस rows से दस लाख तक।
  • Masked production data: production की copy जिसमें नाम, ids, phone numbers, emails और addresses बदले, shuffle किए या हटाए गए हों, और tables के बीच links बरकरार रहें। Realistic — जैसे migration rehearsal के लिए उपयोगी — पर इसके लिए approved process चाहिए।
  • Production data जैसा है वैसा: असली records। Legal basis, approval और production-स्तर की सुरक्षा के बिना test environments के लिए नहीं।
Test data के चार sources: hand-made और generated data synthetic हैं और उनमें personal data नहीं होता, masked production copy से पहचान अब भी हो सकती है, और बिना masking की copy असली personal data को test system में रख देती है।

हाथ से बना (hand-made)Synthetic

Tester वही exact records लिखता है जो test को चाहिए

Values पर नियंत्रण:
पूरा: कोई भी state, boundary या invalid value
Realism:
सिर्फ़ वे cases जो किसी ने सोचे
Volume:
कुछ records
Personal data का जोखिम:
कोई नहीं: किसी असली व्यक्ति का data नहींपास
किसके लिए सबसे सही:
Test cases में exact states और boundaries

GeneratedSynthetic

Tool, script या product की API rules से records बनाती है

Values पर नियंत्रण:
ज़्यादा: rules formats, ranges और volume तय करते हैं
Realism:
उतना ही realistic जितने उसके rules
Volume:
दस rows से दस लाख तक
Personal data का जोखिम:
कोई नहीं: किसी असली व्यक्ति का data नहींपास
किसके लिए सबसे सही:
दोहराने योग्य set-up, load और localisation data

Masked production copyProduction से

Personal fields बदले, shuffle किए या हटाए गए; tables के बीच links बरकरार

Values पर नियंत्रण:
कम: सिर्फ़ वही जो production में संयोग से मौजूद है
Realism:
असली shapes और distributions
Volume:
Subset या पूरा size
Personal data का जोखिम:
पहचान अब भी हो सकती है: approval चाहिएसावधानी
किसके लिए सबसे सही:
ऐसे migration rehearsals जिन्हें असली distributions चाहिए

Production copy जैसी है वैसीअसली data

असली customers के records, बिना बदलाव

Values पर नियंत्रण:
कम: सिर्फ़ वही जो production में संयोग से मौजूद है
Realism:
असली, अपनी गलतियों समेत
Volume:
पूरा size
Personal data का जोखिम:
Test system में असली personal dataफ़ेल
किसके लिए सबसे सही:
Test environments के लिए नहीं

जब तक data protection officer या privacy team कुछ और तय न करे, masked data को personal data ही मानें।

आज़माएँ: टेस्ट डेटा फ़ैक्टरी आज़माएँ: फ़ेक यूज़र जनरेटर आज़माएँ: फ़ेक कस्टमर जनरेटर

Personal data: असली लोगों को test systems से बाहर रखें

PDPL, जिसकी निगरानी Saudi Data and AI Authority (SDAIA) करती है, personal data को व्यापक रूप से परिभाषित करता है: कोई भी data जिससे किसी व्यक्ति की पहचान सीधे या परोक्ष रूप से हो सके, जैसे नाम, identity number, address या phone number। Health data उन categories में है जिन्हें sensitive माना जाता है।

Masking से data अपने-आप anonymous नहीं हो जाता। नाम बदल दें पर जन्म-तिथि, इलाका (district) और employer रहने दें, तो record अब भी एक व्यक्ति की ओर इशारा कर सकता है। कोई masked set अब भी personal data है या नहीं, यह data protection officer या privacy team तय करती है; तब तक उसे personal data ही मानें।

  • Test emails के लिए RFC 2606 द्वारा reserved domains, जैसे example.com, इस्तेमाल करें, ताकि कोई message असली inbox तक न पहुँचे।
  • Payment सिर्फ़ payment provider के sandbox में उसके published test cards से करें।
  • असली personal data को bug reports, screenshots, logs और AI tools से बाहर रखें; test system में मिले तो report करें और copy न करें।

आज़माएँ: फ़ेक ईमेल जनरेटर आज़माएँ: सऊदी एड्रेस टेस्ट डेटा

टेस्ट डेटा मैनेजमेंट

Test data management (TDM) वह तरीका है जिससे team test data की planning करती है, उसे उपलब्ध कराती है, सुरक्षित रखती है और maintain करती है, ताकि tests दोहराए जा सकें। बड़े organisation में इसका अलग role हो सकता है; छोटी team में यह कुछ आदतें हैं:

  • Plan: हर test case का data एक state के रूप में लिखें। "एक valid customer" test data नहीं है; "customer C-101, जिसका एक card order तीन दिन पहले deliver हुआ" test data है।
  • Provide: data को tests के बगल में version control में रखी scripts या generators से बनाएँ, execution वाले दिन हाथ से नहीं।
  • Isolate: हर tester या parallel run को unique ids वाले अपने records दें, ताकि tests एक-दूसरे का data न बदलें।
  • Current रखें: dates run के सापेक्ष लिखें ("आज से 14 दिन पहले deliver हुआ"); fixed date कुछ हफ़्तों बाद rule को टेस्ट करना बंद कर देती है।
  • Reset और retire: runs के बीच known baseline restore करें, और जिन exports और copies की ज़रूरत नहीं उन्हें delete करें।

आज़माएँ: SQL डेटासेट जनरेटर

Worked example: refund rule के लिए test data

Requirement: "Customers delivery के 14 दिनों के अंदर refund माँग सकते हैं। Card payments card में refund होते हैं; cash-on-delivery orders customer के wallet में।"

Steps लिखने से पहले tester data की सूची बनाता है: दोनों refund रास्तों के लिए valid rows, relative dates के साथ day 14 के दोनों तरफ़ boundary rows, गलत state और गलत owner के लिए invalid rows, और एक production-like row। पहले product owner से पूछा जाता है: क्या "14 दिनों के अंदर" में 14वाँ दिन शामिल है? Sheet मानती है कि शामिल है।

ID     Kind             Record (all synthetic)                      Expected
TD-01  valid            card order, delivered today-3, 240.00 SAR   refund to card
TD-02  valid            cash-on-delivery order, delivered today-5   refund to wallet
TD-03  boundary         card order, delivered today-14              refund accepted
TD-04  boundary         card order, delivered today-15              refund refused
TD-05  invalid state    order shipped, not yet delivered            no refund option
TD-06  invalid state    order already refunded                      refund refused
TD-07  invalid owner    order of C-102, opened by its id            access denied
TD-08  production-like  customer with 350 orders, Arabic full name  history pages load

Log in as C-101 for TD-01 to TD-07; TD-08 logs in as C-103.
All emails end in @example.com. Dates are relative to the run date.
Restore baseline "refunds-v3" before each run.

आज़माएँ: अरबी टेस्ट डेटा जनरेटर

आम गलतियाँ

  • सिर्फ़ साफ़-सुथरे, आम data से टेस्ट करना, जिससे खाली, बहुत लंबा, non-Latin और गलत state वाला data कभी आज़माया ही नहीं जाता।
  • Production data copy करना, या सिर्फ़ नाम बदलकर उसे "mask" करना।
  • एक test account को testers या parallel runs के बीच share करना, जिससे tests एक-दूसरे का data बदलते हैं और बेतरतीब fail होते हैं।
  • पुरानी पड़ने वाली dates hard-code करना: "3 मार्च को deliver हुआ" वाला test कुछ हफ़्तों बाद 14 दिन वाला rule टेस्ट करना बंद कर देता है।
  • Exact record और उसकी state की जगह "एक valid customer" लिखना, जिससे कोई test या bug reproduce नहीं कर पाता।

QA का नज़रिया

असली project पर tester data की planning test analysis और design के दौरान करता है, execution वाले दिन नहीं, और उन states को चिह्नित करता है जिन्हें बनाना मुश्किल है, जैसे 15 दिन पहले deliver हुआ order या bank द्वारा decline किया गया payment। इन्हें refinement में उठाएँ: कुछ के लिए developer की मदद चाहिए, जैसे seed script या delivery date set करने का तरीका।

Data को test case में और हर bug report में लिखें: record id, उसकी state और वह कैसे बना। ISO/IEC/IEEE 29119-3 test data requirements को एक अलग documentation item मानता है; agile team में story में एक छोटा note आम तौर पर काफ़ी होता है।

अभ्यास

Appointment booking के लिए test data तैयार करें

आपका काम

एक clinic app के तीन rules हैं: appointments 1 से 30 दिन आगे के book होते हैं; एक patient के पास अधिकतम 2 upcoming appointments हो सकते हैं; 18 से कम उम्र के patients guardian के account से book होते हैं। कम से कम आठ rows की test data sheet लिखें जो चारों प्रकार का data cover करे, हर row के expected result और source के साथ।

फिर उस साथी को जवाब दें जो पिछले महीने के patients production से copy करके उनके नाम बदलने का सुझाव देता है।

मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Valid: बिना appointments वाला adult आज + 7 के लिए book करता है; guardian linked 10 साल के बच्चे के लिए book करता है (दोनों booked)।

Boundary: आज + 1 और आज + 30 (booked), आज और आज + 31 (refuse); दूसरा upcoming appointment (booked), तीसरा (refuse); आज 18 का होने वाला patient ख़ुद book करता है, कल 18 का होने वाला guardian की ओर भेजा जाता है। Product owner से पूछें कि उम्र booking वाले दिन गिनी जाती है या appointment वाले दिन।

Invalid: 17 साल के patient का अपना account, पिछली या खाली date, और unlinked बच्चे के लिए guardian की booking (सब refuse)। Production-like: Arabic, Devanagari और Latin नामों वाले 500 generated patients (search हर script में नाम के एक हिस्से से patient ढूँढ लेता है)।

Sources: exact states के लिए hand-made records, volume के लिए generated; सब synthetic, ages और dates run date से गिनी हुई।

जवाब: "नहीं। Patient records personal data हैं, और PDPL health data को sensitive मानता है। जन्म-तिथि, इलाका और visit history से भी व्यक्ति पहचाना जा सकता है, और synthetic data हमें वैसे भी वे states और boundaries देता है जो हमें चाहिए।"

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

क्या testing के लिए कभी production data इस्तेमाल किया जा सकता है?

सिर्फ़ नियंत्रण के साथ: legal basis और data protection के ज़िम्मेदार व्यक्ति की approval, जाँची हुई masking, production जैसा access control, और इस्तेमाल के बाद deletion। Default synthetic data है। जो checks production में चलने ज़रूरी हैं, वे customers के records नहीं, dedicated test accounts इस्तेमाल करते हैं।

क्या masked data और anonymous data एक ही हैं?

नहीं। Masking चुने हुए fields को बदलती या छिपाती है; बाकी fields मिलकर अब भी किसी की पहचान करा सकते हैं, और कुछ masking उलटी भी जा सकती है। Data तभी anonymous माना जाता है जब उसे किसी व्यक्ति से जोड़ा न जा सके, और यह तय करना आपकी privacy team का काम है।

Test data की ज़िम्मेदारी किसकी है?

यह साझा ज़िम्मेदारी है। Testers data requirements तय करते हैं और run से पहले data जाँचते हैं; developers या DevOps engineers अक्सर seed scripts और reset jobs लिखते हैं; personal data से बनी किसी भी चीज़ पर फ़ैसला data protection officer करता है। कुछ बड़े organisations में test data management का अलग role होता है।

Test data test case में लिखें या अलग file में रखें?

Size के हिसाब से दोनों। कुछ ही values हों तो exact record या value test case में लिखें; बड़े sets को data table या file में रखें जिसे test case refer करे, version control में, ताकि वही steps कई rows के साथ चल सकें। यही data-driven testing का आधार है।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • Personal Data Protection Law (English translation)सऊदी डेटा एवं AI प्राधिकरण (SDAIA) · 2023व्यक्तिगत डेटा पर सऊदी कानून — टेस्ट वातावरण में असली ग्राहक रिकॉर्ड की प्रतियों के बजाय सिंथेटिक डेटा क्यों इस्तेमाल करना चाहिए।
  • ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021टेस्ट दस्तावेज़ों के टेम्पलेट और सामग्री — test policy, strategy, plan, status व completion रिपोर्ट, incident रिपोर्ट।
  • RFC 2606: Reserved Top Level DNS NamesIETF · 1999example.com, example.net, example.org और .test/.example को दस्तावेज़ीकरण और टेस्टिंग के लिए आरक्षित करता है — नकली डेटा में यही डोमेन इस्तेमाल करें।
टूल्स

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

टेस्ट डेटा फ़ैक्टरी

सिंथेटिक टेस्ट डेटा की एक ही जगह पर फ़ैक्टरी: users, customers, companies, पते, संख्याएँ, तारीख़ें और स्ट्रिंग — JSON, CSV, SQL या XML में।

टेस्ट डेटा

फ़ेक यूज़र जनरेटर

टेस्ट अकाउंट के लिए फ़ेक यूज़र रिकॉर्ड (नाम, username, ईमेल, पासवर्ड, avatar seed, role) जनरेट करें।

टेस्ट डेटा

फ़ेक ईमेल जनरेटर

सुरक्षित रिज़र्व्ड डोमेन (example.com, test) और plus-addressing वैरिएंट के साथ टेस्ट ईमेल पते जनरेट करें।

टेस्ट डेटा

SQL डेटासेट जनरेटर

किसी भी dialect के लिए वास्तविक जैसी टेस्ट पंक्तियों के साथ SQL seed स्क्रिप्ट (CREATE TABLE + INSERT) जनरेट करें।

टेस्ट डेटा

अरबी टेस्ट डेटा जनरेटर

लोकलाइज़ेशन टेस्टिंग के लिए अरबी नाम, पते, वाक्य, संख्याएँ (अरबी-हिंदसी अंक) और RTL edge case जनरेट करें।

टेस्ट डेटा

और गहराई से

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

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