Software Testing Fundamentals

With limited time, prioritize testing business-critical areas (1) and fault-prone areas (2). Testing easiest functionalities first (3) is poor risk management - it wastes resources on low-risk areas while critical features may remain untested. Risk-based testing prioritizes by business impact and technical risk.

Testing amount should be determined by risk level, contractual obligations, and legal/safety requirements. Test data is what you use during testing, not a factor in deciding how much testing to perform. The volume of test data doesn't drive testing scope - risk and requirements do.

Computer-Aided Software Testing (CAST) tools yield the highest cost savings in test execution because they automate repetitive test run processes. Planning, design, and management still require heavy manual effort and cognitive input.

Testing's primary objectives are finding faults, improving quality, and validating usability/non-functional requirements. Testing evaluates rather than directly improves accuracy - developers fix faults to improve accuracy. Testing identifies issues but is not itself the mechanism that improves software precision.

Software quality attributes include correctness (does it work), usability (ease of use), and reusability (can components be reused). Viability refers to business feasibility/market success - an economic concept outside technical quality dimensions. Quality engineering focuses on technical attributes, not commercial viability.

Incidents merit investigation, but not all require resolution. Some may be duplicates, misunderstandings, or accepted risks. Incidents do occur when expected and actual results differ (B is true). They can be analyzed for test process improvement (C is true), and can be raised against documentation (D is true). Only A is false.

Non-functional testing evaluates system attributes like usability, performance, and reliability rather than specific functionality. Usability testing assesses how easily users can interact with the system, which is a classic non-functional test. Statement coverage and dataflow testing are white-box structural techniques, while cause-effect graphing is a black-box functional test design method.

Specifying expected outcomes before test execution is fundamental to effective testing because it enables objective pass/fail determination and prevents rationalization after seeing actual results. Without predefined expectations, testers cannot confidently judge whether a test passed or failed, making the test ineffective regardless of how easy or fast it is to run.

BS 7925-1 is the British Standard for Software Component Testing Vocabulary. IEEE 802.11 is a Wi-Fi standard, ISO 9001 relates to general quality management systems, and BS 7925-2 defines the actual software component testing standards.

The V-model emphasizes that each testing level validates corresponding development artifacts against requirements. Unit testing validates modules against detailed designs, while system testing validates the integrated system against user/SRs requirements. The model includes verification throughout (not just design), does not prescribe specific test techniques, and maps the entire development lifecycle, not just testing.

Analysis of specifications is an activity performed to design test cases rather than a component of the high-level test plan document itself. The plan typically outlines scope (functions not to be tested), environments, and entry/exit criteria.

Testing stops when defined test completion criteria (like coverage targets or remaining risk limits) are satisfied. Stopping after finding a fixed number of faults, executing all statements, or only prioritizing by severity does not guarantee complete or quality-aligned exit criteria.

Incident Management (tracking and managing defects found) is least important among test management activities compared to estimating test duration, configuration management (version control), and debugging. While necessary, it's more about defect tracking than managing the test process itself. Estimation, configuration control, and debugging are more critical to test management effectiveness.

The most reliable method to estimate re-testing effort is using metrics from previous similar projects - historical data provides objective evidence of typical re-test rates. While discussions with developers (B) can provide context, they're subjective and less reliable. Regression testing time (C) is a constraint, not an estimation method. Historical metrics offer the best statistical basis for estimation.

Regression testing verifies that recent code modifications have not adversely affected existing features. Verifying a fix is confirmation testing, whereas regression testing focuses on side effects and does not strictly require automation or a large number of tests.

To solve this question, the user needs to have knowledge about software testing and the types of testing performed during the software development life cycle.

Now, let's go through each option and explain why it is right or wrong:

A. This option is incorrect because although it is true that a multi-user system may experience field failures, it is not an acceptable risk. All software systems should be designed and tested to handle multiple users accessing the system simultaneously.

B. This option is incorrect because insufficient functional testing may cause defects or issues in the system's functionality. However, a field failure occurring due to multiple users accessing the system is not a functional issue but a non-functional one.

C. This option is correct. A field failure occurring when multiple users access a system indicates that an important non-functional requirement was not specified and tested. Non-functional requirements include performance, usability, security, and reliability. A multi-user system should be designed and tested to handle the expected number of users accessing the system simultaneously.

D. This option is incorrect because it is possible to test against such events prior to release. Load testing and stress testing are types of non-functional testing that can be performed to test a system's performance when multiple users access the system simultaneously.

Therefore, the correct answer is:

The Answer is: C

Integration testing in the large refers to testing the integration of the system with external systems, APIs, or services. This is higher-level integration testing. Option B describes integration testing in the small (component-level integration using stubs/drivers). Option C describes load testing. Option D describes component integration. The key phrase 'in the large' indicates system-to-system integration.

Data flow analysis is a technique used in static code analysis to gather information about the possible set of values calculated at various points in a program, specifically tracking the use of data along execution paths.