मॉड्यूल 5 · Requirements और static testing

टेस्टेबिलिटी

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

Testability का मतलब है कि किसी चीज़ को कितनी आसानी से टेस्ट किया जा सकता है। ISTQB glossary, ISO/IEC 25010 के आधार पर, इसे वह degree बताती है जिस तक किसी component या system के लिए test conditions तय की जा सकें और यह जानने के लिए tests चलाए जा सकें कि वे conditions पूरी हुईं या नहीं। Tester के लिए इसके दो पहलू हैं: requirement testable है जब आप पहले से बता सकें कि कौन-सा result pass है और कौन-सा fail; system testable है जब test उसे ज़रूरी state में ला सके और देख सके कि system ने क्या किया।

उदाहरण: "Search results जल्दी दिखने चाहिए" testable नहीं है, क्योंकि कोई नहीं बता सकता कि 1.8 seconds pass है या fail। "Staging environment पर catalogue में 50,000 products और एक साथ search कर रहे 100 users होने पर, 95% searches में Search दबाने के 2 seconds के अंदर results दिखें" testable है, बशर्ते team staging में 50,000 products load कर सके, 100 users simulate कर सके और results दिखने तक का समय माप सके। यही शर्त system वाला पहलू है।

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

जिस requirement को कोई भी result fail नहीं कर सकता, वह verdict का कोई आधार नहीं देती। हर व्यक्ति खाली जगह अपनी समझ से भरता है: developer एक behaviour बनाता है, tester दूसरा check करता है, और product owner तीसरे की उम्मीद कर रहा था। यह फ़र्क़ देर से सामने आता है, इस बहस के रूप में कि defect सच में defect है या नहीं, और तब feature बदलना सबसे महँगा होता है।

System की कम testability समय खाती है और defects छिपाती है। अगर test data बनाने में दस screens लगें, reminder सिर्फ़ एक दिन इंतज़ार करके टेस्ट हो सके, या failed request सिर्फ़ "Something went wrong" दिखाए, तो tests धीमे हो जाते हैं, छूट जाते हैं या cause तक नहीं पहुँचते। ISTQB Foundation syllabus test analysis में test basis की testability को assess करना शामिल करता है, इसलिए tester इसे reviews और refinement में उठाता है, जब बदलाव अभी सस्ता है।

Requirement को testable क्या बनाता है

एक quick check: क्या आप आज ही इस requirement से किसी test case का expected result लिख सकते हैं, और क्या दो testers एक ही outcome पर एक ही verdict देंगे? पिछले lesson के तीन defects, यानी ambiguous, incomplete और contradictory requirements, इस check में fail होते हैं; चौथा, यानी छूटी हुई (missing) requirement, check करने के लिए कुछ छोड़ती ही नहीं। Testable requirement होती है:

  • Clear: उसका एक ही अर्थ हो। Actor, trigger और result लिखे हों, terms defined हों, और हर statement एक ही behaviour बताए। "User order cancel कर सकता है" तब तक clear नहीं जब तक पता न हो कि कौन-सा user, order की कौन-सी states और कब तक।
  • Measurable: हर quality word की जगह कोई observable result (message, state, stored record, भेजा गया email) या unit और conditions वाला target हो। Non-functional testing वाले lesson में आपने देखा कि "fast" या "easy" को ऐसे target में कैसे बदलें।
  • Consistent: वह न ख़ुद से टकराए, न दूसरी requirements, business rules या design से, और एक चीज़ का हर जगह एक ही नाम हो। जब दो requirements आपस में टकराती हैं, तो हर संभव result उनमें से किसी एक को fail करता है।

System की testability: controllability और observability

Clear requirement भी टेस्ट नहीं हो सकती अगर system आपको situation set up करने या outcome देखने न दे। इसे दो properties बताती हैं। Controllability यह है कि test कितनी आसानी से system को ज़रूरी state में ला सकता है: data बनाना, date set करना, कोई feature on करना, payment provider से decline करवाना। Observability यह है कि test कितनी आसानी से देख सकता है कि system ने क्या किया, उन results समेत जो screen तक नहीं पहुँचते: stored record, भेजा गया email, log entry, exact error।

