Software Testing and Quality Control

C is correct because it specifies a measurable criterion (response time < 1 second) under defined conditions (specified design load), making it verifiable through testing. A is untestable because 'user friendly' is subjective without quantified metrics. B is untestable because proving zero faults is impossible - you can only demonstrate the absence of known faults. D is untestable because 'portable' is not defined with specific platforms or measurable criteria.

D is correct because testing high-risk areas first maximizes the value of testing effort - failures in critical functionality cause the most damage. A is suboptimal because finding many trivial faults is less valuable than finding critical ones. B is incomplete - coverage is meaningless if it doesn't target risk. C is wrong because ease of testing has no correlation with business impact or technical risk.

The statement that is NOT true is D. While end-users are involved in User Acceptance Testing (UAT), system testing itself is typically performed by independent test teams, not end-users. System testing focuses on verifying the system against specifications, while UAT focuses on business fitness. Options A, B, and C are all true: system tests use independent teams, functional (black-box) testing is more common than structural (white-box) testing at this level, and faults found later are indeed expensive to fix.

Testing is complete when the required level of confidence has been achieved (option B). This is the ISTQB principle: you test enough to meet the quality criteria and risk assessment. Option A (time runs out) is pragmatic but not ideal. Option C is impossible - you can never find all faults. Option D is unrealistic - users will always find some faults. The key is testing sufficiently to meet quality standards within constraints.

Stress testing (option C) is not described in unit test standards. Unit testing focuses on individual components and their logic. Syntax testing (A) can apply to code parsing, equivalence partitioning (B) is a black-box technique applicable at unit level, and modified condition/decision coverage (D) is a white-box coverage metric used in unit testing. Stress testing is a system-level non-functional testing technique that tests system behavior under heavy load, not individual units.

Boundary value analysis (option A) is a functional testing technique. It's a black-box test design technique that checks behavior at input/output boundaries. Options B, C, and D are non-functional testing types: usability testing focuses on user experience, performance testing checks speed/scalability, and security testing verifies protection against threats. Functional testing examines 'what' the system does, while non-functional testing examines 'how' the system works.

State transition testing (option D) is NOT a white box technique - it's a black-box technique that tests system states and transitions without looking at internal code. Options A, B, and C are all white-box techniques: statement testing checks executable statements, path testing analyzes execution paths through code, and data flow testing tracks variable usage. White box techniques require code visibility, while state transition testing only requires knowledge of system states.

User requirements (option A) are the best source for expected outcomes in UAT scripts because UAT validates that the system meets business needs from the user's perspective. Actual results (B) are what happens during testing, not what should happen. Program specification (C) and system specification (D) are technical documents that describe implementation, not business requirements. UAT focuses on 'does this solve the user's problem?' not 'does this match the spec?'

Integration testing in the small tests interactions between modules or subsystems (option B). It focuses on interfaces between components after unit testing is complete. Option A describes unit testing, not integration. Option C is incorrect - test components (stubs, drivers) are used, not just live components. Option D describes integration testing in the large (system integration with external systems). 'In the small' means within the application boundary.

Maintenance testing specifically tests a system after changes have been made to it. It triggers when operational systems are modified - patches, updates, configuration changes - to verify functionality is preserved. It is NOT about updating test cases, user acceptance testing, or competitive advantage. The key is testing an already-released system that has been modified.

Testing is split into stages because each stage serves a distinct purpose: unit testing verifies individual components, integration testing checks interfaces, system testing validates the complete system, and UAT confirms business requirements. This is NOT about manageability, different environments, or maximizing stage count. The different purposes (component-level vs system-level vs user-level) are fundamental.

Error guessing supplements formal test design techniques by leveraging tester experience to find defects that formal techniques might miss. It can be used at any testing level where humans design tests, not just UAT. It is repeatable when documented as test cases based on guessed fault scenarios. Option B correctly captures its role as complementary to formal methods.

Testing is complete when the required level of confidence is achieved - this is the only valid completion criterion among the options. Time running out is a practical constraint, not a theoretical one. Finding no more faults is impossible to prove. Users not finding serious faults is a desired outcome but unverifiable beforehand. Confidence level is the professional standard for test completion.

Boundary value analysis is a functional testing technique - it tests the functional behavior at input/output boundaries. Usability testing is non-functional (user experience). Performance testing is non-functional (system behavior under load). Security testing is non-functional (security attributes). While BVA is technically a test design technique, it designs functional tests of boundary conditions.

Static analysis analyzes program code without executing it - examining source code for defects, vulnerabilities, and compliance issues. It does not analyze batch programs (that could be dynamic). It is not about reviewing test plans or using black box testing. Static analysis = examining code statically, as opposed to dynamic analysis which executes code.