Software Testing Fundamentals

The main difference is leadership: walkthroughs are led by the author, while inspections are led by a trained moderator (option C). Walkthroughs are informal meetings where the author guides peers through the document. Inspections are formal with defined roles - a trained moderator (not the author) leads, participants have specific responsibilities, and defects are systematically recorded. Option D is incorrect - authors can be present in inspections but don't lead them. Inspections are more rigorous and measurable.

Verification involves reviewing artifacts early in the software development life cycle (such as requirements and design documents). Detecting and fixing flaws early prevents these defects from being propagated into dependent downstream phases, which is known as reducing defect multiplication.

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.

Beta testing is performed by customers at their own site on their own hardware - this is its defining characteristic. It is NOT done by an independent test team (that would be internal testing). It is NOT at the developer's site (that's alpha testing). It happens late in lifecycle, not as early as possible. The key is customer testing in their environment.

User-reported faults typically indicate that both the software quality was suboptimal and testing failed to catch defects before release. If testing were comprehensive, most defects would be caught internally. User discovery of defects represents a failure in both development quality and the testing process.

Memory leaks are dynamic runtime phenomena that can only be detected by analyzing program behavior during execution. Dynamic analysis tools, including memory profilers, monitor memory allocation and deallocation patterns to identify leaks. Static techniques like coverage analysis cannot detect memory leaks.

A failure is an external event where the system departs from its specified behavior. An error is a human action (mistake) that produces a defect (fault or bug) in the code, which may subsequently cause a runtime failure.

A walkthrough is led by the author who presents their work to colleagues for feedback, while an inspection is led by a trained moderator who follows a formal process with defined roles. The key difference is leadership: walkthroughs are author-led, inspections are moderator-led. Inspections are more structured and formal.

Black-box techniques test without seeing internal code structure: boundary value analysis, state transition testing, and syntax testing all work from external specifications. LCSAJ (Linear Code Sequence And Jump) is a white-box technique that analyzes internal code paths and control flow.

Early verification catches defects before they propagate through later stages, preventing one defect from causing multiple related defects. When defects are found early, they are cheaper to fix and prevent a multiplier effect. The major benefit is reducing defect multiplication across the lifecycle.

User Acceptance Testing validates that the system meets actual user needs and expectations. User requirements document what users actually need from the system, making them the correct source for expected outcomes. Program and system specifications focus on technical implementation rather than user needs.

Data flow analysis tracks how data values are used and transformed along execution paths through the code. It examines definitions and uses of variables on different paths, identifying potential anomalies like undefined variables or unused computations. It does not study communications bottlenecks, rate of change, or intrinsic complexity.

A testable requirement must be measurable and objective with clear pass/fail criteria. Response time under one second for a specified load is quantifiable and can be verified through performance testing. User friendliness is subjective, zero faults is impossible to prove, and portability is too vague to measure directly.

Risk-based testing prioritizes areas where failure would have the most severe impact on users or the business. High-risk areas include safety-critical functions, financial calculations, security features, and core business logic. Finding many faults in low-risk features is less valuable than finding critical faults in high-risk areas.