Software Engineering — MCQ Practice

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

📚 647 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
647 questions
511
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% दोष निवारण होता है। अर्थशास्त्र: नियमित कोड के लिए जोड़ी प्रोग्रामिंग का उपयोग करें; सुरक्षा-महत्वपूर्ण एल्गोरिदम, क्रिप्टोग्राफ़िक कार्यान्वयन, या ऐतिहासिक रूप से उच्च दोष घनत्व वाले मॉड्यूल के लिए औपचारिक निरीक्षण का उपयोग करें।
512
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 द्वारा आवश्यक है'), क्यों एक स्पष्ट दृष्टिकोण को अस्वीकार कर दिया गया था ('यहां हैशमैप का उपयोग न करें - यह गैर-नियतात्मक आदेश का कारण बनता है जो ऑडिट लॉग को तोड़ देता है'), या अपरिवर्तनीय धारणाएं ('कॉलर गारंटी सूची क्रमबद्ध है')। अच्छे कोड नाम आपको क्या बताते हैं; अच्छी टिप्पणियाँ आपको बताती हैं क्यों।
513
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.
व्याख्या (हिन्दी) दस्तावेज़ीकरण दर्शक मूल रूप से संरचना और शब्दावली को बदलता है। डेवलपर दस्तावेज़ीकरण प्रोग्रामिंग ज्ञान को मानता है, अमूर्तता, एपीआई, परिनियोजन, समस्या निवारण का वर्णन करता है। उपयोगकर्ता दस्तावेज़ीकरण डोमेन ज्ञान मानता है, पूरा किए जाने वाले कार्यों का वर्णन करता है, स्क्रीनशॉट का उपयोग करता है, कार्यान्वयन विवरण से बचता है। डेवलपर्स के लिए उपयोगकर्ता दस्तावेज़ लिखना (बहुत सरल) या उपयोगकर्ताओं के लिए तकनीकी दस्तावेज़ लिखना (बहुत सारगर्भित) दोनों ही सामान्य विफलताएँ हैं।
514
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. सत्र-आधारित खोजपूर्ण परीक्षण इसे समय-सीमा वाले सत्रों और चार्टर दस्तावेज़ीकरण के साथ संरचित करता है, जो जवाबदेही के साथ स्वतंत्रता को संतुलित करता है।
515
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.
व्याख्या (हिन्दी) एएफएल (अमेरिकन फ़ज़ी लोप), लिबफ़ुज़र और ओएसएस-फ़ज़ ने परिपक्व परियोजनाओं (ओपनएसएसएल, लिबपीएनजी, एफएफएमपीईजी) में हजारों सीवीई पाए हैं। फ़ज़िंग ज्ञात वैध इनपुट को परिवर्तित करके या यादृच्छिक इनपुट उत्पन्न करके कार्य करता है; कवरेज-निर्देशित फ़ज़िंग (एएफएल) ट्रैक जो इनपुट नए कोड पथों तक पहुंचते हैं, अज्ञात क्षेत्रों की ओर उत्परिवर्तन का मार्गदर्शन करते हैं। यह बड़े पैमाने पर स्मृति भ्रष्टाचार बग का पता लगाने के लिए सबसे अधिक लागत प्रभावी तकनीक है।
516
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.
व्याख्या (हिन्दी) मॉडल-आधारित परीक्षण (ऑफुट, यूटिंग) एक औपचारिक व्यवहार मॉडल लेता है और परीक्षण मामलों को उत्पन्न करने के लिए परीक्षण मानदंड (सभी राज्य, सभी संक्रमण, सभी संक्रमण जोड़े) लागू करता है जो मानदंड को पूरा करते हैं। कवरेज को कोड के बजाय मॉडल के विरुद्ध मापा जाता है - यदि मॉडल सही है और सभी मॉडल परिवर्तनों का परीक्षण किया जाता है, तो आपके पास सभी निर्दिष्ट व्यवहार का औपचारिक कवरेज होता है। सीमा: अपूर्ण मॉडल का कवरेज बिना मॉडल वाले व्यवहार को छोड़ देता है।
517
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 समवर्ती उपयोगकर्ताओं को सेवा दे सकते हैं
518
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.
व्याख्या (हिन्दी) पैक्ट (उपभोक्ता-संचालित अनुबंध परीक्षण) माइक्रोसर्विसेज एकीकरण परीक्षण विरोधाभास को हल करता है: पूर्ण एकीकरण परीक्षणों के लिए सभी सेवाओं को एक साथ चलाने की आवश्यकता होती है (धीमी, महंगी, नाजुक)। समझौता उपभोक्ता की अपेक्षाओं को अनुबंध के रूप में दर्शाता है; प्रदाता टीमें यह सत्यापित करने के लिए परीक्षण चलाती हैं कि उनकी सेवा सभी उपभोक्ता अनुबंधों को संतुष्ट करती है - उपभोक्ता सेवाओं को चालू किए बिना। यह एकीकरण विश्वास को बनाए रखते हुए स्वतंत्र तैनाती को सक्षम बनाता है।
519
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 के आउटपुट को सत्यापित करते हैं।
520
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+ घंटे तक चलती है और हर असंबंधित बुनियादी ढांचे में बदलाव से सुइट टूट जाता है।
521
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' जैसे गुण विशेष रूप से शक्तिशाली हैं।
522
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% प्रयोज्य समस्याएं मिलती हैं' शोध से पता चलता है कि छोटे पैमाने पर प्रयोज्य परीक्षण अत्यधिक प्रभावी है। कार्यात्मक परीक्षण (क्या पासवर्ड रीसेट काम करता है?) आपको इस बारे में कुछ नहीं बताता है कि उपयोगकर्ता 'पासवर्ड भूल गए' लिंक ढूंढ सकते हैं, त्रुटि संदेशों की व्याख्या कर सकते हैं, या सहायता के बिना प्रवाह पूरा कर सकते हैं। प्रयोज्यता परीक्षण इन खोज योग्य-केवल-अवलोकन विफलताओं को प्रकट करता है।
523
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 चूक जाता है, भाषा-अज्ञेयवादी। पेनेट्रेशन परीक्षण (मानव विशेषज्ञ) हमले के रास्ते स्वचालन चूक को खोजने के लिए रचनात्मक रूप से कमजोरियों को जोड़ते हैं। प्रभावी सुरक्षा परीक्षण के लिए सभी परतों की आवश्यकता होती है।
524
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) ने उत्पादन उदाहरणों को बेतरतीब ढंग से समाप्त करके अराजकता इंजीनियरिंग की शुरुआत की। पारंपरिक परीक्षण यह सत्यापित करते हैं कि घटक अलगाव में काम करते हैं; वे यह सत्यापित नहीं कर सकते कि डेटाबेस धीमा होने पर नेटफ्लिक्स की अनुशंसा सेवा सही ढंग से वापस आ जाती है। कैओस इंजीनियरिंग वास्तविक विफलता स्थितियों के तहत वितरित सिस्टम लचीलेपन को मान्य करती है: 'यदि हम किसी सेवा को बेतरतीब ढंग से क्रैश कर देते हैं, तो क्या सिस्टम शानदार ढंग से ख़राब हो जाता है या भयावह रूप से विफल हो जाता है?'
525
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 बदलता है, तो कौन से परीक्षण मामलों को अद्यतन किया जाना चाहिए? पता लगाने की क्षमता के बिना, यह जासूसी का काम है; इसके साथ, यह एक लुकअप है।
511–525 of 647