346

EN + हिं Easy

GB What is 'usability testing' and what insight does it provide that functional testing cannot?

IN 'प्रयोज्यता परीक्षण' क्या है और यह कौन सी अंतर्दृष्टि प्रदान करता है जो कार्यात्मक परीक्षण नहीं कर सकता?

A

Usability testing verifies that all buttons and links are functional and respond to user clicks प्रयोज्यता परीक्षण सत्यापित करता है कि सभी बटन और लिंक कार्यात्मक हैं और उपयोगकर्ता क्लिक पर प्रतिक्रिया देते हैं

B

Usability testing observes real users attempting real tasks — it reveals whether users can discover features, understand feedback, recover from errors, and achieve goals efficiently; functional tests verify the system works correctly but cannot detect that users cannot figure out how to use it प्रयोज्यता परीक्षण वास्तविक उपयोगकर्ताओं को वास्तविक कार्यों का प्रयास करते हुए देखता है - इससे पता चलता है कि क्या उपयोगकर्ता सुविधाओं की खोज कर सकते हैं, फीडबैक को समझ सकते हैं, त्रुटियों से उबर सकते हैं और लक्ष्यों को कुशलतापूर्वक प्राप्त कर सकते हैं; कार्यात्मक परीक्षण यह सत्यापित करते हैं कि सिस्टम सही ढंग से काम करता है लेकिन यह पता नहीं लगा सकता कि उपयोगकर्ता यह नहीं समझ पा रहे हैं कि इसका उपयोग कैसे किया जाए

C

Usability testing is only valid when conducted with at least 100 participants for statistical significance प्रयोज्यता परीक्षण केवल तभी मान्य होता है जब सांख्यिकीय महत्व के लिए कम से कम 100 प्रतिभागियों के साथ आयोजित किया जाता है

D

Usability testing is the responsibility of the marketing department, not the development team प्रयोज्यता परीक्षण विपणन विभाग की जिम्मेदारी है, विकास टीम की नहीं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Nielsen's '5 users find 85% of usability problems' research shows that small-scale usability testing is highly effective. Functional testing (does the password reset work?) tells you nothing about whether users can find the 'forgot password' link, interpret the error messages, or complete the flow without assistance. Usability testing reveals these discoverable-only-by-observation failures.

व्याख्या (हिन्दी) नील्सन के '5 उपयोगकर्ताओं को 85% प्रयोज्य समस्याएं मिलती हैं' शोध से पता चलता है कि छोटे पैमाने पर प्रयोज्य परीक्षण अत्यधिक प्रभावी है। कार्यात्मक परीक्षण (क्या पासवर्ड रीसेट काम करता है?) आपको इस बारे में कुछ नहीं बताता है कि उपयोगकर्ता 'पासवर्ड भूल गए' लिंक ढूंढ सकते हैं, त्रुटि संदेशों की व्याख्या कर सकते हैं, या सहायता के बिना प्रवाह पूरा कर सकते हैं। प्रयोज्यता परीक्षण इन खोज योग्य-केवल-अवलोकन विफलताओं को प्रकट करता है।

347

EN + हिं Easy

GB What is 'security testing' and what specific methodologies address different attack surfaces?

IN 'सुरक्षा परीक्षण' क्या है और कौन सी विशिष्ट पद्धतियाँ विभिन्न आक्रमण सतहों का समाधान करती हैं?

A

Security testing only verifies that user passwords are stored as encrypted hashes सुरक्षा परीक्षण केवल यह सत्यापित करता है कि उपयोगकर्ता पासवर्ड एन्क्रिप्टेड हैश के रूप में संग्रहीत हैं

B

Security testing identifies vulnerabilities before attackers; methodologies include: SAST (static analysis of source code), DAST (dynamic testing of running application), IAST (instrumented runtime analysis), and penetration testing (expert-driven exploitation attempts) सुरक्षा परीक्षण हमलावरों के सामने कमजोरियों की पहचान करता है; कार्यप्रणाली में शामिल हैं: SAST (स्रोत कोड का स्थैतिक विश्लेषण), DAST (चल रहे एप्लिकेशन का गतिशील परीक्षण), IAST (इंस्ट्रूमेंटेड रनटाइम विश्लेषण), और प्रवेश परीक्षण (विशेषज्ञ-संचालित शोषण प्रयास)

C

Security testing is only required for financial and healthcare applications under regulation विनियमन के तहत सुरक्षा परीक्षण केवल वित्तीय और स्वास्थ्य देखभाल अनुप्रयोगों के लिए आवश्यक है

D

Security testing is fully automatable and requires no human judgment or expertise सुरक्षा परीक्षण पूरी तरह से स्वचालित है और इसके लिए किसी मानवीय निर्णय या विशेषज्ञता की आवश्यकता नहीं है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) SAST (SonarQube, Checkmarx) finds SQL injection, XSS patterns in source code without running it — fast, catches early, high false positives. DAST (OWASP ZAP, Burp Suite) tests the running application like an attacker — finds runtime issues SAST misses, language-agnostic. Penetration testing (human experts) chains vulnerabilities creatively to find attack paths automation misses. Effective security testing requires all layers.

व्याख्या (हिन्दी) एसएएसटी (सोनारक्यूब, चेकमार्क्स) एसक्यूएल इंजेक्शन, एक्सएसएस पैटर्न को बिना चलाए स्रोत कोड में ढूंढता है - तेज, जल्दी पकड़ता है, उच्च झूठी सकारात्मकता। DAST (OWASP ZAP, बर्प सुइट) एक हमलावर की तरह चल रहे एप्लिकेशन का परीक्षण करता है - रनटाइम समस्याओं का पता लगाता है SAST चूक जाता है, भाषा-अज्ञेयवादी। पेनेट्रेशन परीक्षण (मानव विशेषज्ञ) हमले के रास्ते स्वचालन चूक को खोजने के लिए रचनात्मक रूप से कमजोरियों को जोड़ते हैं। प्रभावी सुरक्षा परीक्षण के लिए सभी परतों की आवश्यकता होती है।

