स्टैटिक टेस्टिंग

स्टैटिक टेस्टिंग क्या है — "कोड न चलाने" से आगे

ISTQB Foundation Level सिलेबस (CTFL v4.0) का तीसरा अध्याय पूरी तरह स्टैटिक टेस्टिंग पर है और इसे दो परिवारों में बाँटता है: review, जिसमें लोग किसी वर्क प्रोडक्ट की जाँच करते हैं, और static analysis, जिसमें टूल उसे औपचारिक नियमों के आधार पर परखते हैं। दोनों के लक्ष्य एक जैसे हैं: वर्क प्रोडक्ट में सीधे डिफ़ेक्ट ढूँढना, उसकी क्वालिटी का आकलन करना और उस पर भरोसा बनाना, और उसे लिखने वालों तथा उस पर आधारित बिल्ड, टेस्ट और ऑपरेशन करने वालों के बीच साझा समझ बनाना।

सबसे अहम फ़र्क़ defect और failure का है। Defect किसी वर्क प्रोडक्ट की खामी है — विरोधाभासी वाक्य, हैंडल न की गई null वैल्यू, contract में गायब error response। Failure वह है जो चलता हुआ सिस्टम किसी defect की वजह से गलत करता है। Dynamic टेस्टिंग failures देखती है, फिर कोई debugging करके पीछे defect तक पहुँचता है। स्टैटिक टेस्टिंग सीधे defect पर पहुँचती है, अक्सर उसकी सटीक जगह के साथ। इसीलिए static finding को ठीक करना आम तौर पर सस्ता होता है: न कुछ रिप्रोड्यूस करना, न डायग्नोज़ करना, और अक्सर अभी दोबारा लिखने को कोड भी नहीं।

जो कुछ इंसान पढ़ और समझ सकता है उसका review हो सकता है, वे डॉक्यूमेंट भी जो कभी चलेंगे नहीं; और जिसकी औपचारिक संरचना है — कोड, schema, मॉडल, कॉन्फ़िगरेशन फ़ाइल — उसका टूल से analysis भी हो सकता है।

• यह प्रूफ़रीडिंग नहीं है। स्पेलिंग सुधार एक साइड-इफ़ेक्ट है; असली निशाना वे defects हैं जो आगे चलकर गलत व्यवहार, rework या जोखिम बनते।
• यह dynamic टेस्टिंग का विकल्प नहीं है। यह नहीं दिखा सकती कि सिस्टम तेज़ है, services आपस में जुड़ती हैं, या यूज़र अपना काम पूरा कर पाता है।
• यह सिर्फ़ डेवलपर की गतिविधि नहीं है। टेस्टर requirements और टेस्ट डॉक्यूमेंट review करते हैं, product owner और डिज़ाइनर एक-दूसरे का काम review करते हैं, और operations इंजीनियर deployment कॉन्फ़िगरेशन review करते हैं।

Static टेस्टिंग बनाम Dynamic टेस्टिंग

दोनों एक-दूसरे के पूरक हैं, विकल्प नहीं। नीचे के अंतर ISTQB सिलेबस की तुलना पर आधारित हैं; ज़्यादातर टीमों को हर test level पर दोनों की ज़रूरत होती है।

• क्या पकड़ती है — static: सीधे वर्क प्रोडक्ट में defects। Dynamic: failures, जिनसे debugging करके defect तक पहुँचा जाता है।
• कब शुरू हो सकती है — static: जैसे ही कोई वर्क प्रोडक्ट बने, कोड से पहले भी। Dynamic: जब कुछ चलने लायक मौजूद हो।
• किसकी जाँच कर सकती है — static: चलने लायक और न चलने लायक दोनों वर्क प्रोडक्ट (requirements, डिज़ाइन, test plans, contracts)। Dynamic: सिर्फ़ चलता हुआ सॉफ़्टवेयर।
• क्वालिटी विशेषताएँ — static: वे जो execution पर निर्भर नहीं, जैसे maintainability, consistency और standards का पालन। Dynamic: वे जो निर्भर हैं, जैसे performance efficiency, लोड में reliability और असली integration व्यवहार।
• आसानी से पकड़े जाने वाले defects — static: अस्पष्ट या विरोधाभासी requirements, unreachable या duplicate कोड, undeclared या uninitialised variables, interface parameters का बेमेल होना, coding standards से विचलन, कुछ security कमज़ोरियाँ, ऐसे acceptance criteria जिनका कोई टेस्ट नहीं। Dynamic: खास डेटा पर गलत आउटपुट, timing और concurrency failures, environment और कॉन्फ़िगरेशन की समस्याएँ, usability समस्याएँ।
• Finding की लागत — static: आम तौर पर कम, क्योंकि जगह पता है और defect के ऊपर कम कुछ बना है। Dynamic: ज़्यादा, क्योंकि इसमें reproduction, diagnosis और defect पर बने काम का rework शामिल है।

