Software Testing Fundamentals

QTP maintains synchronization between Expert View (VBScript code) and Keyword View (table format). Every object and method statement in Expert View has a corresponding row in Keyword View. This bidirectional mapping allows switching between views without losing test logic.

QTP/UFT supports working with multiple function libraries simultaneously during test development and execution. You can open multiple function library files, and the test can call functions from any of the loaded libraries, enabling modular reusable code.

Active Screen captures snapshots of application state during recording. After recording ends, you can still insert additional steps on the objects shown in the Active Screen by selecting the object and choosing to insert steps, checkpoints, or parameterization.

The Active Screen provides direct access to parameterization features (replacing fixed values with parameters) and inserting checkpoints (verification points) on captured objects. This enables enhancing tests without revisiting the application under test.

QTP users can configure the level of Active Screen information saved with each test via Tools Options. Higher levels capture more detailed object properties but increase test storage, while lower levels save space but provide less information for post-recording modifications.

Testing activities, such as test planning, test case design, and requirement analysis, can begin as soon as the software requirements are approved. Waiting for code completion or unit testing delays the testing process unnecessarily.

In a review meeting, a moderator is a person who:

B. Mediates between people.

The role of a moderator in a review meeting is to facilitate and guide the discussion, ensuring that all participants have an opportunity to express their views and that the meeting stays on track. The moderator helps manage any conflicts or disagreements that may arise and ensures that everyone's opinions are heard and considered. Their main responsibility is to create a productive and inclusive environment for the review process.

Options A, C, and D are incorrect:

A. Takes minutes of the meeting: While taking minutes is an important task in many meetings, it is not the primary role of a moderator in a review meeting.

C. Takes telephone calls: This task is unrelated to the role of a moderator in a review meeting. A moderator's focus is on facilitating the discussion and ensuring the meeting's objectives are met.

D. Writes the documents to be reviewed: The responsibility of writing the documents to be reviewed typically falls on the individuals or teams responsible for creating those documents, not the moderator. The moderator's role is to guide the review process, not create the content being reviewed.

Therefore, the correct answer is B. Mediates between people.

In review meetings, the moderator's role is to mediate between people, facilitate discussion, and manage the review process. Taking minutes is the recorder's role. Taking calls is not part of a formal review. Writing documents is the author's responsibility.

Acceptance testing verifies that software meets user requirements and business needs, so test cases are derived directly from Requirements. Design and Code are inputs for earlier testing phases. Decision tables are a test design technique, not the basis for acceptance tests.

Testing scope depends on risk (criticality of failure), contractual obligations (SLAs, penalties), and requirements complexity. It's not objectively measurable or easy to answer. Developer maturity is one factor but not the primary determinant.

Statement coverage verifies that all executable statements are run, but it cannot detect statements that should exist but don't (missing requirements). Unused branches, dead code, and unused statements may still be executed and thus covered by statement coverage.

Code coverage measures how thoroughly tests exercise the codebase, making it a metric for Test Effectiveness. It doesn't directly measure defects found (that's defect density). Trend analysis is a separate use of coverage data. Time spent is an efficiency metric, not effectiveness.

Impact Analysis identifies which parts of the system are affected by a change, enabling teams to determine the scope of regression testing needed. Exit Criteria are defined by test planning. Number of test cases is a planning output, not an impact analysis decision. Tools selection is a separate consideration.

Impact Analysis identifies which parts of the system are affected by a change, enabling teams to determine the scope of regression testing needed. Exit Criteria are defined by test planning. Number of test cases is a planning output, not an impact analysis decision. Tools selection is a separate consideration.

Testing is fundamentally about finding defects (option D). Options A, B, and C describe 'showing that the program works' or 'is defect free' - these are impossible to prove and represent destructive thinking. The correct mindset is that testing can only prove defects exist, not that they don't.

Testing is fundamentally about finding defects (option D). Options A, B, and C describe 'showing that the program works' or 'is defect free' - these are impossible to prove and represent destructive thinking. The correct mindset is that testing can only prove defects exist, not that they don't.

In software testing terminology, a failure is the observable deviation from expected behavior that end-users experience. A fault or defect is the actual bug in the code, while an error refers to the human mistake that led to the fault being introduced.

Branch coverage guarantees statement coverage because executing all branches requires executing all statements in those branches. Decision coverage is equivalent to branch coverage. Statement coverage alone doesn't guarantee branch coverage since you can execute all statements without taking both branches in every conditional.

Memory leaks are a runtime phenomenon that depends on dynamic allocation and deallocation patterns during program execution. Static analysis can detect potential leaks through code inspection but cannot definitively identify actual memory leaks without runtime information. The other options are all detectable through compile-time analysis.

Grinder, Avalanche, and CurlPro are all performance/load testing tools used to test application performance under load. Code Pro is not a performance testing tool - the name suggests it might be a code analysis, quality, or development tool rather than a performance testing utility. Performance tools typically have names indicating load, stress, or performance testing.