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
2551
EN + हिं Medium
GB What is the 'strangler fig refactoring' pattern at the code level and how does it differ from its architectural namesake?
IN कोड स्तर पर 'स्ट्रैंगलर फिग रिफैक्टरिंग' पैटर्न क्या है और यह इसके वास्तुशिल्प नाम से कैसे भिन्न है?
A
Both terms describe identical concepts at identical scales of abstraction दोनों शब्द अमूर्तता के समान पैमाने पर समान अवधारणाओं का वर्णन करते हैं
B
At code level, strangler fig refactoring wraps an old implementation with a new interface, routing calls through the wrapper that gradually replaces internal behaviour — it applies the same incremental replacement principle as the architectural pattern but within a single codebase कोड स्तर पर, स्ट्रैंगलर फ़िग रिफैक्टरिंग एक पुराने कार्यान्वयन को एक नए इंटरफ़ेस के साथ लपेटता है, रैपर के माध्यम से कॉल को रूट करता है जो धीरे-धीरे आंतरिक व्यवहार को बदल देता है - यह वास्तुशिल्प पैटर्न के समान वृद्धिशील प्रतिस्थापन सिद्धांत को लागू करता है लेकिन एक ही कोडबेस के भीतर
C
Strangler fig refactoring requires the old code to be deleted before the new code is written स्ट्रैंग्लर अंजीर रीफैक्टरिंग के लिए नया कोड लिखने से पहले पुराने कोड को हटाना आवश्यक है
D
Strangler fig refactoring is only applicable to database stored procedures, not application code स्ट्रैंगलर अंजीर रीफैक्टरिंग केवल डेटाबेस संग्रहीत प्रक्रियाओं पर लागू होती है, एप्लिकेशन कोड पर नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The same risk-management principle scales down: instead of routing HTTP traffic, you introduce an abstraction layer (interface) over a messy class; new callers use the interface; old callers are gradually migrated; the old implementation is replaced behind the interface. At any point both old and new implementations coexist safely. This enables refactoring large untested legacy classes without a risky all-at-once rewrite.
व्याख्या (हिन्दी) समान जोखिम-प्रबंधन सिद्धांत नीचे स्केल करता है: HTTP ट्रैफ़िक को रूट करने के बजाय, आप एक अव्यवस्थित वर्ग पर एक अमूर्त परत (इंटरफ़ेस) पेश करते हैं; नए कॉल करने वाले इंटरफ़ेस का उपयोग करते हैं; पुराने कॉल करने वाले धीरे-धीरे पलायन कर रहे हैं; पुराने कार्यान्वयन को इंटरफ़ेस के पीछे बदल दिया गया है। किसी भी बिंदु पर पुराने और नए दोनों कार्यान्वयन सुरक्षित रूप से सह-अस्तित्व में होते हैं। यह बड़े पैमाने पर अप्रयुक्त विरासत वर्गों को बिना किसी जोखिम भरे पुनर्लेखन के पुन: सक्रिय करने में सक्षम बनाता है।
2552
EN + हिं Easy
GB What is 'naming convention' beyond simple formatting, and what cognitive science principle underlies good identifier naming?
IN सरल स्वरूपण से परे 'नामकरण परंपरा' क्या है, और कौन सा संज्ञानात्मक विज्ञान सिद्धांत अच्छे पहचानकर्ता नामकरण का आधार है?
A
Naming conventions are purely cosmetic and have no measurable impact on code quality नामकरण परंपराएं पूरी तरह से दिखावटी हैं और कोड गुणवत्ता पर इनका कोई मापने योग्य प्रभाव नहीं पड़ता है
B
Good identifier naming encodes domain concepts, intent, and level of abstraction — grounded in the cognitive principle that working memory is limited (Miller's law: 7±2 chunks) and meaningful names reduce cognitive load by making identifiers carry semantic content rather than requiring decode from arbitrary symbols अच्छा पहचानकर्ता नामकरण डोमेन अवधारणाओं, इरादे और अमूर्तता के स्तर को एनकोड करता है - संज्ञानात्मक सिद्धांत पर आधारित है कि कार्यशील मेमोरी सीमित है (मिलर का नियम: 7 ± 2 खंड) और सार्थक नाम पहचानकर्ताओं को मनमाने प्रतीकों से डिकोड की आवश्यकता के बजाय अर्थपूर्ण सामग्री बनाकर संज्ञानात्मक भार को कम करते हैं।
C
The only naming rule that matters is avoiding reserved keywords of the programming language एकमात्र नामकरण नियम जो मायने रखता है वह है प्रोग्रामिंग भाषा के आरक्षित कीवर्ड से बचना
D
Naming conventions should be enforced differently for each type of developer (junior vs senior) प्रत्येक प्रकार के डेवलपर (कनिष्ठ बनाम वरिष्ठ) के लिए नामकरण परंपराएँ अलग-अलग लागू की जानी चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Miller's Law: working memory holds 7±2 chunks. Names like 'x', 'temp', 'd' offer zero semantic content — programmers must decode them from context, consuming working memory slots. Names like 'accountBalanceAfterFees', 'isEmailVerified', 'maxRetryAttempts' encode their meaning directly. Research (Buse and Weimer, Feitelson et al.) shows that poor naming is the top contributor to code incomprehensibility — more than missing comments.
व्याख्या (हिन्दी) मिलर का नियम: कार्यशील मेमोरी में 7±2 खंड होते हैं। 'x', 'temp', 'd' जैसे नाम शून्य अर्थ सामग्री प्रदान करते हैं - प्रोग्रामर को कार्यशील मेमोरी स्लॉट का उपभोग करते हुए उन्हें संदर्भ से डिकोड करना होगा। 'accountBalanceAfterFees', 'isEmailVerified', 'maxRetryAttempts' जैसे नाम सीधे अपने अर्थ को कूटबद्ध करते हैं। अनुसंधान (बुसे और वीमर, फीटेलसन एट अल.) से पता चलता है कि खराब नामकरण कोड की समझ से बाहर होने में शीर्ष योगदानकर्ता है - गायब टिप्पणियों से भी अधिक।
2553
EN + हिं Medium
GB What is 'code coverage' as a metric and why is 100% code coverage NOT sufficient evidence of adequate testing?
IN एक मीट्रिक के रूप में 'कोड कवरेज' क्या है और 100% कोड कवरेज पर्याप्त परीक्षण का पर्याप्त प्रमाण क्यों नहीं है?
A
100% code coverage proves the system has no remaining defects 100% कोड कवरेज साबित करता है कि सिस्टम में कोई शेष दोष नहीं है
B
Code coverage measures which lines/branches are executed during testing; 100% coverage is insufficient because coverage only proves code was executed, not that correct assertions were made — a test with no assertions achieves 100% coverage while detecting zero defects कोड कवरेज मापता है कि परीक्षण के दौरान कौन सी लाइनें/शाखाएं निष्पादित की जाती हैं; 100% कवरेज अपर्याप्त है क्योंकि कवरेज केवल यह साबित करता है कि कोड निष्पादित किया गया था, यह नहीं कि सही दावे किए गए थे - बिना किसी दावे वाला परीक्षण शून्य दोषों का पता लगाते हुए 100% कवरेज प्राप्त करता है
C
100% code coverage is both sufficient and necessary for ensuring software quality सॉफ़्टवेयर गुणवत्ता सुनिश्चित करने के लिए 100% कोड कवरेज पर्याप्त और आवश्यक दोनों है
D
Code coverage metrics are only valid for C and Java; not for Python or JavaScript कोड कवरेज मेट्रिक्स केवल C और Java के लिए मान्य हैं; पायथन या जावास्क्रिप्ट के लिए नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The 'test without assertion' problem: a test that calls every method but asserts nothing achieves 100% coverage and catches nothing. Coverage tells you what was exercised; mutation testing tells you whether tests would detect errors. Coverage is a floor ('at least we ran this code') not a ceiling ('our tests are good'). High coverage with weak assertions is actually dangerous — it creates false confidence.
व्याख्या (हिन्दी) 'बिना दावे के परीक्षण' समस्या: एक परीक्षण जो हर विधि को कॉल करता है लेकिन दावा करता है कि कुछ भी नहीं 100% कवरेज प्राप्त करता है और कुछ भी नहीं पकड़ता है। कवरेज आपको बताता है कि क्या व्यायाम किया गया था; उत्परिवर्तन परीक्षण आपको बताता है कि क्या परीक्षण त्रुटियों का पता लगाएंगे। कवरेज एक मंजिल है ('कम से कम हमने यह कोड चलाया') कोई छत नहीं ('हमारे परीक्षण अच्छे हैं')। कमजोर दावों के साथ उच्च कवरेज वास्तव में खतरनाक है - यह झूठा आत्मविश्वास पैदा करता है।
2554
EN + हिं Easy
GB What is 'pair programming review' versus 'formal code inspection' and when should each be used?
IN 'जोड़ी प्रोग्रामिंग समीक्षा' बनाम 'औपचारिक कोड निरीक्षण' क्या है और प्रत्येक का उपयोग कब किया जाना चाहिए?
A
Both techniques are identical in effectiveness; the choice depends only on team size दोनों तकनीकें प्रभावशीलता में समान हैं; चुनाव केवल टीम के आकार पर निर्भर करता है
B
Pair programming provides continuous lightweight review as code is written (low overhead, catches defects early, knowledge transfer); formal inspection is a structured defect-removal process for critical high-risk modules (higher overhead but finds more defects per review hour on complex code) जोड़ी प्रोग्रामिंग कोड लिखे जाने पर निरंतर हल्की समीक्षा प्रदान करती है (कम ओवरहेड, दोषों को जल्दी पकड़ता है, ज्ञान हस्तांतरण); औपचारिक निरीक्षण महत्वपूर्ण उच्च जोखिम वाले मॉड्यूल के लिए एक संरचित दोष-हटाने की प्रक्रिया है (उच्च ओवरहेड लेकिन जटिल कोड पर प्रति समीक्षा घंटे अधिक दोष पाता है)
C
Pair programming review is always superior to formal inspection for safety-critical code सुरक्षा-महत्वपूर्ण कोड के लिए जोड़ी प्रोग्रामिंग समीक्षा हमेशा औपचारिक निरीक्षण से बेहतर होती है
D
Formal code inspection requires at least 20 reviewers to be statistically significant औपचारिक कोड निरीक्षण के लिए सांख्यिकीय रूप से महत्वपूर्ण होने के लिए कम से कम 20 समीक्षकों की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Pair programming provides a 15% overhead with continuous review — suitable for all daily development. Formal Fagan inspection has 4-8 hour preparation + meeting costs but achieves 60-90% defect removal on the inspected module. Economics: use pair programming for routine code; use formal inspection for safety-critical algorithms, cryptographic implementations, or modules with historically high defect density.
व्याख्या (हिन्दी) जोड़ी प्रोग्रामिंग निरंतर समीक्षा के साथ 15% ओवरहेड प्रदान करती है - जो सभी दैनिक विकास के लिए उपयुक्त है। औपचारिक फागन निरीक्षण में 4-8 घंटे की तैयारी + बैठक की लागत होती है, लेकिन निरीक्षण किए गए मॉड्यूल पर 60-90% दोष निवारण होता है। अर्थशास्त्र: नियमित कोड के लिए जोड़ी प्रोग्रामिंग का उपयोग करें; सुरक्षा-महत्वपूर्ण एल्गोरिदम, क्रिप्टोग्राफ़िक कार्यान्वयन, या ऐतिहासिक रूप से उच्च दोष घनत्व वाले मॉड्यूल के लिए औपचारिक निरीक्षण का उपयोग करें।
2555
EN + हिं Easy
GB What is 'code documentation' best practice, and what is the 'self-documenting code' philosophy?
IN 'कोड दस्तावेज़ीकरण' सर्वोत्तम अभ्यास क्या है, और 'स्व-दस्तावेज़ीकरण कोड' दर्शन क्या है?
A
Self-documenting code means no comments are ever needed in any codebase स्व-दस्तावेजीकरण कोड का मतलब है कि किसी भी कोडबेस में किसी भी टिप्पणी की आवश्यकता नहीं है
B
Self-documenting code uses expressive naming and clean structure so code communicates intent without comments; comments are reserved for WHY decisions were made (not WHAT the code does, which should be obvious), especially counter-intuitive choices and invariants Self-documenting code uses expressive naming and clean structure so code communicates intent without comments; टिप्पणियाँ इस बात के लिए आरक्षित हैं कि निर्णय क्यों लिए गए (यह नहीं कि कोड क्या करता है, जो स्पष्ट होना चाहिए), विशेष रूप से प्रति-सहज विकल्प और अपरिवर्तनीय
C
Best practice requires a comment on every line of code for maximum maintainability सर्वोत्तम अभ्यास के लिए अधिकतम रख-रखाव के लिए कोड की प्रत्येक पंक्ति पर एक टिप्पणी की आवश्यकता होती है
D
Self-documenting code philosophy was invented by Knuth and applies only to mathematical algorithms स्व-दस्तावेजीकरण कोड दर्शन का आविष्कार नथ द्वारा किया गया था और यह केवल गणितीय एल्गोरिदम पर लागू होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The comment that says 'increment i by 1' above i++ is noise — it re-states the obvious. Useful comments explain: why a workaround exists ('This bizarre calculation is required by regulation XYZ'), why an obvious approach was rejected ('Don't use HashMap here — it causes non-deterministic ordering that breaks the audit log'), or invariant assumptions ('Caller guarantees list is sorted'). Good code names tell you WHAT; good comments tell you WHY.
व्याख्या (हिन्दी) टिप्पणी जो कहती है कि i++ के ऊपर 'i को 1 से बढ़ाएँ' शोर है - यह स्पष्ट को पुनः बताता है। उपयोगी टिप्पणियाँ बताती हैं: एक समाधान क्यों मौजूद है ('यह विचित्र गणना विनियमन XYZ द्वारा आवश्यक है'), क्यों एक स्पष्ट दृष्टिकोण को अस्वीकार कर दिया गया था ('यहां हैशमैप का उपयोग न करें - यह गैर-नियतात्मक आदेश का कारण बनता है जो ऑडिट लॉग को तोड़ देता है'), या अपरिवर्तनीय धारणाएं ('कॉलर गारंटी सूची क्रमबद्ध है')। अच्छे कोड नाम आपको क्या बताते हैं; अच्छी टिप्पणियाँ आपको बताती हैं क्यों।
2556
EN + हिं Easy
GB What is 'technical documentation' versus 'user documentation' and who is the primary audience for each?
IN 'तकनीकी दस्तावेज़ीकरण' बनाम 'उपयोगकर्ता दस्तावेज़ीकरण' क्या है और प्रत्येक के लिए प्राथमिक दर्शक कौन है?
A
Technical documentation is written in technical jargon; user documentation avoids all technical terms तकनीकी दस्तावेज़ीकरण तकनीकी शब्दजाल में लिखा गया है; उपयोगकर्ता दस्तावेज़ीकरण सभी तकनीकी शर्तों से बचता है
B
Technical documentation (architecture decision records, API docs, internal wikis) targets developers/maintainers who need to understand, extend, or fix the system; user documentation (manuals, tutorials, help systems) targets end users who need to accomplish tasks तकनीकी दस्तावेज़ीकरण (आर्किटेक्चर निर्णय रिकॉर्ड, एपीआई दस्तावेज़, आंतरिक विकी) उन डेवलपर्स/रखरखावकर्ताओं को लक्षित करता है जिन्हें सिस्टम को समझने, विस्तारित करने या ठीक करने की आवश्यकता होती है; उपयोगकर्ता दस्तावेज़ीकरण (मैनुअल, ट्यूटोरियल, सहायता प्रणाली) उन अंतिम उपयोगकर्ताओं को लक्षित करता है जिन्हें कार्य पूरा करने की आवश्यकता होती है
C
Both documentation types are written by the QA team after the system is completed सिस्टम पूरा होने के बाद दोनों दस्तावेज़ प्रकार QA टीम द्वारा लिखे जाते हैं
D
Technical documentation is optional for agile projects; user documentation is always mandatory त्वरित परियोजनाओं के लिए तकनीकी दस्तावेज़ीकरण वैकल्पिक है; उपयोगकर्ता दस्तावेज़ीकरण हमेशा अनिवार्य है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The documentation audience fundamentally changes structure and vocabulary. Developer documentation assumes programming knowledge, describes abstractions, APIs, deployment, troubleshooting. User documentation assumes domain knowledge, describes tasks to accomplish, uses screenshots, avoids implementation detail. Writing user documentation for developers (too simple) or technical documentation for users (too abstract) are both common failures.
व्याख्या (हिन्दी) दस्तावेज़ीकरण दर्शक मूल रूप से संरचना और शब्दावली को बदलता है। डेवलपर दस्तावेज़ीकरण प्रोग्रामिंग ज्ञान को मानता है, अमूर्तता, एपीआई, परिनियोजन, समस्या निवारण का वर्णन करता है। उपयोगकर्ता दस्तावेज़ीकरण डोमेन ज्ञान मानता है, पूरा किए जाने वाले कार्यों का वर्णन करता है, स्क्रीनशॉट का उपयोग करता है, कार्यान्वयन विवरण से बचता है। डेवलपर्स के लिए उपयोगकर्ता दस्तावेज़ लिखना (बहुत सरल) या उपयोगकर्ताओं के लिए तकनीकी दस्तावेज़ लिखना (बहुत सारगर्भित) दोनों ही सामान्य विफलताएँ हैं।
2557
EN + हिं Easy
GB What is 'exploratory testing' and what defects does it find that scripted testing misses?
IN 'खोजपूर्ण परीक्षण' क्या है और इसमें कौन से दोष पाए जाते हैं कि स्क्रिप्टेड परीक्षण छूट जाता है?
A
Exploratory testing is random clicking without any test plan or documentation खोजपूर्ण परीक्षण बिना किसी परीक्षण योजना या दस्तावेज़ीकरण के यादृच्छिक क्लिक करना है
B
Exploratory testing simultaneously designs and executes tests using tester judgment and domain knowledge — it excels at finding defects in unanticipated scenarios, complex interaction chains, and edge cases that no specification anticipated खोजपूर्ण परीक्षण एक साथ परीक्षक के निर्णय और डोमेन ज्ञान का उपयोग करके परीक्षणों को डिजाइन और निष्पादित करता है - यह अप्रत्याशित परिदृश्यों, जटिल इंटरैक्शन श्रृंखलाओं और किनारे के मामलों में दोष ढूंढने में उत्कृष्टता प्राप्त करता है जिनके लिए कोई विनिर्देश प्रत्याशित नहीं था
C
Exploratory testing is only applicable for usability testing, not functional testing खोजपूर्ण परीक्षण केवल प्रयोज्य परीक्षण के लिए लागू है, कार्यात्मक परीक्षण के लिए नहीं
D
Exploratory testing replaces all other forms of testing in modern agile projects आधुनिक चुस्त परियोजनाओं में खोजपूर्ण परीक्षण अन्य सभी प्रकार के परीक्षण का स्थान ले लेता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Scripted tests verify known expected behaviours. Exploratory testing (Cem Kaner) applies skilled human judgment to discover unknown unknowns — defects that exist in paths no specification mentioned. Session-based exploratory testing structures this with time-boxed sessions and charter documentation, balancing freedom with accountability.
व्याख्या (हिन्दी) स्क्रिप्टेड परीक्षण ज्ञात अपेक्षित व्यवहारों को सत्यापित करते हैं। Exploratory testing (Cem Kaner) applies skilled human judgment to discover unknown unknowns — defects that exist in paths no specification mentioned. सत्र-आधारित खोजपूर्ण परीक्षण इसे समय-सीमा वाले सत्रों और चार्टर दस्तावेज़ीकरण के साथ संरचित करता है, जो जवाबदेही के साथ स्वतंत्रता को संतुलित करता है।
2558
EN + हिं Easy
GB What is 'fuzz testing' (fuzzing) and what vulnerability category is it particularly effective at finding?
IN 'फ़ज़ टेस्टिंग' (फ़ज़िंग) क्या है और यह किस भेद्यता श्रेणी का पता लगाने में विशेष रूप से प्रभावी है?
A
Fuzzing is a performance testing technique that tests systems under random user load patterns फ़ज़िंग एक प्रदर्शन परीक्षण तकनीक है जो यादृच्छिक उपयोगकर्ता लोड पैटर्न के तहत सिस्टम का परीक्षण करती है
B
Fuzzing automatically generates large volumes of random, malformed, or unexpected inputs and feeds them to the system — particularly effective at finding memory safety vulnerabilities (buffer overflows, use-after-free, integer overflows) in C/C++ code फ़ज़िंग स्वचालित रूप से बड़ी मात्रा में यादृच्छिक, विकृत, या अप्रत्याशित इनपुट उत्पन्न करता है और उन्हें सिस्टम में फ़ीड करता है - विशेष रूप से सी/सी++ कोड में मेमोरी सुरक्षा कमजोरियों (बफर ओवरफ्लो, उपयोग-बाद-मुक्त, पूर्णांक ओवरफ्लो) को खोजने में प्रभावी है।
C
Fuzzing is only used to test cryptographic hash function implementations फ़ज़िंग का उपयोग केवल क्रिप्टोग्राफ़िक हैश फ़ंक्शन कार्यान्वयन का परीक्षण करने के लिए किया जाता है
D
Fuzzing requires expert security knowledge for each test case; it cannot be automated फ़ज़िंग के लिए प्रत्येक परीक्षण मामले के लिए विशेषज्ञ सुरक्षा ज्ञान की आवश्यकता होती है; इसे स्वचालित नहीं किया जा सकता
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) AFL (American Fuzzy Lop), libFuzzer, and OSS-Fuzz have found thousands of CVEs in mature projects (OpenSSL, libpng, FFmpeg). Fuzzing works by mutating known valid inputs or generating random inputs; coverage-guided fuzzing (AFL) tracks which inputs reach new code paths, guiding mutation toward unexplored areas. It is the most cost-effective technique for finding memory corruption bugs at scale.
व्याख्या (हिन्दी) एएफएल (अमेरिकन फ़ज़ी लोप), लिबफ़ुज़र और ओएसएस-फ़ज़ ने परिपक्व परियोजनाओं (ओपनएसएसएल, लिबपीएनजी, एफएफएमपीईजी) में हजारों सीवीई पाए हैं। फ़ज़िंग ज्ञात वैध इनपुट को परिवर्तित करके या यादृच्छिक इनपुट उत्पन्न करके कार्य करता है; कवरेज-निर्देशित फ़ज़िंग (एएफएल) ट्रैक जो इनपुट नए कोड पथों तक पहुंचते हैं, अज्ञात क्षेत्रों की ओर उत्परिवर्तन का मार्गदर्शन करते हैं। यह बड़े पैमाने पर स्मृति भ्रष्टाचार बग का पता लगाने के लिए सबसे अधिक लागत प्रभावी तकनीक है।
2559
EN + हिं Easy
GB What is 'model-based testing' (MBT) and what test completeness guarantee does it provide?
IN 'मॉडल-आधारित परीक्षण' (एमबीटी) क्या है और यह परीक्षण पूर्णता की क्या गारंटी प्रदान करता है?
A
MBT generates test cases by randomly selecting from a database of pre-written test patterns एमबीटी पूर्व-लिखित परीक्षण पैटर्न के डेटाबेस से यादृच्छिक रूप से चयन करके परीक्षण मामले उत्पन्न करता है
B
MBT derives test cases automatically from a formal model (finite state machine, UML statechart) of expected system behaviour — guaranteeing that all specified transitions or states in the model are covered, making test completeness formally measurable एमबीटी अपेक्षित सिस्टम व्यवहार के औपचारिक मॉडल (परिमित राज्य मशीन, यूएमएल स्टेटचार्ट) से स्वचालित रूप से परीक्षण मामले प्राप्त करता है - यह गारंटी देता है कि मॉडल में सभी निर्दिष्ट संक्रमण या राज्य शामिल हैं, जिससे परीक्षण पूर्णता औपचारिक रूप से मापने योग्य हो जाती है
C
MBT is only applicable to testing database stored procedures and SQL queries एमबीटी केवल डेटाबेस संग्रहीत प्रक्रियाओं और एसक्यूएल प्रश्नों के परीक्षण पर लागू है
D
MBT guarantees that the system has zero defects when all model-derived tests pass एमबीटी गारंटी देता है कि जब सभी मॉडल-व्युत्पन्न परीक्षण पास हो जाते हैं तो सिस्टम में शून्य दोष होते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Model-based testing (Offutt, Utting) takes a formal behaviour model and applies test criteria (all states, all transitions, all transition pairs) to generate test cases that provably satisfy the criterion. Coverage is measured against the model rather than code — if the model is correct and all model transitions are tested, you have formal coverage of all specified behaviour. The limitation: coverage of an incomplete model leaves unmodelled behaviour untested.
व्याख्या (हिन्दी) मॉडल-आधारित परीक्षण (ऑफुट, यूटिंग) एक औपचारिक व्यवहार मॉडल लेता है और परीक्षण मामलों को उत्पन्न करने के लिए परीक्षण मानदंड (सभी राज्य, सभी संक्रमण, सभी संक्रमण जोड़े) लागू करता है जो मानदंड को पूरा करते हैं। कवरेज को कोड के बजाय मॉडल के विरुद्ध मापा जाता है - यदि मॉडल सही है और सभी मॉडल परिवर्तनों का परीक्षण किया जाता है, तो आपके पास सभी निर्दिष्ट व्यवहार का औपचारिक कवरेज होता है। सीमा: अपूर्ण मॉडल का कवरेज बिना मॉडल वाले व्यवहार को छोड़ देता है।
2560
EN + हिं Easy
GB What is 'load testing' versus 'stress testing' versus 'soak testing' and what specific failure each one targets?
IN 'लोड टेस्टिंग' बनाम 'स्ट्रेस टेस्टिंग' बनाम 'सोक टेस्टिंग' क्या है और प्रत्येक का लक्ष्य कौन सी विशिष्ट विफलता है?
A
All three terms describe the same type of performance test with different marketing names सभी तीन शब्द अलग-अलग मार्केटिंग नामों के साथ एक ही प्रकार के प्रदर्शन परीक्षण का वर्णन करते हैं
B
Load testing verifies system meets performance SLAs at expected peak load; stress testing finds the breaking point by exceeding normal load; soak testing runs normal load for extended periods to find memory leaks and resource exhaustion over time लोड परीक्षण सत्यापित करता है कि सिस्टम अपेक्षित चरम लोड पर प्रदर्शन एसएलए को पूरा करता है; तनाव परीक्षण सामान्य भार से अधिक होने पर ब्रेकिंग पॉइंट का पता लगाता है; समय के साथ मेमोरी लीक और संसाधन की कमी का पता लगाने के लिए सोख परीक्षण विस्तारित अवधि के लिए सामान्य लोड चलाता है
C
Load testing is manual; stress testing and soak testing are automated लोड परीक्षण मैनुअल है; तनाव परीक्षण और सोख परीक्षण स्वचालित हैं
D
Stress testing only applies to database systems; load testing only to web servers तनाव परीक्षण केवल डेटाबेस सिस्टम पर लागू होता है; परीक्षण को केवल वेब सर्वर पर लोड करें
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Load test: can we serve 10,000 concurrent users with <200ms response? Stress test: what happens at 50,000? Does it fail gracefully or catastrophically? Soak test: run 10,000 users for 72 hours — does memory grow unboundedly? Does throughput degrade? Each targets a different failure mode: SLA violation, brittleness, and slow degradation respectively.
व्याख्या (हिन्दी) लोड परीक्षण: क्या हम 10,000 समवर्ती उपयोगकर्ताओं को सेवा दे सकते हैं
2561
EN + हिं Easy
GB What is 'contract testing' in microservices architectures and what integration problem does it solve?
IN माइक्रोसर्विसेज आर्किटेक्चर में 'अनुबंध परीक्षण' क्या है और यह किस एकीकरण समस्या का समाधान करता है?
A
Contract testing verifies that software licensing agreements are honoured by all third-party libraries अनुबंध परीक्षण यह सत्यापित करता है कि सॉफ़्टवेयर लाइसेंसिंग समझौतों का सभी तृतीय-पक्ष पुस्तकालयों द्वारा सम्मान किया जाता है
B
Contract testing verifies that a service provider's API matches the expectations of its consumers — solving the problem of integration tests being too slow and brittle by enabling each team to test against consumer-driven contracts independently, without deploying all services अनुबंध परीक्षण सत्यापित करता है कि एक सेवा प्रदाता का एपीआई अपने उपभोक्ताओं की अपेक्षाओं से मेल खाता है - सभी सेवाओं को तैनात किए बिना, प्रत्येक टीम को उपभोक्ता-संचालित अनुबंधों के खिलाफ स्वतंत्र रूप से परीक्षण करने में सक्षम करके एकीकरण परीक्षणों की बहुत धीमी और भंगुर होने की समस्या को हल करना
C
Contract testing is identical to unit testing but applies to API endpoints instead of functions अनुबंध परीक्षण इकाई परीक्षण के समान है लेकिन फ़ंक्शन के बजाय एपीआई एंडपॉइंट पर लागू होता है
D
Contract testing requires all microservices to be deployed to a shared test environment simultaneously अनुबंध परीक्षण के लिए सभी माइक्रोसर्विसेज को एक साथ साझा परीक्षण वातावरण में तैनात करने की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Pact (consumer-driven contract testing) solves the microservices integration test paradox: full integration tests require all services running simultaneously (slow, expensive, fragile). Pact captures consumer expectations as contracts; provider teams run tests verifying their service satisfies all consumer contracts — without consumer services running. This enables independent deployment while maintaining integration confidence.
व्याख्या (हिन्दी) पैक्ट (उपभोक्ता-संचालित अनुबंध परीक्षण) माइक्रोसर्विसेज एकीकरण परीक्षण विरोधाभास को हल करता है: पूर्ण एकीकरण परीक्षणों के लिए सभी सेवाओं को एक साथ चलाने की आवश्यकता होती है (धीमी, महंगी, नाजुक)। समझौता उपभोक्ता की अपेक्षाओं को अनुबंध के रूप में दर्शाता है; प्रदाता टीमें यह सत्यापित करने के लिए परीक्षण चलाती हैं कि उनकी सेवा सभी उपभोक्ता अनुबंधों को संतुष्ट करती है - उपभोक्ता सेवाओं को चालू किए बिना। यह एकीकरण विश्वास को बनाए रखते हुए स्वतंत्र तैनाती को सक्षम बनाता है।
2562
EN + हिं Easy
GB What is 'test doubles' taxonomy and what distinguishes a 'mock' from a 'stub' from a 'spy'?
IN 'टेस्ट डबल्स' वर्गीकरण क्या है और एक 'मॉक' को 'स्टब' से 'जासूस' से क्या अलग करता है?
A
Mock, stub, and spy are all identical objects that replace production dependencies in tests मॉक, स्टब और स्पाई सभी समान वस्तुएं हैं जो परीक्षणों में उत्पादन निर्भरता को प्रतिस्थापित करती हैं
B
Stub returns hard-coded responses (controls indirect inputs); Mock verifies expected interactions were made (verifies indirect outputs); Spy wraps a real object recording calls for later verification without replacing behaviour by default स्टब हार्ड-कोडित प्रतिक्रियाएँ लौटाता है (अप्रत्यक्ष इनपुट को नियंत्रित करता है); मॉक सत्यापित करता है कि अपेक्षित इंटरैक्शन किए गए थे (अप्रत्यक्ष आउटपुट सत्यापित करता है); जासूस डिफ़ॉल्ट रूप से व्यवहार को प्रतिस्थापित किए बिना बाद के सत्यापन के लिए एक वास्तविक ऑब्जेक्ट रिकॉर्डिंग कॉल को लपेटता है
C
Mocks are only used in dynamic languages; stubs are only for statically typed languages मॉक का उपयोग केवल गतिशील भाषाओं में किया जाता है; स्टब्स केवल स्थिर रूप से टाइप की गई भाषाओं के लिए हैं
D
Test doubles are prohibited in TDD; all tests must use real dependencies टीडीडी में टेस्ट डबल्स निषिद्ध हैं; सभी परीक्षणों में वास्तविक निर्भरता का उपयोग होना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Gerard Meszaros ('xUnit Test Patterns') formalised the taxonomy: Dummy (passed but never used), Fake (working implementation, wrong for production — in-memory DB), Stub (returns canned answers), Spy (records calls, passes to real), Mock (pre-programmed with expectations that are verified). The most important distinction: Stubs control the SUT's inputs; Mocks verify the SUT's outputs to collaborators.
व्याख्या (हिन्दी) जेरार्ड मेस्ज़ारोस ('एक्सयूनिट टेस्ट पैटर्न') ने वर्गीकरण को औपचारिक रूप दिया: डमी (उत्तीर्ण लेकिन कभी उपयोग नहीं किया गया), नकली (कार्यात्मक कार्यान्वयन, उत्पादन के लिए गलत - इन-मेमोरी डीबी), स्टब (डिब्बाबंद उत्तर लौटाता है), स्पाई (कॉल रिकॉर्ड करता है, वास्तविक में पास करता है), मॉक (अपेक्षाओं के साथ पूर्व-प्रोग्राम किया गया जो सत्यापित हैं)। सबसे महत्वपूर्ण अंतर: स्टब्स एसयूटी के इनपुट को नियंत्रित करते हैं; मॉक सहयोगियों को SUT के आउटपुट को सत्यापित करते हैं।
2563
EN + हिं Easy
GB What is the 'test pyramid' model and what problem does inverting it (ice cream cone anti-pattern) cause?
IN 'टेस्ट पिरामिड' मॉडल क्या है और इसे उलटने (आइसक्रीम कोन एंटी-पैटर्न) से क्या समस्या होती है?
A
Test pyramid mandates that all tests must be unit tests; no integration tests are permitted परीक्षण पिरामिड का आदेश है कि सभी परीक्षण इकाई परीक्षण होने चाहिए; किसी एकीकरण परीक्षण की अनुमति नहीं है
B
Test pyramid (Fowler/Cohn) recommends many fast unit tests at base, fewer integration tests in middle, fewest UI/E2E tests at top; inverted 'ice cream cone' (mostly E2E tests) causes slow CI (hours per run), brittle tests (UI changes break everything), and poor defect isolation टेस्ट पिरामिड (फाउलर/कोहन) आधार पर कई तेज इकाई परीक्षण, मध्य में कम एकीकरण परीक्षण, शीर्ष पर सबसे कम यूआई/ई2ई परीक्षण की सिफारिश करता है; उलटा 'आइसक्रीम कोन' (ज्यादातर E2E परीक्षण) धीमी CI (प्रति रन घंटे), भंगुर परीक्षण (UI परिवर्तन सब कुछ तोड़ देता है), और खराब दोष अलगाव का कारण बनता है
C
Test pyramid is only applicable to mobile application testing frameworks टेस्ट पिरामिड केवल मोबाइल एप्लिकेशन परीक्षण ढांचे पर लागू होता है
D
Test pyramid recommends eliminating unit tests in favour of integration tests for better coverage टेस्ट पिरामिड बेहतर कवरेज के लिए एकीकरण परीक्षणों के पक्ष में यूनिट परीक्षणों को खत्म करने की सिफारिश करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) E2E tests test the most but cost the most: they require full infrastructure, run in minutes/hours, fail for environmental reasons unrelated to code, and when they fail pinpoint nothing (which of 10 services broke?). Unit tests run in milliseconds, pinpoint exactly the broken unit, and enable TDD cycles. Ice cream cone teams discover their CI pipeline runs for 3+ hours and every unrelated infrastructure change breaks the suite.
व्याख्या (हिन्दी) E2E परीक्षण सबसे अधिक परीक्षण करते हैं लेकिन उनकी लागत सबसे अधिक होती है: उन्हें पूर्ण बुनियादी ढांचे की आवश्यकता होती है, मिनटों/घंटों में चलते हैं, कोड से असंबंधित पर्यावरणीय कारणों से विफल होते हैं, और जब वे विफल होते हैं तो कुछ भी पता नहीं चलता है (10 सेवाओं में से कौन सा टूट गया?)। इकाई परीक्षण मिलीसेकेंड में चलते हैं, टूटी हुई इकाई का ठीक-ठीक पता लगाते हैं और टीडीडी चक्र सक्षम करते हैं। आइसक्रीम कोन टीमों को पता चलता है कि उनकी सीआई पाइपलाइन 3+ घंटे तक चलती है और हर असंबंधित बुनियादी ढांचे में बदलाव से सुइट टूट जाता है।
2564
EN + हिं Medium
GB What is 'property-based testing' and how does it differ from example-based testing?
IN 'संपत्ति-आधारित परीक्षण' क्या है और यह उदाहरण-आधारित परीक्षण से किस प्रकार भिन्न है?
A
Property-based testing only applies to numerical computation algorithms संपत्ति-आधारित परीक्षण केवल संख्यात्मक गणना एल्गोरिदम पर लागू होता है
B
Property-based testing specifies invariant properties that must hold for all inputs (e.g., 'for any list, sorting it twice gives the same result as sorting it once'), then automatically generates hundreds of random inputs to find counterexamples — example tests verify specific cases संपत्ति-आधारित परीक्षण उन अपरिवर्तनीय गुणों को निर्दिष्ट करता है जो सभी इनपुट के लिए होने चाहिए (उदाहरण के लिए, 'किसी भी सूची के लिए, इसे दो बार सॉर्ट करने से एक बार सॉर्ट करने के समान परिणाम मिलता है'), फिर स्वचालित रूप से काउंटर उदाहरण खोजने के लिए सैकड़ों यादृच्छिक इनपुट उत्पन्न करता है - उदाहरण परीक्षण विशिष्ट मामलों को सत्यापित करते हैं
C
Property-based testing is a synonym for specification testing and requires a formal specification language संपत्ति-आधारित परीक्षण विनिर्देश परीक्षण का पर्याय है और इसके लिए औपचारिक विनिर्देश भाषा की आवश्यकता होती है
D
Property-based testing guarantees correctness once no counterexample is found in 1000 trials 1000 परीक्षणों में कोई प्रति-उदाहरण नहीं मिलने पर संपत्ति-आधारित परीक्षण शुद्धता की गारंटी देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) QuickCheck (Haskell, later Hypothesis in Python, fast-check in JS) generates random inputs satisfying constraints and tests a property. When a counterexample is found, it 'shrinks' it to the minimal failing case. It finds bugs example-based tests would never think to test: what if the list has one element? What if all elements are equal? What if integer arithmetic overflows? Properties like 'encode(decode(x)) == x' are particularly powerful.
व्याख्या (हिन्दी) क्विकचेक (हास्केल, बाद में पायथन में परिकल्पना, जेएस में फास्ट-चेक) बाधाओं को संतुष्ट करने वाले यादृच्छिक इनपुट उत्पन्न करता है और एक संपत्ति का परीक्षण करता है। जब एक प्रति-उदाहरण पाया जाता है, तो यह इसे न्यूनतम असफल मामले में 'सिकुड़' देता है। यह उन बगों का पता लगाता है जिन्हें उदाहरण-आधारित परीक्षण कभी भी परीक्षण करने के बारे में नहीं सोचेंगे: यदि सूची में एक तत्व है तो क्या होगा? यदि सभी तत्व समान हों तो क्या होगा? क्या होगा यदि पूर्णांक अंकगणित अतिप्रवाहित हो जाए? 'एनकोड(डिकोड(x)) == x' जैसे गुण विशेष रूप से शक्तिशाली हैं।
2565
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% प्रयोज्य समस्याएं मिलती हैं' शोध से पता चलता है कि छोटे पैमाने पर प्रयोज्य परीक्षण अत्यधिक प्रभावी है। कार्यात्मक परीक्षण (क्या पासवर्ड रीसेट काम करता है?) आपको इस बारे में कुछ नहीं बताता है कि उपयोगकर्ता 'पासवर्ड भूल गए' लिंक ढूंढ सकते हैं, त्रुटि संदेशों की व्याख्या कर सकते हैं, या सहायता के बिना प्रवाह पूरा कर सकते हैं। प्रयोज्यता परीक्षण इन खोज योग्य-केवल-अवलोकन विफलताओं को प्रकट करता है।
2551–2565 of 2726