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

रिक्वायरमेंट्स क्या हैं?

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

Requirement एक statement है जो बताता है कि product को क्या करना चाहिए, या उसे कौन-सी quality या limit पूरी करनी है, क्योंकि product से जुड़े किसी stakeholder को इसकी ज़रूरत है। "System हर booked appointment से 24 घंटे पहले SMS reminder भेजेगा" एक requirement है। "Patient clinic को फ़ोन किए बिना appointment cancel कर सके" भी requirement है, और इन दोनों के पीछे clinic का goal भी: कम missed appointments।

ये तीनों statements अलग-अलग levels पर हैं — business, stakeholder और system — अलग-अलग लोगों से आते हैं, और अलग-अलग forms में लिखे जाते हैं: strategy document, user story, specification, design या contract। जैसा आपने test analysis वाले lesson में देखा, testing test basis से शुरू होती है, और ज़्यादातर products में requirements उसका सबसे बड़ा हिस्सा होती हैं। यह lesson सिखाता है कि requirements को उनके हर form में कैसे पहचानें और tester की नज़र से कैसे पढ़ें।

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

Defect code लिखे जाने से पहले ही requirement में पैदा हो सकता है। अगर requirement missing, vague या गलत है, तो design, code और tests सब वही गलती दोहराते हैं, और system हर test pass करके भी उन लोगों के काम नहीं आता जिनके लिए बना था। Requirement लिखते समय पकड़ा गया defect एक बातचीत की कीमत लेता है; release के बाद मिले तो fix, retest, कभी-कभी data clean-up, और users का भरोसा।

Product के लिए requirements वह जगह हैं जहाँ scope, cost और risk तय होते हैं। Tester के लिए उन्हें अच्छी तरह पढ़ना इस role का पहला skill है: इसी से तय होता है कि आप क्या टेस्ट करेंगे, पहले क्या टेस्ट करेंगे, और failure को कितनी precision से समझा पाएँगे। "Requirement कहती है appointment से 24 घंटे पहले; reminder 2 घंटे पहले आया" ऐसी bug report है जिस पर developer तुरंत काम कर सकता है।

तीन levels: business, stakeholder और system requirements

Requirements आम तौर पर तीन levels पर लिखी जाती हैं। हर level एक अलग सवाल का जवाब देता है, उसके owner अलग लोग होते हैं, और वह अपने ऊपर वाले level को detail में बदलता है: business goal उन कामों से पूरा होता है जो users को करने हैं, और users की ये ज़रूरतें उन चीज़ों से पूरी होती हैं जो system को करनी हैं।

नाम अलग-अलग होते हैं। Requirements engineering का standard ISO/IEC/IEEE 29148 business, stakeholder, system और software requirements के लिए अलग specifications बताता है; कई teams बीच वाले level को "user requirements" कहती हैं, और जब system सिर्फ़ software हो तो "software requirements"। Agile teams में ये levels मोटे तौर पर product goal, उसे पूरा करने वाली user stories, और हर story के नीचे acceptance criteria व technical notes के रूप में दिखते हैं।

  • Business requirements: organisation को product क्यों चाहिए — कोई goal जिसे पाना है या कोई problem जिसे हल करना है। इन्हें sponsor, management या business owner बताते हैं। उदाहरण: "छह महीनों में हमारे clinics के missed appointments में पाँचवें हिस्से की कमी लाना।"
  • Stakeholder (user) requirements: users और दूसरे stakeholders को क्या करना या हासिल करना है, उन्हीं के शब्दों में। इन्हें product owner या business analyst इकट्ठा करते हैं। उदाहरण: "एक patient के रूप में, मैं appointment से पहले reminder चाहता हूँ ताकि समय पर आ सकूँ या जल्दी cancel कर सकूँ।"
  • System (software) requirements: system को क्या करना है और कितनी अच्छी तरह, इतनी precision से कि उसे build और test किया जा सके। ये developers और architects के साथ तय होती हैं। उदाहरण: "System हर booked appointment से 24 घंटे पहले SMS reminder भेजेगा।" इसी level में functional और non-functional requirements और constraints आते हैं; अगला lesson इनका फ़र्क समझाता है।
