Software Testing Fundamentals

White-box testing (also called glass-box, clear-box, or structural testing) examines the internal structure, design, and coding of software. It requires the tester to have knowledge of the internal code and logic to design test cases that exercise different paths, branches, and conditions within the module. This is in contrast to black-box testing, which focuses on inputs and outputs without knowledge of internal code.

Verification is the process of checking that we are building the system right - meaning it meets the specified requirements and technical specifications. It answers the question: Are we building the product correctly? This is different from validation, which checks that we are building the right system (whether it meets user needs and expectations).

State Transition testing is a black-box testing technique that models system behavior as states and transitions between them. It focuses on the system's external behavior rather than internal code structure. In contrast, Path Testing, Data flow testing, and Statement testing are all white-box techniques that require knowledge of the internal code logic and structure.

Smoke Testing (also called build verification testing) is performed to verify that the most critical functions of an application work properly without failing, ensuring the build is stable enough for further detailed testing. It acts as a preliminary check to decide whether to proceed with more comprehensive testing. Sanity Testing is similar but focuses on a specific functional area after a regression.

The two main techniques in Black-box testing are Equivalence Partitioning and Boundary Value Analysis. Equivalence Partitioning divides input data into groups expected to be treated similarly, while Boundary Value Analysis focuses on testing at the boundaries between these partitions. These are foundational black-box testing methods.

Defect Clustering and Pesticide Paradox are both established principles of testing. Defect Clustering states that a small number of modules contain most defects, while Pesticide Paradox observes that repeating the same tests eventually becomes ineffective as they stop finding new defects. Since both are valid principles, option C (Both 1 & 2) is incorrect, making D (None) the correct answer.

Cyclomatic complexity is a metric that quantifies the number of independent paths through a program's source code. It is calculated using control flow graph analysis and helps determine the minimum number of test cases needed for complete path coverage. Higher complexity indicates more potential execution paths and potentially greater maintenance difficulty.

WinRunner, QTP (QuickTest Professional), and RFT (Rational Functional Tester) are all functional testing tools used for automated testing of applications. QC (Quality Center), now known as ALM (Application Lifecycle Management), is a test management tool used for managing the testing process, not for executing functional tests. This makes QC the correct answer as the non-functional tool.

All listed checkpoint types are valid in QTP: Standard Checkpoint verifies object properties, Text Checkpoint verifies text content, and Text Area Checkpoint verifies text in a specific area. Therefore 'None of the above' correctly indicates that all listed options ARE valid check points.

Low level recording in QTP provides three key benefits: it enables recording on any object regardless of QTP's recognition capability, operates at the object level rather than coordinate-based, and is specifically designed for situations where objects are not recognized by QTP's standard object recognition.

Synchronization points in QTP are designed to wait until a particular object property achieves a specified value, enabling more precise synchronization than fixed time delays. While waiting for specified time is possible, the primary purpose and advantage is waiting for object state changes.

Object Spy is a QTP diagnostic tool that allows viewing the supported properties, methods, and operations of any object in an open application. It's used for inspection and understanding object structure, not for defining actions, naming objects, or deleting from repository.

Reusable actions can be invoked multiple times within a test and from other tests, promoting modularity. They cannot be merely copied as independent actions nor are they uncallable; thus the other statements are false.

In software testing terminology, a 'Failure' is the deviation from specified or expected behavior that is visible to end-users. An error or mistake refers to the human action that caused the issue, a fault or defect is the imperfection in the code, but the observable incorrect behavior is called a failure.

A failure is the observable incorrect behavior that users see. A fault is the defect in the code that causes failures. An error is a human mistake that may introduce faults. A defect is similar to a fault, a flaw in the code. The distinction: error leads to fault leads to failure.

Beta testing involves customers using the software in their own environment with real data, unlike alpha testing which is conducted at the developer's site by internal staff. Independent test teams perform testing at various stages, and early lifecycle testing is a strategy not specific to beta testing.

A test incident report documents the problem: what happened, not how to solve it. Essential elements include reproduction steps (B), test environment details (C), severity/priority (D), and actual vs expected results (E). The solution (how to fix) is a developer task determined during debugging, not part of the incident report.

Static testing examines artifacts without running the software: walkthroughs, inspections, and data flow analysis are examples. Error guessing involves designing and executing test cases based on intuition about where defects might exist, making it a dynamic testing technique that requires running the software.

When users find faults, it indicates both quality issues in the software (faults exist) and gaps in the testing process (they weren't caught before release). Insufficient time (D) can contribute to poor testing, but poor quality software (A) alone doesn't explain why users found them: testing should have caught them. Bad luck (C) is not a systematic cause.

A review moderator facilitates the discussion, manages conflict, and ensures the review process stays focused and productive. Taking minutes is typically done by a scribe/recorder, not the moderator. The moderator doesn't handle external interruptions like phone calls, and doesn't write the documents being reviewed.