किसकी स्टैटिक टेस्टिंग हो सकती है, और आम तौर पर क्या मिलता है

उदाहरण के लिए, एक user story कहती है "500 SAR से ऊपर के ऑर्डर पर डिस्काउंट लागू होगा"। Reviewer पूछता है कि ठीक 500.00 SAR का ऑर्डर योग्य है या नहीं — एक वाक्य में, कोड से पहले, एक static finding। अगर कोई नहीं पूछता, तो डेवलपर "से बड़ा" या "से बड़ा या बराबर" चुन लेता है, और हफ़्तों बाद कोई boundary value टेस्ट दिखा सकता है कि यह चुनाव finance की अपेक्षा से अलग है। वही defect, दो जगह मिला, बहुत अलग लागत पर। नीचे की सूची बताती है कि हर तरह का वर्क प्रोडक्ट आम तौर पर क्या छिपाता है।

• Requirements और user stories — अस्पष्टता, विरोधाभास, छूटी बातें (error paths, permissions, limits), टेस्ट न हो सकने वाले कथन, दोहराए गए या टकराते business rules।
• Architecture और डिज़ाइन — कमज़ोर modularisation, single point of failure, अक्षम data structures या database डिज़ाइन, components के बीच error handling का अभाव, डेटा की ownership अस्पष्ट।
• API contracts और schemas — असंगत naming, गायब error responses, ऐसे types जो अपने examples से मेल नहीं खाते, versions के बीच breaking changes, बिना constraints के fields।
• Source code — undefined या unused variables, unreachable या duplicate कोड, ज़रूरत से ज़्यादा complexity, असुरक्षित calls, यूज़र इनपुट से बनी query strings, coding standards का उल्लंघन।
• कॉन्फ़िगरेशन और infrastructure-as-code — plain text में commit किए secrets, असुरक्षित defaults, किसी environment के लिए गलत वैल्यू, invalid YAML, कभी न चलने वाला cron schedule।
• टेस्ट डॉक्यूमेंट — बिना exit criteria का test plan, धुँधले expected result वाले test cases, बिना किसी टेस्ट के acceptance criteria, duplicate या पुराने cases।

आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर आज़माएँ: AI API कॉन्ट्रैक्ट रिस्क एनालाइज़र

डिफ़ेक्ट की जल्दी पहचान और डिफ़ेक्ट की रोकथाम

Defects आम तौर पर जल्दी डाले जाते हैं और देर से पकड़े जाते हैं। Requirement की गलतफ़हमी डिज़ाइन का फ़ैसला बनती है, फिर कोड, फिर उसी गलतफ़हमी पर लिखे टेस्ट — और जब आख़िरकार समस्या दिखती है तो उस पर बनी हर परत पर rework करना पड़ता है। स्टैटिक टेस्टिंग यह feedback loop छोटा करती है: requirement पर उसी दिन सवाल होता है जिस दिन वह लिखी जाती है, डिज़ाइन पर कोडिंग से पहले, बदलाव पर merge से पहले। ISTQB सिलेबस stakeholders से जल्दी और बार-बार मिलने वाले feedback को review प्रक्रिया के साथ बताता है और कहता है कि इससे requirements को लेकर गलतफ़हमियाँ रोकी जा सकती हैं।

