Software Testing Fundamentals

The Edit menu in QTP/UFT contains all the commands for managing test actions and function library steps. This includes options like cut, copy, paste, delete, and step operations for organizing and modifying test flow and library code. It is the primary menu for structural editing.

In HP QTP/UFT, the "Expand All" option in the View menu recursively expands all steps and nodes in the Keyword View hierarchy. Other options like "Expand" or "Expand Rows" do not perform a full expansion of all levels.

In QTP/UFT (QuickTest Professional / Unified Functional Testing), F7 is the shortcut key to open the Step Generator dialog. F2 opens the object repository, F3 opens the Step Detail pane, and F5 starts/continues the run.

In software testing and quality assurance terminology, 'fault' is the standard synonym for 'defect' - both refer to a flaw in the code that may cause failure. Error (C) typically refers to a human action or mistake that leads to a fault, while mistake (B) is the human action itself. None (D) is incorrect as fault is indeed a valid synonym.

Software testing is often legally mandated or required by contracts and specific standards (e.g., safety-critical system regulations). Thus, the statement is correct, making True the right option and False incorrect since testing is frequently obligatory for compliance.

Quality assurance encompasses multiple activities including maintaining development standards, providing training, and conducting defect analysis. All these elements work together to ensure software quality throughout the development lifecycle.

Deciding when to stop testing must balance risk factors (including technical, safety, and business aspects) alongside project constraints (such as time and budget). Since both elements are essential to the decision, choosing only risk or only constraints is incomplete, making 'both 1 and 2' correct.

Debugging is the process of identifying and fixing defects, which is primarily done by developers who write the code. Testing is the process of evaluating software to find defects, which is primarily done by testers who verify the system from a user perspective. This separation of concerns helps maintain objectivity in testing.

The absence-of-errors fallacy is a fundamental testing principle stating that finding and fixing defects does not guarantee a usable system. A system can be defect-free but still fail to meet user needs or business objectives. Testing is context-dependent, exhaustive testing is impossible, and early testing is actually recommended.

Test analysis and design is the phase where testability is evaluated. During this phase, testers examine the test basis (requirements, specifications) and test objects to determine if they can be effectively tested. This includes checking if the requirements are clear, measurable, and testable.

Test closure activities include checking planned deliverables, archiving testware, and handing over to maintenance. Writing a test summary report is actually part of evaluating exit criteria and reporting, not a test closure activity. The test summary report is created earlier when deciding if testing is complete.

Good relationships between testers and developers depend on professional, objective communication. Writing factual incident reports helps developers understand and fix issues without feeling personally attacked. Understanding managers, identifying workarounds, and promoting quality are all valuable but secondary to clear, objective reporting.

Testing is split into distinct stages primarily because each stage serves a different purpose - unit testing checks individual components, integration testing checks interfaces, system testing checks the whole system, etc. This separation ensures comprehensive coverage.

Regression testing involves re-running many existing tests repeatedly after each code change. Test tools automate this efficiently, saving significant time and effort compared to manual execution. Other testing types like UAT, system testing, and integration testing often require more human judgment and exploratory approaches that benefit less from pure automation.

A requirement is testable if it can be verified through a concrete, measurable test. Specifying that response time must be 'less than one second' under a specific load provides a quantifiable metric, unlike subjective or impossible criteria like 'user friendly' or '0 faults'.

System testing is typically performed by independent test teams (option A is true). Faults found during system testing are indeed expensive to fix because they're caught late in development (option B is true). Functional testing, which tests against requirements, is more commonly used than structural testing in system testing (option D is true). End-users are primarily involved in user acceptance testing, not system testing, making option C the false statement.

Testing is complete when the required level of confidence has been achieved, not when arbitrary conditions are met. Time running out (option A) is a constraint, not a completion criterion. Finding no more faults (option C) is unrealistic and doesn't prove sufficient coverage. Option D is subjective and unmeasurable. Option B is the only criterion based on measurable confidence levels and risk assessment.

The V-model is a systems development lifecycle model that maps testing phases directly to corresponding development phases. It verifies designs early through static techniques and aligns verification (like design reviews) with validation (testing code against specifications).

A test plan includes features to be tested (option A), risks (option C), and schedule (option D) - these are all planning elements. Incident reports (option B) are documents created during test execution when defects are found. They are outputs of the testing process, not inputs to the planning phase.