तीन levels पर clinic appointment reminders: कम missed appointments का business goal, patient की reminder वाली need, और 24 घंटे पहले भेजा जाने वाला system का SMS।

हर level अपने ऊपर वाले level को detail में बदलता है और उस तक trace होना चाहिए

“Business requirements” परत पर: व्यापक goal“System (software) requirements” परत पर: Build और test करने लायक precise

  1. 1Business requirementsक्योंOrganisation का goal, sponsor या business owner बताते हैं: missed appointments में पाँचवें हिस्से की कमी

    Tester priorities तय करता है और देखता है कि goal नापा जा सके

  2. 2Stakeholder (user) requirementsUsers को क्या चाहिएUsers के अपने शब्दों में needs, product owner या analyst इकट्ठा करते हैं: reminder ताकि समय पर आऊँ या cancel करूँ

    Tester पूछता है कि product असली need पूरी करता है या नहीं (validation)

  3. 3System (software) requirementsSystem क्या करता हैPrecise व्यवहार, developers के साथ तय: हर booked appointment से 24 घंटे पहले SMS reminder

    Tester test conditions और expected results निकालता है

नाम अलग-अलग होते हैं: ISO/IEC/IEEE 29148 system और software requirements को भी अलग करता है, और agile teams अक्सर इन levels को product goal, user stories और acceptance criteria के रूप में दिखाती हैं।

Requirements कहाँ से आती हैं और किन forms में लिखी जाती हैं

हर requirement का एक source होता है — वह व्यक्ति, document या rule जिससे वह आई — और एक form — जिस तरह वह लिखी गई। आम sources हैं: customers और end users, product owner या business analyst, support tickets और usage data, laws और regulations, accessibility के लिए WCAG 2.2 जैसे standards, contracts, और उस मौजूदा system का व्यवहार जिसकी जगह नया system ले रहा है। Source पता हो, तो text अस्पष्ट होने पर आप जानते हैं कि किससे पूछना है।

ज़्यादातर teams requirements को एक साथ कई forms में रखती हैं। ISTQB Foundation syllabus requirement specifications, product backlog items, contracts और models को उन work products में गिनता है जिनकी जाँच static testing से हो सकती है, इसलिए इनमें से ज़्यादातर forms का review code बनने से पहले हो सकता है। इन्हें एक set की तरह पढ़ें: story बताती है कि user को क्या चाहिए, design screen दिखाता है, API contract fields तय करता है, और chat thread में लिया गया एक फ़ैसला तीनों को बदल सकता है।

  • Documents: business requirements documents, software requirements specifications, numbered "shall" statements। Precise और versioned, पर बदलने में धीमे।
  • Backlog items: tracker में epics, user stories और उनके acceptance criteria। जान-बूझकर छोटे; details बातचीत में तय होती हैं, इसलिए पक्का करें कि फ़ैसले item में वापस लिखे जाएँ।
  • Models: process flows, state diagrams, data models और OpenAPI file जैसे API contracts। ये वह दिखाते हैं जो prose छिपा लेता है: हर state, हर field, हर error response।
  • Prototypes और designs: wireframes, mock-ups और clickable prototypes। ये layout और flow दिखाते हैं; पूछें कि कौन-से हिस्से binding हैं और कौन-से सिर्फ़ sample content।
  • Examples और अनलिखी अपेक्षाएँ: worked examples, Given/When/Then scenarios, और वे बातें जो कोई नहीं लिखता क्योंकि वे obvious लगती हैं — saved data खोता नहीं, product कानून का पालन करता है, वह मिलते-जुलते products जैसा व्यवहार करता है। ये implicit requirements भी requirements ही हैं।

आज़माएँ: OpenAPI व्यूअर

Worked example: तीन levels पर appointment reminders

एक clinic chain अपने booking app में reminders जोड़ रही है। नीचे पहली refinement meeting के बाद का requirement set है, level के हिसाब से। हर statement का एक identifier है, ताकि सवाल, test cases और bug reports उसकी ओर इशारा कर सकें।

अगले section से पहले इसे दो बार पढ़ें। ऊपर से नीचे: क्या हर need के नीचे कुछ है जो उसे पूरा करता है? नीचे से ऊपर: क्या हर system requirement ऊपर की किसी need को पूरा करती है? दोनों में से एक check पास नहीं होता।

