Software Testing and Quality Control

Explaining test results neutrally is most critical for good tester-developer relationships. Understanding managers' values (A) is useful but secondary. Identifying workarounds (B) helps customers but doesn't directly maintain developer relationships. Neutral communication reduces defensiveness and promotes collaboration, making it the highest priority.

The question asks for a 'test type'. Component testing is a level, not a type. Functional testing and non-functional testing ARE test types. Acceptance testing is a level. Therefore 'Both 2 & 3' (Functional and Non-functional testing) is correct. These are the two main categories of test types based on what is being tested.

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.

In Pega, the New harness is used to initialize and create a new case. Once the case is submitted and created, the user is transitioned to the Perform harness to complete the initial assignment. Review and Confirm harnesses are for read-only viewing or confirmation of completed work, respectively.

In Pega, most activity methods, including Property-Remove, update the system property pxMethodStatus to indicate the success or failure status of the method execution. Property-specific or developer-defined properties like pyPropertyStatus are not automatically updated by system methods.

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.

Test comparator tools are used to compare actual outputs with expected outputs during test execution, making them part of test execution and logging support. They compare files, data, or screens. Option A (performance monitoring) is wrong - that's for load/performance tools. Option B (static testing) is wrong - comparators work on runtime outputs. Option D (management of testing tools) is wrong - comparators aren't meta-tools.

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.

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.

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.