मॉड्यूल 3 · Testing fundamentals

पॉज़िटिव और नेगेटिव टेस्टिंग

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

Positive testing जाँचती है कि system वही करता है जो उसे करना चाहिए, जब उसे इरादे के मुताबिक़ इस्तेमाल किया जाए: valid data, allowed actions और सही क्रम में steps। Negative testing, जैसा ISTQB glossary इसे परिभाषित करती है, system को ऐसे तरीके से टेस्ट करती है जिसके लिए वह बना ही नहीं: missing या invalid data, गलत state में कोई action, या बिना permission वाला user। कई teams इसमें error conditions भी शामिल करती हैं, जैसे जवाब न देने वाली service।

Checkout पर मौजूदा discount code SAVE20 डालकर discount दिखना एक positive test है। RAMADAN24 डालना, जो कल expire हो गया, और जाँचना कि वह साफ़ message के साथ reject होता है और total वही रहता है, एक negative test है।

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

Users typing में गलती करते हैं, fields खाली छोड़ते हैं और गलत समय पर Back दबाते हैं; दूसरे systems का timeout हो जाता है। जो product सिर्फ़ happy path पर काम करता है, वह एक गलती पर user का input खो सकता है, invalid request का जवाब server error से दे सकता है, या customer से दो बार पैसे काट सकता है। ये unexpected को handle करने वाले code के defects हैं, और ये production तक तब पहुँचते हैं जब किसी ने इनके लिए test design नहीं किया।

Developers आम तौर पर feature सौंपने से पहले happy path आज़मा लेते हैं; rejection paths के आज़माए जाने की संभावना कम होती है, इसलिए negative tests छिपे risk का बड़ा हिस्सा उजागर करते हैं। फिर भी positive tests ज़रूरी रहते हैं: वे साबित करते हैं कि feature अपना मकसद पूरा करता है।

Positive testing और happy path

Positive test valid data और actions का allowed क्रम इस्तेमाल करता है, और सफलता की उम्मीद करता है: सही output, सही तरह stored data और सही side effects, जैसे confirmation email। जैसा functional testing वाले lesson में देखा, expected result test basis से आता है, इस बात से नहीं कि system इत्तफ़ाक़ से क्या करता है।

Happy path वह मुख्य scenario है जिसमें सब कुछ योजना के मुताबिक़ चलता है: आम data, default choices, कोई गलती नहीं। कुछ teams इसे main success scenario कहती हैं। किसी feature का happy path एक होता है, पर positive tests आम तौर पर कई होते हैं, क्योंकि सफल होने के एक से ज़्यादा valid तरीके होते हैं।

  • Happy path: 250.00 SAR का cart और code SAVE20 (20% छूट) से 50.00 SAR का discount और 200.00 SAR का total मिलता है।
  • Valid variations: lower case में save20 भी काम करता है, क्योंकि codes case-sensitive नहीं हैं; code हटाने पर total फिर से 250.00 SAR हो जाता है।

आज़माएँ: पॉज़िटिव टेस्ट जनरेटर

Negative testing: invalid input और अनचाहा इस्तेमाल

Negative test जानबूझकर system को ऐसी चीज़ देता है जिसे उसे स्वीकार नहीं करना चाहिए, और एक नियंत्रित rejection की उम्मीद करता है। Test pass होता है जब system ठीक वैसे ही मना करे जैसा specified है। Test fail होता है जब system input स्वीकार कर ले, crash हो जाए, या नुकसानदेह तरीके से मना करे, जैसे पूरा form खाली कर देना।

क्या invalid है, यह test basis तय करता है; यही idea आप test design module में invalid equivalence partitions के रूप में फिर देखेंगे। Negative tests इन categories में खोजें:

  • Missing data: खाली required field, बिना body वाली API request।
  • गलत format या type: amount में letters, बिना @ वाला email, तारीख़ 31/02/2026।
  • Range से बाहर: quantity 0 या -1।
  • गलत state या क्रम: end date के बाद RAMADAN24, पहले से paid order का दोबारा payment।
  • Permission नहीं: दूसरे customer का order खोलना, सिर्फ़ उन systems पर जो आपके हैं या जिन्हें टेस्ट करने की आपको लिखित अनुमति है।
  • Dependency का fail होना: payment provider का timeout।