जल्दी पहचान और रोकथाम (defect prevention) जुड़े हैं पर एक नहीं हैं। पहचान इस defect को जल्दी ढूँढती है; रोकथाम अगले defect को बनने से रोकती है। Review रोकथाम में दो तरह से योगदान देते हैं। लोग सीखते हैं: जिस डेवलपर के बदलावों पर बार-बार "input validate नहीं हुआ" टिप्पणी आती है, वह input validate करने लगता है। और findings प्रक्रिया में checklist items, templates, coding rules और lint rules बनकर लौटती हैं। जो defect type कई reviews में दिखे, वह automated check का उम्मीदवार है, ताकि किसी इंसान को उसे फिर न ढूँढना पड़े।

• Review findings को type के हिसाब से वर्गीकृत करें — अस्पष्टता, missing error handling, naming, security, test gap। गिनती बताती है कि defects कहाँ से आते हैं।
• सिर्फ़ डॉक्यूमेंट नहीं, template ठीक करें: "error cases" शीर्षक वाला user-story template छूटी बातों की एक पूरी श्रेणी हटा देता है।
• Story refinement में टेस्टरों को शामिल करें। "मैं इसे कैसे टेस्ट करूँगा?" पूछना अपने आप में एक static test है।

Review: स्टैटिक टेस्टिंग का मानवीय पक्ष

Review किसी वर्क प्रोडक्ट की संरचित जाँच है, जो उसके लेखक के अलावा (या उसके साथ) दूसरे लोग करते हैं। Review एक सहकर्मी के pull request पढ़ने से लेकर प्रशिक्षित भूमिकाओं, entry criteria और एकत्र किए metrics वाले औपचारिक inspection तक होते हैं। CTFL v4.0 औपचारिकता के इस पैमाने पर चार review प्रकार बताता है: informal review, walkthrough, technical review और inspection। सॉफ़्टवेयर review और audit का IEEE मानक IEEE 1028-2008 (जिसे IEEE अब inactive-reserved के रूप में सूचीबद्ध करता है) इनके अलावा management review और audit भी परिभाषित करता है, जो वर्क प्रोडक्ट की तकनीकी सामग्री के बजाय प्रगति और अनुपालन का आकलन करते हैं। ISO/IEC 20246 वर्क प्रोडक्ट review का एक सामान्य फ़्रेमवर्क बताता है।

Reviews एक सामान्य प्रक्रिया पर आधारित होते हैं — planning, review initiation, individual review, communication and analysis, fixing and reporting — और review जितना औपचारिक होता है, इस प्रक्रिया का उतना ज़्यादा हिस्सा किया जाता है; informal review किसी परिभाषित प्रक्रिया का पालन नहीं करता। मुख्य भूमिकाएँ हैं: manager, author, moderator (facilitator), scribe (recorder), reviewer और review leader। Software review के प्रकारों वाला पेज चारों प्रकारों की तुलना उद्देश्य, औपचारिकता, leader, भूमिकाओं, डॉक्यूमेंटेशन और metrics पर करता है, और प्रक्रिया, भूमिकाएँ और सफलता के कारक विस्तार से समझाता है।

• Informal review — बिना तय प्रक्रिया के एक तेज़ दूसरी नज़र।
• Walkthrough — author प्रतिभागियों को वर्क प्रोडक्ट से गुज़ारता है ताकि समझा सके और साझा समझ बने।
• Technical review — योग्य साथी, moderator के नेतृत्व में, किसी तकनीकी सवाल पर फ़ैसला करते हैं।
• Inspection — सबसे औपचारिक प्रकार, जिसका लक्ष्य जितने हो सकें उतने defects ढूँढना है, metrics के साथ।

Requirements, डिज़ाइन, कोड और टेस्ट डॉक्यूमेंट review

Review का प्रकार बताता है कि वह कितना औपचारिक है; वर्क प्रोडक्ट तय करता है कि reviewers क्या खोजें। एक ही टीम डिज़ाइन का walkthrough, ज़्यादातर कोड बदलावों का informal review और payment rules का inspection कर सकती है।

