196 Question 196 EN + हिं Easy GB What is a 'test oracle' and what is the 'oracle problem' in software testing? IN 'टेस्ट ओरेकल' क्या है और सॉफ्टवेयर परीक्षण में 'ओरेकल समस्या' क्या है? A A senior tester who manually approves all automated test results एक वरिष्ठ परीक्षक जो सभी स्वचालित परीक्षण परिणामों को मैन्युअल रूप से अनुमोदित करता है B A test oracle is the mechanism determining expected output to compare against actual results; the oracle problem is that for many complex systems no reliable oracle exists to determine correct output एक परीक्षण दैवज्ञ वास्तविक परिणामों की तुलना करने के लिए अपेक्षित आउटपुट निर्धारित करने वाला तंत्र है; ओरेकल की समस्या यह है कि कई जटिल प्रणालियों के लिए सही आउटपुट निर्धारित करने के लिए कोई विश्वसनीय ओरेकल मौजूद नहीं है C Legal liability of testing incorrect software in production उत्पादन में ग़लत सॉफ़्टवेयर के परीक्षण का कानूनी दायित्व D An automated tool that generates test cases from source code एक स्वचालित उपकरण जो स्रोत कोड से परीक्षण मामले उत्पन्न करता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Weyuker (1982) identified the oracle problem: to verify a test result, you need an oracle. For ML models, concurrent systems, or simulations where ground truth is unavailable or expensive to compute, constructing reliable oracles is itself a research challenge. व्याख्या (हिन्दी) वेयुकर (1982) ने ओरेकल समस्या की पहचान की: एक परीक्षण परिणाम को सत्यापित करने के लिए, आपको एक ओरेकल की आवश्यकता होती है। एमएल मॉडल, समवर्ती सिस्टम, या सिमुलेशन के लिए जहां जमीनी सच्चाई अनुपलब्ध है या गणना करना महंगा है, विश्वसनीय दैवज्ञ का निर्माण करना अपने आप में एक शोध चुनौती है। 🎯 Exam Perspective Software Engineering ("Software Testing" sub-topic) के इस प्रश्न को — difficulty level "Easy" कई प्रतियोगी परीक्षाओं जैसे SSC, Railway, Banking और State PCS में repeat होते देखा गया है। Concept clarity के लिए explanation section जरूर पढ़ें। 🔗 Related Questions What is a 'test oracle' and what is the 'oracle problem... What is 'non-regression testing strategy' in CI and wha... What is 'regression testing' and what risk does inadequ... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
197 Question 197 EN + हिं Medium GB What is 'equivalence partitioning' and how does it reduce test case count without sacrificing coverage quality? IN 'समतुल्यता विभाजन' क्या है और यह कवरेज गुणवत्ता से समझौता किए बिना टेस्ट केस की संख्या को कैसे कम करता है? A Divides development team into groups each responsible for testing one module विकास टीम को समूहों में विभाजित करता है, प्रत्येक एक मॉड्यूल के परीक्षण के लिए जिम्मेदार होता है B Divides input data into classes where members are expected to cause identical behaviour — testing one value per class is assumed equivalent to testing all values, reducing redundant tests इनपुट डेटा को उन वर्गों में विभाजित करता है जहां सदस्यों से समान व्यवहार की अपेक्षा की जाती है - प्रति वर्ग एक मान का परीक्षण सभी मूल्यों के परीक्षण के बराबर माना जाता है, अनावश्यक परीक्षणों को कम करता है C Only applies to string inputs; cannot be used with numeric data केवल स्ट्रिंग इनपुट पर लागू होता है; संख्यात्मक डेटा के साथ उपयोग नहीं किया जा सकता D A test management technique allocating test cases to team members एक परीक्षण प्रबंधन तकनीक जो टीम के सदस्यों को परीक्षण मामले आवंटित करती है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) If a function accepts integers 1-100, equivalence partitioning identifies valid inputs (1-100) as one partition, invalid negatives as another, and values > 100 as another. Testing one representative from each partition reduces test cases while maintaining reasonable defect detection confidence. व्याख्या (हिन्दी) यदि कोई फ़ंक्शन पूर्णांक 1-100 स्वीकार करता है, तो समतुल्य विभाजन वैध इनपुट (1-100) को एक विभाजन के रूप में, अमान्य नकारात्मक को दूसरे के रूप में, और मान > 100 को दूसरे के रूप में पहचानता है। प्रत्येक विभाजन से एक प्रतिनिधि का परीक्षण उचित दोष पहचान आत्मविश्वास बनाए रखते हुए परीक्षण मामलों को कम करता है। 🎯 Exam Perspective यह सवाल Software Engineering ("Software Testing" sub-topic) category का है — difficulty level "Medium", और SSC CGL, IBPS, RRB और State-level परीक्षाओं के exam pattern में इस तरह के questions common हैं। Answer choose करने के बाद दिया गया explanation जरूर पढ़ें। 🔗 Related Questions What is the fundamental distinction between 'error', 'f... In Waterfall, what is the 'integration testing' phase s... In a Waterfall project, what does Acceptance Testing pr... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
198 Question 198 EN + हिं Easy GB What is 'regression testing' and what risk does inadequate regression testing introduce into CI/CD pipelines? IN 'प्रतिगमन परीक्षण' क्या है और अपर्याप्त प्रतिगमन परीक्षण सीआई/सीडी पाइपलाइनों में क्या जोखिम लाता है? A Checks system performance under decreasing load conditions घटती लोड स्थितियों के तहत सिस्टम के प्रदर्शन की जाँच करता है B Re-executes tests after changes to ensure previously working functionality has not been broken; inadequate regression testing allows regressions to reach production where detection and repair cost is highest यह सुनिश्चित करने के लिए कि पहले से काम कर रही कार्यक्षमता टूटी नहीं है, परिवर्तनों के बाद परीक्षण दोबारा निष्पादित करता है; अपर्याप्त प्रतिगमन परीक्षण प्रतिगमन को उत्पादन तक पहुंचने की अनुमति देता है जहां पता लगाने और मरम्मत की लागत सबसे अधिक होती है C Only required when programming language version is upgraded केवल प्रोग्रामिंग भाषा संस्करण अपग्रेड होने पर ही आवश्यक है D In CI/CD, automatically replaced by monitoring and alerting systems सीआई/सीडी में, स्वचालित रूप से निगरानी और चेतावनी प्रणालियों द्वारा प्रतिस्थापित किया जाता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Regression testing is critical in CD pipelines: every commit potentially affects unrelated functionality through shared dependencies. Without comprehensive automated regression suites, teams either slow delivery or accept the risk of silent regressions surfacing only after deployment. व्याख्या (हिन्दी) सीडी पाइपलाइनों में प्रतिगमन परीक्षण महत्वपूर्ण है: प्रत्येक प्रतिबद्धता संभावित रूप से साझा निर्भरता के माध्यम से असंबंधित कार्यक्षमता को प्रभावित करती है। व्यापक स्वचालित रिग्रेशन सुइट्स के बिना, टीमें या तो डिलीवरी धीमी कर देती हैं या केवल तैनाती के बाद सामने आने वाले साइलेंट रिग्रेशन के जोखिम को स्वीकार करती हैं। 🎯 Exam Perspective यह प्रश्न Software Engineering ("Software Testing" sub-topic) की तैयारी करने वाले अभ्यर्थियों के लिए उपयोगी है — difficulty level "Easy"। इस तरह के प्रश्न अक्सर SSC, Railway, Banking और State PCS जैसी परीक्षाओं में पूछे जाते रहे हैं, इसलिए concept और explanation दोनों को ध्यान से समझें, सिर्फ उत्तर याद न करें। 🔗 Related Questions What is 'regression testing' and what risk does inadequ... What is 'equivalence partitioning' and how does it redu... In a Waterfall project, what does Acceptance Testing pr... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
199 Question 199 EN + हिं Easy GB In Waterfall, what is the 'integration testing' phase specifically designed to verify? IN वॉटरफॉल में, 'एकीकरण परीक्षण' चरण विशेष रूप से सत्यापित करने के लिए क्या डिज़ाइन किया गया है? A That individual modules correctly implement their specified algorithms वह व्यक्तिगत मॉड्यूल अपने निर्दिष्ट एल्गोरिदम को सही ढंग से लागू करते हैं B That independently developed and unit-tested modules work correctly together when combined — specifically verifying interfaces, data exchange contracts, and interactions between integrated components स्वतंत्र रूप से विकसित और यूनिट-परीक्षणित मॉड्यूल संयुक्त होने पर एक साथ सही ढंग से काम करते हैं - विशेष रूप से इंटरफेस, डेटा एक्सचेंज अनुबंध और एकीकृत घटकों के बीच इंटरैक्शन की पुष्टि करते हुए C That the complete integrated system meets all user acceptance criteria यह कि संपूर्ण एकीकृत प्रणाली सभी उपयोगकर्ता स्वीकृति मानदंडों को पूरा करती है D That the production deployment environment matches the development environment specifications यह कि उत्पादन परिनियोजन परिवेश विकास परिवेश विनिर्देशों से मेल खाता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Unit testing verifies individual modules in isolation. Integration testing verifies that the interfaces and interactions between modules work correctly — data passed between them is correctly interpreted, API contracts are honoured, and shared resources are properly managed. System testing then verifies the fully integrated system against requirements. व्याख्या (हिन्दी) यूनिट परीक्षण अलग-अलग मॉड्यूल को अलग-अलग सत्यापित करता है। एकीकरण परीक्षण सत्यापित करता है कि मॉड्यूल के बीच इंटरफेस और इंटरैक्शन सही ढंग से काम करते हैं - उनके बीच पारित डेटा की सही व्याख्या की जाती है, एपीआई अनुबंधों का सम्मान किया जाता है, और साझा संसाधनों को ठीक से प्रबंधित किया जाता है। सिस्टम परीक्षण तब आवश्यकताओं के विरुद्ध पूरी तरह से एकीकृत सिस्टम की पुष्टि करता है। 🎯 Exam Perspective Software Engineering ("Software Testing" sub-topic) से जुड़ा यह सवाल — difficulty level "Easy" उन students के लिए काम का है जो Railway, SSC, Banking और Defence परीक्षाओं की तैयारी कर रहे हैं। बेहतर होगा कि explanation पढ़कर concept clear करें, ताकि exam में similar प्रश्न आने पर confusion न हो। 🔗 Related Questions What is a 'test oracle' and what is the 'oracle problem... What is 'regression testing' and what risk does inadequ... What is a 'test oracle' and what is the 'oracle problem... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
200 Question 200 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 चलाएँ; हर रात पूरा सुइट चलाएँ। जोखिम-आधारित चयन (कोड परिवर्तन कवरेज का उपयोग करके परीक्षण चयन) दोष का पता लगाने को बनाए रखते हुए अनावश्यक परीक्षण निष्पादन को कम करता है। 🎯 Exam Perspective SSC, Railway, Banking और State PCS जैसी परीक्षाओं में Software Engineering ("Software Testing" sub-topic) से सवाल अक्सर पूछे जाते हैं — difficulty level "Easy"। इसलिए सिर्फ answer रटने के बजाय, नीचे दी गई explanation को ध्यान से पढ़ें और concept समझें। 🔗 Related Questions What is 'equivalence partitioning' and how does it redu... In a Waterfall project, what does Acceptance Testing pr... What is 'regression testing' and what risk does inadequ... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
201 Question 201 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σ) वाले नियंत्रण चार्ट सांख्यिकीय रूप से इसका उत्तर देते हैं। नियंत्रण सीमा से बाहर के बिंदु जांच की आवश्यकता वाले विशेष कारणों (नए डेवलपर, नए कोडबेस क्षेत्र, प्रक्रिया परिवर्तन) का संकेत देते हैं। यह गुणवत्ता प्रबंधन को सहजता से साक्ष्य-आधारित निर्णय लेने में बदल देता है। 🎯 Exam Perspective अगर आप SSC CGL, IBPS, RRB और State-level परीक्षाओं की तैयारी कर रहे हैं, तो Software Engineering ("Software Testing" sub-topic) का यह topic आपके लिए महत्वपूर्ण है — difficulty level "Easy"। Exam में accuracy बढ़ाने के लिए हर सवाल की explanation जरूर पढ़ें। 🔗 Related Questions In a Waterfall project, what does Acceptance Testing pr... What is a 'test oracle' and what is the 'oracle problem... What is 'non-regression testing strategy' in CI and wha... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
202 Question 202 EN + हिं Easy GB In a Waterfall project, what does Acceptance Testing primarily verify and who owns it? IN वॉटरफॉल प्रोजेक्ट में, स्वीकृति परीक्षण मुख्य रूप से क्या सत्यापित करता है और इसका मालिक कौन है? A That source code compiles without errors; owned by the development lead वह स्रोत कोड त्रुटियों के बिना संकलित होता है; विकास नेतृत्व के स्वामित्व में B That the delivered system meets contractual requirements and is fit for deployment; owned by the customer/client यह कि वितरित प्रणाली संविदात्मक आवश्यकताओं को पूरा करती है और तैनाती के लिए उपयुक्त है; ग्राहक/ग्राहक के स्वामित्व में C That each module performs unit-level function; owned by QA department प्रत्येक मॉड्यूल इकाई-स्तरीय कार्य करता है; QA विभाग के स्वामित्व में D That system performance meets SLA benchmarks; owned by infrastructure team वह सिस्टम प्रदर्शन SLA बेंचमार्क को पूरा करता है; इंफ्रास्ट्रक्चर टीम के स्वामित्व में ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Acceptance Testing (UAT) is performed by the customer to verify the delivered system fulfils agreed requirements and is suitable for operational use. It is the final gate before handover and the customer's formal sign-off mechanism. व्याख्या (हिन्दी) स्वीकृति परीक्षण (यूएटी) ग्राहक द्वारा यह सत्यापित करने के लिए किया जाता है कि वितरित प्रणाली सहमत आवश्यकताओं को पूरा करती है और परिचालन उपयोग के लिए उपयुक्त है। यह हैंडओवर से पहले का अंतिम द्वार और ग्राहक का औपचारिक साइन-ऑफ तंत्र है। 🎯 Exam Perspective Software Engineering ("Software Testing" sub-topic) के इस प्रश्न को — difficulty level "Easy" कई प्रतियोगी परीक्षाओं जैसे Railway, SSC, Banking और Defence परीक्षाओं में repeat होते देखा गया है। Concept clarity के लिए explanation section जरूर पढ़ें। 🔗 Related Questions What is 'statistical process control' (SPC) applied to... What is 'regression testing' and what risk does inadequ... What is 'software quality assurance' (SQA) and how does... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
203 Question 203 EN + हिं Easy GB What is the fundamental distinction between 'error', 'fault', and 'failure' in software testing? IN सॉफ़्टवेयर परीक्षण में 'त्रुटि', 'त्रुटि' और 'विफलता' के बीच मूलभूत अंतर क्या है? A Error, fault, and failure are synonymous terms in IEEE standards आईईईई मानकों में त्रुटि, गलती और विफलता पर्यायवाची शब्द हैं B An error is a human mistake producing a fault (defect) in code; a fault is the static defect; a failure occurs when the fault is executed and the system behaves incorrectly त्रुटि एक मानवीय गलती है जो कोड में दोष (दोष) उत्पन्न करती है; एक दोष स्थैतिक दोष है; विफलता तब होती है जब गलती निष्पादित हो जाती है और सिस्टम गलत तरीके से व्यवहार करता है C Error is a failing test; fault is a passing test when it should fail; failure is when no tests are written त्रुटि एक असफल परीक्षा है; गलती एक उत्तीर्ण परीक्षा है जब उसे असफल होना चाहिए; विफलता तब होती है जब कोई परीक्षण नहीं लिखा जाता है D Error in hardware; fault in software; failure in UI हार्डवेयर में त्रुटि; सॉफ्टवेयर में खराबी; यूआई में विफलता ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) IEEE 610 defines: Error (human action introducing a fault), Fault (defect present in code), Failure (observable incorrect behaviour when fault manifests). Not all faults cause failures — a fault in dead code never executes. व्याख्या (हिन्दी) आईईईई 610 परिभाषित करता है: त्रुटि (मानव क्रिया गलती का परिचय देती है), दोष (कोड में मौजूद दोष), विफलता (गलती प्रकट होने पर देखने योग्य गलत व्यवहार)। सभी दोष विफलताओं का कारण नहीं बनते - मृत कोड में कोई दोष कभी निष्पादित नहीं होता। 🎯 Exam Perspective यह सवाल Software Engineering ("Software Testing" sub-topic) category का है — difficulty level "Easy", और SSC, Railway, Banking और State PCS के exam pattern में इस तरह के questions common हैं। Answer choose करने के बाद दिया गया explanation जरूर पढ़ें। 🔗 Related Questions What is 'software quality assurance' (SQA) and how does... In Waterfall, what is the 'integration testing' phase s... What is 'regression testing' and what risk does inadequ... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
204 Question 204 EN + हिं Easy GB What is a 'test oracle' and what is the 'oracle problem' in software testing? IN 'टेस्ट ओरेकल' क्या है और सॉफ्टवेयर परीक्षण में 'ओरेकल समस्या' क्या है? A A senior tester who manually approves all automated test results एक वरिष्ठ परीक्षक जो सभी स्वचालित परीक्षण परिणामों को मैन्युअल रूप से अनुमोदित करता है B A test oracle is the mechanism determining expected output to compare against actual results; the oracle problem is that for many complex systems no reliable oracle exists to determine correct output एक परीक्षण दैवज्ञ वास्तविक परिणामों की तुलना करने के लिए अपेक्षित आउटपुट निर्धारित करने वाला तंत्र है; ओरेकल की समस्या यह है कि कई जटिल प्रणालियों के लिए सही आउटपुट निर्धारित करने के लिए कोई विश्वसनीय ओरेकल मौजूद नहीं है C Legal liability of testing incorrect software in production उत्पादन में ग़लत सॉफ़्टवेयर के परीक्षण का कानूनी दायित्व D An automated tool that generates test cases from source code एक स्वचालित उपकरण जो स्रोत कोड से परीक्षण मामले उत्पन्न करता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Weyuker (1982) identified the oracle problem: to verify a test result, you need an oracle. For ML models, concurrent systems, or simulations where ground truth is unavailable or expensive to compute, constructing reliable oracles is itself a research challenge. व्याख्या (हिन्दी) वेयुकर (1982) ने ओरेकल समस्या की पहचान की: एक परीक्षण परिणाम को सत्यापित करने के लिए, आपको एक ओरेकल की आवश्यकता होती है। एमएल मॉडल, समवर्ती सिस्टम, या सिमुलेशन के लिए जहां जमीनी सच्चाई अनुपलब्ध है या गणना करना महंगा है, विश्वसनीय भविष्यवक्ता का निर्माण करना अपने आप में एक शोध चुनौती है। 🎯 Exam Perspective यह प्रश्न Software Engineering ("Software Testing" sub-topic) की तैयारी करने वाले अभ्यर्थियों के लिए उपयोगी है — difficulty level "Easy"। इस तरह के प्रश्न अक्सर Railway, SSC, Banking और Defence परीक्षाओं जैसी परीक्षाओं में पूछे जाते रहे हैं, इसलिए concept और explanation दोनों को ध्यान से समझें, सिर्फ उत्तर याद न करें। 🔗 Related Questions What is 'regression testing' and what risk does inadequ... What is 'regression testing' and what risk does inadequ... What is the fundamental distinction between 'error', 'f... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
205 Question 205 EN + हिं Medium GB What is 'equivalence partitioning' and how does it reduce test case count without sacrificing coverage quality? IN 'समतुल्यता विभाजन' क्या है और यह कवरेज गुणवत्ता से समझौता किए बिना टेस्ट केस की संख्या को कैसे कम करता है? A Divides development team into groups each responsible for testing one module विकास टीम को समूहों में विभाजित करता है, प्रत्येक एक मॉड्यूल के परीक्षण के लिए जिम्मेदार होता है B Divides input data into classes where members are expected to cause identical behaviour — testing one value per class is assumed equivalent to testing all values, reducing redundant tests इनपुट डेटा को उन वर्गों में विभाजित करता है जहां सदस्यों से समान व्यवहार की अपेक्षा की जाती है - प्रति वर्ग एक मान का परीक्षण सभी मूल्यों के परीक्षण के बराबर माना जाता है, अनावश्यक परीक्षणों को कम करता है C Only applies to string inputs; cannot be used with numeric data केवल स्ट्रिंग इनपुट पर लागू होता है; संख्यात्मक डेटा के साथ उपयोग नहीं किया जा सकता D A test management technique allocating test cases to team members टीम के सदस्यों को परीक्षण मामले आवंटित करने वाली एक परीक्षण प्रबंधन तकनीक ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) If a function accepts integers 1-100, equivalence partitioning identifies valid inputs (1-100) as one partition, invalid negatives as another, and values > 100 as another. Testing one representative from each partition reduces test cases while maintaining reasonable defect detection confidence. व्याख्या (हिन्दी) यदि कोई फ़ंक्शन पूर्णांक 1-100 स्वीकार करता है, तो समतुल्य विभाजन मान्य इनपुट (1-100) को एक विभाजन के रूप में, अमान्य नकारात्मक को दूसरे के रूप में, और मान > 100 को दूसरे के रूप में पहचानता है। प्रत्येक विभाजन से एक प्रतिनिधि का परीक्षण उचित दोष पहचान आत्मविश्वास बनाए रखते हुए परीक्षण मामलों को कम करता है। 🎯 Exam Perspective Software Engineering ("Software Testing" sub-topic) से जुड़ा यह सवाल — difficulty level "Medium" उन students के लिए काम का है जो SSC, Railway, Banking और State PCS की तैयारी कर रहे हैं। बेहतर होगा कि explanation पढ़कर concept clear करें, ताकि exam में similar प्रश्न आने पर confusion न हो। 🔗 Related Questions What is 'regression testing' and what risk does inadequ... What is 'statistical process control' (SPC) applied to... In a Waterfall project, what does Acceptance Testing pr... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
206 Question 206 EN + हिं Easy GB What is 'regression testing' and what risk does inadequate regression testing introduce into CI/CD pipelines? IN 'प्रतिगमन परीक्षण' क्या है और अपर्याप्त प्रतिगमन परीक्षण सीआई/सीडी पाइपलाइनों में क्या जोखिम लाता है? A Checks system performance under decreasing load conditions घटती लोड स्थितियों के तहत सिस्टम के प्रदर्शन की जाँच करता है B Re-executes tests after changes to ensure previously working functionality has not been broken; inadequate regression testing allows regressions to reach production where detection and repair cost is highest यह सुनिश्चित करने के लिए कि पहले से काम कर रही कार्यक्षमता टूटी नहीं है, परिवर्तनों के बाद परीक्षण दोबारा निष्पादित करता है; अपर्याप्त प्रतिगमन परीक्षण प्रतिगमन को उत्पादन तक पहुंचने की अनुमति देता है जहां पता लगाने और मरम्मत की लागत सबसे अधिक होती है C Only required when programming language version is upgraded केवल तभी आवश्यक है जब प्रोग्रामिंग भाषा संस्करण अपग्रेड किया गया हो D In CI/CD, automatically replaced by monitoring and alerting systems सीआई/सीडी में, स्वचालित रूप से निगरानी और चेतावनी प्रणालियों द्वारा प्रतिस्थापित किया जाता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Regression testing is critical in CD pipelines: every commit potentially affects unrelated functionality through shared dependencies. Without comprehensive automated regression suites, teams either slow delivery or accept the risk of silent regressions surfacing only after deployment. व्याख्या (हिन्दी) सीडी पाइपलाइनों में प्रतिगमन परीक्षण महत्वपूर्ण है: प्रत्येक प्रतिबद्धता संभावित रूप से साझा निर्भरता के माध्यम से असंबंधित कार्यक्षमता को प्रभावित करती है। व्यापक स्वचालित रिग्रेशन सुइट्स के बिना, टीमें या तो डिलीवरी धीमी कर देती हैं या केवल तैनाती के बाद सामने आने वाले साइलेंट रिग्रेशन के जोखिम को स्वीकार करती हैं। 🎯 Exam Perspective Railway, SSC, Banking और Defence परीक्षाओं जैसी परीक्षाओं में Software Engineering ("Software Testing" sub-topic) से सवाल अक्सर पूछे जाते हैं — difficulty level "Easy"। इसलिए सिर्फ answer रटने के बजाय, नीचे दी गई explanation को ध्यान से पढ़ें और concept समझें। 🔗 Related Questions In a Waterfall project, what does Acceptance Testing pr... What is a 'test oracle' and what is the 'oracle problem... What is 'non-regression testing strategy' in CI and wha... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
207 Question 207 EN + हिं Easy GB In Waterfall, what is the 'integration testing' phase specifically designed to verify? IN वॉटरफॉल में, 'एकीकरण परीक्षण' चरण विशेष रूप से सत्यापित करने के लिए क्या डिज़ाइन किया गया है? A That individual modules correctly implement their specified algorithms वह व्यक्तिगत मॉड्यूल अपने निर्दिष्ट एल्गोरिदम को सही ढंग से लागू करते हैं B That independently developed and unit-tested modules work correctly together when combined — specifically verifying interfaces, data exchange contracts, and interactions between integrated components स्वतंत्र रूप से विकसित और यूनिट-परीक्षणित मॉड्यूल संयुक्त होने पर एक साथ सही ढंग से काम करते हैं - विशेष रूप से इंटरफेस, डेटा विनिमय अनुबंध और एकीकृत घटकों के बीच इंटरैक्शन की पुष्टि करते हुए C That the complete integrated system meets all user acceptance criteria यह कि संपूर्ण एकीकृत प्रणाली सभी उपयोगकर्ता स्वीकृति मानदंडों को पूरा करती है D That the production deployment environment matches the development environment specifications उत्पादन परिनियोजन परिवेश विकास परिवेश विनिर्देशों से मेल खाता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Unit testing verifies individual modules in isolation. Integration testing verifies that the interfaces and interactions between modules work correctly — data passed between them is correctly interpreted, API contracts are honoured, and shared resources are properly managed. System testing then verifies the fully integrated system against requirements. व्याख्या (हिन्दी) यूनिट परीक्षण अलग-अलग मॉड्यूल को अलग-अलग सत्यापित करता है। एकीकरण परीक्षण सत्यापित करता है कि मॉड्यूल के बीच इंटरफेस और इंटरैक्शन सही ढंग से काम करते हैं - उनके बीच पारित डेटा की सही व्याख्या की जाती है, एपीआई अनुबंधों का सम्मान किया जाता है, और साझा संसाधनों को ठीक से प्रबंधित किया जाता है। सिस्टम परीक्षण तब आवश्यकताओं के विरुद्ध पूरी तरह से एकीकृत सिस्टम की पुष्टि करता है। 🎯 Exam Perspective अगर आप UPSC, SSC, Banking और Police भर्ती की तैयारी कर रहे हैं, तो Software Engineering ("Software Testing" sub-topic) का यह topic आपके लिए महत्वपूर्ण है — difficulty level "Easy"। Exam में accuracy बढ़ाने के लिए हर सवाल की explanation जरूर पढ़ें। 🔗 Related Questions What is 'regression testing' and what risk does inadequ... What is a 'test oracle' and what is the 'oracle problem... What is 'software quality assurance' (SQA) and how does... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
208 Question 208 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 चलाएँ; हर रात पूरा सुइट चलाएँ। जोखिम-आधारित चयन (कोड परिवर्तन कवरेज का उपयोग करके परीक्षण चयन) दोष का पता लगाने को बनाए रखते हुए अनावश्यक परीक्षण निष्पादन को कम करता है। 🎯 Exam Perspective Software Engineering ("Software Testing" sub-topic) के इस प्रश्न को — difficulty level "Easy" कई प्रतियोगी परीक्षाओं जैसे Railway, SSC, Banking और Defence परीक्षाओं में repeat होते देखा गया है। Concept clarity के लिए explanation section जरूर पढ़ें। 🔗 Related Questions In a Waterfall project, what does Acceptance Testing pr... What is 'statistical process control' (SPC) applied to... What is a 'test oracle' and what is the 'oracle problem... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
209 Question 209 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σ) वाले नियंत्रण चार्ट सांख्यिकीय रूप से इसका उत्तर देते हैं। नियंत्रण सीमा से बाहर के बिंदु जांच की आवश्यकता वाले विशेष कारणों (नए डेवलपर, नए कोडबेस क्षेत्र, प्रक्रिया परिवर्तन) का संकेत देते हैं। यह गुणवत्ता प्रबंधन को सहजता से साक्ष्य-आधारित निर्णय लेने में बदल देता है। 🎯 Exam Perspective यह सवाल Software Engineering ("Software Testing" sub-topic) category का है — difficulty level "Easy", और SSC, Railway, Banking और State PCS के exam pattern में इस तरह के questions common हैं। Answer choose करने के बाद दिया गया explanation जरूर पढ़ें। 🔗 Related Questions What is 'equivalence partitioning' and how does it redu... In Waterfall, what is the 'integration testing' phase s... What is 'regression testing' and what risk does inadequ... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
210 Question 210 EN + हिं Medium GB What is 'software quality assurance' (SQA) and how does it differ from software testing? IN 'सॉफ़्टवेयर गुणवत्ता आश्वासन' (SQA) क्या है और यह सॉफ़्टवेयर परीक्षण से किस प्रकार भिन्न है? A SQA and software testing are synonymous terms describing the same activity SQA और सॉफ़्टवेयर परीक्षण एक ही गतिविधि का वर्णन करने वाले पर्यायवाची शब्द हैं B SQA is a systematic, planned set of actions ensuring the software development process is followed correctly; testing is a subset of SQA that verifies the product — SQA audits the process, testing evaluates the product एसक्यूए कार्यों का एक व्यवस्थित, नियोजित सेट है जो यह सुनिश्चित करता है कि सॉफ्टवेयर विकास प्रक्रिया का सही ढंग से पालन किया जाए; परीक्षण SQA का एक उपसमूह है जो उत्पाद का सत्यापन करता है - SQA प्रक्रिया का ऑडिट करता है, परीक्षण उत्पाद का मूल्यांकन करता है C SQA only applies to the final product release; testing applies throughout development SQA केवल अंतिम उत्पाद रिलीज़ पर लागू होता है; परीक्षण पूरे विकास में लागू होता है D SQA is performed by an external auditing agency; testing by the internal development team SQA एक बाहरी ऑडिटिंग एजेंसी द्वारा किया जाता है; आंतरिक विकास टीम द्वारा परीक्षण ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) SQA (IEEE 730) encompasses process adherence: are reviews being conducted? Are standards followed? Are change management procedures applied? Testing is product-focused: does this build pass its test suite? SQA would catch 'the team skipped design reviews' — a process defect. Testing would catch 'this function returns wrong results' — a product defect. Both are needed. व्याख्या (हिन्दी) SQA (IEEE 730) में प्रक्रिया का पालन शामिल है: क्या समीक्षाएँ की जा रही हैं? क्या मानकों का पालन किया जाता है? क्या परिवर्तन प्रबंधन प्रक्रियाएँ लागू की गई हैं? परीक्षण उत्पाद-केंद्रित है: क्या यह बिल्ड अपना परीक्षण सूट पास करता है? SQA 'टीम द्वारा डिज़ाइन समीक्षाएँ छोड़े जाने' को पकड़ लेगा - एक प्रक्रिया दोष। परीक्षण से पता चलेगा कि 'यह फ़ंक्शन गलत परिणाम देता है' - एक उत्पाद दोष। दोनों की जरूरत है. 🎯 Exam Perspective यह प्रश्न Software Engineering ("Software Testing" sub-topic) की तैयारी करने वाले अभ्यर्थियों के लिए उपयोगी है — difficulty level "Medium"। इस तरह के प्रश्न अक्सर Railway, SSC, Banking और Defence परीक्षाओं जैसी परीक्षाओं में पूछे जाते रहे हैं, इसलिए concept और explanation दोनों को ध्यान से समझें, सिर्फ उत्तर याद न करें। 🔗 Related Questions What is 'statistical process control' (SPC) applied to... In Waterfall, what is the 'integration testing' phase s... What is 'regression testing' and what risk does inadequ... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)