348

EN + हिं Easy

GB What is 'chaos engineering' and what testing limitation does it address that traditional testing cannot?

IN 'अराजकता इंजीनियरिंग' क्या है और यह किस परीक्षण सीमा को संबोधित करती है जिसे पारंपरिक परीक्षण नहीं कर सकता?

A

Chaos engineering deliberately introduces bugs into code to verify the test suite catches them कैओस इंजीनियरिंग जानबूझकर कोड में बग पेश करती है ताकि यह सत्यापित किया जा सके कि परीक्षण सूट उन्हें पकड़ लेता है

B

Chaos engineering deliberately injects failures (network latency, server crashes, disk exhaustion) into production-like environments to proactively discover system resilience weaknesses — addressing the limitation that traditional tests cannot verify distributed system behaviour under partial failure conditions कैओस इंजीनियरिंग जानबूझकर सिस्टम लचीलापन कमजोरियों की खोज करने के लिए उत्पादन जैसे वातावरण में विफलताओं (नेटवर्क विलंबता, सर्वर क्रैश, डिस्क थकावट) को इंजेक्ट करती है - इस सीमा को संबोधित करते हुए कि पारंपरिक परीक्षण आंशिक विफलता स्थितियों के तहत वितरित सिस्टम व्यवहार को सत्यापित नहीं कर सकते हैं

C

Chaos engineering is a branch of performance testing for measuring throughput under random load कैओस इंजीनियरिंग यादृच्छिक भार के तहत थ्रूपुट को मापने के लिए प्रदर्शन परीक्षण की एक शाखा है

D

Chaos engineering was developed by Microsoft Research as a formal testing methodology कैओस इंजीनियरिंग को माइक्रोसॉफ्ट रिसर्च द्वारा एक औपचारिक परीक्षण पद्धति के रूप में विकसित किया गया था

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Netflix's Chaos Monkey (2010) introduced chaos engineering by randomly terminating production instances. Traditional tests verify components work in isolation; they cannot verify that Netflix's recommendation service correctly falls back when its database is slow. Chaos engineering validates distributed system resilience under real failure conditions: 'If we randomly crash a service, does the system gracefully degrade or catastrophically fail?'

व्याख्या (हिन्दी) नेटफ्लिक्स के कैओस मंकी (2010) ने उत्पादन उदाहरणों को बेतरतीब ढंग से समाप्त करके अराजकता इंजीनियरिंग की शुरुआत की। पारंपरिक परीक्षण यह सत्यापित करते हैं कि घटक अलगाव में काम करते हैं; वे यह सत्यापित नहीं कर सकते कि डेटाबेस धीमा होने पर नेटफ्लिक्स की अनुशंसा सेवा सही ढंग से वापस आ जाती है। कैओस इंजीनियरिंग वास्तविक विफलता स्थितियों के तहत वितरित सिस्टम लचीलेपन को मान्य करती है: 'यदि हम किसी सेवा को बेतरतीब ढंग से क्रैश कर देते हैं, तो क्या सिस्टम शानदार ढंग से ख़राब हो जाता है या भयावह रूप से विफल हो जाता है?'

349

EN + हिं Easy

GB What is 'traceability matrix' in testing and what governance problem does it solve in regulated industries?

IN परीक्षण में 'ट्रेसेबिलिटी मैट्रिक्स' क्या है और यह विनियमित उद्योगों में किस शासन समस्या का समाधान करता है?

A

Traceability matrix is a tool for tracking which developers wrote which test cases ट्रैसेबिलिटी मैट्रिक्स ट्रैकिंग के लिए एक उपकरण है कि कौन से डेवलपर्स ने कौन से परीक्षण मामले लिखे हैं

B

A traceability matrix maps requirements to test cases bidirectionally — solving the regulated industry problem of proving to auditors that every requirement has been tested and every test corresponds to a requirement, enabling gap analysis and change impact assessment एक ट्रैसेबिलिटी मैट्रिक्स मामलों का द्विदिश परीक्षण करने के लिए आवश्यकताओं को मैप करता है - लेखा परीक्षकों को यह साबित करने की विनियमित उद्योग समस्या को हल करता है कि प्रत्येक आवश्यकता का परीक्षण किया गया है और प्रत्येक परीक्षण एक आवश्यकता से मेल खाता है, अंतर विश्लेषण और परिवर्तन प्रभाव मूल्यांकन को सक्षम करता है

C

Traceability matrices are only useful for projects with more than 1000 test cases ट्रैसेबिलिटी मैट्रिसेस केवल 1000 से अधिक परीक्षण मामलों वाली परियोजनाओं के लिए उपयोगी हैं

D

Traceability matrix is automatically generated by all modern test management tools ट्रैसेबिलिटी मैट्रिक्स सभी आधुनिक परीक्षण प्रबंधन उपकरणों द्वारा स्वचालित रूप से उत्पन्न होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) FDA (medical devices), FAA (avionics), and MISRA (automotive) regulations require proof that every specified requirement has test coverage. The traceability matrix is that proof: R1 → TC-1, TC-15; R2 → TC-3; etc. Change impact: if R7 changes, which test cases must be updated? Without traceability, this is detective work; with it, it's a lookup.

