मॉड्यूल 3 · Testing fundamentals

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

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

Non-functional testing यह जाँचती है कि system अपना काम कितनी अच्छी तरह करता है, न कि वह क्या करता है; ISTQB Foundation syllabus इसे "system कितनी अच्छी तरह व्यवहार करता है" की testing कहता है। यह functional suitability के अलावा बाक़ी quality characteristics जाँचती है, जैसे performance efficiency, security, usability, reliability और compatibility। Team में आप इसे नाम वाले test types के रूप में देखेंगे: performance, security, usability, accessibility, compatibility, reliability और localization testing।

एक sign-in page लीजिए। Functional test पूछता है कि सही email और password से user sign in होता है या नहीं। Non-functional tests पूछते हैं कि कितनी अच्छी तरह: जब 500 लोग एक साथ sign in करें तब क्या page 2 seconds में जवाब देता है, क्या इसे keyboard और screen reader से इस्तेमाल किया जा सकता है, क्या यह password guessing को रोकता है, और क्या Arabic version दाएँ से बाएँ पढ़ा जाता है?

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

कोई product हर functional test pass करके भी अपने users को निराश कर सकता है: sale के पहले दिन payment page time out हो जाता है, screen reader user "Pay" button तक नहीं पहुँच पाता, या एक customer दूसरे customer की invoice खोल लेता है। ऐसे failures एक साथ बहुत-से users पर असर डालते हैं और देर से ठीक करना महँगा पड़ता है, क्योंकि वजह अक्सर कोई design decision होती है। Foundation syllabus चेतावनी देता है कि non-functional defects का देर से पता चलना project के लिए गंभीर ख़तरा बन सकता है।

Tester के लिए सवाल "क्या यह काम करता है?" से बदलकर "क्या यह काफ़ी अच्छी तरह काम करता है, किसके लिए और किन हालात में?" हो जाता है। इसके लिए पहले से तय target चाहिए; उसके बिना "काफ़ी तेज़" release के समय बहस बन जाता है, test result नहीं।

System क्या करता है बनाम कितनी अच्छी तरह करता है

Functional test व्यवहार को एक rule से मिलाता है: यह input, यह expected output। Non-functional test वही feature रखता है और एक condition व एक measure जोड़ता है: कितना तेज़, एक साथ कितने users, किस device पर, किस failure के बाद। कई non-functional tests किसी functional test को ही दोबारा इस्तेमाल करते हैं और उसके चलते समय एक constraint जाँचते हैं, जैसे search 2 seconds के अंदर सही results लौटाए।

इसे कभी-कभी ख़ास environment चाहिए होता है: load के लिए production जैसा system, असली devices, assistive technology, या usability lab में असली users। इसका expected result एक target होता है, और नतीजा एक measured value जिसे उस target से मिलाया जाता है। जहाँ संभव हो, यह जल्दी शुरू होती है, requirements और design reviews में और component tests में ही, क्योंकि धीमे या insecure design का fix शायद ही कभी छोटा होता है।

वे areas जिनसे tester सबसे पहले मिलता है

Software quality वाले पाठ ने ISO/IEC 25010 की नौ characteristics से परिचय कराया था: functional suitability functional testing का हिस्सा है, बाक़ी आठ non-functional testing का। Maintainability ज़्यादातर reviews और static analysis से आँकी जाती है, और safety वहाँ मायने रखती है जहाँ software नुक़सान पहुँचा सकता है। रोज़ के काम में testers सबसे पहले इन areas से मिलते हैं:

  • Performance (performance efficiency): system कितनी तेज़ी से जवाब देता है, कितना load सँभालता है और कितने resources इस्तेमाल करता है।
  • Security: data को सिर्फ़ authorised लोग देख और बदल सकें, और system attacks का सामना करे।
  • Usability (ISO/IEC 25010:2023 में interaction capability): intended users अपने goals effectiveness, efficiency और satisfaction के साथ पूरे करें — ये ISO 9241-11 की परिभाषा के तीन हिस्से हैं।
  • Accessibility: disabilities वाले लोग भी इसे इस्तेमाल कर सकें; आम तौर पर इसे WCAG 2.2 के आधार पर आँका जाता है, और ISO/IEC 25010 इसे interaction capability का हिस्सा मानता है।
  • Compatibility: यह supported browsers, devices और operating systems पर, और जुड़े हुए systems के साथ काम करे। ISO/IEC 25010 browser और device support को flexibility (2011 में portability) में रखता है; teams आम तौर पर दोनों को compatibility कहती हैं।
  • Reliability: यह जितनी देर ज़रूरी हो सही काम करे, available रहे, और कुछ गड़बड़ होने पर, जैसे connection टूटने पर, काम करता रहे या recover करे।
  • Localization: हर language और region का version पूरा और सही हो, translation और right-to-left layout से लेकर date, number और currency formats तक। यह ISO/IEC 25010 की characteristic नहीं है; teams इसे अलग test type के रूप में plan करती हैं।

