Software Engineering — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 2726 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2726 questions
2326
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+ आरओआई दर्शाते हैं।
2327
EN + हिं Easy
GB What is 'non-regression testing strategy' in CI and what trade-offs govern selecting which tests to run on every commit?
IN सीआई में 'नॉन-रिग्रेशन टेस्टिंग स्ट्रैटेजी' क्या है और प्रत्येक कमिट पर चलने वाले परीक्षणों का चयन करने के लिए कौन से ट्रेड-ऑफ नियंत्रित होते हैं?
A
Non-regression testing requires running all tests on every commit regardless of duration गैर-प्रतिगमन परीक्षण के लिए अवधि की परवाह किए बिना प्रत्येक प्रतिबद्धता पर सभी परीक्षण चलाने की आवश्यकता होती है
B
Non-regression strategy selects tests per commit based on: speed (unit tests always; integration/E2E on schedule or pull requests), risk (change-impact analysis selects tests covering modified code), and flakiness (quarantine unreliable tests to avoid false failures) गैर-प्रतिगमन रणनीति निम्न के आधार पर प्रति प्रतिबद्धता परीक्षणों का चयन करती है: गति (हमेशा इकाई परीक्षण; शेड्यूल या पुल अनुरोधों पर एकीकरण/ई2ई), जोखिम (परिवर्तन-प्रभाव विश्लेषण संशोधित कोड को कवर करने वाले परीक्षणों का चयन करता है), और परतदारता (झूठी विफलताओं से बचने के लिए संगरोध अविश्वसनीय परीक्षण)
C
Non-regression strategy eliminates all tests except smoke tests to maximise CI speed गैर-प्रतिगमन रणनीति सीआई गति को अधिकतम करने के लिए धूम्रपान परीक्षणों को छोड़कर सभी परीक्षणों को समाप्त कर देती है
D
Non-regression testing is only necessary when releasing to production; it is not needed for development branches गैर-प्रतिगमन परीक्षण केवल उत्पादन के लिए जारी करते समय आवश्यक है; विकास शाखाओं के लिए इसकी आवश्यकता नहीं है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The CI feedback speed vs coverage trade-off is real: running 10,000 unit tests takes 2 minutes; running 500 E2E tests takes 3 hours. Google's solution: run fast tests on every commit (unit + targeted integration); run slow E2E on merge to main; run full suite nightly. Risk-based selection (test selection using code change coverage) reduces redundant test execution while maintaining defect detection.
व्याख्या (हिन्दी) सीआई फीडबैक गति बनाम कवरेज ट्रेड-ऑफ वास्तविक है: 10,000 यूनिट परीक्षण चलाने में 2 मिनट लगते हैं; 500 E2E परीक्षण चलाने में 3 घंटे लगते हैं। Google का समाधान: प्रत्येक प्रतिबद्धता (इकाई + लक्षित एकीकरण) पर तेज़ परीक्षण चलाएं; मुख्य में मर्ज होने पर धीमी गति से E2E चलाएँ; हर रात पूरा सुइट चलाएँ। जोखिम-आधारित चयन (कोड परिवर्तन कवरेज का उपयोग करके परीक्षण चयन) दोष का पता लगाने को बनाए रखते हुए अनावश्यक परीक्षण निष्पादन को कम करता है।
2328
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.
व्याख्या (हिन्दी) प्री-प्रोडक्शन वातावरण कभी भी उत्पादन को पूरी तरह से दोहरा नहीं सकता: वास्तविक डेटा वॉल्यूम, वास्तविक उपयोग पैटर्न, वास्तविक हार्डवेयर विफलताएं। नेटफ्लिक्स, फेसबुक और लिंक्डइन जानबूझकर उत्पादन में परीक्षण करते हैं क्योंकि वास्तविकता यहीं है। सुरक्षा नियंत्रण: कैनरी रिलीज़ धीरे-धीरे नए कोड को उजागर करता है; फ़ीचर फ़्लैग तत्काल अक्षम को सक्षम करते हैं; डार्क ने परिणाम दिए बिना रन कोड लॉन्च किया; व्यापक प्रभाव से पहले ही अवलोकनीयता विसंगतियों को पकड़ लेती है।
2329
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 गुना तेज बनाता है।
2330
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 दोष के रूप में मानना।
2331
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 होनी चाहिए' जैसे परीक्षण लिखता है। सीआई पाइपलाइन इन परीक्षणों को वास्तविक (परीक्षण पर्यावरण) बुनियादी ढांचे के खिलाफ चलाती है, उत्पादन तैनाती से पहले गलत कॉन्फ़िगरेशन को पकड़ती है।
2332
EN + हिं Easy
GB What is 'statistical process control' (SPC) applied to software testing metrics, and what does a control chart reveal?
IN सॉफ़्टवेयर परीक्षण मेट्रिक्स पर लागू 'सांख्यिकीय प्रक्रिया नियंत्रण' (एसपीसी) क्या है, और नियंत्रण चार्ट क्या प्रकट करता है?
A
SPC in software testing automatically fixes defects when their rate exceeds a threshold सॉफ़्टवेयर परीक्षण में SPC स्वचालित रूप से दोषों को ठीक करता है जब उनकी दर एक सीमा से अधिक हो जाती है
B
SPC monitors testing metrics (defect rate per build, test pass rate) over time on a control chart — revealing whether variation is random (common cause, process is stable) or indicates a special cause (process has changed), enabling data-driven process intervention decisions एसपीसी एक नियंत्रण चार्ट पर समय के साथ परीक्षण मेट्रिक्स (प्रति निर्माण दोष दर, परीक्षण पास दर) की निगरानी करता है - यह बताता है कि क्या भिन्नता यादृच्छिक है (सामान्य कारण, प्रक्रिया स्थिर है) या एक विशेष कारण इंगित करती है (प्रक्रिया बदल गई है), डेटा-संचालित प्रक्रिया हस्तक्षेप निर्णयों को सक्षम करती है
C
SPC requires at least 10,000 data points before any meaningful analysis is possible किसी भी सार्थक विश्लेषण को संभव करने से पहले एसपीसी को कम से कम 10,000 डेटा बिंदुओं की आवश्यकता होती है
D
SPC is only applicable to manufacturing quality control and cannot be used for software एसपीसी केवल विनिर्माण गुणवत्ता नियंत्रण पर लागू है और इसका उपयोग सॉफ्टवेयर के लिए नहीं किया जा सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Deming's SPC applied to software: if defect density per sprint is normally 5-8 and suddenly spikes to 20, is it noise or a real change? Control charts with control limits (mean ± 3σ) answer this statistically. Points outside control limits signal special causes (new developer, new codebase area, process change) requiring investigation. This transforms quality management from gut-feel to evidence-based decision-making.
व्याख्या (हिन्दी) डेमिंग का एसपीसी सॉफ़्टवेयर पर लागू होता है: यदि प्रति स्प्रिंट दोष घनत्व सामान्य रूप से 5-8 है और अचानक 20 तक बढ़ जाता है, तो क्या यह शोर है या वास्तविक परिवर्तन है? नियंत्रण सीमा (मतलब ± 3σ) वाले नियंत्रण चार्ट सांख्यिकीय रूप से इसका उत्तर देते हैं। नियंत्रण सीमा से बाहर के बिंदु जांच की आवश्यकता वाले विशेष कारणों (नए डेवलपर, नए कोडबेस क्षेत्र, प्रक्रिया परिवर्तन) का संकेत देते हैं। यह गुणवत्ता प्रबंधन को सहजता से साक्ष्य-आधारित निर्णय लेने में बदल देता है।
2333
EN + हिं Medium
GB What is the 'divide and conquer' debugging strategy and why is it more efficient than sequential tracing?
IN 'फूट डालो और राज करो' डिबगिंग रणनीति क्या है और यह अनुक्रमिक अनुरेखण से अधिक कुशल क्यों है?
A
Divide and conquer debugging splits the codebase between two developers who debug simultaneously फूट डालो और जीतो डिबगिंग दो डेवलपर्स के बीच कोडबेस को विभाजित करती है जो एक साथ डिबग करते हैं
B
Divide and conquer debugging bisects the execution path — placing a checkpoint at the midpoint to determine which half contains the fault, then recursing on the faulty half — reducing search space from O(n) to O(log n) versus sequential line-by-line tracing फूट डालो और जीतो डिबगिंग निष्पादन पथ को द्विभाजित करती है - यह निर्धारित करने के लिए कि किस आधे में गलती है, मध्यबिंदु पर एक चेकपॉइंट रखकर, फिर दोषपूर्ण आधे पर पुनरावृत्ति - अनुक्रमिक लाइन-बाय-लाइन ट्रेसिंग बनाम ओ (एन) से ओ (लॉग एन) तक खोज स्थान को कम करना
C
Divide and conquer is only applicable to sorting algorithms, not general debugging फूट डालो और राज करो केवल सॉर्टिंग एल्गोरिदम पर लागू होता है, सामान्य डिबगिंग पर नहीं
D
Sequential tracing is always faster than divide and conquer for small codebases under 1000 lines 1000 लाइनों से कम के छोटे कोडबेस के लिए अनुक्रमिक अनुरेखण हमेशा विभाजित करने और जीतने की तुलना में तेज़ होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) If a bug is in a 1000-line execution path, sequential tracing may require 1000 steps. Divide and conquer requires log2(1000) ≈ 10 checkpoints. This is why 'git bisect' (binary search over commits) finds the introducing commit in ~10 bisections across a 1000-commit history. The same principle applied to code via strategic assertion/log placement achieves the same logarithmic efficiency.
व्याख्या (हिन्दी) यदि कोई बग 1000-लाइन निष्पादन पथ में है, तो अनुक्रमिक ट्रेसिंग के लिए 1000 चरणों की आवश्यकता हो सकती है। फूट डालो और जीतो के लिए log2(1000) ≈ 10 चौकियों की आवश्यकता होती है। यही कारण है कि 'गिट बाइसेक्ट' (कमिट पर बाइनरी सर्च) 1000-प्रतिबद्ध इतिहास में ~10 द्विभाजनों में परिचयात्मक कमिट ढूंढता है। रणनीतिक अभिकथन/लॉग प्लेसमेंट के माध्यम से कोड पर लागू समान सिद्धांत समान लघुगणकीय दक्षता प्राप्त करता है।
2334
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?).
व्याख्या (हिन्दी) जीडीबी, एलएलडीबी, और विनडीबीजी सटीक मेमोरी स्थिति का निरीक्षण करने के लिए कोर डंप लोड कर सकते हैं: क्रैश पर कॉल स्टैक, सभी चर के मान, ढेर सामग्री। यह निदान करता है: नल पॉइंटर डेरेफ़रेंस (नल पॉइंटर क्या था? इसे किस ऑब्जेक्ट की ओर इंगित करना चाहिए था?), स्टैक ओवरफ्लो (कॉल चेन क्या है जिसके कारण स्टैक थकावट हुई?), और डेटा भ्रष्टाचार (कौन सा मान वहां लिखा गया था जहां इसे नहीं होना चाहिए था?)।
2335
EN + हिं Easy
GB What is a 'watchpoint' (data breakpoint) in debugging and what bug type makes it invaluable?
IN डिबगिंग में 'वॉचपॉइंट' (डेटा ब्रेकपॉइंट) क्या है और कौन सा बग प्रकार इसे अमूल्य बनाता है?
A
Watchpoint is a breakpoint that triggers when execution reaches a specific code line वॉचपॉइंट एक ब्रेकपॉइंट है जो तब ट्रिगर होता है जब निष्पादन एक विशिष्ट कोड लाइन तक पहुंचता है
B
A watchpoint triggers when a specific memory address or variable is read or written — invaluable for debugging data corruption bugs where a variable is being modified by an unknown code path that is hard to find by reading code जब एक विशिष्ट मेमोरी एड्रेस या वेरिएबल पढ़ा या लिखा जाता है तो वॉचपॉइंट ट्रिगर हो जाता है - डेटा भ्रष्टाचार बग को डीबग करने के लिए अमूल्य है जहां एक वेरिएबल को अज्ञात कोड पथ द्वारा संशोधित किया जा रहा है जिसे कोड पढ़कर ढूंढना मुश्किल है
C
Watchpoints are a JavaScript-only debugging feature not available in compiled languages वॉचप्वाइंट एक जावास्क्रिप्ट-केवल डिबगिंग सुविधा है जो संकलित भाषाओं में उपलब्ध नहीं है
D
Watchpoints are identical to conditional breakpoints and the terms are used interchangeably वॉचप्वाइंट सशर्त ब्रेकप्वाइंट के समान हैं और शब्दों का उपयोग परस्पर किया जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Classic data corruption scenario: a struct's field is being overwritten with garbage values and you can't find where. Setting a watchpoint on that memory address causes GDB/LLDB to stop execution exactly when and where the write occurs — regardless of which function, pointer chain, or code path is responsible. Without watchpoints, this class of bug may require hours of manual code tracing.
व्याख्या (हिन्दी) क्लासिक डेटा भ्रष्टाचार परिदृश्य: एक संरचना के क्षेत्र को कचरा मूल्यों के साथ अधिलेखित किया जा रहा है और आप यह नहीं ढूंढ पा रहे हैं कि कहां है। उस मेमोरी एड्रेस पर वॉचपॉइंट सेट करने से जीडीबी/एलएलडीबी ठीक उसी समय और जहां लेखन होता है, निष्पादन को रोक देता है - भले ही कौन सा फ़ंक्शन, पॉइंटर श्रृंखला या कोड पथ जिम्मेदार हो। वॉचपॉइंट के बिना, बग के इस वर्ग को मैन्युअल कोड ट्रेसिंग के घंटों की आवश्यकता हो सकती है।
2336
EN + हिं Easy
GB What is 'logging strategy' in debugging and what are the trade-offs between too little and too much logging?
IN डिबगिंग में 'लॉगिंग रणनीति' क्या है और बहुत कम और बहुत अधिक लॉगिंग के बीच क्या अंतर है?
A
Logging strategy only matters for security-sensitive applications; other applications need minimal logging लॉगिंग रणनीति केवल सुरक्षा-संवेदनशील अनुप्रयोगों के लिए मायने रखती है; अन्य अनुप्रयोगों को न्यूनतम लॉगिंग की आवश्यकता होती है
B
Too little logging: insufficient context to diagnose production issues, forcing blind fixes; too much logging: performance degradation, storage costs, signal buried in noise, potential logging of sensitive data. Optimal: structured logs with configurable levels (ERROR/WARN/INFO/DEBUG) and correlation IDs बहुत कम लॉगिंग: उत्पादन समस्याओं का निदान करने के लिए अपर्याप्त संदर्भ, अंधाधुंध सुधारों को मजबूर करना; बहुत अधिक लॉगिंग: प्रदर्शन में गिरावट, भंडारण लागत, शोर में दबे सिग्नल, संवेदनशील डेटा की संभावित लॉगिंग। इष्टतम: विन्यास योग्य स्तरों (त्रुटि/चेतावनी/सूचना/डीबग) और सहसंबंध आईडी के साथ संरचित लॉग
C
More logging is always better; storage is cheap enough that all debug output should be retained permanently अधिक लॉगिंग हमेशा बेहतर होती है; भंडारण इतना सस्ता है कि सभी डिबग आउटपुट को स्थायी रूप से बनाए रखा जाना चाहिए
D
Logging should only be added after a bug is reported, not proactively during development लॉगिंग केवल बग रिपोर्ट होने के बाद ही जोड़ी जानी चाहिए, विकास के दौरान सक्रिय रूप से नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Structured logging (JSON logs with request IDs, user IDs, timestamps, context fields) with log levels enables: ERROR always on (alerts), INFO for audit trails, DEBUG off in production (enable per-service for diagnosis). Correlation IDs trace requests across microservices. The key insight: log what you'll need to diagnose a failure you can't predict, not what you currently think might fail.
व्याख्या (हिन्दी) लॉग स्तरों के साथ संरचित लॉगिंग (अनुरोध आईडी, उपयोगकर्ता आईडी, टाइमस्टैम्प, संदर्भ फ़ील्ड के साथ JSON लॉग) सक्षम करता है: त्रुटि हमेशा चालू (अलर्ट), ऑडिट ट्रेल्स के लिए जानकारी, उत्पादन में डीबग बंद (निदान के लिए प्रति-सेवा सक्षम करें)। सहसंबंध आईडी माइक्रोसर्विसेज़ में अनुरोधों का पता लगाती हैं। मुख्य अंतर्दृष्टि: उस विफलता का निदान करने के लिए आपको जो चाहिए उसे लॉग करें जिसकी आप भविष्यवाणी नहीं कर सकते हैं, न कि वह जो आप वर्तमान में सोचते हैं कि विफल हो सकता है।
2337
EN + हिं Easy
GB What is 'remote debugging' and what specific challenges does it introduce compared to local debugging?
IN 'रिमोट डिबगिंग' क्या है और यह स्थानीय डिबगिंग की तुलना में कौन सी विशिष्ट चुनौतियाँ प्रस्तुत करता है?
A
Remote debugging refers to debugging software written by a remote overseas development team रिमोट डिबगिंग से तात्पर्य दूरस्थ विदेशी विकास टीम द्वारा लिखे गए डिबगिंग सॉफ़्टवेयर से है
B
Remote debugging attaches a debugger to a process running on a different machine — introducing challenges: network latency making stepping slow, security risks from debug ports exposure, environment differences between local and remote, and inability to use memory-intensive debugging on production रिमोट डिबगिंग एक डिबगर को एक अलग मशीन पर चलने वाली प्रक्रिया से जोड़ता है - चुनौतियां पेश करता है: नेटवर्क विलंबता के कारण कदम धीमा हो जाता है, डिबग पोर्ट एक्सपोज़र से सुरक्षा जोखिम, स्थानीय और रिमोट के बीच पर्यावरण अंतर, और उत्पादन पर मेमोरी-सघन डिबगिंग का उपयोग करने में असमर्थता
C
Remote debugging is identical to local debugging except the IDE must be cloud-hosted रिमोट डिबगिंग स्थानीय डिबगिंग के समान है, सिवाय इसके कि आईडीई को क्लाउड-होस्ट किया जाना चाहिए
D
Remote debugging is prohibited in regulated industries because it exposes production data विनियमित उद्योगों में रिमोट डिबगिंग निषिद्ध है क्योंकि यह उत्पादन डेटा को उजागर करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Docker and Kubernetes made remote debugging critical: services run in containers/pods unreproducible locally. SSH tunnelling + GDB remote, Java JPDA (JDWP protocol), Python debugpy, and Node.js (1, 1, 5, 69, 4, 'What is 'undefined behaviour' (UB) in C/C++ and why is it particularly dangerous from a debugging perspective?
व्याख्या (हिन्दी) डॉकर और कुबेरनेट्स ने रिमोट डिबगिंग को महत्वपूर्ण बना दिया है: कंटेनर/पॉड में चलने वाली सेवाएं स्थानीय स्तर पर अप्राप्य हैं। SSH टनलिंग + GDB रिमोट, जावा JPDA (JDWP प्रोटोकॉल), पायथन डिबगपी, और Node.js (1, 1, 5, 69, 4, 'सी/सी++ में 'अपरिभाषित व्यवहार' (यूबी) क्या है और डिबगिंग परिप्रेक्ष्य से यह विशेष रूप से खतरनाक क्यों है?
2338
EN + हिं Easy
GB What is 'printf debugging' and what is its key limitation that debugger-based debugging overcomes?
IN 'प्रिंटफ डिबगिंग' क्या है और इसकी प्रमुख सीमा क्या है जिसे डिबगर-आधारित डिबगिंग खत्म कर देती है?
A
Printf debugging is a deprecated technique never used by professional software engineers प्रिंटफ़ डिबगिंग एक अप्रचलित तकनीक है जिसका उपयोग पेशेवर सॉफ़्टवेयर इंजीनियरों द्वारा कभी नहीं किया जाता है
B
Printf debugging inserts print statements to observe execution state — its key limitation is that it requires code modification and recompilation for each investigation step and cannot interactively explore state at runtime; debuggers allow inspection without code changes प्रिंटफ डिबगिंग निष्पादन स्थिति का निरीक्षण करने के लिए प्रिंट स्टेटमेंट सम्मिलित करता है - इसकी मुख्य सीमा यह है कि इसमें प्रत्येक जांच चरण के लिए कोड संशोधन और पुनर्संकलन की आवश्यकता होती है और रनटाइम पर इंटरैक्टिव रूप से स्थिति का पता नहीं लगाया जा सकता है; डिबगर्स कोड परिवर्तन के बिना निरीक्षण की अनुमति देते हैं
C
Printf debugging is superior to debuggers for multithreaded programs because it is non-intrusive प्रिंटफ डिबगिंग मल्टीथ्रेडेड प्रोग्राम के लिए डिबगर्स से बेहतर है क्योंकि यह गैर-घुसपैठकारी है
D
Printf debugging is only possible in languages with a built-in print function Printf डिबगिंग केवल अंतर्निहित प्रिंट फ़ंक्शन वाली भाषाओं में ही संभव है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Printf debugging is actually widely used even by experienced engineers — especially in distributed systems where attaching a debugger is impractical. Its limitation: each new piece of information requires a code change, rebuild, and redeploy cycle. Debuggers allow interactive inspection of any variable, stack frame, or memory address without touching the code — enabling much faster investigation cycles for local bugs.
व्याख्या (हिन्दी) प्रिंटफ डिबगिंग वास्तव में अनुभवी इंजीनियरों द्वारा भी व्यापक रूप से उपयोग किया जाता है - विशेष रूप से वितरित सिस्टम में जहां डिबगर संलग्न करना अव्यावहारिक है। इसकी सीमा: प्रत्येक नई जानकारी के लिए कोड परिवर्तन, पुनर्निर्माण और पुन: तैनाती चक्र की आवश्यकता होती है। डिबगर्स कोड को छुए बिना किसी भी वेरिएबल, स्टैक फ्रेम या मेमोरी एड्रेस के इंटरैक्टिव निरीक्षण की अनुमति देते हैं - स्थानीय बग के लिए बहुत तेज़ जांच चक्र सक्षम करते हैं।
2339
EN + हिं Medium
GB What is 'snapshot debugging' and how does it differ from traditional live debugging?
IN 'स्नैपशॉट डिबगिंग' क्या है और यह पारंपरिक लाइव डिबगिंग से कैसे भिन्न है?
A
Snapshot debugging creates database backups at regular intervals during development स्नैपशॉट डिबगिंग विकास के दौरान नियमित अंतराल पर डेटाबेस बैकअप बनाता है
B
Snapshot debugging captures a complete program state snapshot at the point of failure (variables, call stack, heap) without pausing execution — allowing post-hoc investigation without interrupting service; traditional debugging pauses execution interactively but requires the process to be running स्नैपशॉट डिबगिंग निष्पादन को रोके बिना विफलता के बिंदु (वेरिएबल, कॉल स्टैक, हीप) पर एक पूर्ण प्रोग्राम स्थिति स्नैपशॉट कैप्चर करता है - सेवा में बाधा डाले बिना पोस्ट-हॉक जांच की अनुमति देता है; पारंपरिक डिबगिंग अंतःक्रियात्मक रूप से निष्पादन को रोकती है लेकिन प्रक्रिया को चालू रखने की आवश्यकता होती है
C
Snapshot debugging is identical to core dump analysis and both terms describe the same technique स्नैपशॉट डिबगिंग कोर डंप विश्लेषण के समान है और दोनों शब्द एक ही तकनीक का वर्णन करते हैं
D
Snapshot debugging is only available in cloud platforms like Azure and AWS स्नैपशॉट डिबगिंग केवल Azure और AWS जैसे क्लाउड प्लेटफ़ॉर्म में उपलब्ध है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Tools like Visual Studio Snapshot Debugger (Azure), Lightrun, and Rookout enable production debugging by capturing full execution context when a specific line is hit — without stopping the process. This solves the production debugging paradox: traditional debuggers interrupt service; logging lacks detail; snapshot debugging captures complete state non-intrusively. Developers can inspect any variable value at the failure point hours after it occurred.
व्याख्या (हिन्दी) विज़ुअल स्टूडियो स्नैपशॉट डिबगर (एज़्योर), लाइटरन और रूकआउट जैसे उपकरण प्रक्रिया को रोके बिना, एक विशिष्ट लाइन हिट होने पर पूर्ण निष्पादन संदर्भ को कैप्चर करके उत्पादन डिबगिंग को सक्षम करते हैं। यह उत्पादन डिबगिंग विरोधाभास को हल करता है: पारंपरिक डिबगर्स सेवा को बाधित करते हैं; लॉगिंग में विवरण का अभाव है; स्नैपशॉट डिबगिंग पूरी स्थिति को बिना किसी हस्तक्षेप के कैप्चर करता है। डेवलपर्स किसी भी वैरिएबल मान का उसके घटित होने के कुछ घंटों बाद विफलता बिंदु पर निरीक्षण कर सकते हैं।
2340
EN + हिं Easy
GB What is 'differential debugging' and when is it most effectively applied?
IN 'डिफ़रेंशियल डिबगिंग' क्या है और इसे सबसे प्रभावी ढंग से कब लागू किया जाता है?
A
Differential debugging compares two developers' implementations of the same function डिफरेंशियल डिबगिंग एक ही फ़ंक्शन के दो डेवलपर्स के कार्यान्वयन की तुलना करती है
B
Differential debugging compares two configurations that exhibit different behaviour (buggy vs working, version A vs version B) — systematically varying one factor at a time to identify which difference causes the fault; most effective when a regression is known to exist between two states डिफरेंशियल डिबगिंग दो कॉन्फ़िगरेशन की तुलना करती है जो अलग-अलग व्यवहार प्रदर्शित करती है (छोटी गाड़ी बनाम काम करना, संस्करण ए बनाम संस्करण बी) - यह पहचानने के लिए कि कौन सा अंतर गलती का कारण बनता है, एक समय में व्यवस्थित रूप से एक कारक को बदलता है; सबसे प्रभावी तब होता है जब दो राज्यों के बीच एक प्रतिगमन मौजूद होता है
C
Differential debugging is a formal verification technique requiring mathematical proofs डिफरेंशियल डिबगिंग एक औपचारिक सत्यापन तकनीक है जिसके लिए गणितीय प्रमाण की आवश्यकता होती है
D
Differential debugging can only be applied to database query performance problems विभेदक डिबगिंग केवल डेटाबेस क्वेरी प्रदर्शन समस्याओं पर लागू की जा सकती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) 'It worked yesterday, it doesn't today' — differential debugging is perfect here. git bisect performs differential debugging across commits. Environmental differential: 'works on my machine, fails on staging' — systematically compare OS, JVM version, library versions, environment variables, network configuration until the differing factor is found. The hypothesis: 'if X is the same in both environments, X is not the cause.'
व्याख्या (हिन्दी) 'इसने कल काम किया, आज नहीं किया' - यहां डिफरेंशियल डिबगिंग एकदम सही है। git bisect पूरे कमिट में डिफरेंशियल डिबगिंग करता है। पर्यावरणीय अंतर: 'मेरी मशीन पर काम करता है, स्टेजिंग पर विफल रहता है' - भिन्न कारक मिलने तक व्यवस्थित रूप से ओएस, जेवीएम संस्करण, लाइब्रेरी संस्करण, पर्यावरण चर, नेटवर्क कॉन्फ़िगरेशन की तुलना करें। परिकल्पना: 'यदि X दोनों वातावरणों में समान है, तो X इसका कारण नहीं है।'
2326–2340 of 2726