Software Testing Fundamentals and Methodologies

Non-functional testing examines quality attributes rather than functional behavior. This includes performance testing (speed, response time), usability testing (user experience), reliability, security, and other '-ilities'. Option A describes functional testing, while options C and D describe functional feature testing.

Early test design prevents fault multiplication (catching requirements issues before implementation), finds faults early when cheaper to fix, and can cause requirement changes based on test insights. Statement ii is false - early faults are LESS expensive to fix. Statement v is situational - early design can reduce total effort despite upfront investment.

For valid equivalence classes and boundaries within 10000-99999: test values should include minimum boundary (10000), a typical value from valid class (50000), and maximum boundary (99999). Option A uses invalid range values (1000, 5000). Option B uses boundary-adjacent invalid values (9999, 100000). Option D lacks a typical value.

Testing completion is risk-based, not based on arbitrary criteria like running all tests, time expiration, or fixing all faults. The decision depends on the acceptable level of residual risk for the system being tested. Options A, B, and C are incomplete approaches that don't consider business risk.

Exhaustive testing (testing all possible inputs and combinations) is impractical and impossible for non-trivial systems - it's NOT a testing principle. Early testing, defect clustering (Pareto principle), and pesticide paradox (repeated tests become less effective) ARE recognized testing principles.

The bug life cycle follows a logical sequence where a bug is first opened/reported, then assigned to a developer, fixed by the developer, and finally closed after verification. Options B, C, and D present incorrect orderings that violate this workflow.

Maintenance testing uses breadth testing for comprehensive coverage across the system and depth testing for thorough examination of affected areas. Retesting and confirmation testing are similar techniques but not the primary methodologies, while sanity testing is a different category altogether.

White box testing examines the internal code structure and implementation details of software, which is why it's alternatively called structural testing. Design-based testing, error guessing, and experience-based techniques are distinct testing approaches.

An equivalence partition groups input values that are expected to produce similar results, so testing one value from the group is sufficient to represent the entire partition. This is the core principle of equivalence partitioning - one value represents the whole range.

Use case test cases are most valuable for uncovering defects in process flows during real-world system usage because they simulate actual user scenarios. The key distinction in the options is between 'real world use' and 'testing use' - real-world usage is where use cases shine.

Test implementation and execution involves creating test suites from test cases, executing them manually or with tools, and comparing actual results with expected results. Designing tests is part of the earlier test design phase, not implementation and execution.

A risk-based approach uses identified risks to determine the test techniques, the depth of testing required, and to prioritize tests to find critical bugs early. Project cost estimation is a project management activity, not a function of testing risks, making statements i, ii, and iii true and iv false.

According to standard ISTQB testing guidelines, designing test specifications, preparing test data, and executing/logging tests are core tasks of a tester. Interacting with tool vendors to leverage tools on the project is typically a test manager's responsibility, making statement i false and statements ii, iii, and iv true.

Static analysis examines source code without executing it, finding issues like unused variables, dead code, and potential array bounds violations. Memory leaks are dynamic runtime anomalies caused by improper allocation/deallocation during execution, which are detected via dynamic testing rather than static analysis.

An alphanumeric field accepts both alphabetic letters and numeric digits. 'Boo01k' is the only option containing a combination of both letters and numbers, making it the only valid representative of the alphanumeric equivalence class. Other options like 'BOOK' and 'Book' consist solely of alphabetic characters.

OAT (Oracle Application Testing) focuses on validating documentation existence and log file creation, but does not include performance testing of the Oracle service from connected entities. This specific performance check falls outside the standard OAT testing scope and requires separate testing tools or methodologies.

System testing produces multiple key documents throughout its lifecycle: a Test Plan outlines the approach, Traceability Matrices map requirements to test cases, and a Test Completion Report summarizes results. All three are standard deliverables from a system testing phase.

At the start of System Testing, the System Test Plan (STP) is prepared. This document defines the scope, approach, resources, and schedule for system-level testing. DTP (Detail Test Plan) comes later for specific test cases, MTP (Master Test Plan) is for overall test strategy across all test levels, and Traceability Matrices are prepared during test planning.

HP Quality Center 9.2 contains 6 main tabs: Dashboard (for overview), Requirements (for requirement management), Test Plan (for test case design), Test Lab (for test execution), Defects (for bug tracking), and one more (typically Analysis or Administration depending on configuration). The 6-tab structure is a characteristic of this version.

Test Plans are the designated tab or section in test management tools where test scripts and test cases are uploaded, organized, and executed. Test tabs typically show test execution status, while Defects tabs track bugs.