दोनों design decisions हैं, और feature बनने से पहले इन्हें माँगना सबसे सस्ता है। ISO/IEC 25010:2023 testability को maintainability के अंदर रखता है: जिस product को टेस्ट करना मुश्किल है, उसे सुरक्षित रूप से बदलना भी मुश्किल है। Testers की आम माँगें:

  • Test data बनाने और reset करने का तरीका (seed script, API या admin screen)।
  • ऐसी clock या expiry setting जिसे test control कर सके, हर उस चीज़ के लिए जो expire या schedule होती है।
  • Third-party services के लिए sandbox (test) modes या test doubles, यानी असली service की नकल करने वाले stand-ins, ताकि declined payment या timeout ज़रूरत पड़ने पर पैदा किया जा सके।
  • Correlation id (एक id जो एक ही request की हर log entry को जोड़ती है) वाले logs, specific error codes, और application में दिखने वाला build version।
  • Automation के लिए stable identifiers, जैसे data-testid attribute, जिससे test किसी element को तब भी ढूँढ सके जब उसका text या layout बदल जाए।
  • इस बात की पुष्टि कि data reset या clock override जैसे control hooks test environments के बाहर बंद हैं: production से पहुँचा जा सकने वाला data-reset endpoint अपने आप में एक defect है।

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

Untestable requirement को दोबारा लिखना

Rewrite एक proposal है, decision नहीं। Tester बताता है कि क्या कमी है और wording सुझाता है; requirement का owner, आम तौर पर product owner या business analyst, values तय करता है और text approve करता है। इस क्रम में काम करें:

  • हर वह शब्द चिह्नित करें जिसे test check नहीं कर सकता: quality adjectives (fast, easy, secure), vague amounts (कुछ, बड़ा, reasonable), open lists (etc., जैसे) और weak verbs (support, handle, manage)।
  • हर एक की जगह observable result या unit और conditions वाला target रखें। कोई value propose करें और उस पर "confirm करना है" लिखें।
  • Compound sentences तोड़ें ताकि हर statement का एक ही pass या fail verdict हो, और statements को number दें ताकि test cases उनसे trace हो सकें।
  • Actor, trigger, preconditions और error paths लिखें।
  • Rewrite को जुड़ी हुई requirements और business rules से मिलाएँ, फिर लिखें कि उसे टेस्ट करने के लिए आपको क्या control और observe करना होगा।

आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर

Worked example: subscription renewal की requirement

एक language-learning app monthly subscriptions बेचता है। उसकी specification में लिखा है: REQ-21 "Subscribers को subscription renew होने से पहले समय रहते याद दिलाया जाना चाहिए। अगर payment fail हो, तो subscription ख़त्म होने से पहले कुछ बार फिर से कोशिश की जानी चाहिए।" एक business rule भी है: BR-9 "Paused subscription से कोई charge नहीं लिया जाता।"

Review: "समय रहते" और "कुछ बार" measurable नहीं हैं; "याद दिलाया जाना" और "चाहिए" clear नहीं हैं (किस channel से, क्या लिखकर, और क्या यह mandatory है?); और REQ-21 paused subscriptions पर चुप है, इसलिए वह BR-9 से टकरा सकता है। Tester नीचे दिया गया rewrite propose करता है, product owner से पूछता है कि "ख़त्म होने" का मतलब cancel है या pause, और लिखता है कि test environment में क्या होना चाहिए:

  • एक clock जिसे test environment में आगे बढ़ाया जा सके, ताकि reminder (21.1) और retries (21.3) एक हफ़्ते इंतज़ार किए बिना test हो सकें (controllability)।
  • Payment provider का sandbox, जिसमें ऐसे test cards हों जो ज़रूरत पड़ने पर decline हों, ताकि एक, दो या तीन declined attempts पैदा किए जा सकें (controllability, 21.3)।
  • एक capture inbox, ताकि reminder और cancellation वाले emails असली mailboxes के बिना पढ़े जा सकें (observability, 21.1 और 21.3)।
  • Test data जिसमें एक active और एक paused subscription हो, और sandbox में charge attempts की list, यह पक्का करने के लिए कि चौथी attempt नहीं होती और paused subscription से कभी charge नहीं लिया जाता (controllability और observability, 21.3 और 21.4)।
REQ-21  Monthly renewal (proposed rewrite; values product owner confirm करेगा)

21.1  Renewal date से 7 दिन पहले subscriber को एक email जाता है, जिसमें renewal
      date, amount और pause या cancel करने का तरीका लिखा होता है।
21.2  Renewal date पर saved card से plan की कीमत charge होती है, और subscription
      एक महीने और चलता है।
21.3  Charge decline होने पर renewal date के 1 दिन और 3 दिन बाद फिर कोशिश होती है।
      तीनों attempts decline हों, तो subscription cancel होता है और subscriber को
      इसका email जाता है। उसके बाद कोई charge attempt नहीं होता।
21.4  Paused subscription को न reminder जाता है, न उससे charge लिया जाता है (BR-9)।
21.5  हर charge attempt, accepted या declined, "Billing history" में अपनी date,
      amount और result के साथ दिखता है।
