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

रिक्वायरमेंट्स वैलिडेशन

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

Requirements validation यह पक्का करता है कि requirements वही बताती हैं जिसकी stakeholders को सच में ज़रूरत है: सही समस्या, सही users के लिए, सही rules के साथ, उन हालात में जहाँ product सच में इस्तेमाल होगा। यह verification और validation वाले lesson का validation सवाल, "क्या हम सही product बना रहे हैं?", ख़ुद requirements पर लागू करता है, इससे पहले कि उन पर design, code और tests बनें।

एक उदाहरण: "Customer order को shipped होने तक cancel कर सकता है।" वाक्य साफ़ और testable है, और requirements review उसे pass कर देता है। लेकिन validation session में warehouse lead बताता है कि orders shipping से एक दिन पहले तक pack हो जाते हैं, और pack हुए order को cancel करने का मतलब है उसे खोलकर सामान वापस shelves पर रखना। Business को असल में चाहिए "packing शुरू होने तक"। Wording में कोई गलती नहीं थी; rule ही गलत था।

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

हर अगली activity requirement की नकल करती है। Developers उसे बनाते हैं, testers उससे test conditions और expected results निकालते हैं, और tests pass हो जाते हैं। अगर requirement गलत ज़रूरत बताती है, तो पूरी chain आपस में सहमत रहती है और फिर भी गलत होती है, और यह gap तभी दिखता है जब असली users product से मिलते हैं: acceptance testing में, या production में complaints, workarounds और change requests के रूप में। ISTQB Foundation syllabus (CTFL v4.0) stakeholder feedback के बारे में यही बात कहता है: stakeholders की भागीदारी कम हो तो हो सकता है कि product उनकी चाहत से मेल न खाए, जिसका मतलब महँगा rework, छूटी deadlines और सबसे बुरी हालत में पूरा project fail होना हो सकता है।

Tester के लिए validation वह जगह है जहाँ expected result को अपना आधार मिलता है। बिना validate हुई requirement से लिया गया expected result किसी की लिखी हुई धारणा भर है। Validation में शामिल होकर आप rules के पीछे के कारण भी सुनते हैं, जिससे पता चलता है कि कौन-से scenarios और data सबसे ज़्यादा मायने रखते हैं, और आप ज़रूरत पर अपना शक तब उठा पाते हैं जब उसे बदलने की क़ीमत सिर्फ़ एक बातचीत है, rebuild नहीं।

Requirements validation क्या जाँचता है

Validation किसी requirement की तुलना उन लोगों की ज़रूरतों से करता है जिनके लिए वह है। ये लोग stakeholders हैं: end users, वह customer या business owner जिसने बदलाव माँगा, और हर वह व्यक्ति जिसके काम पर बदलाव असर डालता है, जैसे support, operations, finance और compliance। उनकी बहुत-सी जानकारी कहीं लिखी नहीं होती, इसलिए validation का मतलब हमेशा उनसे पूछना है और जहाँ हो सके, उन्हें काम करते देखना।

  • सही समस्या: क्या requirement वही समस्या हल करती है जो stakeholder के पास सच में है, या उसके बारे में किसी का अंदाज़ा?
  • सही users और हालात: इसे कौन इस्तेमाल करता है, किस device पर, किस समय, किस दबाव में? Head office के लिए ठीक rule closing time पर भीड़ वाले store में fail हो सकता है।
  • सही rules और numbers: क्या limits, fees, deadlines और permissions वही हैं जो business सच में लागू करता है, सरकारी छुट्टियों या ख़ास customer groups जैसे exceptions समेत?
  • कुछ छूटा नहीं: users किस चीज़ को इतना स्वाभाविक मानते हैं कि किसी ने उसे लिखा ही नहीं?
  • कोई छिपा टकराव नहीं: क्या दो stakeholders को अलग-अलग चीज़ें चाहिए? फ़ैसला product owner करता है; टकराव को code या test case में चुपचाप सुलझाना नहीं चाहिए।

Requirements review से validation कैसे अलग है

इस module में पहले आया requirements review verification है। वह requirement की तुलना अच्छी requirement के गुणों और उसके आस-पास के documents से करता है: क्या यह साफ़, पूरी, consistent, testable और feasible है? Validation requirement की तुलना stakeholders की ज़रूरतों से करता है। Reference point documents से हटकर लोगों और उनके काम पर आ जाता है। Review checklist पूछती ज़रूर है कि requirement सही है या नहीं, लेकिन मेज़ के चारों ओर बैठे reviewers सिर्फ़ शक दर्ज कर सकते हैं; validation उसे उन लोगों के साथ तय करता है जो जानते हैं।

