Software Testing and QTP Descriptive Programming

Test planning and test execution are separate phases in the software testing lifecycle. Test planning happens first (strategy, resource planning), followed by test execution (running tests). Test reporting and defect management occur after execution, as part of test closure/monitoring and control, making 'none of the above' correct.

A Test Strategy is a high-level document outlining the overall test approach, standards, and test types for a project, rather than a plan for executing an individual test case. The other definitions correctly state that a test plan acts as a contract, lists objectives/risks, and starts during requirements.

Error-based testing aims to prove that specific, common programming mistakes or faults (errors) were not made during code development. It focuses on validating that the programming process avoided these specific bugs, rather than checking the correctness of test execution or validating the bug fixes of a release.

Error guessing is an experience-based technique where testers use intuition to find defects. It's best applied AFTER formal techniques (equivalence partitioning, boundary value analysis, etc.) because these systematic methods provide structured coverage first. Error guessing then catches edge cases formal methods might miss - it's a supplement, not a replacement.

Statement coverage measures lines executed; branch coverage requires testing both branches of each decision; decision coverage is equivalent to branch coverage. 100% branch coverage guarantees 100% statement coverage (ii is True) because executing every branch means executing every statement. Branch and decision coverage are equivalent (iii, iv are True). However, 100% statement coverage doesn't guarantee branch coverage (i, v are False) - you can execute all statements without testing both branches of every if-else.

Acceptance testing verifies that a system meets USER requirements and business needs, not just technical requirements. It's about whether the system delivers value and solves the intended problem from the stakeholder's perspective. A system can meet technical requirements yet fail acceptance testing if it doesn't address actual user needs. The statement is False because it conflates technical requirements with user acceptance.

Regression testing time can be effectively reduced through three key approaches: automation eliminates manual execution overhead, combining test cases reduces redundant setup and teardown, and periodic testing allows critical tests to run on a schedule rather than in every cycle. All three methods are valid and complementary strategies used in practice.

Testing effort is fundamentally driven by product complexity, development process maturity, and desired testing outcomes. Characteristics of reported bugs (severity, frequency, type) are a result of testing, not a factor that determines how much effort is required to plan and execute testing in the first place.

Testing provides stakeholders with information about the quality and risks associated with releasing software, enabling informed risk-based decisions. Option A is incorrect because testing cannot guarantee a system will work after release. Option B partially captures the purpose but is less precise than D. Option C describes a goal of testing but not its main reason - testing informs release decisions rather than just finding bugs.

IEEE829 is the standard for software test documentation, BS7925-1 covers vocabulary for software testing, and BS7925-2 addresses software component testing. IEEE827 is not a testing-related standard - it refers to a different IEEE standard unrelated to software testing practices.

Faults in requirements are the most expensive to fix because they affect all downstream phases - specifications, design, implementation, and testing. The earlier a fault is introduced, the more widespread its impact and the higher the cost to correct it later. Faults in specifications, designs, or code are progressively less expensive to fix than requirements faults.

Standard integration testing strategies include Big-bang (all components at once), Top-down (from highest level down), and Bottom-up (from lowest level up). Design based is not a recognized integration strategy - it describes a design approach rather than an integration testing strategy.

Descriptive programming in QTP has two types: Static (where properties are hardcoded in the script) and Dynamic (where properties are built programmatically at runtime). Both approaches eliminate the need for an object repository. Option B (Tertiary) is not a valid type of descriptive programming.

Inline descriptive programming, where property-value pairs are passed directly to test object methods as strings (e.g., "Title:=Login"), is called Static Descriptive Programming (Static DP). Dynamic DP involves using the Description.Create() object.

When using descriptive programming in QTP/UFT, we can describe all objects in the hierarchy programmatically, or describe the child programmatically while referencing its parent from the Object Repository. Once a child is described programmatically, its descendants must also be programmatically described.

To optimize performance and code readability when a programmatic description is reused, we can assign the description to an object variable or group the statements using a With/End With block. Both options are valid, but as this is a multiple-choice question with multiple 'correct' options, it is marked as ok.

Instantiating a description object using Set Myvar = Description.Create() and adding properties programmatically at runtime is known as dynamic descriptive programming. Static descriptive programming involves writing the property-value pairs directly in the statement inline.

In QTP/UFT, using Description.Create() instantiates a Properties collection object (often referred to as a Description object or Property Object) that dynamically defines object properties. It is not a single property name, a single property value, or a dynamic property itself.

The ChildObjects method in QTP retrieves all child objects within a parent container that match specified description criteria. It returns a collection of objects that can be iterated through programmatically. Property objects are used for defining descriptions, Set assigns object references, and Count returns the number of items.

In QTP's descriptive programming, Index is 0-based, so Index:=1 refers to the second occurrence of a WebEdit object on the page. Index:=0 would be the first WebEdit. This indexing allows selecting specific instances when multiple objects with similar descriptions exist on the same page.