रिक्वायरमेंट डिफ़ेक्ट्स
Requirement defect खुद requirement में मौजूद defect है: किसी user story, acceptance criterion, business rule या specification में। Requirements test basis का हिस्सा होती हैं, और ISTQB Foundation syllabus उनके defects (inconsistencies, अस्पष्टता, विरोधाभास, छूटी बातें, अशुद्धियाँ और दोहराव) को उन defects में गिनता है जिन्हें static testing, dynamic testing से ज़्यादा आसानी से या कम लागत में पकड़ती है। यह lesson उन चार प्रकारों पर है जिनसे tester सबसे ज़्यादा मिलता है: ambiguous (अस्पष्ट), incomplete (अधूरी), contradictory (विरोधाभासी) और missing (छूटी हुई) requirements।
एक ही वाक्य चारों दिखा सकता है। "Customer 24 घंटे के अंदर order cancel कर सकता है" ambiguous है (order करने से या payment से?) और incomplete है (payment का क्या होगा?)। यह उस rule से contradict करता है कि shipped orders cancel नहीं हो सकते, क्योंकि order 24 घंटे के अंदर ship हो सकता है। और अगर कोई requirement आंशिक रूप से ship हुए order को cover नहीं करती, तो वह requirement missing है।
यह क्यों ज़रूरी है
Requirement defect document में नहीं रुकता। Developer एक अर्थ के हिसाब से बनाता है, tester दूसरे अर्थ के हिसाब से check करता है, और फ़र्क देर से सामने आता है, जब design, code और tests सबको बदलना पड़ता है। जहाँ requirement missing हो, वहाँ व्यवहार संयोग से तय होता है, और उसे सबसे पहले देखने वाला शायद customer होता है।
Tester के लिए लागत सीधी है: test case को expected result चाहिए, और defective requirement या तो कोई result नहीं देती या दो देती है। उसी text से लिखे tests गलत व्यवहार पर pass भी हो सकते हैं, क्योंकि code और tests एक ही गलतफ़हमी साझा करते हैं। ISTQB का principle "early testing समय और पैसा बचाती है" practice में यही है: review में सवाल मिनटों का होता है, release के बाद वही सवाल fix और retest की क़ीमत लेता है।
Requirement defects के चार प्रकार
Finding उठाते समय प्रकार का नाम लें, क्योंकि हर प्रकार अलग तरह से ठीक होता है। ISTQB की सूची inconsistencies और contradictions को अलग-अलग गिनती है; यह lesson दोनों को contradictory मानता है। Requirement सही है भी या नहीं, यह requirements validation वाले lesson का विषय है।
- Ambiguous (अस्पष्ट): text एक से ज़्यादा उचित अर्थ देता है, इसलिए दो सावधान लोग अलग-अलग व्यवहार बना या टेस्ट कर सकते हैं और दोनों text का पालन कर रहे होते हैं। कारणों में धुंधले शब्द, undefined terms, गायब unit, और ऐसी condition शामिल है जो list के एक item पर लागू हो सकती है या सब पर।
- Incomplete (अधूरी): requirement मौजूद है और उसका main path साफ़ है, लेकिन उसके व्यवहार का कोई हिस्सा नहीं लिखा, जैसे error path, limit, role, या rejection या timeout पर क्या होगा। आप happy path टेस्ट कर सकते हैं, बाकी नहीं।
- Contradictory (विरोधाभासी): दो statements एक ही स्थिति में एक साथ सच नहीं हो सकते, इसलिए हर संभव result उनमें से एक को तोड़ता है। टकराव एक requirement के अंदर, दो requirements के बीच, या किसी business rule, design या API contract (interface की requests और responses का तय किया गया विवरण) से हो सकता है।
- Missing (छूटी हुई): product को जिस व्यवहार या rule की ज़रूरत है, वह कहीं लिखा ही नहीं, इसलिए mark करने को कोई वाक्य नहीं होता। Incomplete के उलट, gap किसी मौजूद requirement के अंदर नहीं, बल्कि वहाँ है जहाँ कोई requirement है ही नहीं।
हर प्रकार कहाँ छिपता है और उसे कैसे खोजें
हर प्रकार की अपनी खोज चाहिए:
- Ambiguity: दो अलग expected results लिखने की कोशिश करें जो दोनों text का पालन करें। अगर लिख पाएँ, तो वह ambiguous है। हर number की unit, गिनती कहाँ से शुरू होती है और limit खुद शामिल है या नहीं, यह check करें।
- Incompleteness: हर requirement से पूछें कि इसे कौन कर सकता है और कौन नहीं, और input invalid होने, limit पूरी होने, action reject होने या जिस system पर यह निर्भर है उसके fail होने पर क्या होगा।
- Contradiction: एक ही actor, data या rule को छूने वाली requirements की तुलना करें, और उन्हें business rules, designs और API contract से मिलाएँ। Decision table, जैसे business rules वाले lesson में, वे combinations दिखाती है जहाँ दो rules अलग actions माँगते हैं।
- Missing requirements: business process को शुरू से अंत तक, और हर object, जैसे request, का जीवन बनने, बदलने, cancel होने और expire होने तक चलकर देखें; उसके states और events लिखने से वे events दिखते हैं जिन्हें किसी ने specify नहीं किया। फिर हर role और ISO/IEC 25010 की quality characteristics, जैसे security और reliability, check करें।
आज़माएँ: डिसीज़न टेबल जनरेटर आज़माएँ: स्टेट ट्रांज़िशन जनरेटर
Worked example: leave request की specification
एक HR portal की leave requests वाली draft specification backlog refinement के लिए तैयार है, और tester उससे पहले इसका review करता है। Findings पढ़ने से पहले हर प्रकार का एक defect खुद ढूँढने की कोशिश करें।
Leave requests: HR portal, release 3 (draft)
LV-1 Employee leave type, start date और end date चुनकर leave माँगता है।
LV-2 Leave request, leave शुरू होने से कम से कम 5 दिन पहले submit होनी चाहिए।
LV-3 Team leads और employees, जिनकी service 2 साल से ज़्यादा है, हर साल 30 दिन
की annual leave पाते हैं। बाकी employees को 21 दिन मिलते हैं।
LV-4 Employee का manager request approve या reject करता है। 10 दिन से लंबी
requests को HR की approval भी चाहिए।
LV-5 Sick leave उसी दिन माँगी जा सकती है जिस दिन वह शुरू होती है।
LV-6 Approved leave के दिन employee के balance से घटाए जाते हैं।Findings और हर एक के लिए पूछने वाला सवाल
हर finding प्रकार, उसे उजागर करने वाला case, और requirement owner, यहाँ HR के product owner, के लिए एक सवाल बताती है। अच्छा सवाल "इसका क्या मतलब है?" पूछने की बजाय संभावित जवाब सामने रखता है, ताकि एक line में जवाब दिया जा सके।
- Ambiguous, LV-3: "जिनकी service 2 साल से ज़्यादा है" दोनों groups पर लागू हो सकता है या सिर्फ़ employees पर, इसलिए 1 साल की service वाले team lead को एक अर्थ में 21 दिन मिलते हैं और दूसरे में 30। पूछें: "1 साल की service वाले team lead को 21 दिन मिलेंगे या 30?"
- Incomplete, LV-4: यह approve करने वालों के नाम बताती है, पर 10 दिन से लंबी request में सिर्फ़ तब का नतीजा साफ़ है जब दोनों approve करें। पूछें: "12 दिन की request में पहले कौन फ़ैसला करता है? अगर manager approve करे और HR reject, तो final status क्या है, और कोई जवाब न दे तो क्या होगा?"
- Contradictory, LV-2 और LV-5: उसी दिन की sick leave को LV-2 reject करता है और LV-5 allow। पूछें: "क्या sick leave को LV-2 के 5 दिन के notice से छूट है?" आम तौर पर एक statement का दायरा छोटा किया जाता है; कौन-सा, यह owner तय करता है।
- Missing: कहीं नहीं लिखा कि employee request cancel कर सकता है या नहीं; LV-6 दिन घटाता है, पर उन्हें लौटाने वाला कुछ नहीं। पूछें: "क्या employee pending या approved request cancel कर सकता है, कब तक, और क्या दिन लौटते हैं? अगर यह release 3 के scope से बाहर है, तो क्या हम इसे दर्ज कर दें?"
- यह भी उठाने लायक है: LV-2 के 5 दिन calendar days हैं या working days?
| प्रकार | Specification में उदाहरण | उठाने वाला सवाल | समाधान क्या है |
|---|---|---|---|
| Ambiguous (अस्पष्ट) | LV-3: क्या "2 साल से ज़्यादा service" की शर्त team leads पर भी लागू है? | 1 साल की service वाले team lead को 21 दिन मिलेंगे या 30? | Owner एक अर्थ चुनता है और wording उसे साफ़ लिखती है |
| Incomplete (अधूरी) | LV-4: 10 दिन से लंबी request में सिर्फ़ तब का नतीजा साफ़ है जब manager और HR दोनों approve करें | Manager 12 दिन की request approve करे और HR reject करे: final status क्या है? | छूटी branches उसी requirement में जोड़ी जाती हैं |
| Contradictory (विरोधाभासी) | LV-2 और LV-5: उसी दिन की sick leave reject भी है और allowed भी | क्या sick leave को LV-2 के 5 दिन के notice से छूट है? | Owner तय करता है कि कौन-सा statement माना जाए, और दूसरे का दायरा छोटा होता है |
| Missing (छूटी हुई) | Request cancel करने पर कोई requirement नहीं है | क्या employee request cancel कर सकता है, कब तक, और क्या दिन balance में लौटते हैं? | नई requirement लिखी जाती है, या gap को out of scope दर्ज किया जाता है |
आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर आज़माएँ: AI Requirement गैप एनालाइज़र
आम गलतियाँ
- "LV-3 साफ़ नहीं है" लिख देना, बिना ठोस case या संभावित अर्थों के; owner इसका जवाब नहीं दे सकता।
- खुद एक अर्थ चुनकर उसी के हिसाब से टेस्ट करना। आपका चुनाव एक अलिखित requirement बन जाता है; इसकी जगह पूछें, और जवाब requirement में दर्ज करवाएँ।
- हर requirement को अकेले review करना, जबकि contradictions statements और documents के बीच रहते हैं।
- हर finding को एक जैसा मानना। Ambiguity को एक अर्थ का चुनाव चाहिए, incomplete requirement को और branches, contradiction को यह फ़ैसला कि कौन-सा statement माना जाए, और missing requirement को नई requirement या साफ़ out-of-scope note।
- Test execution में दिखे व्यवहार को code bug के रूप में report करना, जबकि वह किसी ambiguous requirement के एक अर्थ से मेल खाता है; defect requirement में हो सकता है, इसलिए पहले उसके owner से पूछें।
QA का नज़रिया
Requirement defects तभी से खोजें जब text मौजूद हो: backlog refinement में, requirements reviews में, और test analysis में जब कोई test condition न निकल पाए। फ़ैसला product owner या business analyst करता है; developers को भी शामिल करें, वे अक्सर limits और failure cases जैसे technical gaps देख लेते हैं।
हर finding वहीं दर्ज करें जहाँ requirement रहती है, story पर comment या review log की line के रूप में: requirement ID, प्रकार, case, सवाल, कौन जवाब देगा और कब तक। जब तक कोई खुला सवाल किसी acceptance criterion को रोक रहा हो, story को ready mark न करें। जवाब requirement के text में जाता है, और आपके test cases उसी text से trace होते हैं, किसी chat message से नहीं।
अभ्यास
Class booking specification में चारों प्रकार खोजें
एक gym app में group classes बुक करने के लिए नीचे draft requirements हैं। कम से कम एक ambiguous, एक incomplete, एक contradictory और एक missing requirement खोजें, और हर एक के लिए वह सवाल लिखें जो आप उठाएँगे।
GB-1 Members किसी group class में जगह class से अधिकतम 7 दिन पहले बुक कर सकते हैं।
GB-2 एक class में अधिकतम 20 जगहें होती हैं।
GB-3 Member class से थोड़ा पहले तक booking free में cancel कर सकता है।
GB-4 Premium और family members, जिनका annual plan है, class से 14 दिन पहले
बुक कर सकते हैं।
GB-5 किसी class की booking class शुरू होने से 7 दिन पहले खुलती है।
GB-6 जब member booking cancel करता है, तो जगह release हो जाती है।- किसी requirement का हर वह हिस्सा mark करें जिसके दो अर्थ निकलते हों।
- हर requirement से पूछें: limit पूरी होने या action reject होने पर क्या होगा?
- एक ही चीज़, जैसे booking window, की बात करने वाली requirements की तुलना करें।
- एक booking और एक class को अंत तक follow करें और वे events लिखें जिन्हें कोई requirement cover नहीं करती।
मॉडल उत्तर दिखाएँ
Ambiguous: GB-4 में "जिनका annual plan है" सिर्फ़ family members पर लागू हो सकता है या premium members पर भी: "क्या monthly plan वाला premium member 14 दिन पहले बुक कर सकता है?" GB-3 में "थोड़ा पहले": "Class से कितने घंटे पहले free cancellation ख़त्म होता है?"
Incomplete: GB-2 21वें member को नज़रअंदाज़ करता है: "Class भर जाने पर member को error दिखता है या वह waiting list में जाता है?" GB-6: "जगह किसके लिए release होती है, और क्या उसे बताया जाता है?"
Contradictory: GB-4 14 दिन पहले booking की इजाज़त देता है, लेकिन GB-5 booking सिर्फ़ 7 दिन पहले खोलता है: "Class से 10 दिन पहले क्या eligible member बुक कर सकता है?" GB-1 और GB-5 एक ही rule दो बार भी कहते हैं, जो duplication है।
Missing: gym के class cancel करने और न आने वाले member के बारे में कुछ नहीं लिखा: "Gym class cancel करे तो members को कैसे बताया जाता है, और क्या उन्हें कुछ वापस मिलता है? क्या no-show का कोई rule है?"
अक्सर पूछे जाने वाले सवाल
Incomplete और missing requirement में क्या फ़र्क है?
Gap की जगह का। Incomplete requirement मौजूद है, पर अपने व्यवहार का कोई हिस्सा छोड़ देती है, जैसे error path या limit। Missing requirement है ही नहीं: product को जिस व्यवहार की ज़रूरत है, जैसे request cancel करना, वह कहीं describe नहीं है। Incomplete requirements हर requirement से सवाल पूछकर मिलती हैं, और missing requirements उन्हें process, हर object के जीवन और quality characteristics से मिलाकर।
अगर developer ने सही अर्थ का अंदाज़ा लगा लिया, तो क्या ambiguity फिर भी defect है?
हाँ। Defect requirement में है, जो एक work product है, चाहे उससे अभी तक failure हुआ हो या नहीं। अगला developer, tester या maintainer उसे दूसरे अर्थ में पढ़ सकता है, और test basis अब भी एक expected result नहीं दे पाता। अर्थ तय हो जाने के बाद wording ठीक करना सस्ता है।
Requirement defects कहाँ report करें?
वहाँ जहाँ requirement owner काम करता है: आम तौर पर story पर comment या सवाल के रूप में, requirements review के review log में, या refinement के एक item के रूप में। कुछ teams इन्हें defect tracker में "requirement" जैसे type के साथ भी दर्ज करती हैं ताकि गिन सकें; अपनी team की process अपनाएँ।
क्या AI tools ये defects मेरे लिए ढूँढ सकते हैं?
Mutqan के AI Requirement अस्पष्टता डिटेक्टर और AI Requirement गैप एनालाइज़र (sign-in ज़रूरी, daily quota के साथ) जल्दी से संभावित ambiguities, contradictions और gaps की list दे सकते हैं। उन्हें आपके दूसरे documents, फ़ैसले या users पता नहीं होते, इसलिए वे उन rules से टकराव चूक जाते हैं जो उन्होंने देखे नहीं, और ऐसे gaps उठाते हैं जिनका जवाब कहीं और दिया जा चुका है। इन्हें अपनी पढ़ाई के बाद इस्तेमाल करें, और हर सुझाव को उठाने से पहले check करें।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelउत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
Mutqan tools से अभ्यास करें
conditions और actions से decision table बनाएँ, सभी rule संयोजन जनरेट करें और असंभव संयोजनों को समेट दें।
states और events परिभाषित करें, फिर transition तालिका, वैध/अमान्य transition टेस्ट और 0-switch/1-switch coverage जनरेट करें।
क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।
requirements में अस्पष्ट, धुँधले या परस्पर विरोधी कथन पकड़ें और Mutqan AI से स्पष्टीकरण के सवाल पाएँ।
Mutqan AI से छूटी हुई requirements खोजें — error handling, permissions, edge conditions, non-functional ज़रूरतें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।