व्याख्या (हिन्दी) एफडीए (चिकित्सा उपकरण), एफएए (एवियोनिक्स), और एमआईएसआरए (ऑटोमोटिव) नियमों के लिए प्रमाण की आवश्यकता होती है कि प्रत्येक निर्दिष्ट आवश्यकता में परीक्षण कवरेज है। ट्रैसेबिलिटी मैट्रिक्स वह प्रमाण है: R1 → TC-1, TC-15; आर2 → टीसी-3; आदि। परिवर्तन प्रभाव: यदि R7 बदलता है, तो कौन से परीक्षण मामलों को अद्यतन किया जाना चाहिए? पता लगाने की क्षमता के बिना, यह जासूसी का काम है; इसके साथ, यह एक लुकअप है।

350

EN + हिं Easy

GB What is the 'shift-left' testing philosophy and what measurable quality improvement does it deliver?

IN 'शिफ्ट-लेफ्ट' परीक्षण दर्शन क्या है और यह किस मापनीय गुणवत्ता में सुधार प्रदान करता है?

A

Shift-left testing means moving all testing activities to a dedicated test team at project start शिफ्ट-लेफ्ट परीक्षण का अर्थ है प्रोजेक्ट प्रारंभ में सभी परीक्षण गतिविधियों को एक समर्पित परीक्षण टीम में ले जाना

B

Shift-left moves testing activities earlier in the development lifecycle — starting testing at requirements (inspections, test planning) and design (design reviews, testability assessment) rather than after implementation, reducing defect cost by catching them at their cheapest fix point शिफ्ट-लेफ्ट परीक्षण गतिविधियों को विकास जीवनचक्र में पहले ले जाता है - कार्यान्वयन के बजाय आवश्यकताओं (निरीक्षण, परीक्षण योजना) और डिज़ाइन (डिज़ाइन समीक्षा, परीक्षण क्षमता मूल्यांकन) पर परीक्षण शुरू करना, दोष लागत को उनके सबसे सस्ते फिक्स बिंदु पर पकड़कर कम करना

C

Shift-left testing eliminates the need for dedicated QA teams by making developers responsible for all quality शिफ्ट-लेफ्ट परीक्षण डेवलपर्स को सभी गुणवत्ता के लिए जिम्मेदार बनाकर समर्पित क्यूए टीमों की आवश्यकता को समाप्त कर देता है

D

Shift-left only applies to unit testing; system and acceptance testing cannot be shifted left शिफ्ट-लेफ्ट केवल यूनिट परीक्षण पर लागू होता है; सिस्टम और स्वीकृति परीक्षण को बाईं ओर स्थानांतरित नहीं किया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Boehm's cost-of-change curve makes the ROI clear: defects found in requirements cost 1x; in testing cost 40-100x; in production cost 100-200x. Shift-left practices (requirements inspections, design reviews, static analysis, TDD) systematically move detection to the left side of the curve. IBM, HP, and NASA studies all show 10:1+ ROI from early defect detection versus late.

व्याख्या (हिन्दी) बोहेम का परिवर्तन लागत वक्र आरओआई को स्पष्ट करता है: आवश्यकताओं में पाए गए दोषों की लागत 1x है; परीक्षण लागत में 40-100x; उत्पादन लागत में 100-200x. शिफ्ट-लेफ्ट प्रथाएं (आवश्यकताओं का निरीक्षण, डिजाइन समीक्षा, स्थैतिक विश्लेषण, टीडीडी) व्यवस्थित रूप से पता लगाने को वक्र के बाईं ओर ले जाती हैं। आईबीएम, एचपी और नासा के सभी अध्ययन दोष का जल्दी पता लगाने की तुलना में देर से पता लगाने से 10:1+ आरओआई दर्शाते हैं।

351

EN + हिं Easy

GB What is 'testing in production' (TiP) and what risk controls make it safe?

IN 'उत्पादन में परीक्षण' (टीआईपी) क्या है और कौन से जोखिम नियंत्रण इसे सुरक्षित बनाते हैं?

A

Testing in production means deliberately deploying buggy code to observe real user failures उत्पादन में परीक्षण का अर्थ है वास्तविक उपयोगकर्ता विफलताओं का निरीक्षण करने के लिए जानबूझकर बग्गी कोड को तैनात करना

B

TiP runs tests/experiments against real production traffic using real user data — safe through: canary releases (1% traffic first), feature flags (instant rollback), dark launches (run new code without returning its results), and monitoring/alerting to detect anomalies before full rollout TiP वास्तविक उपयोगकर्ता डेटा का उपयोग करके वास्तविक उत्पादन ट्रैफ़िक के विरुद्ध परीक्षण/प्रयोग चलाता है - इसके माध्यम से सुरक्षित: कैनरी रिलीज़ (पहले 1% ट्रैफ़िक), फ़ीचर फ़्लैग (तत्काल रोलबैक), डार्क लॉन्च (इसके परिणाम लौटाए बिना नया कोड चलाना), और पूर्ण रोलआउट से पहले विसंगतियों का पता लगाने के लिए निगरानी/चेतावनी

C

Testing in production is universally prohibited because it risks data corruption for real users उत्पादन में परीक्षण सार्वभौमिक रूप से निषिद्ध है क्योंकि इससे वास्तविक उपयोगकर्ताओं के लिए डेटा भ्रष्टाचार का जोखिम होता है

D

TiP only works for read-only operations; write operations can never be tested in production TiP केवल रीड-ओनली ऑपरेशंस के लिए काम करता है; लेखन संचालन का उत्पादन में कभी भी परीक्षण नहीं किया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Pre-production environments can never perfectly replicate production: real data volumes, real usage patterns, real hardware failures. Netflix, Facebook, and LinkedIn deliberately test in production because that's where reality is. Safety controls: canary release gradually exposes new code; feature flags enable instant disable; dark launches run code without serving results; observability catches anomalies before widespread impact.

