मॉड्यूल 3 · Testing fundamentals

फ़ंक्शनल टेस्टिंग

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

Functional testing यह जाँचती है कि system क्या करता है: उसे कौन-से functions करने चाहिए और वे क्या results देते हैं। ISTQB के अनुसार इसका मुख्य लक्ष्य तीन चीज़ें जाँचना है: functional completeness, functional correctness और functional appropriateness। अगर requirement कहती है कि promo code WELCOME10 cart के items पर 10% छूट देता है, तो functional test 200.00 SAR के items पर code लगाकर जाँचता है कि discount ठीक 20.00 SAR है।

इसके expected results code से नहीं, बल्कि requirements, user stories और acceptance criteria से आते हैं, इसलिए functional tests आम तौर पर black-box तरीके से design होते हैं। Feature कितना तेज़, सुरक्षित या इस्तेमाल में आसान है, यह non-functional testing का विषय है, जो अगला पाठ है।

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

लोग अपना काम करने के लिए software इस्तेमाल करते हैं: bill भरना, appointment book करना। जब कोई function ग़ायब हो, गलत result दे या काम को बेवजह मुश्किल बना दे, तो users तुरंत नोटिस करते हैं, और पैसे या personal data के मामले में गलत result नुकसान करता है, भले ही कुछ crash न हो। तेज़ और सुरक्षित checkout जो गलत total दिखाए, फिर भी failure है।

Tester के लिए functional testing रोज़ के काम का केंद्र है। यह वह आदत भी बनाती है जिस पर बाक़ी सब टिका है: system क्या करता है यह देखने से पहले test basis से expected result निकालना।

हर test level पर लागू होने वाला test type

ISTQB tests को level और type, दोनों के हिसाब से बाँटता है। Functional testing एक test type है: यह पूछती है कि test object को क्या करना चाहिए, जबकि non-functional testing पूछती है कि वह कितना अच्छा व्यवहार करता है। हर test type हर test level पर लागू हो सकता है, इसलिए पिछले पाठों के हर level के अपने functional tests होते हैं; बस test object बड़ा होता जाता है।

  • Component: discount function 200.00 के subtotal और code WELCOME10 के लिए 20.00 लौटाता है।
  • Integration: cart service payment service को discount के बाद वाला total भेजती है, original total नहीं।
  • System: browser में checkout पर code लगाने से discount की line और नया total जुड़ता है।
  • Acceptance और end-to-end: customer code लगाता है, payment करता है और ऐसा confirmation पाता है जिसमें discount के बाद की राशि दिखती है।

Completeness, correctness और appropriateness

ये तीनों ISO/IEC 25010 में functional suitability की sub-characteristics हैं, जिन्हें आपने software quality वाले पाठ में देखा। इनमें stated needs आती हैं, जो requirements में लिखी होती हैं, और implied needs भी, जिन्हें किसी ने नहीं लिखा। हर लक्ष्य एक ही feature से अलग सवाल पूछने का तरीका देता है:

  • Functional completeness: क्या functions सभी तय tasks और user objectives को cover करते हैं? ऐसा promo-code feature जिसमें लगाया गया code हटाने का कोई तरीका नहीं, अधूरा है, बाक़ी हिस्सा कितना भी अच्छा चले।
  • Functional correctness: क्या functions सटीक results देते हैं? Calculations, stored data, state changes और messages को rule से मिलाकर जाँचें। 249.95 SAR पर 10% discount उसी तरह round होना चाहिए जैसा business ने तय किया है, न कि जैसा code संयोग से round कर दे।
  • Functional appropriateness: क्या functions users को बिना फ़ालतू steps के उनके tasks पूरे करने में मदद करते हैं? अगर code field सिर्फ़ cart में है, तो payment step पर पहुँचे customer को उसे इस्तेमाल करने के लिए पीछे जाना पड़ता है: function मौजूद और सही है, पर appropriate नहीं। Supported task को करना कितना आसान है, यह usability है (ISO/IEC 25010:2023 में इसे interaction capability कहा गया है), एक non-functional सवाल।

Test basis: requirements और user stories

