Software Testing Fundamentals

Static analysis tools examine source code without running it, allowing them to detect structural issues like unreachable code, undeclared variables, or insufficient comments. However, they cannot evaluate whether the program meets business needs, meaning faults in requirements can only be identified through dynamic testing or manual reviews.

The equivalence partitions are: below 18 (heating on), 18-21 (no change needed), and above 21 (heating off). Valid partitions are <18, 18-21, >21. To cover all valid partitions with minimum values: pick one from each partition - 15 (<18), 19 (18-21), and 25 (>21). This set of three values validates each equivalence class.

Boundary value analysis tests at boundaries and just beyond them. For postal rates at 10, 50, 75, and 100 grams, we need values at each boundary: 0 and 1 (below 10), 10 and 11 (at/beyond 10), 50 and 51 (at/beyond 50), 75 and 76 (at/beyond 75), 100 and 101 (at/beyond 100). Option C covers all 11 critical test points.

Independent testing involves testers who are separate from the development team, reducing confirmation bias and promoting objectivity. In contrast, unit testing is typically performed by the original developers who may overlook their own mistakes. System and destructive testing define scope and approach rather than organizational independence.

Structure-based (white-box) coverage includes: decision outcomes (branch coverage), conditions within decisions (condition coverage), and statements executed (statement coverage). Partitions and boundaries are black-box (equivalence partitioning and boundary value analysis) concepts, not white-box. Therefore V (decision outcomes), Y (conditions), and Z (statements) are the correct white-box measures.

To understand this question, the user needs to know the basic concepts of test automation and the common scripting techniques.

Data-driven testing is a technique that uses data from external sources (such as spreadsheets or databases) to drive test execution. Keyword-driven testing is a technique that uses a set of keywords or actions to define test steps. Capture-driven and keyhole-driven are not commonly used scripting techniques in test automation. Playback-driven is a term that refers to the ability of a tool to record user actions and then play them back as a test script. However, it is not an advanced scripting technique.

Therefore, the correct answer is:

The Answer is: A. Data-driven and keyword-driven.

Test Planning and Control is indeed one of the fundamental activities in the test process according to ISTQB. The fundamental test process consists of planning and control, analysis and design, implementation and execution, evaluating exit criteria and reporting, and closure. Option A incorrectly says 'Planning and Design' which are separate phases. Option B incorrectly says 'Analysis and Control' - analysis is separate from planning/control. Option D has a typo ('reoprting') but also incorrectly names a phase.

Designing tests early in the lifecycle helps prevent defects from being introduced into code. This is because test identification makes requirements testable and clarifies expectations before coding begins. The other options are incorrect: early test design isn't necessarily cheaper (A), early tests aren't inherently more effective than later tests (C), and while it may save time (D), that's not the MAIN benefit - defect prevention is the primary advantage.

Deriving test cases based solely on the functional specification of a component, without knowledge of its internal structure, is the definition of black-box testing. White-box (or glass-box) testing requires internal code visibility, while experience-based techniques rely on subjective tester expertise rather than specifications.

All three activities - reviews, static analysis, and dynamic testing - share the objective of identifying defects. Reviews find defects in documents, static analysis finds defects in code without executing it, and dynamic testing finds defects by executing the code. Option B is wrong because none of these directly fix defects - fixing is a development activity. Option C is incorrect because fixing isn't their objective.

According to ISTQB risk categorization, poor software characteristics like poor performance, poor usability, or poor security are classified as Product Risks. Product risks are risks that the software will not meet its quality characteristics. Project Risks are different - they're about schedule, budget, resources, and organizational issues. Options A, C, D are incorrect because poor software quality is specifically a product risk, not a project risk.

Debugging is NOT a testing objective - it's a development activity. Testing objectives include: finding defects (A), gaining confidence about quality (B), and preventing defects (C) by designing tests early. Debugging (identifying root cause and fixing) happens after testing finds a defect. Options A, B, C are valid testing objectives.

The correct bug life cycle is Open → Assigned → Fixed → Closed. When a bug is found, it's Open. Then it's Assigned to a developer. After the developer fixes it, it becomes Fixed. After verification/retesting, it's Closed. Options B, C, D are incorrect because they don't follow this logical sequence - you can't Close before Fixed, and you can't Fix before it's Assigned.

Decision Testing is a white-box technique (also called branch testing), not a black-box technique. Black-box techniques include Equivalence Partitioning (A), Boundary Value Analysis, Decision Tables (B), State Transition Testing, and Use Case Testing. Transaction Diagrams (C) are not a standard black-box technique name but may refer to flow-based testing. Decision Testing examines internal code branches and requires knowledge of implementation.

Database testing is comprehensive, covering data validity (correct values and formats), data integrity (relationships, constraints, and referential integrity), performance (optimization and indexing), and programmatic objects (procedures, triggers, and functions). All these aspects are essential for thorough database quality assurance.

Database testing encompasses initialization (setting up test data and schema), functional testing (validating CRUD operations work correctly), and data verification (ensuring data accuracy and consistency). These tasks together form a complete database testing strategy from setup through validation.

DataGenerator and TestDataGenerator are specialized tools for database testing that create realistic test data for validation. While LoadRunner, QTP, WinRunner, and Quality Center are testing tools, they focus on performance, functional, or test management rather than data generation. Data generation is critical for comprehensive database testing.

Query Analyzer tools help monitor, trace, and analyze database queries during testing. They allow testers to verify data loads are executing correctly and efficiently by examining query execution plans, performance metrics, and results.

Data-driven testing enables running the same test with multiple input sets from external sources like data tables. This approach efficiently tests various scenarios by replacing parameters with different values from structured data sources.