Checkout पर discount code: positive test तब pass होता है जब SAVE20 लागू हो, और negative test तब pass होता है जब expired code RAMADAN24 साफ़ message के साथ reject हो और total 250.00 SAR ही रहे।

पॉज़िटिव टेस्ट

Valid input, इरादे के मुताबिक़ इस्तेमाल

किस सवाल का जवाब देता है:
क्या इरादे के मुताबिक़ इस्तेमाल पर यह काम करता है?
आम input:
Valid data, allowed actions, अपेक्षित क्रम
उदाहरण:
250.00 SAR के cart पर SAVE20
अपेक्षित परिणाम:
Discount 50.00, total 200.00, code applied दिखता है
Test pass होता है जब:
Action specified तरीके से सफल होपास
Defect ऐसे दिखता है:
गलत result, या valid input का reject होनाफ़ेल

नेगेटिव टेस्ट

Invalid input या अनचाहा इस्तेमाल

किस सवाल का जवाब देता है:
क्या गलत इस्तेमाल पर यह सुरक्षित तरीके से मना करता है?
आम input:
Missing data, गलत format, range से बाहर, गलत state, permission नहीं, fail हुई dependency
उदाहरण:
RAMADAN24, जो कल ख़त्म हो गया
अपेक्षित परिणाम:
“इस code की अवधि ख़त्म हो चुकी है”, total अब भी 250.00, कोई internal detail नहीं दिखती
Test pass होता है जब:
Action specified तरीके से reject होपास
Defect ऐसे दिखता है:
Invalid input का स्वीकार होना, 500 error, अस्पष्ट message या बदला हुआ dataफ़ेल

दोनों ऐसे tests हैं जिन्हें pass होना चाहिए: “negative” input और इरादे को बताता है, नतीजे को नहीं।

आज़माएँ: नेगेटिव टेस्ट जनरेटर आज़माएँ: वैलिडेशन टेस्ट जनरेटर

Expected error handling: सही rejection कैसा दिखता है

"Error दिखता है" कोई expected result नहीं है, क्योंकि लगभग हर व्यवहार उसमें pass हो जाएगा। सही rejection के हिस्से लिखें:

API level पर नीचे वाली request expired code भेजती है। Test status और body जाँचता है, और दूसरी request, GET /api/cart, पुष्टि करती है कि total अब भी 250.00 SAR है।

  • Field के पास text में एक specific message जो बताए कि क्या ठीक करना है। Specific का मतलब सब बता देना नहीं: login form कहता है कि email या password गलत है, यह नहीं कि कौन-सा।
  • और कोई बदलाव नहीं: कोई record नहीं बना, पैसा नहीं हिला, कोई email नहीं गया, और user का input बना रहा।
  • कोई internal details नहीं: न stack trace, न SQL error। OWASP Error Handling Cheat Sheet user के लिए generic message और details server log में रखने की सलाह देती है।
  • वही status code जो API contract तय करता है। RFC 9110 client की request की गलतियों के लिए 4xx class और server errors के लिए 5xx class इस्तेमाल करता है, इसलिए invalid data पर 400 या 422 जैसा 4xx मिलता है, कभी 500 नहीं।
  • Recovery: input ठीक करने के बाद positive path बिना दोबारा शुरू किए काम करे।
POST /api/cart/discount HTTP/1.1
Host: shop.example.com
Content-Type: application/json

{"code": "RAMADAN24"}

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"error": "code_expired", "message": "This discount code has expired."}

आज़माएँ: API स्टेटस कोड सिम्युलेटर आज़माएँ: Mock एरर रिस्पॉन्स जनरेटर

Worked example: discount code के tests

Requirement: "Checkout पर customer एक discount code लगा सकता है। Code सिर्फ़ अपनी start और end date के बीच और हर customer के लिए एक बार काम करता है, और case-sensitive नहीं है।" Cart में 250.00 SAR के eligible items हैं।