Functional tests आम तौर पर black-box तरीके से design होते हैं: आप उन्हें test object के बाहर के documents से निकालते हैं, उसका code पढ़े बिना। कुछ teams "functional" और "black-box" को एक ही मानती हैं, लेकिन ISTQB इन्हें अलग रखता है: functional बताता है कि क्या जाँचा जाता है, black-box बताता है कि tests कहाँ से आते हैं। Discount function के लिए developer का unit test functional है, भले ही वह code खोलकर लिखा गया हो।

Functional tests के लिए आम test basis:

  • Requirements, specifications और business rules, जैसे "300.00 SAR या उससे ज़्यादा के orders की delivery free है"।
  • User stories और उनके acceptance criteria, जो agile teams में मुख्य basis हैं।
  • Use cases, ऐसे flows के लिए जिनमें alternatives और exceptions हों।
  • API contracts, regulations, user manuals या replace होने वाला system, जब team मान ले कि ये लागू होते हैं।

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

Functional check की बनावट

हर functional check के हिस्से एक जैसे होते हैं: वह state जिसमें system शुरू होता है, एक input या action, test basis का rule, और वह expected output जो rule बताता है। मान लीजिए cart में 200.00 SAR के items हैं और 15.00 SAR delivery fee है, और criterion है "WELCOME10 item subtotal पर 10% छूट देता है; delivery fee पर छूट नहीं"। Input WELCOME10 के लिए rule के हिसाब से discount 20.00 SAR और total 195.00 SAR होना चाहिए।

Promo code का एक functional check: state, input और rule AC-1 से 20.00 SAR discount और 195.00 SAR total तय होता है, जो run से पहले लिखा जाता है और फिर actual output से मिलाया जाता है।

Worked example का check F1

भाग 1:state     items 200.00 SAR + delivery fee 15.00 SAR
भाग 2:input     promo code WELCOME10, then Apply
भाग 3:rule      AC-1: 10% off the item subtotal; fee not discounted
भाग 4:expected  discount 20.00 SAR, total 195.00 SAR
भाग 5:actual    discount 20.00 SAR, total 195.00 SAR
  1. 1StatePrecondition: input से पहले cart में क्या है।
  2. 2InputTester क्या डालता है या क्या करता है।
  3. 3Test basis का ruleAcceptance criterion AC-1 result तय करता है, और check उसी से trace होता है।
  4. 4Expected outputRun से पहले निकाला गया: 200.00 का 10% है 20.00, और 215.00 में से 20.00 घटाने पर 195.00।पहले लिखा जाता है
  5. 5Actual outputयह expected output से मेल खाता है, इसलिए check pass है। 193.50 का total failure होता: delivery fee पर भी छूट लगी।पास

Expected output run से पहले लिखें। बाद में screen जो दिखाए उसे मान लेना आसान होता है: 193.50 SAR ठीक लगता है, लेकिन इसका मतलब है कि delivery fee पर भी छूट दे दी गई। यह failure है, और report उस rule का नाम लेती है जो टूटा।

जब test basis चुप हो, जैसे 24.995 को कैसे round करें, तो यह चुप्पी ख़ुद एक finding है: product owner से पूछें और जवाब दर्ज करें, या जिस assumption पर आपने टेस्ट किया उसे दर्ज करें।

Worked example: promo code के functional checks

नीचे दी गई story और उसके चार acceptance criteria test basis हैं। Tester हर criterion के लिए कम से कम एक check बनाता है, हर expected output पहले से निकालता है, फिर पूरे feature से तीनों सवाल पूछता है।

  • Correctness: F1 और F2 calculation जाँचते हैं, और F3 से F5 rejection के rules। F2 का अभी कोई expected result नहीं है क्योंकि AC-1 में rounding का rule नहीं है, इसलिए tester टेस्ट से पहले पूछता है।
  • Completeness: F6 को remove function चाहिए। अगर build में यह नहीं है, तो यह ग़ायब function है, यानी functional defect।
  • Appropriateness: story कहती है "checkout पर", इसलिए tester पुष्टि करता है कि code field payment step पर भी उपलब्ध है, सिर्फ़ cart में नहीं।
  • Table में नहीं: discount कितनी जल्दी दिखता है, या क्या codes का अंदाज़ा लगाया जा सकता है। ये non-functional सवाल हैं।
Story PROMO-31
एक customer के रूप में, मैं checkout पर promo code लगाना चाहता हूँ
ताकि मैं discount वाली क़ीमत चुकाऊँ।

