Software Testing and Quality Control

Scrum has five events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. 'Product Review' is not a formal Scrum event - the correct term is Sprint Review.

The Product Owner is solely responsible for managing the Product Backlog in Scrum. They own, prioritize, and ensure the Product Backlog is visible, transparent, and clear to the Scrum Team.

The five phases of test management in HP Quality Center are: (1) Specify Releases - define release cycles, (2) Specify Requirements - document what needs to be tested, (3) Plan Tests - design test cases, (4) Execute Tests - run the tests, and (5) Track Defects - log and manage bugs. 'Run Tests' is redundant with 'Execute Tests', and 'Analyze Tests' is not one of the core five phases.

HP ALM or Quality Center allows users to attach files, such as screenshots or logs, to entities like requirements, tests, and defects throughout the testing lifecycle.

Quality Center includes traceability and notification engines that automatically alert linked entities and responsible users when requirements, tests, or defects are modified.

The requirement is unclear because 'at least 500 dollers' [sic] is ambiguous - it could mean exactly 500, 500 minimum, or more. It doesn't specify if higher amounts are allowed or if there's a maximum. The supported cards list (American Express, Visa, Japan Credit Bank, Eurocard, Master Card) is explicit and unambiguous. There's no indication of performance or usability issues in this paragraph.

In a sequential lifecycle model, the earliest artifact available for static analysis is the requirements specification document. Grammatical analysis (checking for completeness, consistency, ambiguity) can be applied immediately after requirements are written. Performance simulation, security analysis, and unit testing all require designs or code to exist first, which come later in the sequential model.

Set-Use pairs are fundamental to data flow analysis, which tracks how variables are assigned (set) and subsequently used (referenced) through a program. This analysis identifies potential defects like using uninitialized variables, variables used after being freed, or redundant computations. Control flow analysis examines execution paths, coding standards check style, and cyclomatic complexity measures structural complexity.

Use cases focus on user interactions and typical workflows through the system. They are designed to capture how actors accomplish their goals step-by-step, making them ideal for identifying workflow-related defects. Boundary value analysis handles large/small values, configuration testing handles combinations, and equivalence partitioning handles input classes - these are different testing techniques.

A test case is formally defined as a set of inputs, execution preconditions, and expected outcomes. This definition captures the essential elements: what you put into the system (inputs), what state the system must be in (preconditions), and what should happen (expected outcomes). Option A is incomplete, while options C and D include elements not part of the standard test case definition.

Static testing is the practice of testing software without executing the code. This includes reviews, inspections, walkthroughs, and static analysis tools. Options A and D refer to types of dynamic testing (where code runs), while option B (white-box testing) requires code execution to examine internal structure.

Acceptance testing's primary goal is to establish confidence that the system meets business requirements and is ready for deployment. It is typically performed by users or customers, not technical staff (making C wrong). Option A is incorrect because stress testing is a separate performance testing activity. Option D is wrong because acceptance testing addresses both functional and non-functional requirements.

A Test Harness is a tool that provides stubs, drivers, or mock objects to simulate missing components, allowing unit tests to run in isolation when dependent components are unavailable. Options A, B, and C describe different tools (comparison tools, coverage analyzers, peer review systems) not specific to test harnesses.

To answer this question, the user needs to know what a test case is and its elements. A test case is a set of steps or conditions that are used to test a specific aspect of a software program. It includes a set of inputs, execution preconditions, and expected outcomes.

Now, let's go through each option and explain why it is right or wrong:

A. A test environment description and test instructions: This option is incorrect. While a test case may include test instructions, it is not limited to only that. A test environment description is not an essential element of a test case.

B. A set of inputs, execution preconditions, and expected outcomes: This option is correct. A test case includes a set of inputs, execution preconditions, and expected outcomes. Inputs are the data that is entered into the system as part of the test case, execution preconditions are the conditions that must be met before the test case can be run, and expected outcomes are the results that are expected from the test case.

C. A test plan, test inputs, and logging instructions: This option is incorrect. A test case is a part of a test plan, but it is not the test plan itself. The test inputs are an essential element of a test case, but logging instructions are not necessary.

D. Execution instructions and a function description to determine correct outcome: This option is incorrect. While execution instructions are a part of a test case, they are not the only element. A function description to determine the correct outcome is not a necessary part of a test case.

Therefore, the answer is: B. A set of inputs, execution preconditions, and expected outcomes.

Configuration management provides unique identification and version control for all documents and software items, allowing the test group to reference them unambiguously. This ensures everyone is working with the correct version. Options A, B, and D are important practices but don't directly address unambiguous referencing.