आज़माएँ: टेस्ट सिनेरियो जनरेटर आज़माएँ: सिक्योरिटी हेडर एनालाइज़र

"तेज़" को measurable criterion में बदलना

"Page तेज़ होना चाहिए" टेस्ट नहीं किया जा सकता, क्योंकि कोई नहीं बता सकता कि यह कब fail होता है। Time के लिए averages की जगह percentiles लें। 95th percentile (p95) वह समय है जिसके अंदर 95% requests पूरी हो जाती हैं: "p95 अधिकतम 2 s" का मतलब है कि कम से कम 95% requests 2 seconds के अंदर पूरी होती हैं, जबकि 1 second का average 10 seconds लेने वाली requests छिपा सकता है। किसी standard के लिए उसका version और level लिखें, जैसे WCAG 2.2 level AA।

Measurable acceptance criterion चार बातें बताता है:

  • Measure: क्या गिना या नापा जाता है, जैसे p95 response time, error rate, task success rate या recover होने में लगे minutes।
  • Target: pass या fail तय करने वाली सीमा, unit के साथ: अधिकतम 2 s, 1% से कम, शून्य।
  • Conditions: वह load, data, devices, network, users और environment जिस पर target लागू होता है।
  • Method: कैसे और कहाँ नापा जाता है, ताकि दो testers को तुलना लायक numbers मिलें।
Vague:       Registration page तेज़ होना चाहिए।

Measurable:
  Measure     "Register" का p95 response time, और error rate
  Target      p95 <= 2 s, errors < 1%
  Conditions  2,000 concurrent students, 15 minutes तक,
              production-size data, staging environment
  Method      load test script; numbers tool report से

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

Worked example: course registration का दिन

एक university सुबह 09:00 बजे course registration खोलती है, और ज़्यादातर students पहले कुछ minutes में कोशिश करते हैं। Story functional है: "एक student के रूप में, मैं किसी course section में register करना चाहता हूँ, ताकि मुझे seat मिले।" Refinement में tester हर area के लिए एक सवाल पूछता है, और team ये criteria तय करती है:

  • Performance: 2,000 concurrent students के साथ 15 minutes तक "Register" का p95 अधिकतम 2 s और errors 1% से कम, staging पर production-size data के साथ load test में।
  • Security: किसी दूसरे student की id वाली request HTTP status 403 (Forbidden) या 404 (Not Found) के साथ मना हो जाए और कोई data न लौटे, दो test accounts से जाँचा गया।
  • Usability: पहले साल के 5 में से कम से कम 4 students बिना मदद के 3 minutes में register कर लें, moderated session में, जहाँ एक facilitator task देता है और बिना मदद किए देखता है।
  • Accessibility: WCAG 2.2 level AA; जैसे हर step सिर्फ़ keyboard से काम करे (success criterion 2.1.1) और normal text का contrast ratio कम से कम 4.5:1 हो (1.4.3), keyboard walk-through और contrast checker से जाँचा गया।
  • Compatibility: registration tests support matrix के हर browser और device पर pass हों, हर row पर चलाकर।
  • Reliability: "Register" दबाने के बाद connection टूटे तो student के पास एक registration हो या कोई नहीं, दो कभी नहीं; request के बीच network काटकर और फिर registrations गिनकर जाँचा गया।
  • Localization: Arabic interface में कोई untranslated text न हो, वह दाएँ से बाएँ पढ़ा जाए और class times university के time zone में दिखें, Arabic test data से जाँचा गया।