AC-1  WELCOME10 item subtotal पर 10% छूट देता है। Delivery fee पर छूट नहीं।
AC-2  Expired या अनजान code message के साथ reject होता है; total नहीं बदलता।
AC-3  हर order पर एक ही code: दूसरा code message के साथ reject होता है।
AC-4  Customer payment से पहले लगाया गया code हटा सकता है।

अलग न लिखा हो तो cart: items 200.00 SAR + delivery fee 15.00 SAR = 215.00 SAR

Check  Basis  Input या action                  Expected output
F1     AC-1   WELCOME10 लगाएँ                  discount 20.00, total 195.00
F2     AC-1   items 249.95, WELCOME10 लगाएँ    discount 24.995: 25.00 या 24.99? पूछें।
F3     AC-2   SUMMER24 लगाएँ (expired)         message के साथ reject, total 215.00
F4     AC-2   WELCOM10 लगाएँ (typo)            message के साथ reject, total 215.00
F5     AC-3   WELCOME10 के बाद VIP5 लगाएँ      VIP5 message के साथ reject, total 195.00
F6     AC-4   WELCOME10 हटाएँ                  discount line नहीं, total 215.00

आज़माएँ: User Story → टेस्ट केस आज़माएँ: प्रतिशत कैलकुलेटर

आम गलतियाँ

  • Expected result को test basis से निकालने की बजाय system जो दिखाए उससे ले लेना।
  • सिर्फ़ happy path (valid input वाला सामान्य flow) की correctness जाँचना, और कभी यह न पूछना कि कोई वादा किया गया function ग़ायब तो नहीं या वह user के task के लिए ठीक बैठता है या नहीं।
  • Functional testing को test level समझना, या black-box या manual testing का दूसरा नाम मान लेना।
  • "Discount सही लगा" जैसे vague expected results लिखना, exact राशि, message या state की जगह।
  • Requirement चुप हो तो पूछने और जवाब दर्ज करने की बजाय अंदाज़ा लगाना।

QA का नज़रिया

Functional testing refinement में ही शुरू हो जाती है, कोई code लिखे जाने से पहले: हर criterion के लिए पूछें कि वह किस state, inputs और outputs की बात करता है और कहाँ चुप है। Rounding का सवाल वहाँ एक मिनट लेता है, और release के बाद एक defect fix। Developers के साथ तय करें कि कौन क्या जाँचेगा: unit tests आम तौर पर अकेले functions cover करते हैं, जबकि आप system और acceptance levels पर और components के जोड़ों पर ध्यान देते हैं।

हर check को उस criterion के साथ दर्ज करें जिससे वह trace होता है, साथ में उसकी state, input और exact expected output। तब fail हुआ check एक सटीक bug report बनता है: "AC-1: items 200.00 + fee 15.00 पर WELCOME10 के साथ total 195.00 होना चाहिए; actual 193.50, delivery fee पर भी छूट लगी"। Traceability से आप हर requirement के हिसाब से results बता सकते हैं, सिर्फ़ pass हुए tests की गिनती नहीं।

अभ्यास

Appointment cancellation के functional checks लिखें

आपका काम

एक clinic app की story और acceptance criteria नीचे हैं। State, input, rule और expected output के रूप में कम से कम छह functional checks लिखें, हर एक को किसी criterion से trace करते हुए।

हर check को completeness, correctness या appropriateness का label दें, और story जो खुला छोड़ती है उसे product owner के लिए सवालों के रूप में लिखें।

सामग्री
Story APPT-7
एक patient के रूप में, मैं app से appointment cancel करना चाहता हूँ
ताकि वह slot किसी दूसरे patient के लिए खाली हो जाए।

AC-1  Patient "मेरे appointments" से आने वाला appointment cancel कर सकता है।
AC-2  Start से 24 घंटे या उससे पहले cancel करना free है। उसके बाद cancel करने पर
      50.00 SAR fee लगती है, जो patient के confirm करने से पहले दिखती है।
AC-3  Cancel के बाद slot फिर से book हो सकता है और patient को
      confirmation SMS मिलता है।