व्याख्या (हिन्दी) प्री-प्रोडक्शन वातावरण कभी भी उत्पादन को पूरी तरह से दोहरा नहीं सकता: वास्तविक डेटा वॉल्यूम, वास्तविक उपयोग पैटर्न, वास्तविक हार्डवेयर विफलताएं। नेटफ्लिक्स, फेसबुक और लिंक्डइन जानबूझकर उत्पादन में परीक्षण करते हैं क्योंकि वास्तविकता यहीं है। सुरक्षा नियंत्रण: कैनरी रिलीज़ धीरे-धीरे नए कोड को उजागर करता है; फ़ीचर फ़्लैग तत्काल अक्षम को सक्षम करते हैं; डार्क ने परिणाम दिए बिना रन कोड लॉन्च किया; व्यापक प्रभाव से पहले ही अवलोकनीयता विसंगतियों को पकड़ लेती है।

352

EN + हिं Medium

GB What is 'test impact analysis' and how does it use code change information to optimise CI test selection?

IN 'परीक्षण प्रभाव विश्लेषण' क्या है और यह सीआई परीक्षण चयन को अनुकूलित करने के लिए कोड परिवर्तन जानकारी का उपयोग कैसे करता है?

A

Test impact analysis evaluates the business impact of defects found during testing परीक्षण प्रभाव विश्लेषण परीक्षण के दौरान पाए गए दोषों के व्यावसायिक प्रभाव का मूल्यांकन करता है

B

Test impact analysis instruments the test suite to record which source files each test exercises, then on each commit selects only tests whose coverage intersects with changed files — running only tests that could possibly be affected by the specific code changes परीक्षण प्रभाव विश्लेषण उपकरण परीक्षण सूट को रिकॉर्ड करता है कि कौन सा स्रोत प्रत्येक परीक्षण अभ्यास को फाइल करता है, फिर प्रत्येक कमिट पर केवल उन परीक्षणों का चयन करता है जिनकी कवरेज बदली हुई फाइलों के साथ प्रतिच्छेद करती है - केवल ऐसे परीक्षण चला रहे हैं जो संभवतः विशिष्ट कोड परिवर्तनों से प्रभावित हो सकते हैं

C

Test impact analysis is only possible in compiled languages; dynamic languages cannot support it परीक्षण प्रभाव विश्लेषण केवल संकलित भाषाओं में ही संभव है; गतिशील भाषाएँ इसका समर्थन नहीं कर सकतीं

D

Test impact analysis always runs fewer tests but provides lower confidence than running all tests परीक्षण प्रभाव विश्लेषण हमेशा कम परीक्षण चलाता है लेकिन सभी परीक्षण चलाने की तुलना में कम आत्मविश्वास प्रदान करता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Microsoft's research on test impact analysis (TABIA) showed 95%+ reduction in tests run per commit while maintaining near-identical defect detection rates for Microsoft Office. By mapping each test to its covered source files, when only File A changes, only tests that touch File A need to run. This makes CI feedback 10-100x faster without sacrificing safety.

व्याख्या (हिन्दी) परीक्षण प्रभाव विश्लेषण (टीएबीआईए) पर माइक्रोसॉफ्ट के शोध ने माइक्रोसॉफ्ट ऑफिस के लिए लगभग समान दोष पहचान दरों को बनाए रखते हुए प्रति कमिट किए गए परीक्षणों में 95%+ की कमी दिखाई। प्रत्येक परीक्षण को उसकी कवर की गई स्रोत फ़ाइलों में मैप करके, जब केवल फ़ाइल ए बदलती है, तो केवल फ़ाइल ए को छूने वाले परीक्षणों को चलाने की आवश्यकता होती है। यह सुरक्षा से समझौता किए बिना सीआई फीडबैक को 10-100 गुना तेज बनाता है।

353

EN + हिं Medium

GB What is 'flaky test' and why is it considered more damaging to CI effectiveness than a simply failing test?

IN 'परतदार परीक्षण' क्या है और इसे केवल असफल परीक्षण की तुलना में सीआई प्रभावशीलता के लिए अधिक हानिकारक क्यों माना जाता है?

A

Flaky tests are tests written by junior developers that have poor assertions फ़्लैकी परीक्षण जूनियर डेवलपर्स द्वारा लिखे गए परीक्षण हैं जिनका दावा ख़राब है

B