Feature: appointment reminders (clinic booking app)

Business
BR-1  Launch के छह महीनों के अंदर हमारे clinics के missed appointments में
      पाँचवें हिस्से की कमी लाना।

Stakeholder (user)
UR-1  एक patient के रूप में, मैं appointment से पहले reminder चाहता हूँ ताकि
      समय पर आ सकूँ या जल्दी cancel कर सकूँ।
UR-2  एक receptionist के रूप में, मैं देखना चाहता हूँ कि किन patients ने
      confirm किया, ताकि बाक़ी को call कर सकूँ।

System
SR-1  System हर booked appointment से 24 घंटे पहले SMS reminder भेजेगा,
      उस भाषा में जो patient ने चुनी (Arabic या English)।
SR-2  SMS में appointment confirm या cancel करने का link होगा।
SR-3  Patient के link से cancel करने पर slot 1 मिनट के अंदर फिर से
      booking के लिए उपलब्ध होगा।

आज़माएँ: Requirements → टेस्ट केस आज़माएँ: Requirements → टेस्ट सिनेरियो

Tester requirements क्यों पढ़ता है, उसी example पर

Test analysis वाले lesson में आपने test basis को evaluate किया और उससे test conditions निकालीं। Requirements आम तौर पर इस basis का सबसे बड़ा हिस्सा होती हैं, और उन्हें जल्दी पढ़ने से tester को नीचे दी गई हर चीज़ मिलती है — हर एक reminder वाले example में दिखती है।

  • Code से पहले कमियाँ: नीचे से ऊपर वाला check पास होता है — SR-1 और SR-2, UR-1 को पूरा करती हैं, और SR-3 slot को दूसरे patient के लिए खाली करके जल्दी cancel करने को उपयोगी बनाती है। ऊपर से नीचे वाला check पास नहीं होता: UR-2 को पूरा करने वाली कोई system requirement नहीं है, इसलिए कहीं नहीं लिखा कि confirmations कहाँ दिखेंगे या उन्हें कौन देखेगा। अभी उठाया जाए तो यह एक review comment है; system testing में मिले तो एक missing feature। इस तरह requirements का review करना static testing है, और ISTQB का principle "early testing saves time and money" यहाँ सीधे लागू होता है।
  • Expected results: requirement आम तौर पर test oracle होती है, यानी expected result का source। SR-3 सीधा result देती है: link से cancel करें, और slot 1 मिनट के अंदर फिर से booking के लिए उपलब्ध होना चाहिए।
  • ऐसे सवाल जिनका जवाब test खुद नहीं दे सकता: SR-1 नहीं बताती कि 24 घंटे से कम पहले book हुए appointment का क्या होगा, "24 घंटे पहले" किस time zone में गिना जाएगा, या patient ने कोई भाषा नहीं चुनी तो कौन-सी भाषा इस्तेमाल होगी। हर जवाब एक expected result बनता है।
  • Priorities: BR-1 बताती है कि feature क्यों है; जो reminder पहुँचे ही नहीं वह goal को नाकाम करता है, SMS में spelling mistake नहीं। यह एक छिपी need भी दिखाती है: goal तभी नापा जा सकता है जब system missed appointments दर्ज करे।
  • Verification के साथ validation भी: build को SR-1 से मिलाना verification है; यह पूछना कि 24 घंटे पहले का SMS सच में patients की ज़रूरत है या नहीं, validation है, जैसा verification और validation वाले lesson में देखा।
  • Traceable काम: test conditions अपना source साथ रखती हैं — "reminder 24 घंटे पहले भेजा गया (SR-1)", "appointment 3 घंटे पहले book हुआ (SR-1)", "cancel link slot खाली करता है (SR-3)" — ताकि coverage और failures हर requirement के हिसाब से report हो सकें।