AC-4  पिछले (past) appointments cancel नहीं हो सकते।
चरण
  1. हर criterion को अपने शब्दों में rule के रूप में लिखें।
  2. हर rule के लिए कम से कम एक check लिखें, expected output अभी निकालकर।
  3. हर check को लक्ष्य के हिसाब से label दें।
  4. खुले सवाल लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Correctness: F1 (AC-2) appointment 3 दिन बाद, cancel → कोई fee नहीं, status Cancelled। F2 (AC-2) ठीक 24 घंटे पहले → free, क्योंकि rule कहता है "24 घंटे या उससे पहले"। F3 (AC-2) 23 घंटे पहले → confirm से पहले 50.00 SAR fee दिखती है। F4 (AC-2) patient fee देखकर वापस जाता है → appointment वैसा ही रहता है, कोई fee नहीं।

Components के पार correctness: F5 (AC-3) cancel के बाद दूसरा patient वह slot book कर सकता है। F6 (AC-3) patient को SMS मिलता है जिसमें cancel हुए appointment का ज़िक्र है। अगर कोई SMS भेजा ही न जाए, तो वादा किया गया function ग़ायब है (completeness); गलत appointment वाला SMS correctness की समस्या है।

Completeness: F7 (AC-1) "मेरे appointments" हर आने वाले appointment पर cancel action दिखाता है। Correctness: F8 (AC-4) past appointment पर कोई cancel action नहीं है। Appropriateness: F9 (AC-1) patient clinic को phone किए बिना कुछ ही steps में cancel कर सकता है।

खुले सवाल: 24 घंटे किस time zone से गिने जाते हैं? Fee कब ली जाती है? जो appointment शुरू हो चुका है पर ख़त्म नहीं हुआ, क्या वह past गिना जाएगा? अगर SMS deliver न हो तो क्या cancellation फिर भी valid है? क्या patient इसे वापस ले सकता है?

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

क्या functional testing और black-box testing एक ही हैं?

नहीं। Functional testing इस बारे में है कि क्या जाँचा जाता है: functions और उनके results। Black-box testing इस बारे में है कि tests कहाँ से आते हैं: test object के बाहर के documents से। ज़्यादातर functional tests black-box तरीके से design होते हैं, लेकिन किसी function के लिए developer का unit test भी functional है, भले ही वह code खोलकर लिखा गया हो।

Functional testing manual होती है या automated?

दोनों। यह term बताता है कि क्या टेस्ट होता है, यह नहीं कि test कैसे चलाया जाता है। हर बदलाव पर दोहराए जाने वाले stable checks automation के अच्छे candidates हैं; नए features को अक्सर पहले हाथ से टेस्ट किया जाता है। क्या automate करना है, यह बाद के पाठ बताते हैं।

Functional और non-functional testing में क्या फ़र्क है?

Functional testing जाँचती है कि system क्या करता है, जैसे क्या checkout सही total निकालता है। Non-functional testing जाँचती है कि वह यह कितनी अच्छी तरह करता है: कितना तेज़, कितना सुरक्षित, कितना आसान, किन devices पर। ज़्यादातर features को दोनों चाहिए, और अगला पाठ non-functional पक्ष को cover करता है।

अगर लिखी हुई requirements न हों तो क्या करें?

जो भी expected व्यवहार बताए उसका इस्तेमाल करें: replace होने वाला system, user manual, domain rules, regulations या product owner से बातचीत। जिस rule पर आप टेस्ट कर रहे हैं उसे लिखें और उसकी पुष्टि करवाएँ, ताकि आपके expected results सिर्फ़ आपके अंदाज़े पर न टिकें।

संदर्भ

  • 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टेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
टूल्स

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

User Story → टेस्ट केस

किसी user story (As a / I want / So that) को टेम्पलेट और heuristics की मदद से संरचित टेस्ट केस में बदलें।

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

Requirements → टेस्ट केस

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

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

टेस्ट केस जनरेटर

फ़ीचर के विवरण और फ़ील्ड सूची से संरचित टेस्ट केस (id, शीर्षक, पूर्व-शर्तें, स्टेप, अपेक्षित परिणाम, प्राथमिकता) जनरेट करें।

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

प्रतिशत कैलकुलेटर

प्रतिशत, प्रतिशत परिवर्तन, वृद्धि/कमी और X, Y का कितना प्रतिशत है — सब गिनें।

यूटिलिटीज़

और गहराई से

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

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