A flaky test non-deterministically passes or fails for the same code — more damaging than a consistently failing test because it trains developers to ignore CI failures ('it's probably flaky') rather than investigate, eroding the entire team's trust in the CI safety net एक परतदार परीक्षण गैर-नियतात्मक रूप से एक ही कोड के लिए पास या विफल हो जाता है - लगातार विफल होने वाले परीक्षण से अधिक हानिकारक क्योंकि यह डेवलपर्स को जांच करने के बजाय सीआई विफलताओं ('यह शायद परतदार है') को नजरअंदाज करने के लिए प्रशिक्षित करता है, जिससे सीआई सुरक्षा जाल में पूरी टीम का भरोसा खत्म हो जाता है।

C

Flaky tests are only a problem in JavaScript test frameworks like Jest and Mocha परतदार परीक्षण केवल जेस्ट और मोचा जैसे जावास्क्रिप्ट परीक्षण ढांचे में एक समस्या है

D

Flaky tests can be safely ignored if they pass more than 90% of the time statistically यदि परतदार परीक्षण सांख्यिकीय रूप से 90% से अधिक समय पास कर लेते हैं, तो उन्हें सुरक्षित रूप से अनदेखा किया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Google identified flaky tests as one of the biggest threats to CI effectiveness. When tests fail randomly, developers stop rerunning them to verify — they just rerun hoping it passes, or ignore failures. This 'cry wolf' effect means real regressions are ignored alongside flaky false alarms. Google quarantines flaky tests (removes from blocking CI) and requires immediate fix — treating flakiness as a P1 defect.

व्याख्या (हिन्दी) Google ने परतदार परीक्षणों को सीआई प्रभावशीलता के लिए सबसे बड़े खतरों में से एक के रूप में पहचाना। जब परीक्षण अनियमित रूप से विफल हो जाते हैं, तो डेवलपर्स सत्यापित करने के लिए उन्हें दोबारा चलाना बंद कर देते हैं - वे बस यह उम्मीद करते हैं कि यह सफल हो जाए, या विफलताओं को अनदेखा कर देते हैं। इस 'क्राई वुल्फ' प्रभाव का मतलब है कि परतदार झूठे अलार्म के साथ-साथ वास्तविक प्रतिगमन को नजरअंदाज कर दिया जाता है। Google परतदार परीक्षणों को अलग करता है (सीआई को अवरुद्ध करने से बचाता है) और तत्काल सुधार की आवश्यकता है - परतदारपन को P1 दोष के रूप में मानना।

354

EN + हिं Medium

GB What is 'test-driven infrastructure' (TDI) in DevOps and how does it extend the TDD principle?

IN DevOps में 'परीक्षण-संचालित बुनियादी ढांचा' (TDI) क्या है और यह TDD सिद्धांत का विस्तार कैसे करता है?

A

TDI means writing unit tests for infrastructure deployment scripts only टीडीआई का मतलब केवल बुनियादी ढांचा परिनियोजन स्क्रिप्ट के लिए यूनिट परीक्षण लिखना है

B

TDI applies TDD to infrastructure code: tests for server configuration, network policies, and deployment scripts are written first (using tools like ServerSpec, InSpec, Terraform test) — verifying infrastructure behaves as specified before and after changes, exactly as TDD verifies application code टीडीआई इन्फ्रास्ट्रक्चर कोड पर टीडीडी लागू करता है: सर्वर कॉन्फ़िगरेशन, नेटवर्क नीतियों और परिनियोजन स्क्रिप्ट के लिए परीक्षण पहले लिखे जाते हैं (सर्वरस्पेक, इनस्पेक, टेराफॉर्म टेस्ट जैसे टूल का उपयोग करके) - इन्फ्रास्ट्रक्चर की पुष्टि करना परिवर्तनों से पहले और बाद में निर्दिष्ट व्यवहार करता है, ठीक उसी तरह जैसे टीडीडी एप्लिकेशन कोड को सत्यापित करता है

C

TDI replaces all monitoring and alerting in production with pre-deployment tests टीडीआई उत्पादन में सभी निगरानी और चेतावनी को पूर्व-परिनियोजन परीक्षणों से बदल देता है

D

TDI only applies to containerised environments using Kubernetes and Docker टीडीआई केवल कुबेरनेट्स और डॉकर का उपयोग करके कंटेनरीकृत वातावरण पर लागू होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Infrastructure as Code (Terraform, Ansible, Puppet) is real code and shares application code's failure modes: untested changes break production. TDI writes tests like 'port 443 must be open', 'service X must be running', 'this file must have permissions 600' before changing infrastructure. The CI pipeline runs these tests against actual (test environment) infrastructure, catching misconfigurations before production deployment.

व्याख्या (हिन्दी) कोड के रूप में इन्फ्रास्ट्रक्चर (टेराफॉर्म, एन्सिबल, पपेट) वास्तविक कोड है और एप्लिकेशन कोड के विफलता मोड को साझा करता है: अप्रयुक्त परिवर्तन उत्पादन को तोड़ देते हैं। टीडीआई बुनियादी ढांचे को बदलने से पहले 'पोर्ट 443 खुला होना चाहिए', 'सर्विस एक्स चालू होना चाहिए', 'इस फ़ाइल में अनुमतियाँ 600 होनी चाहिए' जैसे परीक्षण लिखता है। सीआई पाइपलाइन इन परीक्षणों को वास्तविक (परीक्षण पर्यावरण) बुनियादी ढांचे के खिलाफ चलाती है, उत्पादन तैनाती से पहले गलत कॉन्फ़िगरेशन को पकड़ती है।

355

EN + हिं

GB What is 'core dump analysis' and what specific class of production bugs can only be diagnosed this way?

IN 'कोर डंप विश्लेषण' क्या है और उत्पादन बग के किस विशिष्ट वर्ग का निदान केवल इस तरह से किया जा सकता है?

A

Core dump analysis reconstructs the project requirements from binary deployment artifacts कोर डंप विश्लेषण बाइनरी परिनियोजन कलाकृतियों से परियोजना आवश्यकताओं का पुनर्निर्माण करता है

B

Core dump analysis examines the saved memory state at the moment of a crash — uniquely diagnosing bugs that only manifest in production under specific data/load conditions and disappear when a debugger is attached (Heisenbugs) or the environment is changed कोर डंप विश्लेषण क्रैश के समय सहेजी गई मेमोरी स्थिति की जांच करता है - विशिष्ट रूप से बग का निदान करता है जो केवल विशिष्ट डेटा/लोड स्थितियों के तहत उत्पादन में प्रकट होते हैं और डिबगर संलग्न होने पर गायब हो जाते हैं (हेइज़नबग्स) या पर्यावरण बदल जाता है

C

Core dump analysis only works for programs written in C and C++ कोर डंप विश्लेषण केवल C और C++ में लिखे गए प्रोग्रामों के लिए काम करता है

D

Core dumps are too large to be practically useful; log analysis is always superior कोर डंप व्यावहारिक रूप से उपयोगी होने के लिए बहुत बड़े हैं; लॉग विश्लेषण हमेशा बेहतर होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) GDB, LLDB, and WinDbg can load core dumps to inspect the exact memory state: call stack at crash, values of all variables, heap contents. This diagnoses: null pointer dereferences (what was the null pointer? which object should it have pointed to?), stack overflows (what is the call chain that caused the stack exhaustion?), and data corruption (what value was written where it shouldn't have been?).

व्याख्या (हिन्दी) जीडीबी, एलएलडीबी, और विनडीबीजी सटीक मेमोरी स्थिति का निरीक्षण करने के लिए कोर डंप लोड कर सकते हैं: क्रैश पर कॉल स्टैक, सभी चर के मान, ढेर सामग्री। यह निदान करता है: नल पॉइंटर डेरेफ़रेंस (नल पॉइंटर क्या था? इसे किस ऑब्जेक्ट की ओर इंगित करना चाहिए था?), स्टैक ओवरफ्लो (कॉल चेन क्या है जिसके कारण स्टैक थकावट हुई?), और डेटा भ्रष्टाचार (कौन सा मान वहां लिखा गया था जहां इसे नहीं होना चाहिए था?)।

356

EN + हिं Hard

GB What is 'debuggability' as a software quality attribute and what design decisions most improve it?

IN सॉफ़्टवेयर गुणवत्ता विशेषता के रूप में 'डिबगबिलिटी' क्या है और कौन से डिज़ाइन निर्णय इसमें सबसे अधिक सुधार करते हैं?

A

Debuggability is improved by removing all abstractions and writing flat procedural code सभी अमूर्तताओं को हटाकर और फ्लैट प्रक्रियात्मक कोड लिखकर डिबगबिलिटी में सुधार किया जाता है

B

Debuggability is the ease with which failures can be diagnosed — improved by: centralised structured logging, correlation IDs through all layers, explicit error messages with context, health endpoints, observable internal state, and minimal side effects that make execution traceable डिबगबिलिटी वह आसानी है जिसके साथ विफलताओं का निदान किया जा सकता है - इसमें सुधार किया गया है: केंद्रीकृत संरचित लॉगिंग, सभी परतों के माध्यम से सहसंबंध आईडी, संदर्भ के साथ स्पष्ट त्रुटि संदेश, स्वास्थ्य समापन बिंदु, अवलोकन योग्य आंतरिक स्थिति, और न्यूनतम दुष्प्रभाव जो निष्पादन को ट्रैक करने योग्य बनाते हैं

C

Debuggability is automatically maximised by using a strongly-typed programming language दृढ़ता से टाइप की गई प्रोग्रामिंग भाषा का उपयोग करके डिबगबिलिटी स्वचालित रूप से अधिकतम हो जाती है

D

Debuggability and performance are always in perfect alignment — improving one always improves the other डिबगबिलिटी और प्रदर्शन हमेशा सही संरेखण में होते हैं - एक में सुधार करने से हमेशा दूसरे में सुधार होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Debuggability is a design quality that must be planned for, not added after. Decisions that harm debuggability: swallowing exceptions silently, using generic error messages ('an error occurred'), fire-and-forget async operations without correlation IDs, deeply nested call chains with no logging. Each removes a trail that would lead to the fault. Netflix, Google, and Amazon design for debuggability explicitly as a system property.

व्याख्या (हिन्दी) डिबगबिलिटी एक डिज़ाइन गुणवत्ता है जिसके लिए योजना बनाई जानी चाहिए, बाद में नहीं जोड़ी जानी चाहिए। निर्णय जो डिबगबिलिटी को नुकसान पहुंचाते हैं: अपवादों को चुपचाप निगलना, सामान्य त्रुटि संदेशों ('एक त्रुटि हुई') का उपयोग करना, सहसंबंध आईडी के बिना एसिंक ऑपरेशंस को आग लगाना और भूल जाना, बिना लॉगिंग के गहराई से नेस्टेड कॉल चेन। प्रत्येक उस निशान को हटाता है जो गलती की ओर ले जाता है। नेटफ्लिक्स, गूगल और अमेज़ॅन स्पष्ट रूप से एक सिस्टम प्रॉपर्टी के रूप में डिबगबिलिटी के लिए डिज़ाइन करते हैं।

357

EN + हिं Easy

GB What is 'breakpoint management' in large codebases and what discipline is needed to avoid breakpoint chaos?

IN बड़े कोडबेस में 'ब्रेकपॉइंट प्रबंधन' क्या है और ब्रेकपॉइंट अराजकता से बचने के लिए किस अनुशासन की आवश्यकता है?

A

Breakpoint management is a source control feature for saving and sharing breakpoints with team members ब्रेकप्वाइंट प्रबंधन टीम के सदस्यों के साथ ब्रेकप्वाइंट को सहेजने और साझा करने के लिए एक स्रोत नियंत्रण सुविधा है

B

In complex multi-session debugging, accumulated stale breakpoints in wrong files cause debuggers to stop at irrelevant points, wasting time — discipline requires: clearing all breakpoints before each debugging session, naming conditional breakpoints, and using focused logpoints instead of code-modifying prints जटिल बहु-सत्र डिबगिंग में, गलत फ़ाइलों में संचित बासी ब्रेकप्वाइंट के कारण डिबगर्स अप्रासंगिक बिंदुओं पर रुक जाते हैं, जिससे समय बर्बाद होता है - अनुशासन की आवश्यकता होती है: प्रत्येक डिबगिंग सत्र से पहले सभी ब्रेकप्वाइंट को साफ़ करना, सशर्त ब्रेकप्वाइंट का नामकरण करना, और कोड-संशोधित प्रिंट के बजाय केंद्रित लॉगप्वाइंट का उपयोग करना

C

Breakpoints have no management overhead because modern IDEs automatically track and remove them ब्रेकप्वाइंट का कोई प्रबंधन ओवरहेड नहीं है क्योंकि आधुनिक आईडीई स्वचालित रूप से उन्हें ट्रैक करते हैं और हटा देते हैं

D

More breakpoints always improve debugging efficiency by providing more observation points अधिक ब्रेकप्वाइंट हमेशा अधिक अवलोकन बिंदु प्रदान करके डिबगिंग दक्षता में सुधार करते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Experienced debuggers maintain a discipline: clear all breakpoints at session start, add only what you need for the current hypothesis. IDEs like VS Code and IntelliJ support breakpoint groups, conditional breakpoints (only trigger when x > 0), hit count breakpoints (trigger on 5th call), and logpoints (log without pausing) — these reduce the cognitive load of managing many observation points.

व्याख्या (हिन्दी) अनुभवी डिबगर्स एक अनुशासन बनाए रखते हैं: सत्र शुरू होने पर सभी ब्रेकप्वाइंट साफ़ करें, केवल वही जोड़ें जो आपको वर्तमान परिकल्पना के लिए चाहिए। वीएस कोड और इंटेलीजे जैसे आईडीई ब्रेकप्वाइंट समूहों, सशर्त ब्रेकप्वाइंट (केवल x > 0 होने पर ट्रिगर), हिट काउंट ब्रेकप्वाइंट (5वीं कॉल पर ट्रिगर), और लॉगप्वाइंट (बिना रुके लॉग) का समर्थन करते हैं - ये कई अवलोकन बिंदुओं को प्रबंधित करने के संज्ञानात्मक भार को कम करते हैं।

358

EN + हिं Easy

GB What is a 'debugger trap' instruction and what security implication does it have in production code?

IN 'डीबगर ट्रैप' निर्देश क्या है और उत्पादन कोड में इसका क्या सुरक्षा निहितार्थ है?

A

Debugger trap instruction terminates the program immediately regardless of attached debugger डिबगर ट्रैप निर्देश संलग्न डिबगर की परवाह किए बिना प्रोग्राम को तुरंत समाप्त कर देता है

B

A debugger trap (INT 3 on x86, BKPT on ARM) halts execution and transfers control to an attached debugger; in production code without a debugger, it causes a crash — anti-debugging techniques (debugger detection) sometimes use this to detect reverse engineering attempts एक डिबगर ट्रैप (x86 पर INT 3, ARM पर BKPT) निष्पादन रोक देता है और नियंत्रण को एक संलग्न डिबगर में स्थानांतरित कर देता है; डिबगर के बिना उत्पादन कोड में, यह क्रैश का कारण बनता है - एंटी-डिबगिंग तकनीक (डीबगर डिटेक्शन) कभी-कभी रिवर्स इंजीनियरिंग प्रयासों का पता लगाने के लिए इसका उपयोग करती है

C

Debugger trap instructions are only valid in assembly language and cannot appear in high-level compiled code डिबगर ट्रैप निर्देश केवल असेंबली भाषा में मान्य हैं और उच्च-स्तरीय संकलित कोड में प्रकट नहीं हो सकते हैं

D

Debugger trap instructions have no security implications and are safe in any production system डिबगर ट्रैप निर्देशों का कोई सुरक्षा निहितार्थ नहीं है और ये किसी भी उत्पादन प्रणाली में सुरक्षित हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) In debug builds, INT 3 inserted by breakpoints is safe — the debugger catches it. In production, accidentally shipping INT 3 (e.g., a debug build in production) crashes the process for any user. Malware uses INT 3 chains as an anti-analysis technique: if execution reaches INT 3 and no debugger is attached, it crashes (anti-sandbox); if a debugger catches it, the malware changes behaviour (anti-analysis). Security-sensitive code must be audited for debug artifacts before production deployment.