आम गलतियाँ

  • सिर्फ़ formal specification को "requirements" मानना और user stories, designs, API contracts और chat में लिए गए फ़ैसलों को नज़रअंदाज़ करना — या उल्टा, story को उसकी details जोड़ने वाले design और contract खोले बिना टेस्ट करना।
  • सिर्फ़ system level की details पढ़ना और business goal छोड़ देना, जिससे पता नहीं चलता कि कौन-से failures सबसे ज़्यादा मायने रखते हैं या feature असल problem हल करता भी है या नहीं।
  • Requirements पढ़ने के लिए build का इंतज़ार करना, जिससे missing या contradictory requirement पकड़ने का सबसे सस्ता मौक़ा निकल जाता है।
  • Gaps को चुपचाप अपनी assumptions से भर देना। तब test आपके अंदाज़े को जाँचता है, तय किए गए व्यवहार को नहीं; पूछें, और जवाब requirement या story में लिखें।
  • पुराने version के against टेस्ट करना। Requirements बदलती हैं, इसलिए जिस story, specification या design से tests निकाल रहे हैं उसका version या date देखें।
  • यह मानना कि जो लिखा नहीं, वह required नहीं। अनलिखी अपेक्षाएँ — data न खोना, कानून का पालन, platform के साथ consistency — implicit requirements हैं, और product इन्हें तोड़े तो report किया जा सकता है।

QA का नज़रिया

असली team में tester requirements की बातचीत में जल्दी जुड़ता है: refinement में, product owner और developer के साथ "three amigos" sessions में, या specification के review में। Business और user levels के बारे में product owner या business analyst से पूछें ("इसकी ज़रूरत किसे है, और हमें कैसे पता चलेगा कि यह काम कर गया?"), और system level के बारे में developers या architects से ("Limits क्या हैं, और fail होने पर क्या होता है?")। Support team और product इस्तेमाल करने वाले लोग अक्सर असली user needs का सबसे अच्छा source होते हैं।

साथ-साथ दर्ज करते रहें। जिस requirement के against टेस्ट करते हैं उसका identifier और version लिखें, हर सवाल और उसका जवाब अपने दिमाग़ या private chat में नहीं, story या ticket में रखें, और test cases व bug reports को requirement IDs से link करें। जब requirements कम हों, अपनी समझ expected behaviours की छोटी list के रूप में लिखें और product owner से confirm करवाएँ; unconfirmed assumptions के against testing एक risk है, जिसे test report में लिखें।

अभ्यास

Requirement set को level, source और form के हिसाब से छाँटें

आपका काम

एक pharmacy chain अपने app में online prescription refill जोड़ रही है। नीचे के छह statements पढ़ें। हर एक का level (business, stakeholder या system) तय करें, उसका संभावित source और form बताएँ, और test design से पहले tester जो एक सवाल पूछेगा, वह लिखें।

फिर set को ऊपर से नीचे और नीचे से ऊपर जाँचें, और ऐसी need बताएँ जिसके नीचे कुछ नहीं है।

सामग्री
Feature: online prescription refill (pharmacy app)

R1  एक साल के अंदर refills के बारे में हमारी branches को आने वाली phone calls
    आधी करना।
R2  एक patient के रूप में, मैं अपने phone से refill request करना चाहता हूँ,
    ताकि branch को call न करना पड़े।
R3  एक pharmacist के रूप में, मैं अपनी branch की refill requests की एक list
    चाहता हूँ, pickup time के क्रम में, ताकि उन्हें क्रम से तैयार कर सकूँ।
R4  App सिर्फ़ वे prescriptions दिखाएगा जिनमें refills बाक़ी हैं और जो expire
    नहीं हुईं।
R5  Refill request का status "Ready for pickup" होने पर app push notification
    भेजेगा।
R6  Prescription data राष्ट्रीय health-data protection regulation के अनुसार
    store और process होगा।
चरण
  1. हर statement पर उसका level लिखें: business, stakeholder (user) या system।
  2. संभावित source (किससे या कहाँ से आया) और जिस form में लिखा है, वह नोट करें।
  3. हर system requirement को उस need से जोड़ें जिसे वह पूरा करती है, और हर need को business goal से।
  4. जिस need के नीचे कुछ नहीं है उसे चिह्नित करें, और हर statement के लिए एक सवाल लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Levels: R1 business requirement है (chain का goal, management से, आम तौर पर business case या project goal में लिखा)। R2 और R3 stakeholder (user) requirements हैं, patients और pharmacists से product owner के ज़रिए, user stories के रूप में। R4 और R5 system requirements हैं, product owner और developers से, specification में या R2 के acceptance criteria में। R6 system level का एक constraint है जिसका source एक regulation है; यहाँ इसका form एक "shall" statement है जो कानूनी text की ओर इशारा करता है।

