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

फ़ंक्शनल और नॉन-फ़ंक्शनल रिक्वायरमेंट्स

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

Functional requirement बताता है कि system को क्या करना है: ऐसा व्यवहार जिसे आप trigger करके देख सकें, जैसे "जब customer order देता है, तो system order number दिखाता है और confirmation email भेजता है।" Non-functional requirement बताता है कि वह यह काम कितनी अच्छी तरह और किन conditions में करे: "जब 500 customers एक साथ checkout कर रहे हों, तब 95% orders में confirmation page 2 seconds के अंदर दिखे।"

यह बँटवारा testing fundamentals module की functional और non-functional testing जैसा ही है। कुछ teams non-functional requirements को quality requirements या NFRs कहती हैं।

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

Non-functional requirements ही सबसे ज़्यादा छूटते हैं, या एक विशेषण बनकर रह जाते हैं: "fast", "secure", "easy to use"। कोई feature ठीक वही कर सकता है जो उसके functional requirements कहते हैं, फिर भी users के लिए fail हो सकता है, क्योंकि उसमें 40 seconds लगते हैं, एक customer को दूसरे customer का data दिखता है, या screen reader से उसे इस्तेमाल नहीं किया जा सकता। ऐसी problems अक्सर देर से सामने आती हैं, जब fix का मतलब architecture बदलना हो सकता है।

Tester के लिए कोई requirement तभी काम का test basis है जब उससे expected result लिखा जा सके। "Page fast होना चाहिए" से कोई result नहीं मिलता। Development शुरू होने से पहले non-functional requirements को numbers में लिखवाना ही उन्हें testable बनाता है।

Functional requirements: system क्या करता है

Functional requirement ऐसा व्यवहार बताता है जिसे user या कोई दूसरा system देख सके: क्या अंदर जाता है, कौन-से rules लागू होते हैं, और क्या बाहर आता है या बदलता है। अगर आप कोई action करके और result को expected outcome से मिलाकर इसे check कर सकते हैं, तो यह लगभग निश्चित रूप से functional है। हर functional requirement आम तौर पर किसी एक feature या story का हिस्सा होता है। किसी online shop में:

  • Validation: postcode field सिर्फ़ delivery countries के formats स्वीकार करता है।
  • Business rules: 300 SAR या उससे ज़्यादा के orders की delivery free है (अगला पाठ business rules पर है)।
  • Workflows: warehouse के parcel scan करने पर order "Paid" से "Shipped" में जाता है।
  • Outputs और interfaces: confirmation emails, invoices, और payment provider को call।
  • Permissions और errors: order history सिर्फ़ account owner देखता है; declined payment पर basket वैसा ही रहता है।

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

Non-functional requirements: कितनी अच्छी तरह

Non-functional requirement कोई नया व्यवहार नहीं जोड़ता; वह तय करता है कि व्यवहार की quality कितनी होनी चाहिए। Software quality वाले पाठ के ISO/IEC 25010:2023 की भाषा में, functional requirements functional suitability के अंतर्गत आते हैं और non-functional requirements बाक़ी आठ characteristics के। कुछ teams constraints, जैसे कोई तय database या regulation, अलग से list करती हैं।

कई non-functional requirements कई features पर एक साथ लागू होते हैं: response-time target या WCAG conformance हर page पर लागू होता है, इसलिए उसकी जगह quality requirements की shared list या Definition of Done है, किसी एक story में नहीं। इन्हें तय conditions में कोई value measure करके जाँचा जाता है, अक्सर specialised tests और tools से; कुछ, जैसे monthly availability, सिर्फ़ production में monitoring से। उसी shop के उदाहरण:

  • Performance efficiency: 200 concurrent users के साथ search 95th percentile पर 1.5 s के अंदर जवाब देता है।
  • Security: 15 minutes तक कोई activity न होने पर session ख़त्म हो जाता है।
  • Reliability: announced maintenance को छोड़कर, checkout हर महीने 99.9% समय उपलब्ध रहता है।
  • Interaction capability: checkout pages WCAG 2.2 level AA के अनुरूप हैं।
  • Compatibility, जिसे ISO/IEC 25010 flexibility के अंतर्गत रखता है: shop Chrome, Safari, Firefox और Edge के latest दो major versions में काम करता है।
Online shop: functional requirement बताता है कि system क्या करता है और तय output से जाँचा जाता है; non-functional बताता है कितनी अच्छी तरह, तय conditions में measured target के रूप में।

Functional requirement

System को क्या करना है

उदाहरण:
Order देने पर order number दिखता है और confirmation email जाता है
ISO/IEC 25010 characteristic:
Functional suitability
दायरा:
आम तौर पर एक feature या story
Expected result:
तय output, message या state change
कैसे जाँचा जाता है:
Functional tests: action करें, result मिलाएँ

Non-functional requirement

वह कितनी अच्छी तरह और किन conditions में करे