Course registration के दिन हर non-functional area को अपना test और measurable target मिलता है, 2,000 students पर p95 अधिकतम 2 s से लेकर Arabic interface में एक भी untranslated text न होने तक।
क्षेत्रउदाहरण testMeasure और target
Performanceperformance efficiencyStaging पर production-size data के साथ load test2,000 concurrent students, 15 minutes तक"Register" का p95 अधिकतम 2 serrors 1% से कम
Securityदो test accounts, student ids बदलकर403 या 404, कोई data नहींदूसरे student की id वाली हर request पर
Usabilityinteraction capabilityपहले साल के students के साथ moderated session5 में से कम से कम 4 बिना मदद के register करें3 minutes के अंदर
AccessibilityWCAG 2.2 level AAसिर्फ़ keyboard से walk-through और contrast checkहर step keyboard से काम करे (2.1.1)normal text का contrast कम से कम 4.5:1 (1.4.3)
CompatibilitySupport matrix की हर row पर registration testsहर supported browser और device पर pass
Reliability"Register" दबाने के बाद network काटनाएक registration या कोई नहीं, दो कभी नहींबाद में registrations गिनें
LocalizationArabic test data के साथ पूरा flow Arabic मेंशून्य untranslated textright-to-left layout; class times university के time zone में

ये targets इस उदाहरण के हैं; हर product अपने targets product owner के साथ तय करता है।

आज़माएँ: अरबी टेस्ट डेटा जनरेटर

आम गलतियाँ

  • Non-functional testing को आख़िर तक टालना, जब धीमे design या छूटे security control को बदलना महँगा हो चुका होता है।
  • "तेज़", "secure" या "user-friendly" को बिना measure, target और conditions के स्वीकार कर लेना।
  • Average response time report करना, जो users को खलने वाली धीमी requests छिपा देता है।
  • Laptop पर या लगभग खाली database के साथ performance नापना और उस number को production का result मान लेना।
  • Automated accessibility scan को WCAG conformance का सबूत मान लेना; कई success criteria के लिए इंसानी judgement चाहिए।
  • सिर्फ़ English में और एक ही browser पर टेस्ट करना, जिससे layout, translation और device की problems पहले users तक पहुँचती हैं।

QA का नज़रिया

Non-functional सवाल refinement और requirements review में, code से पहले उठाएँ: "Peak पर कितने users होंगे?", "यह data कौन देख सकता है?", "हम कौन-से browsers और devices support करते हैं?", "हम WCAG के किस level के लिए प्रतिबद्ध हैं?" Targets product owner तय करता है; developers, operations और security specialists बताते हैं कि क्या realistic है। अगर अभी किसी को पता न हो, तो उसे owner के साथ open question के रूप में दर्ज करें।

हर result के साथ conditions दर्ज करें: build, environment, data size, load, device, browser और tool। Non-functional bug report में criterion, measured value और method होते हैं: "Register का p95 2,000 users पर 4.8 s रहा (target 2 s), staging, build 7.3.1।" बताएँ कि कौन-से areas टेस्ट नहीं हुए, ताकि team वह risk जानते-बूझते स्वीकार करे। Load और security tests सिर्फ़ उन्हीं systems पर चलाएँ जो आपके हैं या जिन्हें टेस्ट करने की आपके पास लिखित अनुमति है, और तय समय पर।

अभ्यास

अस्पष्ट requirements को measurable बनाएँ

आपका काम

एक online pharmacy अपनी website Arabic और English में launch करने वाली है। उसके requirements document में नीचे के चार statements हैं। हर statement का area बताएँ, फिर उसे measure, target, conditions और method वाले acceptance criterion के रूप में दोबारा लिखें। जहाँ आपको कोई number नहीं पता, वहाँ वह सवाल लिखें जो आप पूछेंगे, और यह भी कि उसका जवाब किसे देना चाहिए।

सामग्री
NFR-1  Website तेज़ होनी चाहिए।
NFR-2  Customer data secure होना चाहिए।
NFR-3  Website बड़ी उम्र के customers के लिए इस्तेमाल में आसान होनी चाहिए।
NFR-4  Orders कभी खोने नहीं चाहिए।
चरण
  1. हर statement का area बताएँ।
  2. ऐसा measure चुनें जो दिखाए कि ज़रूरत पूरी हुई।
  3. Target और वे conditions प्रस्तावित करें जिन पर वह लागू होता है।
  4. Method बताएँ और अपने open questions लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