Subscription renewal REQ-21 rewrite से पहले और बाद में: vague शब्द 7 दिन पहले reminder, दो retries और तय end बन जाते हैं, और tester इसे टेस्ट करने के लिए test clock और decline होने वाले sandbox cards जोड़ता है।

मूल REQ-21Untestable

Subscribers को "समय रहते" याद दिलाया जाए; failed payment "कुछ बार" फिर से try हो

Clear: कौन और क्या:
"याद दिलाया जाए", "चाहिए": किस channel से, क्या लिखकर, और क्या यह mandatory है?
Measurable:
"समय रहते", "कुछ बार"
Consistent:
Paused subscriptions पर चुप: BR-9 से टकरा सकता है
Control और observe:
सोचा ही नहीं गया
क्या test verdict तक पहुँच सकता है?:
सिर्फ़ obvious failures पर: कोई तय expected result नहीं हैफ़ेल

Rewrite 21.1–21.5Testable

पाँच numbered statements, हर एक का एक verdict

Clear: कौन और क्या:
Renewal से 7 दिन पहले एक email, जिसमें date, amount और pause या cancel का तरीका हो
Measurable:
Renewal date के 1 और 3 दिन बाद retry; तीन declined attempts के बाद subscription cancel होता है
Consistent:
Paused subscription को न reminder जाता है, न charge होता है, जैसा BR-9 कहता है
Control और observe:
Test clock और ज़रूरत पर decline होने वाले sandbox cards; capture inbox और charge attempts की list
क्या test verdict तक पहुँच सकता है?:
हाँ: हर statement या तो pass होता है या failपास

Rewrite की values तब तक tester के proposals हैं जब तक product owner उन्हें confirm न करे।

आज़माएँ: Requirements → टेस्ट केस आज़माएँ: AI Acceptance Criteria रिव्यूअर

आम गलतियाँ

  • "fast", "intuitive" या "secure" को जैसा लिखा है वैसा मान लेना और testing के दौरान अपने pass criteria गढ़ लेना, जिससे verdict आपकी राय बन जाता है, सहमति नहीं।
  • अपनी चुनी values सिर्फ़ अपने test cases में डालना। इससे एक छिपी हुई दूसरी specification बन जाती है; तय की गई wording को requirement में ही दर्ज करवाएँ।
  • Conditions के बिना number जोड़ना: data volume, load या measuring point के बिना "2 seconds के अंदर" पर अब भी दोनों तरफ़ बहस हो सकती है।
  • सिर्फ़ wording review करना, फिर test के दिन पता चलना कि email पढ़ा नहीं जा सकता या 24 घंटे की expiry का मतलब 24 घंटे का test है।
  • Testable को correct मान लेना: precise wording भी गलत behaviour बता सकती है।
  • Data reset या clock override जैसे test hooks माँगना, बिना यह पक्का किए कि production में वे बंद हैं।

QA का नज़रिया

Testability वहाँ check होती है जहाँ requirements पर बात होती है: backlog refinement, requirements reviews और test analysis। हर statement पर दो सवाल पूछें: "मुझे कैसे पता चलेगा कि यह pass हुआ?" और "मुझे क्या set up करना और क्या देखना होगा?" हर finding को review comment या ticket पर सवाल के रूप में लिखें: statement, वह testable क्यों नहीं है, proposed rewrite और फ़ैसला कौन करेगा।

System वाला पहलू developers और architects के साथ बातचीत है। Testability features को story का हिस्सा बनाकर माँगें, और जो न मिलें उन्हें test plan में risk के रूप में दर्ज करें। Rewrite तय हो जाने पर वह आपका test basis बन जाता है, और हर test case किसी numbered statement से trace होता है; requirements traceability वाला lesson इसी पर आगे बढ़ता है।

अभ्यास

Delivery slot की requirement को testable बनाएँ

आपका काम

एक grocery delivery app में नीचे दी गई requirement और business rule हैं। उनकी testability आँकें, requirement को testable statements में दोबारा लिखें, और लिखें कि उन्हें टेस्ट करने के लिए system को क्या देना होगा।

सामग्री
REQ-14  Customers एक convenient delivery slot चुन सकें। Slots real time में
        update होने चाहिए, और fully booked slots नहीं दिखाए जाने चाहिए, etc.
BR-3    22:00 के बाद दिए गए orders की delivery सबसे पहले परसों होती है।
चरण
  1. हर वह शब्द या phrase चिह्नित करें जिसे test check नहीं कर सकता, और बताएँ कि वह कौन-सी property तोड़ता है: clear, measurable या consistent।
  2. REQ-14 को BR-3 से मिलाएँ और कोई टकराव या कमी लिखें।
  3. REQ-14 को numbered statements में दोबारा लिखें, हर एक का एक verdict हो, और proposed values पर "confirm करना है" लिखें।
  4. लिखें कि अपना rewrite टेस्ट करने के लिए आपको क्या control और क्या observe करना होगा।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