Happy path से शुरू करें, फिर हर negative test में सिर्फ़ एक invalid condition रखें, ताकि कोई भी failure ठीक एक rule की ओर इशारा करे। DC-03 से DC-06 तक total 250.00 SAR ही रहना चाहिए। Negative tests design करते समय requirement की कमियाँ भी सामने आती हैं, जैसा DC-07 दिखाता है।

  • DC-01, positive (happy path): SAVE20 → discount 50.00, total 200.00।
  • DC-02, positive: save20 → DC-01 जैसा ही result।
  • DC-03, negative: field खाली रखकर Apply → "Discount code डालें"।
  • DC-04, negative: NOPE99, जो मौजूद नहीं → "यह code valid नहीं है"।
  • DC-05, negative: RAMADAN24, जो कल ख़त्म हो गया → "इस code की अवधि ख़त्म हो चुकी है"।
  • DC-06, negative: उसी customer का दूसरी बार SAVE20 → "आप यह code पहले ही इस्तेमाल कर चुके हैं"।
  • DC-07, खुला सवाल: SAVE20 लगे होने पर WELCOME10। क्या यह पहले code की जगह लेगा या reject होगा? Expected result लिखने से पहले product owner से पूछें।

आम गलतियाँ

  • सिर्फ़ happy path टेस्ट करना, क्योंकि demo और acceptance criteria में वही दिखता है।
  • Expected result में "error दिखता है" लिखना, बिना exact message के और बिना यह बताए कि क्या नहीं बदलना चाहिए।
  • एक test में कई invalid values डालना: पहली error बाकी को छिपा देती है।
  • Negative test को fail मार्क करना क्योंकि error दिखी, जबकि वही error expected result थी।
  • सिर्फ़ screen जाँचना: message दिख गया, पर order फिर भी बन गया।
  • Invalid input सिर्फ़ form से टेस्ट करना, जबकि उसके पीछे की API वही data स्वीकार कर लेती है। उसे API को भी भेजें, ऐसे system पर जिसे टेस्ट करने की आपको अनुमति है।

QA का नज़रिया

Negative testing backlog refinement में ही शुरू हो जाती है। हर acceptance criterion के लिए पूछें "और अगर ऐसा न हो तो?": missing input, गलत state, permission नहीं, payment service down। User stories अक्सर सिर्फ़ happy path बताती हैं, इसलिए ये सवाल ऐसा error behaviour सामने लाते हैं जिसे अभी किसी ने तय नहीं किया। Coding शुरू होने से पहले messages product owner के साथ और status codes developers के साथ तय कर लें।

हर test case को positive या negative चिह्नित करें ताकि suites filter हो सकें। Happy path सबसे पहले चलाएँ: अगर वह टूटा है, तो उसे तुरंत report करें, क्योंकि वह बाकी ज़्यादातर tests रोक देता है। Fail हुए negative test की bug report में exact input, expected rejection, actual behaviour और हर side effect लिखें। Severity नतीजे पर निर्भर करती है: अस्पष्ट message आम तौर पर minor होता है, जबकि invalid data का save होना या पैसे का हिलना critical है।

अभ्यास

Transfer के लिए positive और negative tests design करें

आपका काम

एक banking app की requirement: "Signed-in customer अपने दो accounts के बीच पैसे transfer कर सकता है। Amount 0 से बड़ा हो, उसमें ज़्यादा से ज़्यादा 2 decimal places हों, और वह available balance या एक दिन में कुल 20,000.00 SAR से ज़्यादा न हो। Source और destination अलग होने चाहिए। सफल transfer के बाद दोनों balances update होते हैं और एक reference number दिखता है।"

Tests कागज़ पर design करें, फिर अपनी list की तुलना Positive Test Generator और Negative Test Generator से करें।

चरण
  1. Happy path exact data और expected result के साथ लिखें, फिर दो और positive tests।
  2. इस lesson की हर category के लिए कम से कम एक negative test लिखें, हर एक में एक invalid condition।
  3. हर negative test के लिए expected error handling लिखें।
  4. वे सवाल लिखें जिनका requirement जवाब नहीं देती।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Positive: Current (available 2,000.00) से Savings में 500.00 SAR reference number के साथ सफल; Current में 1,500.00 और Savings 500.00 ज़्यादा। यही happy path है। साथ ही: 125.50 SAR सफल, और Savings से Current सफल।

