Software Testing and Quality Control

Specification-based testing (also called black-box testing) focuses on verifying software functionality against requirements and specifications without examining internal code structure. It tests what the system should do based on documented requirements, user needs, and functional specifications. This contrasts with structure-based (white-box) testing which examines internal implementation.

This statement is True. As established by Edsger Dijkstra's famous principle, software testing can demonstrate the presence of bugs but can never prove their absence. Testing is a sampling technique that shows defects exist under specific test conditions, but provides no guarantee about untested scenarios. Complete confidence in error-free software requires mathematical proof techniques beyond empirical testing.

When updating Test Cases, the editable fields are: Actual ETP values, Re-Run Likely, Test Case Complexity, Regression status, and No. of similar Test Cases. Option A is incomplete (missing Re-Run Likely and Complexity). Option C includes Demand/Release/Stream which are reference fields not typically editable after creation. Option D includes HLSP Name and Stream which are reference fields, not editable update fields.

The full Test Case List Report for a particular Release, Stream, or both can be downloaded from the Estimation Tab. Options A (Demand Tab), B (Summary Tab), and D (Others Tab) are incorrect as the Estimation Tab is specifically designed to provide comprehensive Test Case listings with ETP information.

The correct answer is 'carried out' (option B). This formal phrasal verb means to conduct, perform, or execute a procedure, test, or investigation. 'Taken up' means to begin a new activity or address an issue, 'looked into' means to investigate, and 'run on' means to continue without stopping or to operate on a particular source.

Testing can demonstrate the presence of defects but can never prove their complete absence (Edsger Dijkstra's principle). Even extensive testing cannot guarantee that no errors remain, making 'there are none' the correct completion of the statement.

Beta testing is performed by customers at their own sites using pre-release versions of software. This differs from alpha testing (internal or at developer site) and allows real-world testing in actual customer environments before general release.

In testing terminology, a failure is the observable deviation from specified behavior that end users experience. A fault is the defect in code that causes the failure, an error is the human mistake that introduced the fault, and defect is often used interchangeably with fault.

Testing stops based on risk assessment and business decisions, not arbitrary thresholds like time or test completion. Factors include remaining risk, cost-benefit analysis, deadlines, and acceptable quality level. It's impossible to test everything or find all faults.

Impact analysis is most critical during maintenance testing because it helps identify which parts of the system might be affected by changes or modifications. When maintaining software, you need to understand the ripple effects of changes to ensure existing functionality isn't broken. Unit testing focuses on individual components in isolation, non-functional testing examines quality attributes, and UAT focuses on business requirements - none require impact analysis as extensively as maintenance testing does.

In Oracle Application Integration Architecture (AIA), Enterprise Business Flows (EBFs) are categorized as Process EBFs or Entity EBFs. Orchestration-type flows like TestOrderOrchestrationEBF are Process EBFs, which coordinate business processes across multiple systems.

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.

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.