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
2566
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 चूक जाता है, भाषा-अज्ञेयवादी। पेनेट्रेशन परीक्षण (मानव विशेषज्ञ) हमले के रास्ते स्वचालन चूक को खोजने के लिए रचनात्मक रूप से कमजोरियों को जोड़ते हैं। प्रभावी सुरक्षा परीक्षण के लिए सभी परतों की आवश्यकता होती है।
2567
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) ने उत्पादन उदाहरणों को बेतरतीब ढंग से समाप्त करके अराजकता इंजीनियरिंग की शुरुआत की। पारंपरिक परीक्षण यह सत्यापित करते हैं कि घटक अलगाव में काम करते हैं; वे यह सत्यापित नहीं कर सकते कि डेटाबेस धीमा होने पर नेटफ्लिक्स की अनुशंसा सेवा सही ढंग से वापस आ जाती है। कैओस इंजीनियरिंग वास्तविक विफलता स्थितियों के तहत वितरित सिस्टम लचीलेपन को मान्य करती है: 'यदि हम किसी सेवा को बेतरतीब ढंग से क्रैश कर देते हैं, तो क्या सिस्टम शानदार ढंग से ख़राब हो जाता है या भयावह रूप से विफल हो जाता है?'
2568
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 बदलता है, तो कौन से परीक्षण मामलों को अद्यतन किया जाना चाहिए? पता लगाने की क्षमता के बिना, यह जासूसी का काम है; इसके साथ, यह एक लुकअप है।
2569
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+ आरओआई दर्शाते हैं।
2570
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 चलाएँ; हर रात पूरा सुइट चलाएँ। जोखिम-आधारित चयन (कोड परिवर्तन कवरेज का उपयोग करके परीक्षण चयन) दोष का पता लगाने को बनाए रखते हुए अनावश्यक परीक्षण निष्पादन को कम करता है।
2571
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.
व्याख्या (हिन्दी) प्री-प्रोडक्शन वातावरण कभी भी उत्पादन को पूरी तरह से दोहरा नहीं सकता: वास्तविक डेटा वॉल्यूम, वास्तविक उपयोग पैटर्न, वास्तविक हार्डवेयर विफलताएं। नेटफ्लिक्स, फेसबुक और लिंक्डइन जानबूझकर उत्पादन में परीक्षण करते हैं क्योंकि वास्तविकता यहीं है। सुरक्षा नियंत्रण: कैनरी रिलीज़ धीरे-धीरे नए कोड को उजागर करता है; फ़ीचर फ़्लैग तत्काल अक्षम को सक्षम करते हैं; डार्क ने परिणाम दिए बिना रन कोड लॉन्च किया; व्यापक प्रभाव से पहले ही अवलोकनीयता विसंगतियों को पकड़ लेती है।
2572
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 गुना तेज बनाता है।
2573
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 दोष के रूप में मानना।
2574
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 होनी चाहिए' जैसे परीक्षण लिखता है। सीआई पाइपलाइन इन परीक्षणों को वास्तविक (परीक्षण पर्यावरण) बुनियादी ढांचे के खिलाफ चलाती है, उत्पादन तैनाती से पहले गलत कॉन्फ़िगरेशन को पकड़ती है।
2575
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σ) वाले नियंत्रण चार्ट सांख्यिकीय रूप से इसका उत्तर देते हैं। नियंत्रण सीमा से बाहर के बिंदु जांच की आवश्यकता वाले विशेष कारणों (नए डेवलपर, नए कोडबेस क्षेत्र, प्रक्रिया परिवर्तन) का संकेत देते हैं। यह गुणवत्ता प्रबंधन को सहजता से साक्ष्य-आधारित निर्णय लेने में बदल देता है।
2576
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 द्विभाजनों में परिचयात्मक कमिट ढूंढता है। रणनीतिक अभिकथन/लॉग प्लेसमेंट के माध्यम से कोड पर लागू समान सिद्धांत समान लघुगणकीय दक्षता प्राप्त करता है।
2577
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?).
व्याख्या (हिन्दी) जीडीबी, एलएलडीबी, और विनडीबीजी सटीक मेमोरी स्थिति का निरीक्षण करने के लिए कोर डंप लोड कर सकते हैं: क्रैश पर कॉल स्टैक, सभी चर के मान, ढेर सामग्री। यह निदान करता है: नल पॉइंटर डेरेफ़रेंस (नल पॉइंटर क्या था? इसे किस ऑब्जेक्ट की ओर इंगित करना चाहिए था?), स्टैक ओवरफ्लो (कॉल चेन क्या है जिसके कारण स्टैक थकावट हुई?), और डेटा भ्रष्टाचार (कौन सा मान वहां लिखा गया था जहां इसे नहीं होना चाहिए था?)।
2578
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.
व्याख्या (हिन्दी) क्लासिक डेटा भ्रष्टाचार परिदृश्य: एक संरचना के क्षेत्र को कचरा मूल्यों के साथ अधिलेखित किया जा रहा है और आप यह नहीं ढूंढ पा रहे हैं कि कहां है। उस मेमोरी एड्रेस पर वॉचपॉइंट सेट करने से जीडीबी/एलएलडीबी ठीक उसी समय और जहां लेखन होता है, निष्पादन को रोक देता है - भले ही कौन सा फ़ंक्शन, पॉइंटर श्रृंखला या कोड पथ जिम्मेदार हो। वॉचपॉइंट के बिना, बग के इस वर्ग को मैन्युअल कोड ट्रेसिंग के घंटों की आवश्यकता हो सकती है।
2579
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 लॉग) सक्षम करता है: त्रुटि हमेशा चालू (अलर्ट), ऑडिट ट्रेल्स के लिए जानकारी, उत्पादन में डीबग बंद (निदान के लिए प्रति-सेवा सक्षम करें)। सहसंबंध आईडी माइक्रोसर्विसेज़ में अनुरोधों का पता लगाती हैं। मुख्य अंतर्दृष्टि: उस विफलता का निदान करने के लिए आपको जो चाहिए उसे लॉग करें जिसकी आप भविष्यवाणी नहीं कर सकते हैं, न कि वह जो आप वर्तमान में सोचते हैं कि विफल हो सकता है।
2580
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, 'सी/सी++ में 'अपरिभाषित व्यवहार' (यूबी) क्या है और डिबगिंग परिप्रेक्ष्य से यह विशेष रूप से खतरनाक क्यों है?
2566–2580 of 2726