Negative: खाली amount ("Amount डालें"); abc ("Valid amount डालें"); 0 और -100 ("Amount 0 से बड़ा होना चाहिए"); 12.345 ("ज़्यादा से ज़्यादा 2 decimal places"); 2,000.00 available होने पर 2,500.00 ("Balance पर्याप्त नहीं"); दोनों तरफ़ एक ही account ("कोई दूसरा account चुनें"); आज 19,800.00 भेजने के बाद 600.00 ("Daily limit पार हो गई")।

State, permission और dependency: Confirm से पहले session expire (कोई transfer नहीं); आपके test environment में API से भेजा गया किसी दूसरे customer का account number (4xx के साथ reject, कुछ नहीं हिलता); core banking service जवाब नहीं देती (साफ़ "बाद में कोशिश करें" message, और पैसा Savings तक पहुँचे बिना Current से कभी नहीं निकलता)।

हर negative test में error handling: दोनों balances unchanged, कोई reference number नहीं, history में कोई entry नहीं, input बना रहे, कोई technical details नहीं।

सवाल: "एक दिन" किस time zone से तय होता है? Limit हर customer के लिए है या हर account के लिए? Confirm के बाद connection टूट जाए तो customer क्या देखता है?

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

अगर negative test pass हो, तो क्या इसका मतलब है कि system fail हुआ?

नहीं। Test तब pass होता है जब actual result expected result से मेल खाए। Negative test का expected result एक सही rejection है, इसलिए test तब pass होता है जब system input को specified तरीके से reject करे। अगर system expired code स्वीकार कर ले, तो test fail होता है और आपने एक failure देखा है, जिसकी वजह input validation में एक defect है।

Positive tests की तुलना में कितने negative tests लिखूँ?

कोई तय अनुपात नहीं है। किसी feature को गलत तरीके से इस्तेमाल करने के रास्ते आम तौर पर सही तरीकों से ज़्यादा होते हैं, इसलिए negative tests अक्सर संख्या में ज़्यादा होते हैं। उन्हें risk के हिसाब से चुनें: पहले वह सब जो पैसे, personal data या permissions को छूता है, फिर वे गलतियाँ जो असली users सबसे ज़्यादा करते हैं।

क्या negative testing और edge cases की testing एक ही है?

नहीं। Negative testing इरादे के बारे में है: यह जाँचना कि invalid input या अनचाहा इस्तेमाल reject हो। Edge case किसी extreme पर मौजूद value या स्थिति है, जैसे सबसे लंबा allowed नाम या खाली list, और वह valid भी हो सकता है और invalid भी। Limit से एक character ज़्यादा लंबा नाम edge value भी है और negative test भी।

संदर्भ

  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • OWASP Cheat Sheet Series: Error HandlingOWASP Foundationऐसी एरर रिस्पॉन्स जो कॉलर की मदद करें पर स्टैक ट्रेस, वर्ज़न या आंतरिक पाथ लीक न करें।
  • RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
टूल्स

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

पॉज़िटिव टेस्ट जनरेटर

positive (happy-path) टेस्ट केस बनाएँ जो पुष्टि करें कि हर आवश्यकता और हर वैध इनपुट संयोजन काम करता है।

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

नेगेटिव टेस्ट जनरेटर

फ़ॉर्म फ़ील्ड और API के लिए negative टेस्ट केस बनाएँ: खाली, null, ग़लत टाइप, बहुत लंबा, injection, अमान्य फ़ॉर्मेट।

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

वैलिडेशन टेस्ट जनरेटर

फ़ॉर्म फ़ील्ड के लिए validation टेस्ट केस बनाएँ: required, फ़ॉर्मेट, लंबाई, रेंज, pattern और cross-field नियम।

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

API स्टेटस कोड सिम्युलेटर

ऐसा सार्वजनिक endpoint पाएँ जो कोई भी HTTP स्टेटस कोड लौटाए, वैकल्पिक देरी और कस्टम JSON बॉडी के साथ, ताकि क्लाइंट की error हैंडलिंग टेस्ट हो सके।

API टेस्टिंग

और गहराई से

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

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