• Requirements review — अस्पष्टता, पूर्णता, consistency, सही होना, testability, feasibility, traceability और non-functional ज़रूरतें जाँचता है, बेहतर हो तो product, development और testing साथ बैठकर। यहीं स्टैटिक टेस्टिंग आम तौर पर सबसे ज़्यादा फ़ायदा देती है, और इसका checklist व पूरे उदाहरण वाला अलग पेज है।
• Design review — जाँचता है कि डिज़ाइन requirements, non-functional समेत, पूरी करता है: services के बीच failure कैसे फैलता है, डेटा कहाँ रहता है और उसका मालिक कौन है, peak लोड पर क्या होता है, सिस्टम को कैसे टेस्ट और monitor किया जाएगा। डायग्राम के हर तीर से पूछें: "यह dependency धीमी या बंद हो तो क्या होगा?"
• Code review — सही होना, टेस्ट, पठनीयता, security और codebase से consistency जाँचता है। Google की प्रकाशित code review गाइड एक व्यावहारिक मानक रखती है: बदलाव को तब मंज़ूर करें जब वह कोड की समग्र सेहत को साफ़ तौर पर बेहतर करे, भले परफ़ेक्ट न हो, और वैकल्पिक टिप्पणियों को चिह्नित करें (जैसे "Nit:" से) ताकि author जाने कि merge किस चीज़ से रुका है। Formatting और style टूल्स पर छोड़ें, ताकि इंसानी ध्यान logic, डिज़ाइन और टेस्ट पर जाए।
• Test plan review — scope और स्पष्ट रूप से out-of-scope चीज़ें, plan किन risks को संबोधित करता है, हर test level का approach, entry और exit criteria, environments और डेटा, ज़िम्मेदारियाँ और schedule जाँचें। बिना exit criteria का plan किसी को नहीं बता सकता कि टेस्टिंग कब पूरी हुई।
• Test case review — जाँचें कि हर case किसी requirement या acceptance criterion से जुड़ा है, preconditions और डेटा बताता है, उसका expected result देखा जा सकता है, और पूरा सेट negative व boundary cases बिना duplicates के कवर करता है। अच्छे test case की बनावट test cases लिखने वाली गाइड में है।

आज़माएँ: AI Acceptance Criteria रिव्यूअर आज़माएँ: AI टेस्ट केस ऑप्टिमाइज़र आज़माएँ: AI डुप्लिकेट टेस्ट केस डिटेक्टर आज़माएँ: AI टेस्ट कवरेज एनालाइज़र

Static analysis: टूल्स की श्रेणियाँ और वे क्या जाँचते हैं

Static analysis स्टैटिक टेस्टिंग का टूल-आधारित आधा हिस्सा है: एक प्रोग्राम कोड, मॉडल या संरचित डॉक्यूमेंट पढ़ता है और नियमों के उल्लंघन रिपोर्ट करता है। इसे औपचारिक संरचना चाहिए — प्रोग्रामिंग भाषा, schema, specification फ़ॉर्मैट — और यह उस पैमाने पर चलता है जिस पर इंसान नहीं चल सकते: linter हर बदलाव की हर लाइन, हर बार, सेकंडों में जाँचता है।

नीचे के नाम हर श्रेणी के जाने-माने उदाहरण हैं, कोई रैंकिंग नहीं। सही टूल वह है जो आपकी भाषाएँ सपोर्ट करे, आपकी pipeline में चले, और इतने कम false alarms दे कि टीम उसका आउटपुट पढ़ती रहे।