व्याख्या (हिन्दी) डिबग बिल्ड में, ब्रेकप्वाइंट द्वारा डाला गया INT 3 सुरक्षित है - डिबगर इसे पकड़ लेता है। उत्पादन में, गलती से INT 3 की शिपिंग (उदाहरण के लिए, उत्पादन में एक डिबग बिल्ड) किसी भी उपयोगकर्ता के लिए प्रक्रिया को क्रैश कर देती है। मैलवेयर एंटी-एनालिसिस तकनीक के रूप में INT 3 चेन का उपयोग करता है: यदि निष्पादन INT 3 तक पहुंचता है और कोई डिबगर संलग्न नहीं है, तो यह क्रैश हो जाता है (एंटी-सैंडबॉक्स); यदि कोई डिबगर इसे पकड़ लेता है, तो मैलवेयर व्यवहार बदल देता है (एंटी-एनालिसिस)। उत्पादन परिनियोजन से पहले डिबग कलाकृतियों के लिए सुरक्षा-संवेदनशील कोड का ऑडिट किया जाना चाहिए।

359

EN + हिं Easy

GB What is 'software asset management' in maintenance and what financial implication does inadequate tracking create?

IN रखरखाव में 'सॉफ़्टवेयर परिसंपत्ति प्रबंधन' क्या है और अपर्याप्त ट्रैकिंग क्या वित्तीय निहितार्थ पैदा करती है?