NFR-1, performance: 500 concurrent users के साथ 15 minutes तक search और order place करने का p95 अधिकतम 2 s और errors 1% से कम, staging पर production-size data के साथ load test में। असली peak product owner से पूछें।

NFR-2, security: customer सिर्फ़ अपने orders, prescriptions और addresses देखे; दूसरे customer की id वाली कोई भी request 403 या 404 लौटाए और कोई data नहीं, id लेने वाले हर page और endpoint पर दो test accounts से जाँचा गया। बाक़ी ज़रूरी controls के बारे में security lead से पूछें।

NFR-3, usability और accessibility: 60 या उससे ज़्यादा उम्र के 5 में से कम से कम 4 customers moderated session में बिना मदद के 3 minutes के अंदर पिछला order दोबारा दें, और website WCAG 2.2 level AA पूरा करे, keyboard, screen reader और बड़े text के साथ जाँचा गया। Product owner से पूछें कि बड़ी उम्र के customers के लिए कौन-से tasks सबसे ज़रूरी हैं और वे किन devices से ख़रीदारी करते हैं।

NFR-4, reliability: checkout के दौरान network या payment provider fail हो, तो customer के पास ठीक एक paid order हो, या न order हो न charge, और वह देख सके कि क्या हुआ; target है बिना payment का एक भी order नहीं और बिना order का एक भी payment नहीं। Order के बीच network काटकर और payment की test service रोककर टेस्ट करें, फिर orders को payments से मिलाएँ। Developers से पूछें कि दोबारा किया गया payment दूसरा order बनाने से कैसे रोका जाता है।

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

क्या non-functional testing सिर्फ़ specialists के लिए है?

नहीं। गहरी performance या security testing के लिए specialists और tools चाहिए, लेकिन हर tester measurable criteria माँग सकता है, धीमी screens पर ध्यान दे सकता है, keyboard आज़मा सकता है, language बदल सकता है और दूसरे device पर टेस्ट कर सकता है। इस roadmap के आगे के specialist modules हर area में गहराई से जाते हैं।

क्या non-functional tests automate किए जा सकते हैं?

कई हाँ: load tests scripts होते हैं, कुछ accessibility rules और security headers pipeline में automatically जाँचे जा सकते हैं, और compatibility runs browser automation इस्तेमाल कर सकते हैं। कुछ के लिए इंसान चाहिए, जैसे usability sessions और यह आँकना कि image का alternative text सही अर्थ देता है या नहीं। ज़्यादातर teams दोनों को मिलाती हैं।

Non-functional requirement और non-functional test में क्या अंतर है?

Requirement बताती है कि product में कौन-सी quality होनी चाहिए, बेहतर हो कि measure और target के साथ। Test वह activity है जो तय conditions में उसे नापती है और result को target से मिलाती है। अस्पष्ट requirement से ऐसा test बनता है जिसका कोई expected result नहीं होता।

Localization functional testing है या non-functional?

Teams इसे अलग-अलग तरह classify करती हैं। Currency की गलत calculation functional defect है, जबकि कटा हुआ Arabic text या mirror न होने वाला layout आम तौर पर localization defect के रूप में report होता है। मायने यह रखता है कि यह plan हो और इसके criteria हों, न कि यह किस column में रखा गया है।

संदर्भ

  • 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उत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
  • ISO 9241-11:2018 — Ergonomics of human-system interaction — Part 11: Usability: Definitions and conceptsISO · 2018usability की अवधारणा का ढाँचा: निर्दिष्ट उपयोगकर्ताओं, लक्ष्यों और context of use के लिए effectiveness, efficiency और satisfaction, जहाँ usability को उपयोग का परिणाम माना जाता है।
  • Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।
टूल्स

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

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

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

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

सिक्योरिटी हेडर एनालाइज़र

पेस्ट किए गए हेडर या किसी सार्वजनिक URL से HTTP सुरक्षा हेडर (CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP/CORP) को ग्रेड दें।

वैलिडेशन

अरबी टेस्ट डेटा जनरेटर

लोकलाइज़ेशन टेस्टिंग के लिए अरबी नाम, पते, वाक्य, संख्याएँ (अरबी-हिंदसी अंक) और RTL edge case जनरेट करें।

टेस्ट डेटा

और गहराई से

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

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