• Linters और style checkers — संदिग्ध constructs और conventions का उल्लंघन पकड़ते हैं: unused variables, unreachable code, shadowed names, छूटा हुआ await, असंगत formatting। उदाहरण: ESLint (JavaScript, TypeScript), Pylint और Ruff (Python), Checkstyle (Java), RuboCop (Ruby), ShellCheck (shell scripts), SQLFluff (SQL)।
• Type checkers और compilers — जाँचते हैं कि values अपने declared types के अनुसार इस्तेमाल हों, और execution से पहले null व type errors की पूरी श्रेणियाँ पकड़ते हैं। उदाहरण: TypeScript compiler, Python के लिए mypy, और Java, C#, Go, Rust जैसी statically typed भाषाओं के compilers।
• Static application security testing (SAST) — untrusted sources से ख़तरनाक sinks तक डेटा का रास्ता ट्रेस करता है और जानी-पहचानी कमज़ोरियों के पैटर्न मिलाता है: SQL injection, cross-site scripting, path traversal, कोड में लिखे secrets, कमज़ोर cryptography। उदाहरण: Semgrep, CodeQL, SonarQube, security plugins के साथ SpotBugs। OWASP बताता है कि source-code analysis टूल क्या कर सकते हैं और क्या नहीं, और NIST का SAMATE कार्यक्रम उनके मूल्यांकन के लिए test suites रखता है।
• Schema और specification validation — जाँचता है कि संरचित artefacts अपने specification के अनुसार valid हैं: JSON को JSON Schema के सामने, OpenAPI डॉक्यूमेंट को OpenAPI specification के सामने, XML की well-formedness, YAML और cron syntax। Spectral जैसे OpenAPI linters संरचनात्मक वैधता के ऊपर consistency और style नियम जोड़ते हैं।
• Complexity और maintainability metrics — cyclomatic complexity, function की लंबाई, duplication और coupling, जो reviewers को उस कोड की ओर ले जाते हैं जिसे टेस्ट करना और बदलना कठिन है।
• Dependency, secret और infrastructure scanners — declared dependencies को vulnerability databases से मिलाते हैं, commits में credentials खोजते हैं, और infrastructure-as-code व container फ़ाइलों में असुरक्षित settings देखते हैं। उदाहरण: npm audit और pip-audit, OWASP Dependency-Check, gitleaks, hadolint, Checkov।

# Illustrative findings from three kinds of static analysis
src/checkout/discount.ts:41:18  error  "rate" is possibly "undefined".              TS18048 (type checker)
src/checkout/discount.ts:57:3   error  Unreachable code.                              no-unreachable (linter)
src/orders/search.ts:22:9       error  SQL query built by concatenating request
                                       parameter "q"; use a parameterised query.   sql-injection (SAST)
openapi.yaml  paths./orders/{id}.get.responses
                                warn   Operation defines no 4xx response.           (contract linter)

आज़माएँ: OpenAPI वैलिडेटर आज़माएँ: JSON Schema वैलिडेटर आज़माएँ: SQL क्वेरी वैलिडेटर आज़माएँ: YAML फ़ॉर्मेटर

Static analysis क्या नहीं पकड़ सकता

Static analysis की साफ़ रिपोर्ट का मतलब है कि artefact उन नियमों पर खरा उतरा जो किसी ने लिखे थे। इससे यह पता नहीं चलता कि सॉफ़्टवेयर वह करता है जो उसके यूज़र्स को चाहिए।

हर टूल दो तरह की गलतियाँ भी करता है। False positives — ठीक कोड पर चेतावनियाँ — भरोसा घटाते हैं, यहाँ तक कि लोग रिपोर्ट पढ़ना बंद कर देते हैं; false negatives — टूल से छूटे defects — झूठा भरोसा पैदा करते हैं। Computability theory का एक क्लासिक नतीजा है कि कोई analyser हर मनमाने प्रोग्राम की हर non-trivial व्यवहारिक property तय नहीं कर सकता, इसलिए हर टूल इन दोनों गलतियों के बीच संतुलन बनाता है। Static analysis को review और dynamic टेस्ट से पहले का तेज़ फ़िल्टर मानें, अंतिम फ़ैसला नहीं।

• व्यवहार सही है या नहीं। टूल पुष्टि कर सकता है कि function एक संख्या लौटाता है; वह नहीं जानता कि संख्या में VAT शामिल होना चाहिए।
• छूटी या गलत समझी गई requirements। अगर story में refund का ज़िक्र ही नहीं था, तो कोई टूल नहीं बताएगा कि refund गायब है।
• Runtime और environment का व्यवहार: response time, असली लोड में memory, timeouts, असली services से integration, staging और production के बीच कॉन्फ़िगरेशन का अंतर।
• ज़्यादातर concurrency और timing defects, और वे defects जो सिर्फ़ runtime पर पहुँचने वाली खास डेटा वैल्यू पर निर्भर हैं।
• Usability, और keyboard या screen reader इस्तेमाल करने वाले के अनुभव वाली accessibility। Linters कुछ markup समस्याएँ पकड़ते हैं, जैसे बिना alt text वाली इमेज, पर यह नहीं कि पेज सच में इस्तेमाल हो सकता है या नहीं।