जैसा लिखा है वैसा testable नहीं: "convenient" (measurable नहीं: कौन-से दिन और कितने लंबे slots दिखें?), "real time में" (measurable नहीं: भरा हुआ slot कितनी देर में गायब हो?), "fully booked" (clear नहीं: कितने orders से slot भरता है?), "etc." (clear नहीं: open list) और "should" (clear नहीं: mandatory या optional?)। BR-3 अपनी edge को छोड़कर testable है: पूछें कि ठीक 22:00 पर दिया गया order "22:00 के बाद" गिना जाएगा या नहीं, और clock किस time zone का है।

Consistency: REQ-14 में 22:00 के cut-off का ज़िक्र नहीं, इसलिए 22:30 पर order देने वाले customer को कल के slots दिख सकते हैं, जिसे BR-3 मना करता है। Rewrite को BR-3 मानना होगा, या owner दोनों में से एक को बदले।

Proposed rewrite, values confirm करनी हैं: 14.1 Checkout कल से शुरू करके अगले 7 दिनों में हर दिन 08:00 से 22:00 के बीच 2 घंटे के slots दिखाता है। 14.2 22:00 के बाद दिए गए order के लिए कल के slots नहीं दिखते: सबसे पहला slot परसों का होता है (BR-3)। 14.3 एक slot में अधिकतम 20 orders आते हैं; 20 confirmed orders वाला slot नहीं दिखता। 14.4 भरा हुआ slot बाक़ी customers के लिए 10 seconds के अंदर गायब हो जाता है; अगर कोई customer अभी-अभी भरा slot confirm करे, तो order place नहीं होता और message "यह slot अब उपलब्ध नहीं है। कोई दूसरा slot चुनें।" दिखता है। Product owner से पूछें कि "etc." से क्या मतलब था।

Controllability: 22:00 cut-off को बिना इंतज़ार टेस्ट करने के लिए test environment में current time set करना, slot भरने के लिए bulk में orders बनाना (API या seed data), और testing में slot capacity configurable होना। Observability: हर slot की capacity और booked orders की गिनती देखना (admin screen, API या database), और 10 seconds वाले update को मापने के लिए logs में timestamps।

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

Testability requirements के बारे में है या system के बारे में?

दोनों। Requirement वाला पहलू तय करता है कि आपको expected result पता है या नहीं; system वाला पहलू तय करता है कि आप test set up कर सकते हैं और actual result देख सकते हैं या नहीं। जिस system को observe न किया जा सके, उस पर clear requirement को टेस्ट करना उतना ही मुश्किल हो सकता है जितना ऐसे system पर vague requirement को जो अपना हर काम दिखाता है।

Untestable requirement को कौन दोबारा लिखता है, tester या product owner?

Tester gap ढूँढता है, wording propose करता है और सवाल पूछता है। Requirement का owner values तय करता है और wording approve करता है, और तय version backlog या specification में जाता है ताकि developers और testers एक ही text से काम करें।

अगर requirement testable है, तो क्या वह सही भी है?

नहीं। Testable का मतलब है कि test दिखा सकता है कि system उसे पूरा करता है या नहीं; यह इस बारे में कुछ नहीं कहता कि वह users और business की असली ज़रूरत बताती है या नहीं। एक precise requirement भी precisely गलत हो सकती है। इसे जाँचना requirements validation है, जो अगले lesson का विषय है।

क्या हर requirement को testable बनाया जा सकता है?

ज़्यादातर को, कोई observable result या conditions वाला target लिखकर। "Customers app पर भरोसा करें" जैसा बड़ा goal जैसा लिखा है वैसे टेस्ट नहीं हो सकता: उसे context के रूप में रखें और उससे testable requirements निकालें जो उसे support करें, जैसे security, privacy और error handling के specific rules।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023उत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
टूल्स

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

Requirements → टेस्ट केस

क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।

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

AI Requirement अस्पष्टता डिटेक्टर

requirements में अस्पष्ट, धुँधले या परस्पर विरोधी कथन पकड़ें और Mutqan AI से स्पष्टीकरण के सवाल पाएँ।

आवश्यकता विश्लेषण AI

AI Acceptance Criteria रिव्यूअर

acceptance criteria की testability, पूर्णता और अस्पष्टता की समीक्षा करें और Mutqan AI से बेहतर लिखे गए सुझाव पाएँ।

आवश्यकता विश्लेषण AI

और गहराई से

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

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