दोनों आम तौर पर static testing हैं, क्योंकि कुछ चलता नहीं, और CTFL v4.0 syllabus कहता है कि static testing verification और validation दोनों के काम आ सकती है। भविष्य के users के साथ walkthrough भी एक review है। किसी activity को validation यह बनाता है कि requirement की तुलना किससे हो रही है, meeting का format नहीं।

दोनों अलग-अलग समस्याएँ पकड़ते हैं, इसलिए एक दूसरे की जगह नहीं ले सकता। कोई requirement review pass करके validation में fail हो सकती है, जैसे order cancel करने का rule: अच्छी तरह लिखा, testable और गलत। वह meeting में stakeholders को पसंद आकर review में fail भी हो सकती है, क्योंकि "जल्दी cancel" बोलने में ठीक लगा पर उसका कोई testable अर्थ नहीं।

  • Review पूछता है "क्या यह सही लिखा है?"; validation पूछता है "क्या यह सही ज़रूरत है?"
  • Review delivery team ख़ुद कर सकती है, जैसे checklist के साथ product owner, एक developer और एक tester; validation को ज़रूरत के असली मालिक या उनके सबसे नज़दीकी प्रतिनिधि चाहिए।
  • Review finding author के पास review comment बनकर लौटती है; validation finding product owner के लिए फ़ैसला है: requirement confirm करें, बदलें या नई जोड़ें।
  • कुछ टीमें और requirements engineering की किताबें "requirements validation" को requirements document की पूरी जाँच के लिए इस्तेमाल करती हैं, consistency और completeness समेत। यह शब्द सुनें तो पूछें कि कौन-सा सवाल मतलब है।

Validation की चार techniques

हर technique ज़रूरत को इतना ठोस बनाती है कि stakeholders उस पर प्रतिक्रिया दे सकें। Requirement किस बारे में है, उसके हिसाब से चुनें और मिलाकर इस्तेमाल करें: business rules examples से, screens और workflows prototypes से, और कई roles से गुज़रने वाले flows walkthroughs से सबसे अच्छे validate होते हैं। तैयार product का user acceptance testing भी validation करता है, लेकिन वह देर से आता है, जब requirement के गलत होने का पता चलना पहले ही महँगा पड़ता है; ये techniques तब काम करती हैं जब requirement अभी सिर्फ़ शब्द है।

  • Stakeholder review: requirement सिर्फ़ delivery team नहीं, ज़रूरत के मालिकों के साथ पढ़ी जाती है। Wording नहीं, उनके काम के बारे में पूछें: "पिछली बार आपने यह कैसे किया, step by step बताइए", "सबसे व्यस्त दिन क्या होता है?", "और किस पर असर पड़ता है?" Sign-off के लिए भेजे गए लंबे documents अक्सर बिना पढ़े approve हो जाते हैं, इसलिए एक बार में कुछ ही stories review करें, और जहाँ हो सके आमने-सामने बातचीत में।
  • Walkthrough: author, आम तौर पर product owner या business analyst, stakeholders को requirement से एक कहानी की तरह गुज़ारता है: "एक customer गुरुवार रात 21:30 पर order करता है, फिर…"। CTFL v4.0 में walkthrough वह review type है जिसका नेतृत्व author करता है; उसके उद्देश्यों में anomalies ढूँढने के साथ सहमति बनाना और participants को सिखाना भी शामिल है।
  • Prototype: paper sketch, wireframe या clickable mock-up, जिस पर stakeholders असली tasks आज़माते हैं और आप देखते हैं कि वे कहाँ अटकते हैं। यह वे ज़रूरतें सामने लाता है जिन्हें users पहले से बता नहीं पाते। पर यह सिर्फ़ सतह दिखाता है, उसके पीछे के rules नहीं, और चमकदार prototype लोगों को यह भ्रम दे सकता है कि product लगभग तैयार है।
  • Examples के रूप में acceptance tests: input और expected result वाले ठोस cases, जो coding से पहले लिखे जाते हैं और stakeholder उन्हें confirm करता है: "15:00 पर 17:00 वाले slot का order: accept। क्या यह सही है?" CTFL v4.0 में acceptance test-driven development (ATDD) का यही विचार है। किसी एक expected result पर असहमति गलत या छूटा rule उजागर करती है, और तय हुए examples बाद में acceptance tests बनकर चलते हैं।

आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर आज़माएँ: User Story → टेस्ट सिनेरियो

Worked example: click-and-collect rule का validation

एक grocery chain click and collect शुरू करती है। REQ-17 कहती है: "Customer अगले तीन दिनों में से किसी दिन 10:00 से 22:00 के बीच एक घंटे का collection slot चुनता है। Order उसके slot शुरू होने से कम से कम 2 घंटे पहले देना होगा। हर slot अधिकतम 20 orders लेता है।" Requirements review ने इसे pass किया: हर number साफ़ है और हर rule testable है। फिर product owner उन लोगों के साथ इसका validation करता है जिनका काम यह बदलती है, और tester हर session में शामिल होता है।

हर session में अलग technique इस्तेमाल हुई, और हर एक ने कुछ ऐसा पाया जो कोई review checklist नहीं पा सकती थी, क्योंकि REQ-17 साफ़, consistent और testable थी:

  • दो store managers के साथ stakeholder review: opening hours हर branch में अलग हैं और रमज़ान में बदल जाते हैं, इसलिए 10:00 से 22:00 के fixed slots ऐसे समय भी दिखाएँगे जब कुछ stores बंद होते हैं। Slots को हर branch के opening hours के हिसाब से चलना होगा।
  • Orders तैयार करने वाले pickers के साथ walkthrough: भीड़ वाली गुरुवार शाम से गुज़रने पर दिखता है कि 20 छोटे orders और 60 items वाले 20 orders को pick करने में बहुत अलग समय लगता है। असली limit picking capacity है, orders की गिनती नहीं।
  • पाँच customers के साथ prototype session: clickable mock-up में तीन ने slot चुन लिया और बाद में देखा कि वह उनकी चाही branch का नहीं था। Slots दिखने से पहले branch चुनी जानी चाहिए और दिखती रहनी चाहिए।
  • Business owner के साथ acceptance examples: "15:00 पर 17:00 वाले slot का order: accept" confirm हुआ। "07:30 पर 10:00 वाले slot का order: accept" confirm नहीं हुआ: picking 09:00 पर शुरू होती है, तो इस order को सिर्फ़ एक घंटे की picking मिलेगी। 2 घंटे का मतलब picking time है, एक ऐसा rule जिसे किसी ने लिखा ही नहीं था।
REQ-17 validation log
V1  Stakeholder review · store managers
    गलत rule: slots हर branch के opening hours को नज़रअंदाज़ करते हैं।
V2  Walkthrough · pickers
    गलत rule: limit orders गिनती है, जबकि picking time items पर निर्भर है।
V3  Prototype · 5 customers
    छूटी ज़रूरत: 5 में से 3 ने branch देखे बिना slot चुन लिया।
V4  Acceptance examples · business owner
    छूटा rule: "2 घंटे" का मतलब picking time है, घड़ी का समय नहीं।

Product owner: V1, V3 और V4 sprint से पहले REQ-17 बदलते हैं। Operations के
picking time का अनुमान देने के बाद V2 अलग story बनेगी। REQ-17 v2 फिर
review से गुज़रती है, फिर V1, V3 और V4 उन्हीं लोगों से confirm होते हैं
जिन्होंने उन्हें उठाया था।
Click-and-collect rule REQ-17 का validation: review pass होने के बाद ज़रूरत के मालिक उसे अपने काम से परखते हैं, product owner हर finding पर फ़ैसला करता है, और बदला हुआ rule फिर review में जाता है।
  1. 1Requirement का reviewVerificationसाफ़, consistent और testableपास
  2. 2ज़रूरत के मालिक पहचानेंStore managers, pickers, customers, business owner
  3. 3ज़रूरत को ठोस बनाएँउनके काम के सवाल, walkthrough, clickable prototype, acceptance examples
  4. 4Sessions चलाएँदेखें, "क्यों" पूछें, हर अनपेक्षित बात नोट करें
  5. 5Findings दर्ज करेंV1 से V4: दो गलत rules, एक छूटी ज़रूरत, एक छूटा rule
  6. 6Product owner फ़ैसला करता हैV1, V3, V4 से REQ-17 बदलता है; V2 नई story बनती है

चरण 2–6 के दौरान Requirements validation: क्या यह सही ज़रूरत है?

चरण 1 पर वापस REQ-17 v2: फिर से review, फिर वही लोग बदलाव confirm करें