CI/CD pipeline में स्टैटिक टेस्टिंग

Static checks pipeline का सबसे सस्ता चरण हैं, इसलिए वे सबसे पहले और हर बदलाव पर चलते हैं।

• Editor में और pre-commit hooks में — formatters, linters और type checks commit बनने से पहले ही feedback देते हैं।
• हर pull request पर — lint, type check, SAST, schema और contract validation और secret scanning, नतीजे सीधे diff पर दिखें ताकि इंसानी reviewer उन्हें देखे।
• Quality gate के रूप में — तय severity से ऊपर के नए उल्लंघन merge रोकते हैं; legacy कोड के मौजूदा उल्लंघन baseline के रूप में दर्ज होकर धीरे-धीरे चुकाए जाते हैं, पहले ही दिन सबको रोकने के बजाय।
• Specification checks — OpenAPI, JSON Schema और कॉन्फ़िगरेशन फ़ाइलों को उसी pipeline में validate करें जिसमें उन पर निर्भर कोड बनता है, ताकि टूटा contract उसी build को fail करे जिसने उसे डाला।

# Illustrative stage order (commands are examples, not requirements)
stages:
  static-checks:
    - format-check        # formatter in check mode
    - lint                # e.g. eslint . --max-warnings=0
    - typecheck           # e.g. tsc --noEmit
    - validate-contracts  # OpenAPI and JSON Schema files
    - sast                # security rules on changed code
    - secret-scan
  unit-tests:          { needs: static-checks }
  integration-tests:   { needs: unit-tests }

शुरुआत की व्यावहारिक योजना

• एक formatter और एक linter छोटे, सहमत rule set के साथ जोड़ें; build सिर्फ़ नए उल्लंघनों पर fail करें।
• हर contract, schema और कॉन्फ़िगरेशन फ़ाइल को pipeline में validate करें।
• टेस्टरों को story refinement का हिस्सा बनाएँ और हर story को sprint में जाने से पहले requirements checklist से review करें।
• एक हल्की code review नीति तय करें: कौन review करेगा, merge किससे रुकेगा, बदलाव review के लिए कितनी देर रुक सकता है।
• औपचारिक inspection उन गिने-चुने वर्क प्रोडक्ट के लिए रखें जहाँ छूटा defect महँगा पड़ता है: payment और pricing rules, security-critical कोड, नियामक requirements, data migrations।

आज़माएँ: AI Requirement गैप एनालाइज़र आज़माएँ: AI Acceptance Criteria रिव्यूअर

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

संदर्भ

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• ISO/IEC 20246:2017 — Software and systems engineering — Work product reviewsISO/IEC · 2017वर्क प्रोडक्ट की समीक्षा का सामान्य फ़्रेमवर्क — review प्रक्रिया, भूमिकाएँ और review तकनीकें।
• IEEE 1028-2008 — IEEE Standard for Software Reviews and AuditsIEEE Standards Association · 2008management review, technical review, inspection, walkthrough और audit की क्लासिक परिभाषाएँ (IEEE इसे inactive-reserved के रूप में सूचीबद्ध करता है)।
• ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
• Source Code Analysis ToolsOWASP Foundationstatic application security testing (SAST) टूल क्या करते हैं, उनकी ताक़त और कमज़ोरियाँ, और कैसे चुनें।
• Software Assurance Metrics And Tool Evaluation (SAMATE)NISTसॉफ़्टवेयर assurance टूल — static analyzers सहित — के मूल्यांकन का NIST कार्यक्रम और उन्हें मापने वाले टेस्ट सूट।
• Code Review Developer GuideGoogle (eng-practices)Google की प्रकाशित code review प्रथाएँ: reviewer क्या देखते हैं, बदलाव मंज़ूर करने का मानक और review टिप्पणियाँ कैसे लिखें।