A

Software asset management refers to version control for source code repositories सॉफ़्टवेयर परिसंपत्ति प्रबंधन स्रोत कोड रिपॉजिटरी के लिए संस्करण नियंत्रण को संदर्भित करता है

B

Software asset management tracks all software licenses, versions, and usage across an organisation — inadequate tracking creates: license compliance violations (fines), paying for unused licenses, or running unsupported/unpatched software creating security liability सॉफ़्टवेयर परिसंपत्ति प्रबंधन किसी संगठन में सभी सॉफ़्टवेयर लाइसेंस, संस्करण और उपयोग को ट्रैक करता है - अपर्याप्त ट्रैकिंग उत्पन्न करती है: लाइसेंस अनुपालन उल्लंघन (जुर्माना), अप्रयुक्त लाइसेंस के लिए भुगतान करना, या असमर्थित/अप्रकाशित सॉफ़्टवेयर चलाने से सुरक्षा दायित्व उत्पन्न होता है

C

Software asset management is only required for organisations with more than 1000 employees सॉफ़्टवेयर परिसंपत्ति प्रबंधन केवल 1000 से अधिक कर्मचारियों वाले संगठनों के लिए आवश्यक है

D

Software asset management is entirely automated by cloud providers and requires no manual tracking सॉफ़्टवेयर परिसंपत्ति प्रबंधन क्लाउड प्रदाताओं द्वारा पूरी तरह से स्वचालित है और इसके लिए किसी मैन्युअल ट्रैकिंग की आवश्यकता नहीं होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) BSA (Business Software Alliance) audits have resulted in multi-million dollar settlements for companies running unlicensed software. Conversely, organisations routinely pay for 30% more licenses than they use. Software asset management (ISO 19770) provides the inventory, entitlements, and usage data needed to optimise license spend, ensure compliance, and maintain a patched, supported software estate.