इसके बाद:तय हुई requirement test design के लिए test basis बनती है

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

आम गलतियाँ

  • Requirements review pass होने को इस बात का सबूत मानना कि requirement सही है। Review जाँचता है कि वह कैसे लिखी है; वह क्या कहती है, यह सिर्फ़ ज़रूरत के मालिक confirm कर सकते हैं।
  • सिर्फ़ proxies से validation करना, जैसे product owner, कोई manager या users के काम का अंदाज़ा लगाती टीम, बजाय उन users, operators और support staff के जो असल में काम करते हैं।
  • "क्या यह ठीक है?" पूछना और जल्दी में मिली "हाँ" को validation मान लेना। असली हालात और ठोस examples के बारे में पूछें; लोग ऊपर-ऊपर से पढ़ा text भी approve कर देते हैं।
  • Validation को user acceptance testing तक टाल देना, जब गलत requirement design, build और test हो चुकी होती है।
  • चमकदार prototype दिखाकर उसे पीछे के business rules का validation मान लेना। Prototype वह validate करता है जो users देखते और करते हैं; rules के लिए expected results वाले examples चाहिए।
  • Stakeholders के बीच टकराव को test case या bug report में ख़ुद सुलझा देना। उसे दर्ज करें और product owner को फ़ैसला करने दें।

QA का नज़रिया

ज़्यादातर टीमों में validation का owner product owner या business analyst होता है; tester का काम इसे जल्दी करवाना और ठोस बनाना है। Refinement में, जब किसी story का rule किसी धारणा पर टिका हो, तो पूछें कि उसे इस्तेमाल करने वालों से किसने confirm किया। Rules को expected results वाले examples में बदलने की पेशकश करें, और prototype sessions व walkthroughs में observer के रूप में शामिल होने के लिए कहें: वहाँ आप वे exceptions, peak times और workarounds सुनेंगे जिनसे सबसे अच्छे test scenarios बनते हैं।

Validation findings को review comments और defects से अलग दर्ज करें: क्या मिला, किस technique से, किसने उठाया और product owner ने क्या तय किया। जो finding requirement बदलती है वह change है, code का defect नहीं, और जिस rule को अब तक कोई validate नहीं कर पाया वह test plan में नाम लेने लायक risk है। अगर test execution के दौरान पता चले कि कोई rule असली इस्तेमाल में फ़िट नहीं बैठता, तो उसे अपने evidence के साथ product owner के लिए सवाल बनाकर उठाएँ, failed test बनाकर नहीं और expected result चुपचाप बदलकर भी नहीं।

अभ्यास

Library loan rule का validation plan और findings की छँटाई

आपका काम

एक university library app में नीचे दी गई requirement REQ-8 है। उसके review और validation के दौरान टीम ने पाँच findings दर्ज कीं। Plan करें कि requirement को किसके साथ validate करना चाहिए, फिर findings की छँटाई करें।

हर finding के लिए तय करें कि वह verification finding है (requirement की तुलना quality criteria या दूसरे documents से) या validation finding (requirement की तुलना किसी की असली ज़रूरत से), और बताएँ कि उस पर कौन कार्रवाई करेगा। आख़िर में तीन examples लिखें जिन्हें head librarian confirm करे।

सामग्री
REQ-8  Library loans
Student एक समय में अधिकतम 5 किताबें 14 दिनों के लिए ले सकता है। Loan दो
बार renew हो सकता है, हर बार 14 दिनों के लिए, जब तक किसी दूसरे student ने
किताब reserve न की हो। देर से लौटाई गई किताब पर 1 SAR प्रति दिन fine लगता
है, जो circulation desk पर भरा जाता है।

Review और validation में दर्ज findings
F1  "14 दिनों के लिए renew" यह नहीं बताता कि गिनती due date से है
    या renew वाले दिन से।
F2  Head librarian: postgraduate students पूरे semester के लिए किताबें लेते हैं।
F3  University की fines policy 1 SAR नहीं, 2 SAR प्रति दिन कहती है।
F4  Paper prototype: students ने home screen पर अपनी due dates ढूँढीं और
    किताब लौटाने की तारीख से पहले reminder माँगा।
F5  Finance office: fines अब cash में नहीं भरे जाते; वे student account
    में जुड़ते हैं।
