Software Testing and Quality Control

Parameterization is the feature of selecting different test data values at run-time. It allows tests to use data-driven inputs from external sources (data tables, Excel, databases) instead of hardcoded values, enabling the same test to run with multiple data sets.

A Recovery Scenario in HP QuickTest Professional (QTP) is designed to handle unpredictable errors and testing exceptions during execution. Standard control statements like Do Loop or IF cannot handle unexpected popups.

Low-Level Recording mode is specifically used when QuickTest cannot recognize an object during recording. It records at the coordinate level. Analog mode is for continuous mouse/keyboard operations, Normal mode is standard recording, and Run Analog is not a recording mode type.

A Reusable Action can be called by other tests or actions in QTP, enabling code modularity and reusability. Call Action is a command, Split Action divides actions, and Called action is not the formal term for this capability.

WaitProperty is the synchronization method that waits for a specific object property to reach a desired value. Synchronize is a general term, Wait introduces a fixed delay, and Pause halts execution without property-based waiting.

Boundary value analysis is a black-box testing technique that focuses on testing at the boundaries, just below, and just above the edges of input and output equivalence classes. It's distinct from equivalence partitioning (A), doesn't test combinations (C), and is not specific to white-box testing (D).

Non-functional testing evaluates system attributes beyond functional behavior. Usability testing assesses user experience and interface design, while Performance testing measures system responsiveness, scalability, and speed under load. Both test quality characteristics rather than specific features.

Capture/Playback tools record manual test interactions and replay them automatically, making them ideal for regression test automation. They capture user actions and test inputs during manual execution, then reproduce them precisely to validate that recent changes haven't broken existing functionality.

Independent Verification & Validation means testing performed by an organization completely separate from the development project. This independence ensures objectivity - the evaluating entity has no stake in the project's outcome and no influence from the development team, providing unbiased quality assessment.

Maintenance testing involves testing a system that has already been released and is operational, after changes or modifications have been made. It ensures that updates, patches, or enhancements haven't introduced defects and that the system continues to function correctly in its production environment.

Beta testing is performed by actual end users at their own locations using their own hardware and data. This distinguishes it from alpha testing, which is conducted at the developer's site by internal teams. Beta testing provides real-world validation before general release.

Re-testing (confirmation testing) is performed to verify that a specific bug has been successfully resolved. Regression testing checks whether recent code modifications have accidentally introduced new faults or broken existing functionality in unmodified areas of the system. Their purposes and scopes are distinct.

The V-model is a software development model that links each development phase with a corresponding testing phase. Its key principle is that modules are validated against user requirements through verification and validation activities. Option B correctly captures this fundamental testing principle.

Testing stops when predetermined completion criteria are met, not when arbitrary fault counts are reached or specific test categories finish. Good test planning defines exit criteria based on risk, coverage, and quality thresholds. Statement coverage alone is insufficient as a stopping criterion.

A test plan typically includes features to be tested, risks, schedule, and scope. Incident reports are outputs of test execution, not inputs to planning. They belong in test summary reports, not the plan itself. The plan documents what will be tested and how, not results from testing.