उदाहरण:
500 customers एक साथ checkout करें, तब भी 95% orders में confirmation page 2 s के अंदर दिखे
ISO/IEC 25010 characteristic:
बाक़ी आठ: performance efficiency, security, reliability, interaction capability…
दायरा:
अक्सर कई features: shared list या Definition of Done में रखा जाता है
Expected result:
Target से तुलना की गई measured value
कैसे जाँचा जाता है:
Specialised tests और tools; कुछ सिर्फ़ production monitoring से

सीमा हमेशा साफ़ नहीं होती: account lockout जैसा rule security के लिए है, पर व्यवहार के रूप में लिखा और test किया जाता है।

Non-functional requirements को measurable बनाना

Non-functional testing वाले पाठ की तरह, measurable requirement एक measure, unit वाला target, वे conditions जिन पर वह लागू होता है, और measurement method बताता है। Requirement के रूप में लिखे जाने पर उसमें तीन चीज़ें और होती हैं: वह ISO/IEC 25010 characteristic जिसका वह हिस्सा है, ताकि team देख सके कि कौन-सी qualities cover हैं और कौन-सी अभी छूटी हैं; एक ID, ताकि test cases और results उससे trace हो सकें; और यह record कि numbers किसने तय किए। कुछ requirements methods requirement के इस measurable हिस्से को fit criterion कहते हैं।

Numbers business के फ़ैसले हैं: tester propose करता है और पूछता है, product owner फ़ैसला करता है, और फ़ैसला requirement के साथ record होता है। कोई number propose करने से पहले tester यह भी जाँचता है कि वह पूरा हो भी सकता है या नहीं, जैसा नीचे का worked example दिखाता है।

आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र

Worked example: homework portal का draft

एक school homework portal बनवा रहा है, और development शुरू होने से पहले tester को यह draft मिलता है। हर line के लिए तय करें कि वह functional है या non-functional, और क्या आप उसे अभी के रूप में test कर सकते हैं।

Homework portal: draft requirements
H1  Student हर assignment के लिए deadline तक एक file upload कर सकता है।
H2  Accepted formats PDF और DOCX हैं, अधिकतम 20 MB।
H3  Deadline के बाद Upload button disabled होता है और "Submission closed" दिखाता है।
H4  Submission सिर्फ़ student और course teachers खोल सकते हैं।
H5  Uploads fast होने चाहिए।
H6  Portal exam weeks में उपलब्ध होना चाहिए।
H7  Portal phones पर काम करना चाहिए।

Worked example, आगे: छाँटना और दोबारा लिखना

H1 से H3 functional हैं: हर एक में action और observable result है। H4 सीमा पर है: यह security (confidentiality) की रक्षा करता है, पर व्यवहार के रूप में लिखा है और functional requirement की तरह test होता है: किसी दूसरे student का submission खोलें और refusal की उम्मीद करें। Teams इसे किसी भी heading में रखती हैं; ज़रूरी यह है कि यह अभी के रूप में testable है। H5 से H7 non-functional हैं और अभी के रूप में testable नहीं। Tester values propose करता है, जिन्हें school confirm करेगा:

  • H5, performance efficiency: जब 300 students एक साथ upload करें, तब 10 Mbit/s connection से भेजी गई 20 MB file 95% uploads में Upload दबाने के 30 s के अंदर confirm हो। सिर्फ़ transfer में ही कम से कम 16 s लगते हैं, इसलिए इससे कम का target कभी पूरा नहीं हो सकता।
  • H6, reliability: exam weeks में 06:00 से 24:00 तक portal 99.5% समय उपलब्ध रहे, जिसे हर minute एक external check से measure किया जाए।
  • H7, compatibility (ISO/IEC 25010 में flexibility): upload और download, Android पर Chrome और iOS पर Safari के latest दो major versions में काम करें।
  • छूटा हुआ: accessibility target, और files कितने समय रखी जाएँगी।

आज़माएँ: टेस्ट सिनेरियो जनरेटर आज़माएँ: AI Requirement गैप एनालाइज़र

आम गलतियाँ

  • सिर्फ़ वही test करना जो user stories में लिखा है, और performance, security, accessibility या compatibility के बारे में कभी न पूछना।
  • हर page पर लागू होने वाले requirement, जैसे WCAG conformance, को किसी एक story में डाल देना, जहाँ वह एक बार check होकर भुला दिया जाता है।
  • Conditions के बिना number लिखना: 2 seconds किस operation के लिए, किस load पर, किस percentile पर?
  • Target propose करना बिना यह जाँचे कि वह पूरा हो सकता है: 10 Mbit/s पर 20 MB का upload 16 s से कम में पूरा नहीं हो सकता, code कैसा भी हो।
  • ख़ुद target गढ़कर उसके against ऐसे test करना जैसे वह agreed हो, बजाय उसे product owner को propose करने के।

QA का नज़रिया

Non-functional सवाल backlog refinement और requirements review में पूछें, release से पहले वाले हफ़्ते में नहीं। हर feature के लिए quality characteristics को checklist की तरह देखें: क्या यह लागू होती है, और target क्या है? हर जवाब को ID वाले requirement के रूप में record करें, ताकि tests और results उससे trace हो सकें।