Links: R4 और R5, R2 को पूरा करती हैं, और R2, R1 को। R3, R1 को सिर्फ़ indirectly पूरा करती है: refills pickup time पर तैयार हों तो patients के पास call करने की वजह कम होती है। R6 किसी user need को पूरा नहीं करती, और यह gap नहीं है: constraint अपने source तक trace होता है, यहाँ regulation तक, किसी story तक नहीं। Gap: system level पर R3 को कुछ पूरा नहीं करता — pharmacist की list, उसके क्रम या filters के बारे में कोई requirement नहीं है। इसे review comment के रूप में उठाएँ।

सवाल: R1 — आज calls कैसे गिनी जाती हैं, और अभी संख्या कितनी है? R2 — app किन platforms पर है, और क्या sign in ज़रूरी है? R3 — जिन requests का pickup time नहीं है वे किस क्रम में आएँगी, और क्या pharmacist दूसरी branches देख सकता है? R4 — आज expire होने वाली prescription दिखेगी या नहीं? R5 — patient ने notifications बंद किए हों तो क्या होगा? R6 — कौन-सा regulation और कौन-से articles लागू हैं, और refill data कितने समय तक रखा जा सकता है?

R4 और R5 से अभी test conditions बन सकती हैं; R3 तब तक टेस्ट नहीं हो सकती जब तक उसकी system requirement न हो, और R1 test case से नहीं, release के बाद नापी जाती है।

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

क्या user story एक requirement है?

हाँ। User story stakeholder (user) requirement का एक आम form है, पर अकेले उसमें details कम होती हैं; details उसके acceptance criteria, examples और उसके आसपास की बातचीत से आती हैं। User stories का अपना lesson इसी module में आगे है।

लिखी हुई requirements न हों तो किसके against टेस्ट करूँ?

जो team ने तय किया है उसके against: बातचीत, designs, मौजूदा system, मिलते-जुलते products, regulations और users की उचित अपेक्षाएँ। अपनी समझ expected behaviours की छोटी list में लिखें, product owner से confirm करवाएँ, और जो भी व्यवहार आपने unconfirmed assumption के against टेस्ट किया, उसे report करें।

क्या business requirements टेस्ट होती हैं?

आम तौर पर release से पहले test case से नहीं। इन्हें release के बाद नतीजे नापकर जाँचा जाता है, जो validation का एक रूप है। Release से पहले tester इनसे priorities तय करता है और जाँचता है कि system इन्हें नापने के लिए ज़रूरी data दर्ज करता है।

क्या requirement और specification एक ही हैं?

पूरी तरह नहीं। Requirement एक need या condition है; specification एक document है जो requirements इकट्ठा करता है, अक्सर context, definitions और designs जैसी दूसरी जानकारी के साथ। एक specification में आम तौर पर कई requirements होती हैं, और एक requirement story, design और contract में बँटी हो सकती है।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020Scrum की परिभाषा: उसकी ज़िम्मेदारियाँ, events और artifacts, Definition of Done सहित जिसे पूरा करने में टेस्टिंग मदद करती है।
  • Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009एजाइल टेस्टिंग क्वाड्रेंट और टेस्टर डिलीवरी टीम के भीतर कैसे काम करते हैं — "सही परत पर टेस्टिंग" का आधार।
टूल्स

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

Requirements → टेस्ट केस

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

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

OpenAPI व्यूअर

OpenAPI 3.x / Swagger 2.0 स्पेक (JSON या YAML) को ब्राउज़ करने लायक़ endpoint दस्तावेज़ों के रूप में दिखाएँ।

वेब

AI Requirement गैप एनालाइज़र

Mutqan AI से छूटी हुई requirements खोजें — error handling, permissions, edge conditions, non-functional ज़रूरतें।

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

और गहराई से

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

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

इस topic से पहले