चरण
  1. REQ-8 के हर हिस्से के मालिक stakeholders लिखें: borrowing, renewals और fines।
  2. हर finding के लिए बताएँ कि REQ-8 की तुलना किससे हुई।
  3. हर finding को verification या validation में बाँटें, और बताएँ कि उस पर कौन कार्रवाई करेगा।
  4. Head librarian के confirm करने के लिए expected results वाले तीन examples लिखें, हर एक ऐसे rule पर जो अब भी गलत हो सकता है।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Stakeholders: undergraduate और postgraduate students (borrowing, renewals), circulation desk staff और head librarian (loan rules, reservations), और finance office (fines)।

F1: verification। REQ-8 को quality criteria से मिलाकर पढ़ने पर वह ambiguous निकलती है; author उसे दोबारा लिखता है, पर जवाब ख़ुद head librarian से आना चाहिए।

F2: validation। REQ-8 की तुलना postgraduate students की ज़रूरतों से हुई, जैसा head librarian उन्हें जानते हैं: अलग ज़रूरत वाला user group। Product owner तय करता है कि loan period student के प्रकार पर निर्भर हो या नहीं।

F3: verification। REQ-8 की तुलना एक दूसरे document, university की fines policy, से हुई, और दोनों एक-दूसरे के उलट हैं। पर कौन-सी रक़म सही है यह fines policy के मालिकों का सवाल है, इसलिए finding validation पर ख़त्म होती है; फिर product owner REQ-8 ठीक करता है।

F4: validation, prototype के ज़रिए। REQ-8 की तुलना इस बात से हुई कि paper prototype पर students ने क्या किया और क्या माँगा। छूटी ज़रूरत: home screen पर due dates दिखाएँ और reminder भेजें। Product owner के लिए change या नई story।

F5: validation, stakeholder review के ज़रिए। REQ-8 की तुलना finance office के आज के काम करने के तरीक़े से हुई: rule ऐसी payment process बताता है जो university अब इस्तेमाल नहीं करती। Product owner finance office के साथ REQ-8 बदलता है।

Confirm करने के examples: "5 किताबें लिए हुए student छठी किताब लेने की कोशिश करता है: मना।" "10 मार्च को due loan 3 मार्च को renew होता है: नई due date 24 मार्च।" "किताब 3 दिन देर से लौटी और उनमें से एक दिन library बंद थी: 2 दिन का fine।" हर example को या तो "हाँ" मिलता है या वह कोई ऐसा rule उजागर करता है जिसे लिखना ज़रूरी है।

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

क्या requirements validation और user acceptance testing एक ही हैं?

नहीं। Requirements validation requirements की जाँच करता है, आम तौर पर code बनने से पहले, stakeholder reviews, walkthroughs, prototypes और तय किए गए examples के ज़रिए। User acceptance testing तैयार product की जाँच उसके users या उनके प्रतिनिधियों के साथ करता है। UAT भी गलत requirement पकड़ सकता है, पर तब उसे ठीक करने का मतलब design, code और tests का rework है।

Requirements validation की ज़िम्मेदारी किसकी है?

आम तौर पर product owner या business analyst की, जो फ़ैसले भी लेते हैं; stakeholders जानकारी देते हैं। Testers expected results वाले examples, असली हालात और edge cases के सवाल, और sessions से अपने observations देते हैं। जिन टीमों में business analyst नहीं होता, वहाँ अक्सर tester sessions organise करने में भी मदद करता है।

क्या agile टीमें भी requirements validate करती हैं?

हाँ, एक बार के sign-off की जगह छोटे और बार-बार के steps में। Stories refinement में examples और prototypes से validate होती हैं, और 2020 Scrum Guide में बताए गए Sprint Review में Scrum Team sprint के नतीजे key stakeholders के सामने रखती है, सब मिलकर देखते हैं कि क्या पूरा हुआ और क्या बदला, और Product Backlog adjust हो सकता है। हर काम करता increment यह जाँचने का मौका है कि requirements अब भी सही ज़रूरत बताती हैं।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • Certified Tester Acceptance Testing (CT-AcT)ISTQB · 2019acceptance testing पर ISTQB का specialist पाठ्यक्रम: user, contractual और regulatory acceptance testing, alpha व beta testing, और टेस्टर product owners व business analysts के साथ कैसे काम करते हैं।
  • The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020Scrum की परिभाषा: उसकी ज़िम्मेदारियाँ, events और artifacts, Definition of Done सहित जिसे पूरा करने में टेस्टिंग मदद करती है।
टूल्स

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

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

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

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

और गहराई से

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

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

इस topic से पहले