वैलिडेशन टेस्ट जनरेटर — फ़ॉर्म और फ़ील्ड वैलिडेशन टेस्ट बनाएँ

नेगेटिव टेस्टिंग क्या है?

नेगेटिव टेस्टिंग सिस्टम को ऐसा इनपुट देती है जिसे उसे अस्वीकार करना चाहिए — गुम फ़ील्ड, ग़लत टाइप, सीमा से बाहर का मान, विकृत फ़ाइल, समाप्त टोकन, दूसरा क्लिक — और जाँचती है कि वह साफ़-सुथरे ढंग से अस्वीकार करे: एक विशिष्ट त्रुटि, डेटा में कोई बदलाव नहीं, कोई क्रैश नहीं, कुछ लीक नहीं। पॉज़िटिव टेस्ट साबित करते हैं कि फ़ीचर काम करता है; नेगेटिव टेस्ट साबित करते हैं कि वह सुरक्षित रूप से विफल होता है, और एज-केस टेस्ट साबित करते हैं कि वैध लेकिन असामान्य स्थितियों में भी वह सही व्यवहार करता है — ठीक सीमा वाला मान, लीप डे, दाएँ-से-बाएँ लिखा टेक्स्ट, या फ़ॉर्म भरते-भरते समाप्त होने वाला सेशन। इन्हीं रास्तों में ज़्यादातर प्रोडक्शन इंसिडेंट और सुरक्षा निष्कर्ष रहते हैं। ISTQB सिलेबस इन्हें अलग विषय नहीं, सामान्य टेस्ट डिज़ाइन का हिस्सा मानता है।

गाइड पढ़ें: टेस्ट केस कैसे लिखें

वैलिडेशन टेस्ट जनरेटर कैसे इस्तेमाल करें

हर इनपुट को उसकी validation constraints के साथ, एक पंक्ति में एक, लिखें।
स्वाभाविक नाम इस्तेमाल करें (confirmPassword, startDate, endDate) ताकि cross-field नियम पहचाने जा सकें।
Generate दबाएँ और नियम तालिका को अपने specification से मिलाकर देखें।
केस अपने test management टूल में एक्सपोर्ट करें।

वैलिडेशन टेस्ट जनरेटर की खूबियाँ

required, फ़ॉर्मेट, टाइप, रेंज, लंबाई, आइटम-संख्या, फ़ाइल, pattern, अनुमत वैल्यू, कॉम्प्लेक्सिटी और uniqueness नियम पहचानता है
हर नियम के लिए एक पास होने वाला और एक फ़ेल होने वाला टेस्ट, अपेक्षित मैसेज के साथ
cross-field नियम: confirm password, confirm email, start/end तारीख़ का क्रम, बराबर-तारीख़ वाली boundary सहित
हर फ़ील्ड के लिए "सुधार के बाद एरर हट जाना" वाला usability केस
यह साबित करने वाला Critical केस कि सर्वर-साइड validation को बायपास नहीं किया जा सकता
नियम तालिका और क्रमांकित केस, जो Markdown, JSON, CSV या Gherkin में एक्सपोर्ट किए जा सकते हैं

वैलिडेशन टेस्ट जनरेटर का उदाहरण

password reset फ़ॉर्म के validation नियम

इनपुट:

password: password, required, min=10
confirmPassword: password, required

आउटपुट:

password   Required     ""              "Password is required"
password   Complexity   password        "Password is too weak"
password   Min length   9 chars         "Password must be at least 10 characters"
VAL-013    ConfirmPassword must match password → "Passwords do not match"
VAL-014    Server-side validation cannot be bypassed → API responds 400/422

वैलिडेशन टेस्ट जनरेटर के बारे में अक्सर पूछे जाने वाले सवाल

कौन-कौन से नियम पहचाने जाते हैं?

Required, टाइप/फ़ॉर्मेट (email, URL, phone, date, UUID), min/max वैल्यू, min/max लंबाई, आइटम संख्या, फ़ाइल साइज़ और टाइप, pattern, अनुमत वैल्यू, password कॉम्प्लेक्सिटी और uniqueness — हर एक के साथ एक पास होने वाला और एक फ़ेल होने वाला इनपुट तथा अपेक्षित मैसेज।

क्या cross-field नियम समर्थित हैं?

हाँ: confirmPassword का password से मेल खाना, end तारीख़ का start तारीख़ से पहले न होना (बराबर-तारीख़ वाली boundary के साथ), और confirmEmail का email से मेल खाना। फ़ील्ड के नाम स्वाभाविक रखें और नियम अपने आप पकड़ लिए जाएँगे।

सर्वर-साइड बायपास वाला केस क्यों है?

फ़्रंट-एंड validation बंद की जा सकती है। जनरेट हुआ Critical केस अमान्य डेटा सीधे API पर भेजता है और वहीं फ़ील्ड-स्तर के एरर की उम्मीद रखता है।

क्या मैं अपेक्षित मैसेज बदल सकता हूँ?

मैसेज एक तटस्थ परंपरा का पालन करते हैं ("Email is required")। एक्सपोर्ट की गई CSV या JSON में उन्हें अपने प्रोडक्ट की भाषा से बदल दें।

संदर्भ

ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
OWASP Cheat Sheet Series: Input ValidationOWASP Foundationअलाउ-लिस्ट वैलिडेशन, सिंटैक्टिक बनाम सेमांटिक जाँच, और क्लाइंट-साइड वैलिडेशन कभी सुरक्षा नियंत्रण क्यों नहीं है।