एज केस और कॉर्नर केस
Edge case ऐसा test है जिसमें एक input या condition किसी extreme पर होती है — बिल्कुल कुछ नहीं, सबसे बड़ी allowed value, पहला या आख़िरी valid दिन — जबकि बाकी सब सामान्य रहता है। Corner case दो या ज़्यादा extremes को एक साथ रखता है। Gift card form पर ठीक 150 characters का message, यानी maximum, एक edge case है; वही message ऐसे card पर जो आज deliver होना है, यानी सबसे पहली allowed date, एक corner case है।
दोनों industry के terms हैं, ISTQB techniques नहीं, और teams इनके बीच की रेखा थोड़ी अलग खींचती हैं। असली बात आदत है: typical positive और negative tests pass होने के बाद हर input को उसके extremes तक ले जाएँ, फिर उन extremes को मिलाएँ जो आपस में interact करते हैं।
यह क्यों ज़रूरी है
Features typical data से बनाए और आज़माए जाते हैं, इसलिए extremes उस code तक पहुँचते हैं जो कम ही चलता है: empty list वाली branch, गलत unit में गिनी गई length, user की बजाय server के time zone में calculate हुई date। ऐसे defects हर सामान्य test से बच निकलते हैं, फिर उस पहले customer के लिए failure पैदा करते हैं जिसका order 29 फ़रवरी को पड़ता है।
Tester के लिए, जान-बूझकर चुने गए कुछ extremes उस code तक पहुँचते हैं जिसे सामान्य data नहीं छूता, और requirements की कमियाँ सामने लाते हैं, जो शायद ही बताती हैं कि empty, बहुत बड़ी या मिली-जुली extreme values पर क्या होगा।
एक extreme, या कई एक साथ
हर input को एक axis की तरह सोचें जो उसकी सबसे छोटी से सबसे बड़ी value तक जाती है। Typical test हर axis के बीच में होता है। Edge case एक axis को किनारे तक ले जाता है, इसलिए failure एक ही input की ओर इशारा करता है। Corner case दो या ज़्यादा axes को एक साथ किनारों तक ले जाता है; interactions वहीं छिपे होते हैं, जब हर extreme अकेले ठीक चलता है पर उनका मेल नहीं।
Gift card form पर message optional है, 150 characters तक, और delivery आज से 90 दिन आगे तक हो सकती है। खाली message एक edge है, आज की delivery एक edge है, और दोनों साथ एक corner हैं। Edges valid भी हो सकते हैं और invalid भी: 150 characters accept होने चाहिए, 151 साफ़ error के साथ reject।
Corners तेज़ी से बढ़ते हैं: दो-दो extremes वाले दस inputs से 1,024 combinations बनते हैं जिनमें हर input किसी extreme पर है। वे corners test करें जहाँ inputs एक calculation, record या output में मिलते हैं।
| Message length | Delivery date | ||
|---|---|---|---|
| आजसबसे पहली date | सामान्य daterange के अंदर | Day 90आख़िरी date | |
| खाली0 characters | Corner caseदो extremes एक साथ | Edge caseएक extreme | Corner caseदो extremes एक साथ |
| सामान्यछोटा message | Edge caseएक extreme | Typicalकोई extreme नहीं | Edge caseएक extreme |
| Maximum150 characters | Corner caseदो extremes एक साथ | Edge caseएक extreme | Corner caseदो extremes एक साथ |
- Typical: कोई input extreme पर नहीं
- Edge case: एक input extreme पर, दूसरा सामान्य
- Corner case: दोनों inputs एक साथ extreme पर
Grid valid extremes दिखाता है। हर edge range के ठीक बाहर भी test होता है: 151 characters, बीता हुआ कल, day 91।
कहाँ देखें: extremes के पाँच परिवार
Edge cases खोजने के लिए inspiration नहीं, checklist चाहिए। हर input, stored value और output को पाँच परिवारों से गुज़ारें।
- Empty: खाली string, सिर्फ़ spaces,
0, खाली list, 0 bytes की file, खाली छोड़ा गया date field। - Null और missing:
"note": null,"note": ""और बिनाnoteवाली request, API के लिए तीन अलग inputs हैं। इनमें से किसी से service crash नहीं होनी चाहिए, न screen पर "null" दिखना चाहिए। - Minimum और maximum: ठीक limit और उससे एक आगे, एक item, सबसे बड़ा allowed count या file size, बिना spaces का लंबा शब्द, data type में आने वाला सबसे बड़ा number।
- Unicode: Arabic और Devanagari, मिली-जुली text direction, diacritics, zero-width space,
١٢٣जैसे Arabic-Indic digits, Arabic में file name, और skin tone वाला emoji। Medium skin tone वाला thumbs up,U+1F44D U+1F3FD, दिखने में एक character है, पर उसमें दो code points, चार UTF-16 code units और आठ UTF-8 bytes हैं, इसलिए दिखने वाले characters, code units या bytes में गिनी गई limits एक ही text पर अलग नतीजे देती हैं। - Time और date: आधी रात, महीने और साल का अंत, 29 फ़रवरी (2028 leap year है, 2100 नहीं), पहला और आख़िरी allowed दिन, दूसरा time zone, daylight saving का बदलाव। Asia/Riyadh (UTC+03:00) और Asia/Kolkata (UTC+05:30) में daylight saving नहीं है, इसलिए सिर्फ़ वहीं test करने वाली team को यह बदलाव कभी नहीं मिलता।
| Input type | कुछ नहींempty, null, missing | सबसे छोटा और सबसे बड़ाminimum और maximum | असामान्य contentUnicode, time और date |
|---|---|---|---|
| Text | "", सिर्फ़ spaces, null, field ही नहीं | ठीक limit, उससे एक आगे, बिना spaces का लंबा शब्द | Arabic और Devanagari, मिली-जुली direction, skin tone वाला emoji, zero-width space |
| Number | 0, null, field ही नहीं | Limit और उससे एक आगे, type में आने वाली सबसे बड़ी value | Arabic-Indic digits ١٢٣ |
| Date और time | खाली छोड़ा गया date field, null | पहला और आख़िरी allowed दिन, महीने और साल का अंत | आधी रात, 29 फ़रवरी, दूसरा time zone, daylight saving का बदलाव |
| List या file | खाली list, 0 bytes की file | एक item, सबसे बड़ा allowed count या size | Arabic में file name |
आज़माएँ: एज केस जनरेटर आज़माएँ: Unicode डेटासेट जनरेटर आज़माएँ: तारीख़ टेस्ट डेटा जनरेटर
Edge cases और boundary values एक ही चीज़ नहीं
ISTQB की भाषा में boundary value किसी ordered equivalence partition की सबसे छोटी या सबसे बड़ी value है। Equivalence partition values का ऐसा group है जिसके साथ system को एक जैसा व्यवहार करना चाहिए, जैसे 0 से 150 characters तक की सभी valid message lengths; ordered का मतलब है कि उसकी values को सबसे छोटी से सबसे बड़ी तक क्रम में रखा जा सकता है। Boundary values पर बनी technique, boundary value analysis, test design module में आएगी। दोनों ideas overlap करते हैं, पर कोई भी दूसरे को पूरी तरह नहीं समेटता।
- कई edges boundary values हैं: 0 और 150 characters valid message length के सिरे हैं; 151 पहली invalid length है।
- कुछ edges का कोई क्रम नहीं, इसलिए कोई boundary नहीं:
null, emoji, मिली-जुली direction वाला text। - कुछ boundaries extremes नहीं हैं: 100.00 SAR पर बदलने वाली delivery fee की boundary valid range के अंदर है।
- Boundary value analysis systematic है और coverage मापने देती है। Edge cases checklists और अनुभव से आते हैं, ISTQB की दो experience-based techniques की तरह जो आप test design module में देखेंगे: error guessing, जो tester के ज्ञान के आधार पर संभावित errors, defects और failures का अनुमान लगाती है, और checklist-based testing।
Worked example: gift card
Requirement: "Message optional है, 150 characters तक। Delivery आज से 90 दिन आगे तक। Card delivery date पर recipient के time zone में 09:00 बजे e-mail से भेजा जाता है।" हर input के edges लिखें, फिर उन extremes को मिलाएँ जो एक output में मिलते हैं।
- Message के edges: खाली → message block नहीं, "null" कभी नहीं; 150 → पूरा दिखता है; 151 → reject, limit बताते हुए; Arabic text और skin tone वाला emoji → सही-सलामत दिखते हैं।
- Date के edges: आज और day 90 → accept; 29 फ़रवरी 2028, जब भी वह 90 दिनों के अंदर हो → accept; बीता हुआ कल और day 91 → reject।
- Corner, length × Unicode: 150 दिखने वाले characters, जिनमें कई emoji हैं। अगर counter 150/150 दिखाए पर server message reject कर दे या किसी emoji को बीच से काट दे, तो counter और server अलग units में गिन रहे हैं — यह defect है।
- Corner, आज × भेजने का समय: delivery आज, order recipient के time zone में 11:00 बजे, जब वहाँ 09:00 बीत चुका है। Requirement चुप है: तुरंत भेजें या order reject करें? Product owner से पूछें।
- Corner, day 90 × time zone: Riyadh में रात 23:30 बजे एक sender Kolkata के recipient के लिए day 90 चुनता है, जहाँ अगले दिन के 02:00 बज चुके हैं। 90 दिन sender के "आज" से गिने जाएँ या recipient के?
आम गलतियाँ
- "Edge case" को invalid input का नाम मान लेना; कई edges valid हैं और accept होने चाहिए।
- सिर्फ़ English text से test करना, जिससे bytes या code units वाली limits और मिली-जुली direction वाला display कभी test नहीं होते।
- Extremes को सिर्फ़ अकेले test करना, या उन corners की बजाय जहाँ inputs interact करते हैं, सबको मिला देना।
- Dates सिर्फ़ team के अपने time zone में और सामान्य दिनों पर test करना।
null, खाली string और missing field को एक ही case मानना।- Requirement चुप हो तो पूछकर जवाब record करने की बजाय expected result का अंदाज़ा लगाना।
QA का नज़रिया
Edge cases refinement में शुरू होते हैं: हर field के लिए पूछें कि खाली होने पर क्या होता है, सबसे बड़ी supported value क्या है, और date किसके time zone में पढ़ी जाती है। जवाब acceptance criteria बनते हैं। Worked example में तीन में से दो corners सवालों पर ख़त्म हुए, जो आम है: requirements सामान्य cases बताती हैं।
Exact data record करें: string उसकी length और गिनने के तरीके के साथ, समय उसके time zone के साथ। "150 characters का message जो दो emoji पर ख़त्म होता है" reproduce हो सकता है; "लंबा message" नहीं। Team के लिए पाँच परिवारों की checklist रखें और जब भी कोई production defect नया extreme दिखाए, उसे बढ़ाएँ।
अभ्यास
Booking form के edges और corners खोजें
एक clinic app कहता है: "Patient पूरा नाम (2 से 60 characters) और एक optional note (300 characters तक) डालता है, और कल से 30 दिन आगे तक का slot book करता है, clinic time (Asia/Riyadh) में 08:00 से 16:45 तक हर 15 मिनट पर। Appointment से 24 घंटे पहले reminder SMS भेजा जाता है।"
कम से कम आठ edge cases और तीन corner cases लिखें, हर एक के साथ expected result, या जहाँ requirement चुप हो वहाँ एक सवाल।
- Inputs और outputs लिखें, reminder SMS समेत।
- हर input को पाँच परिवारों से गुज़ारें।
- हर edge का expected result लिखें, valid या invalid।
- जो extremes एक calculation या output में मिलते हैं उन्हें मिलाएँ।
मॉडल उत्तर दिखाएँ
Edges: 2 और 60 characters के नाम accept; खाली नाम, 1 और 61 characters और सिर्फ़ spaces reject; Arabic और Devanagari नाम सही दिखते हैं। खाली note "कोई note नहीं" की तरह दिखता है, "null" कभी नहीं; 300 characters accept, 301 reject। कल, day 30, 08:00 और 16:45 दिखते हैं; आज, day 31, 07:45 और 17:00 नहीं; leap year की 29 फ़रवरी, जब भी वह 30 दिनों के अंदर हो, दिखती है।
Corners: (1) कल का 08:00 slot आज 10:00 बजे book हुआ — reminder का समय बीत चुका है; अभी भेजें या कभी नहीं? (2) Reminder में 60 characters का Arabic नाम — Arabic text वाले एक SMS में आम तौर पर सिर्फ़ 70 characters आते हैं, इसलिए वह बँट या कट सकता है। (3) Asia/Kolkata पर set phone से पहला slot, 08:00, book होता है — वह clinic time के 08:00 पर book होना चाहिए (उस phone पर 10:30), Kolkata के 08:00 पर नहीं, जो Riyadh में 05:30 है और clinic खुलने से पहले; reminder भी clinic time के हिसाब से चलता है।
सवाल: देर से हुई booking का reminder, नाम में emoji कैसे गिने जाएँ, क्या बँटा हुआ SMS ठीक है, और "30 दिन आगे" किस time zone में गिना जाए।
अक्सर पूछे जाने वाले सवाल
Edge case और corner case में क्या फ़र्क है?
Edge case एक input या condition को extreme पर रखता है और बाकी सब सामान्य रहता है। Corner case दो या ज़्यादा को एक ही समय पर उनके extremes पर रखता है। पहले edges test करें: अगर कोई corner fail हो जबकि उसका हर edge pass होता है, तो आपको interaction defect मिला है।
क्या edge case और boundary value एक ही हैं?
हमेशा नहीं। Boundary value किसी ordered partition की सबसे छोटी या सबसे बड़ी value है, जिसे boundary value analysis इस्तेमाल करती है। कई edge cases boundary values हैं, लेकिन null, emoji या मिली-जुली direction वाले text का कोई क्रम नहीं, और range के बीच की boundary, जैसे 100.00 पर बदलने वाली fee, input का extreme नहीं है।
क्या edge cases और negative tests एक ही हैं?
नहीं। Negative test जाँचता है कि invalid input या misuse ठीक से handle हो। Edge cases valid भी हो सकते हैं और invalid भी: 150 characters का message accept होना चाहिए, 151 वाला reject। इन्हें test data चुनने का अलग तरीका मानें जिसे आप positive और negative tests के साथ मिलाते हैं।
मुझे कितने corner cases test करने चाहिए?
सब नहीं; हर नए input के साथ उनकी संख्या तेज़ी से बढ़ती है। वे combinations चुनें जिनमें inputs कोई calculation, stored record या output साझा करते हैं, और वे जिनका failure सबसे महँगा होगा। Combinations के लिए techniques, जैसे pairwise testing, आगे test design module में आती हैं।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
- UAX #29: Unicode Text Segmentationटेक्स्ट को ग्रैफ़ीम क्लस्टर, शब्दों और वाक्यों में कैसे बाँटा जाता है — "कैरेक्टर" की गिनती कोड-पॉइंट या बाइट की गिनती से क्यों अलग हो सकती है।
- Time Zone Databaseदुनिया के time zone और उनके ऐतिहासिक offset व daylight-saving नियमों का tz डेटाबेस, जो साल में कई बार अपडेट होता है।
Mutqan tools से अभ्यास करें
फ़ील्ड परिभाषा से strings, संख्याओं, तारीख़ों, फ़ाइलों, lists और concurrency के edge case जनरेट करें।
कई लिपियों (अरबी, देवनागरी, CJK, सिरिलिक), emoji, संयोजक चिह्न और normalisation रूपों में Unicode टेस्ट स्ट्रिंग जनरेट करें।
स्ट्रिंग की लंबाई कैरेक्टर, कोड पॉइंट, UTF-8 बाइट और UTF-16 यूनिट में मापें।
तारीख़ों के डेटासेट जनरेट करें: किसी रेंज में रैंडम तारीख़ें, leap day, महीने के अंत, DST किनारे और कई फ़ॉर्मेट।
तारीख़ और समय को अलग-अलग timezone के बीच बदलें (रियाद, अम्मान, दिल्ली, UTC, न्यूयॉर्क, लंदन…)।
स्पेस सहित और बिना स्पेस के कैरेक्टर तथा लाइनें गिनें, और ट्वीट, SMS व मेटा डिस्क्रिप्शन की सीमाएँ जाँचें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।