Non-functional testing की planning जल्दी करें: load test को production जैसा environment और realistic data चाहिए, और availability को monitoring। Test report में measured value को target और conditions के साथ लिखें: "200 users पर 95th percentile 1.8 s, जबकि target 1.5 s है" ऐसी जानकारी है जिस पर team काम कर सकती है।

अभ्यास

Table booking app के requirements classify करें

आपका काम

एक restaurant chain table booking app बना रही है। नीचे दिए हर requirement को functional या non-functional में classify करें, हर एक की ISO/IEC 25010 characteristic बताएँ, और बताएँ कि किन्हें आप अभी के रूप में test कर सकते हैं। एक untestable requirement को product owner के लिए proposal के रूप में दोबारा लिखें। फिर product owner के लिए दो सवाल लिखें कि list में क्या छूट गया है।

सामग्री
B1  Guest 1 से 8 लोगों के लिए table book कर सकता है, अधिकतम 30 दिन पहले तक।
B2  हर नई booking पर restaurant को SMS मिलता है।
B3  Booking confirmation जल्दी दिखना चाहिए।
B4  App secure होना चाहिए।
B5  App को Ramadan की शाम की भीड़ संभालनी चाहिए।
चरण
  1. हर requirement पर F या NF लिखें, साथ में उसकी ISO/IEC 25010 characteristic।
  2. वह expected result लिखें जिसे test check करेगा; जहाँ न लिख सकें, requirement को untestable mark करें, और उनमें से एक को rewrite करें।
  3. जो छूटा है उसे सवालों के रूप में लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

B1 और B2 functional (functional suitability) हैं, और दोनों का ऐसा expected result है जिसे test check कर सकता है। B1: 8 लोगों की 30 दिन पहले की booking स्वीकार होती है; 9 लोगों की, या 31 दिन पहले की booking अस्वीकार होती है। इसकी boundary values test करने लायक हैं: 0, 1, 8 और 9 लोग, और 30 व 31 दिन पहले। B2: हर नई booking पर restaurant को ठीक एक SMS मिलता है।

B3, B4 और B5 non-functional हैं और अभी के रूप में testable नहीं। B3 performance efficiency (time behaviour) है। B4 security है, और इतना broad है कि इसे कई specific requirements में बाँटना होगा। B5 performance efficiency (capacity) है, क्योंकि यह उस load के बारे में है जो app को संभालना है; शाम का असली peak पिछले साल के data से आना चाहिए।

एक rewrite, यहाँ B3: "Guest के Confirm दबाने के बाद, 150 bookings प्रति minute पर, 95% bookings में confirmation 2 s के अंदर दिखे।" इसे ID और उसकी characteristic के साथ record करें, और values को तब तक proposed mark करें जब तक product owner उन्हें confirm न करे।

सवाल: SMS न भेजा जा सके तो क्या होगा? कौन-सा accessibility standard लागू है?

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

Security requirement functional है या non-functional?

Security एक non-functional quality characteristic है, लेकिन कई security ज़रूरतें व्यवहार के रूप में लिखी जाती हैं, जैसे 5 failed attempts के बाद account lock करना, और functional requirements की तरह test होती हैं। Label से ज़्यादा ज़रूरी है व्यवहार और उसके पीछे के risk, दोनों को test करना।

Non-functional requirement के numbers कौन तय करता है?

Product owner या business stakeholders, architects, operations और मौजूदा usage data की मदद से। Tester numbers माँगता है, न हों तो values propose करता है, और ऐसे targets की ओर ध्यान दिलाता है जिन्हें measure या पूरा नहीं किया जा सकता।

Agile team में non-functional requirements कहाँ लिखे जाते हैं?

किसी एक story का requirement उसके acceptance criteria में जाता है। जो हर story पर लागू हो, जैसे WCAG conformance, वह आम तौर पर Definition of Done या quality requirements की shared list में जाता है।

इनमें से non-functional requirement कौन-सा है: सिस्टम में search करना, reports बनाना और print करना, सिस्टम की response speed और security, या pages के बीच navigation?

Response speed और security। Search करना, reports बनाना और print करना और pages के बीच जाना ऐसे काम हैं जो सिस्टम करता है, इसलिए ये functional requirements हैं। Speed और security बताते हैं कि ये काम कितनी अच्छी तरह होने चाहिए, और numbers जुड़ने पर testable बनते हैं, जैसे 95% searches का जवाब 2 seconds में।

Non-functional requirements के आम उदाहरण क्या हैं?

Performance और capacity (response time, एक साथ कितने users सिस्टम सँभाले), reliability और failure के बाद recovery, usability (इस्तेमाल में आसानी), compatibility और दूसरे सिस्टम के साथ interoperability, security, maintainability और portability। Reports बनाना और print करना इनमें नहीं आता: वह एक function है, यानी functional requirement।

संदर्भ

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

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

Requirements → टेस्ट केस

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

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

टेस्ट सिनेरियो जनरेटर

किसी फ़ीचर के लिए functional, negative, security, usability और compatibility पहलुओं को कवर करने वाले उच्च-स्तरीय टेस्ट सिनेरियो जनरेट करें।

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

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

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

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

और गहराई से

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

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