व्याख्या (हिन्दी) BSA (Business Software Alliance) audits have resulted in multi-million dollar settlements for companies running unlicensed software. इसके विपरीत, संगठन नियमित रूप से उपयोग की तुलना में 30% अधिक लाइसेंस के लिए भुगतान करते हैं। सॉफ़्टवेयर परिसंपत्ति प्रबंधन (आईएसओ 19770) लाइसेंस व्यय को अनुकूलित करने, अनुपालन सुनिश्चित करने और एक पैच किए गए, समर्थित सॉफ़्टवेयर संपदा को बनाए रखने के लिए आवश्यक सूची, पात्रता और उपयोग डेटा प्रदान करता है।

360

EN + हिं Easy

GB What is 'impact analysis' in software change management and what artefacts does it require?

IN सॉफ़्टवेयर परिवर्तन प्रबंधन में 'प्रभाव विश्लेषण' क्या है और इसके लिए किन कलाकृतियों की आवश्यकता है?

A

Impact analysis measures the financial cost of a software defect after production deployment प्रभाव विश्लेषण उत्पादन परिनियोजन के बाद सॉफ़्टवेयर दोष की वित्तीय लागत को मापता है

B

Impact analysis determines which system components, tests, documents, and dependent systems will be affected by a proposed change — requiring: design documentation, traceability matrices, dependency maps, and test coverage data to accurately scope change effects प्रभाव विश्लेषण यह निर्धारित करता है कि कौन से सिस्टम घटक, परीक्षण, दस्तावेज़ और आश्रित सिस्टम प्रस्तावित परिवर्तन से प्रभावित होंगे - आवश्यकता है: डिज़ाइन दस्तावेज़, ट्रैसेबिलिटी मैट्रिसेस, निर्भरता मानचित्र, और परिवर्तन प्रभावों को सटीक रूप से लागू करने के लिए कवरेज डेटा का परीक्षण करें।

C

Impact analysis is only required for changes that touch the database schema प्रभाव विश्लेषण केवल उन परिवर्तनों के लिए आवश्यक है जो डेटाबेस स्कीमा को छूते हैं

D

Modern refactoring tools perform impact analysis automatically, eliminating the need for documentation आधुनिक रीफैक्टरिंग उपकरण स्वचालित रूप से प्रभाव विश्लेषण करते हैं, जिससे दस्तावेज़ीकरण की आवश्यकता समाप्त हो जाती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Impact analysis prevents scope blindness: changing a function signature without knowing it's called by 47 modules leads to cascading compile errors. Thorough impact analysis answers: which tests must be updated? Which documents are now inaccurate? Which downstream systems consume this API? Which data migrations are needed? Without artefacts (design docs, traceability matrices), impact analysis degrades to guesswork.

व्याख्या (हिन्दी) प्रभाव विश्लेषण स्कोप ब्लाइंडनेस को रोकता है: किसी फ़ंक्शन हस्ताक्षर को 47 मॉड्यूल द्वारा कॉल किए जाने के बिना बदलने से कैस्केडिंग संकलन त्रुटियां होती हैं। संपूर्ण प्रभाव विश्लेषण उत्तर: कौन से परीक्षण अद्यतन किए जाने चाहिए? अब कौन से दस्तावेज़ ग़लत हैं? कौन से डाउनस्ट्रीम सिस्टम इस एपीआई का उपभोग करते हैं? कौन से डेटा माइग्रेशन की आवश्यकता है? कलाकृतियों (डिज़ाइन दस्तावेज़, ट्रैसेबिलिटी मैट्रिक्स) के बिना, प्रभाव विश्लेषण अनुमान लगाने में कम हो जाता है।

Software Engineering — MCQ Practice